Странности службы Azure Kubernetes с виртуальной сетью (CNI)

Question

У меня возникли проблемы с подключением модулей/контейнеров AKS к нашей локальной сети.

У меня есть виртуальная сеть в пространствах имен 172.16.20.0/22и 172.16.24.0/29. У них есть 2 подсети, каждая из которых имеет один из вышеуказанных диапазонов в качестве своего диапазона подсети.

Кластер AKS привязан к 172.16.20.0/22подсети, и каждый из узлов, а также pod'ы получают IP-адрес в этом диапазоне. Я также добавил обычную виртуальную машину в эту подсеть для временной отладки.

В 172.16.24.0/29подсети у нас есть шлюз виртуальной сети (у него нет IP в этой подсети), который соединяет эту подсеть с нашей локальной сетью. Шлюз виртуальной сети имеет соответствующий шлюз локальной сети с адресным пространством 172.17.151.0/24. В нашей локальной сети у нас есть сервер SMTP на 172.17.151.254, прослушивающий порт 25.

На виртуальной машине, которую я развернул для отладки, я могу нормально подключиться к SMTP-серверу. Я также могу без проблем пинговать виртуальную машину с SMTP-сервера. Однако из модулей я не могу подключиться к SMTP (проверено с помощью netcat -zv 172.17.151.254 25), и я не могу пинговать IP-адрес модуля с SMTP-сервера.

Ни одна из подсетей не имеет прикрепленной группы безопасности сети (NSG), поэтому это не может быть неправильно настроенное правило NSG. Что еще может быть причиной сбоя соединения? Модули получают одну и ту же базовую конфигурацию сети от DHCP-сервера в подсети:

• IP-адрес 172.16.20.0/22
• 172.16.20.1 в качестве шлюза по умолчанию

Наши ИТ-специалисты, которые обслуживают локальное устройство, подключающееся к Azure VNG, помогли мне с отладкой. Они говорят, что при инициировании SMTP-подключения 172.17.151.254они видят прибывающий пакет и ответный пакет с сервера, возвращающийся в VPN-туннель, так что, похоже, ответный пакет теряется где-то в Azure.
Редактировать: во время дальнейшего сеанса отладки с нашими ИТ-специалистами мы заметили, что исходный IP-адрес пакетов, поступающих из нашего некорректно работающего модуля, — 172.17.20.5, а не 172.16.20.21. 172.17.20.5— это IP-адрес узла VMSS, на котором работает модуль, так что это может иметь смысл, но это будет означать, что внутренняя маршрутизация на этом узле настроена неправильно.

Или это какая-то особенность Kubernetes, которая приводит к сбою?

Что я уже попробовал:

• На виртуальной машине: ping к 172.16.20.21(pod): работает нормально
• На виртуальной машине: ping до 172.17.151.254: работает нормально
• На виртуальной машине: tracert 172.17.151.254успешно за 1 переход (разве не должно быть показано как минимум 2 перехода при прохождении через шлюз по умолчанию?)
• На поде: пинг на 172.16.20.4(vm): работает нормально
• На модуле: пинг до 172.17.151.254: не удается
• На поде: traceroute 172.17.151.254происходит сбой, переходы не отображаются
• На локальном VPN-устройстве: ping на 172.16.20.4(vm): работает нормально
• На локальном VPN-устройстве: ping к 172.16.20.21(pod): не удается

Дополнительная информация:

ifconfig -aиз стручка:

eth0: flags=67<UP,BROADCAST,RUNNING>  mtu 1500
        inet 172.16.20.21  netmask 255.255.252.0  broadcast 0.0.0.0
        ether de:c7:74:e3:c5:24  txqueuelen 1000  (Ethernet)
        RX packets 386868  bytes 35746728 (34.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 511891  bytes 43865660 (41.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 5  bytes 504 (504.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 504 (504.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

routeвывод из pod:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.16.20.1     0.0.0.0         UG    0      0        0 eth0
172.16.20.0     0.0.0.0         255.255.252.0   U     0      0        0 eth0

ipconfig /allиз отладочной виртуальной машины:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : debug-vm
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : nedz0ha4spbubmi5cnxgsnswdh.ax.internal.cloudapp.net

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : nedz0ha4spbubmi5cnxgsnswdh.ax.internal.cloudapp.net
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 00-0D-3A-2D-DC-BA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::e9bb:fede:66cc:398c%6(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.16.20.4(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Lease Obtained. . . . . . . . . . : Friday, August 28, 2020 7:15:08 AM
   Lease Expires . . . . . . . . . . : Friday, October 8, 2156 1:20:49 PM
   Default Gateway . . . . . . . . . : 172.16.20.1
   DHCP Server . . . . . . . . . . . : 168.63.129.16
   DHCPv6 IAID . . . . . . . . . . . : 100666682
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-26-DA-67-54-00-0D-3A-2D-DC-BA
   DNS Servers . . . . . . . . . . . : 168.63.129.16
   NetBIOS over Tcpip. . . . . . . . : Enabled

route printиз отладочной виртуальной машины:

===========================================================================
Interface List
  6...00 0d 3a 2d dc ba ......Microsoft Hyper-V Network Adapter
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      172.16.20.1      172.16.20.4     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
    168.63.129.16  255.255.255.255      172.16.20.1      172.16.20.4     11
  169.254.169.254  255.255.255.255      172.16.20.1      172.16.20.4     11
      172.16.20.0    255.255.252.0         On-link       172.16.20.4    266
      172.16.20.4  255.255.255.255         On-link       172.16.20.4    266
    172.16.23.255  255.255.255.255         On-link       172.16.20.4    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link       172.16.20.4    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link       172.16.20.4    266
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  1    331 ::1/128                  On-link
  6    266 fe80::/64                On-link
  6    266 fe80::e9bb:fede:66cc:398c/128
                                    On-link
  1    331 ff00::/8                 On-link
  6    266 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Answer 1

Проблема была обнаружена после тщательного устранения неполадок с помощью службы поддержки Microsoft.

Первопричиной был IP-адрес сервера SMTP (конечная точка VPN) на 172.17.151.254, он перекрывается с сетью моста docker по умолчанию, 172.17.0.0/16которая была настроена на узлах K8S. Поскольку этот аспект отсутствовал на запущенной мной отладочной виртуальной машине, проблема там не проявилась.

Извлеченный урок: держитесь подальше от стрельбища 172.17.0.0/16при использовании АКС