☰

Estranheza do serviço Azure Kubernetes com rede virtual (CNI)

tag-icon • tag-icon vpn azure kubernetes
Estranheza do serviço Azure Kubernetes com rede virtual (CNI)

Estou tendo alguns problemas para conectar meus pods/contêineres do AKS à nossa rede local.

Eu tenho uma rede virtual nos namespaces 172.16.20.0/22e 172.16.24.0/29. Eles têm 2 sub-redes, cada uma com um dos intervalos acima como intervalo de sub-rede.

O cluster AKS está ligado à 172.16.20.0/22sub-rede, e cada um dos nós, bem como as cápsulas, estão a obter um endereço IP nesse intervalo. Também adicionei uma VM regular a esta sub-rede para depuração temporária.

Na 172.16.24.0/29sub-rede, temos um Gateway de Rede Virtual (não há IP nesta sub-rede) que conecta essa sub-rede à nossa rede local. O gateway VN possui um gateway de rede local correspondente com espaço de endereço 172.17.151.0/24. Em nossa rede local temos um servidor SMTP ligado 172.17.151.254, escutando na porta 25.

Na VM que criei para depuração, posso me conectar perfeitamente ao servidor SMTP. Também posso executar ping na VM do servidor SMTP sem problemas. No entanto, nos pods, não consigo me conectar ao SMTP (testado com netcat -zv 172.17.151.254 25), nem consigo executar ping no endereço IP de um pod no servidor SMTP.

Nem as sub-redes têm um grupo de segurança de rede (NSG) anexado, por isso não pode ser uma regra NSG mal configurada. O que mais poderia estar causando falha na conexão? Os pods obtêm a mesma configuração básica de rede do servidor DHCP na sub-rede:

  • Um endereço IP 172.16.20.0/22
  • 172.16.20.1 como gateway padrão

Nossa equipe de TI que mantém o dispositivo local que está se conectando ao Azure VNG me ajudou a depurar, eles dizem que ao iniciar uma conexão SMTP 172.17.151.254eles veem o pacote chegando e um pacote de resposta do servidor voltando para o túnel VPN, então parece que o pacote de resposta está sendo descartado em algum lugar do Azure.
Editar: durante mais uma sessão de depuração com nossa equipe de TI, percebemos que o IP de origem dos pacotes provenientes de nosso pod com comportamento incorreto é 172.17.20.5, em vez de 172.16.20.21. 172.17.20.5é o IP do nó VMSS em que o pod está sendo executado, então isso pode fazer sentido, mas significaria que o roteamento interno nesse nó não está configurado corretamente.

Ou isso é algo específico do kubernetes que está causando a falha?

O que eu tentei até agora:

  • Na VM: ping para 172.16.20.21(pod): funciona bem
  • Na VM: ping para 172.17.151.254: funciona bem
  • Na VM: tracert 172.17.151.254é bem-sucedido em 1 salto (isso não deveria mostrar pelo menos 2 saltos ao passar pelo gateway padrão?)
  • No pod: ping para 172.16.20.4(vm): funciona bem
  • No pod: ping para 172.17.151.254: falha
  • No pod: traceroute 172.17.151.254falha sem exibição de saltos
  • No dispositivo VPN local: ping para 172.16.20.4(vm): funciona bem
  • No dispositivo VPN local: ping para 172.16.20.21(pod): falha

Informação extra:

ifconfig -ado pod:

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

routesaída do 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 /allda VM de depuração:

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 printda depuração vm:

===========================================================================
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

Responder1

O problema foi encontrado após extensa solução de problemas com a ajuda do suporte da Microsoft.

A causa raiz foi o endereço IP do servidor SMTP (endpoint VPN) em 172.17.151.254, que se sobrepõe à rede docker bridge padrão 172.17.0.0/16configurada nos nós K8S. Como esse aspecto não estava presente na VM de depuração que iniciei, o problema não se manifestou ali.

Lição aprendida: Fique longe do 172.17.0.0/16alcance ao usar AKS

informação relacionada