Rede de sobreposição CNI (Container Networking Interface) do Azure

Com a Sobreposição CNI do Azure, os nós de cluster são implantados em uma sub-rede da Rede Virtual do Azure (VNet). Os pods recebem endereços IP de um CIDR privado logicamente diferente da VNet que hospeda os nós. O tráfego de pod e nó dentro do cluster usa uma rede de sobreposição. Network Address Translation (NAT) usa o endereço IP do nó para alcançar recursos fora do cluster. Essa solução salva uma quantidade significativa de endereços IP de rede virtual e permite dimensionar o cluster para tamanhos grandes. Uma vantagem extra é que você pode reutilizar o CIDR privado em diferentes clusters AKS, o que estende o espaço IP disponível para aplicativos em contêineres no Serviço Kubernetes do Azure (AKS).

Visão geral da rede de sobreposição

Na rede de sobreposição, apenas os nós de cluster do Kubernetes recebem IPs de sub-redes. Os pods recebem IPs de um CIDR privado fornecido no momento da criação do cluster. A cada nó é atribuído um /24 espaço de endereço esculpido a partir do mesmo CIDR. Os nós extras criados quando você dimensiona um cluster recebem /24 automaticamente espaços de endereço do mesmo CIDR. O Azure CNI atribui IPs a pods a partir deste /24 espaço.

Um domínio de roteamento separado é criado na pilha de Rede do Azure para o espaço CIDR privado do pod, que cria uma rede de sobreposição para comunicação direta entre pods. Não há necessidade de provisionar rotas personalizadas na sub-rede do cluster ou usar um método de encapsulamento para encapsular o tráfego entre pods, o que fornece desempenho de conectividade entre pods no mesmo nível das VMs em uma VNet. As cargas de trabalho em execução dentro dos pods nem sequer estão cientes de que a manipulação de endereços de rede está acontecendo.

A comunicação com pontos de extremidade fora do cluster, como VNets locais e emparelhadas, acontece usando o IP do nó por meio de NAT. O Azure CNI traduz o IP de origem (IP de sobreposição do pod) do tráfego para o endereço IP primário da VM, o que permite que a pilha de Rede do Azure roteie o tráfego para o destino. Os pontos de extremidade fora do cluster não podem se conectar diretamente a um pod. Você precisa publicar o aplicativo do pod como um serviço de balanceador de carga do Kubernetes para torná-lo acessível na rede virtual.

Você pode fornecer conectividade de saída (saída) à Internet para pods de sobreposição usando um balanceador de carga SKU padrão ou um gateway NAT gerenciado. Você também pode controlar o tráfego de saída direcionando-o para um firewall usando Rotas Definidas pelo Usuário na sub-rede do cluster.

Você pode configurar a conectividade de entrada para o cluster usando um controlador de entrada, como o roteamento de aplicativos Nginx ou HTTP. Não é possível configurar a conectividade de entrada usando o Gateway de Aplicativo do Azure. Para obter detalhes, consulte Limitações com a sobreposição CNI do Azure.

Diferenças entre kubenet e Azure CNI Overlay

A tabela a seguir fornece uma comparação detalhada entre kubenet e Azure CNI Overlay:

Área	Sobreposição do Azure CNI	Kubenet
Escala de cluster	5000 nós e 250 pods/nó	400 nós e 250 pods/nó
Configuração de rede	Simples - sem configurações extras necessárias para rede pod	Complexo - requer tabelas de rotas e UDRs na sub-rede do cluster para rede pod
Desempenho de conectividade do pod	Desempenho em pé de igualdade com VMs em uma VNet	Salto extra adiciona latência menor
Políticas de rede do Kubernetes	Políticas de Rede do Azure, Calico, Cilium	Calico
Plataformas de SO suportadas	Linux e Windows Server 2022, 2019	Apenas Linux

Planeamento de endereços IP

Nós do cluster

Ao configurar seu cluster AKS, certifique-se de que suas sub-redes VNet tenham espaço suficiente para crescer para dimensionamento futuro. Você pode atribuir cada pool de nós a uma sub-rede dedicada.

Uma /24 sub-rede pode acomodar até 251 nós, uma vez que os três primeiros endereços IP são reservados para tarefas de gerenciamento.

Pods

A solução de sobreposição atribui um /24 espaço de endereço para pods em cada nó do CIDR privado especificado durante a criação do cluster. O /24 tamanho é fixo e não pode ser aumentado ou diminuído. Você pode executar até 250 pods em um nó.

Ao planejar o espaço de endereço IP para pods, considere os seguintes fatores:

• Certifique-se de que o CIDR privado seja grande o suficiente para fornecer /24 espaços de endereço para novos nós para suportar a expansão futura do cluster.
• O mesmo espaço CIDR pod pode ser usado em vários clusters AKS independentes na mesma VNet.
• O espaço CIDR do pod não deve se sobrepor ao intervalo de sub-rede do cluster.
• O espaço CIDR do pod não deve se sobrepor a redes conectadas diretamente (como emparelhamento VNet, Rota Expressa ou VPN). Se o tráfego externo tiver IPs de origem no intervalo podCIDR, ele precisará de conversão para um IP não sobreposto via SNAT para se comunicar com o cluster.

Intervalo de endereços do serviço Kubernetes

O tamanho do CIDR de endereço de serviço depende do número de serviços de cluster que você planeja criar. Deve ser menor que /12. Esse intervalo não deve se sobrepor ao intervalo CIDR do pod, ao intervalo de sub-rede do cluster e ao intervalo de IP usados em redes virtuais emparelhadas e redes locais.

Endereço IP do serviço DNS do Kubernetes

Esse endereço IP está dentro do intervalo de endereços de serviço do Kubernetes usado pela descoberta do serviço de cluster. Não use o primeiro endereço IP no seu intervalo de endereços, pois esse endereço é usado para o kubernetes.default.svc.cluster.local endereço.

Grupos de segurança de rede

O tráfego de pod para pod com a sobreposição CNI do Azure não é encapsulado e as regras do grupo de segurança de rede de sub-rede são aplicadas. Se a sub-rede NSG contiver regras de negação que possam afetar o tráfego CIDR do pod, certifique-se de que as seguintes regras estejam em vigor para garantir a funcionalidade adequada do cluster (além de todos os requisitos de saída do AKS):

• Tráfego do nó CIDR para o nó CIDR em todas as portas e protocolos
• Tráfego do nó CIDR para o pod CIDR em todas as portas e protocolos (necessário para roteamento de tráfego de serviço)
• Tráfego do pod CIDR para o pod CIDR em todas as portas e protocolos (necessário para pod to pod e pod para tráfego de serviço, incluindo DNS)

O tráfego de um pod para qualquer destino fora do bloco CIDR do pod utiliza o SNAT para definir o IP de origem para o IP do nó onde o pod é executado.

Se desejar restringir o tráfego entre cargas de trabalho no cluster, recomendamos o uso de diretivas de rede.

Pods máximos por nó

Você pode configurar o número máximo de pods por nó no momento da criação do cluster ou ao adicionar um novo pool de nós. O valor padrão e máximo para a Sobreposição CNI do Azure é 250., e o valor mínimo é 10. O valor máximo de pods por nó configurado durante a criação de um pool de nós aplica-se apenas aos nós desse pool de nós.

Escolher um modelo de rede a utilizar

O Azure CNI oferece duas opções de endereçamento IP para pods: A configuração tradicional que atribui IPs VNet a pods e rede de sobreposição. A escolha de qual opção usar para seu cluster AKS é um equilíbrio entre flexibilidade e necessidades de configuração avançada. As considerações a seguir ajudam a descrever quando cada modelo de rede pode ser o mais apropriado.

Use a rede de sobreposição quando:

• Você gostaria de dimensionar para um grande número de pods, mas tem espaço de endereço IP limitado em sua rede virtual.
• A maior parte da comunicação do pod está dentro do cluster.
• Você não precisa de recursos avançados do AKS, como nós virtuais.

Use a opção VNet tradicional quando:

• Você tem espaço de endereço IP disponível.
• A maior parte da comunicação do pod é para recursos fora do cluster.
• Os recursos fora do cluster precisam alcançar os pods diretamente.
• Você precisa de recursos avançados do AKS, como nós virtuais.

Limitações com a sobreposição CNI do Azure

A sobreposição CNI do Azure tem as seguintes limitações:

• Não é possível usar o Application Gateway como um controlador de entrada (AGIC).
• Não há suporte para Conjuntos de Disponibilidade de Máquina Virtual (VMAS).
• Não é possível usar máquinas virtuais da série DCsv2 em pools de nós. Para atender aos requisitos de computação confidencial, considere usar VMs confidenciais das séries DCasv5 ou DCadsv5.
• Se você estiver usando sua própria sub-rede para implantar o cluster, os nomes da sub-rede, da rede virtual e do grupo de recursos que contém a rede virtual deverão ter 63 caracteres ou menos. Esses nomes serão usados como rótulos nos nós de trabalho do AKS e estão sujeitos às regras de sintaxe de rótulos do Kubernetes.