Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Escolha uma configuração de rede de pods com base na necessidade de os pods terem acesso direto por IP a partir das redes conectadas e nos seus requisitos de escalabilidade de endereços IP.
Você precisa de acesso direto ao IP do pod?
A rede pod controla como os pods obtêm endereços IP e define como os pods se comunicam entre si, nós de cluster e destinos fora do cluster. O Kubernetes implementa a rede de pods por meio de um plug-in CNI (Interface de Rede de Contêiner ), que gerencia endereços IP de pod e conectividade de rede.
Ao configurar a rede de pods, você precisa planejar o IPAM (gerenciamento de endereços IP) e o roteamento e o transporte (plano de dados).
Se suas cargas de trabalho exigirem que os pods sejam acessíveis por meio de IP privado a partir de redes conectadas à VNet do cluster do AKS (Serviço de Kubernetes do Azure), use um modelo de rede plana. Caso contrário, use o Azure CNI Overlay.
Opções de IPAM (gerenciamento de endereço IP)
Ao configurar o IPAM, você pode escolher entre um Modelo de Rede Overlay com Azure CNI Overlay e um Modelo de Rede Plano com Sub-rede de Pod do Azure CNI ou Sub-rede de Nó do Azure CNI:
A tabela a seguir compara as opções de IPAM disponíveis para a rede de pods do AKS, incluindo seus principais recursos e limites de escala.
| Opções de IPAM | Diagrama de componentes de rede | Recursos & funcionalidade |
|---|---|---|
| Modelo de rede de sobreposição (com uso de sobreposição da CNI do Azure) |
|
• Os IPs de pod vêm de um intervalo de sobreposição que não faz parte do espaço da VNet. • Rede altamente escalonável, com até 5.000 nós e 200.000 pods por cluster. Os limites do nó, de pods por nó e agregados de pods são independentes. • O espaço de endereço de sobreposição de pod pode ser reutilizado em clusters independentes. O CIDR do pod não deve se sobrepor a redes conectadas diretamente, incluindo VNets emparelhadas, redes conectadas por meio do ExpressRoute ou de uma VPN e outras rotas que expõem o espaço de endereço privado. • Suporte a pilha dupla (IPv4/IPv6). • Os pods não podem ser acessados diretamente de fora do cluster. |
| Modelo de Rede Simples (com a Sub-rede de Pod CNI do Azure ou a Sub-rede de nó) |
|
• Os IPs de nó e de pod vêm do espaço da VNet. • Os pods podem ser acessados por seus endereços IP privados de redes conectadas. O Azure CNI Pod Subnet preserva o IP de origem do pod entre VNets conectadas, enquanto os destinos fora da VNet do cluster enxergam o IP de origem do nó com o Azure CNI Node Subnet. • As opções de sub-rede do Pod CNI do Azure incluem alocação de IP dinâmico para eficiência ou alocação de bloco estático para escala. |
Considerações sobre opções de Modelo de Rede Simples
Tenha as seguintes considerações em mente ao decidir entre a sub-rede de pod CNI do Azure com alocação de IP dinâmica, a sub-rede de pod CNI do Azure com alocação de bloco estático e a sub-rede de nó CNI do Azure:
| Opção Modelo de Rede Plano | Considerações |
|---|---|
| Sub-rede de pod CNI do Azure com alocação de IP dinâmico | • Requer sub-redes separadas para nós e pods, que você pode dimensionar e escalar independentemente. • Aloca endereços IP dos pods para nós da sub-rede de pods em lotes de 16. • Sujeito aos limites de endereço IP privado configurados pela VNet. |
| Sub-rede de Pod da CNI do Azure com Alocação de Bloco Fixo | • Requer um planejamento cuidadoso, pois você precisa alocar um intervalo específico de IPs para seus pods e garantir que ele não se sobreponha a outras sub-redes. • Pode obter até 1.000.000 IPs. • Os IPs podem não ser usados com eficiência, o que pode levar ao desperdício. |
| Sub-rede de Nó da CNI do Azure | • Opção legada que pode usar uma VNet gerenciada pelo AKS ou uma VNet e uma sub-rede gerenciadas pelo cliente. • Nós e pods compartilham a sub-rede do nó, portanto você precisa planejar com antecedência a capacidade para nós, pods, dimensionamento e atualizações. • Sujeito aos limites de endereço IP privado configurados pela VNet. |
Opções de roteamento e transporte (plano de dados)
Ao configurar o plano de dados, você pode escolher entre Azure CNI alimentado por Cilium, Azure plano de dados iptables e BYO CNI:
A tabela a seguir compara as opções do plano de dados disponíveis para a rede de pods do AKS e seus principais recursos.
| Opções do plano de dados | Recursos & funcionalidade |
|---|---|
| CNI do Azure alimentado por Cilium | • Maior escalabilidade e melhor desempenho para pools de nós do Linux. Pools de nós do Windows não são suportados. • Aplicação integrada de políticas de rede do Cilium. • A filtragem de FQDN requer Serviços Avançados de Rede de Contêiner e Kubernetes 1.29 ou posterior. |
| Azure iptables | • Use o Calico para Windows para aplicação de políticas de rede. O suporte do NPM (Azure Network Policy Manager) termina em 30 de setembro de 2026, para Windows e 30 de setembro de 2028, para Linux. Novas assinaturas não podem mais habilitar Azure NPM. • Para clusters Linux, use Azure CNI alimentado por Cilium em vez de Azure NPM. • Dá suporte ao Kubernetes NetworkPolicy. |
| BYO CNI | • Nenhum plug-in de CNI gerenciado instalado – você pode usar qualquer opção que dê suporte ao AKS. • A Microsoft não dá suporte a problemas relacionados à CNI. |
Recomendações sobre rede para pods no AKS
Nossa recomendação geral é usar Azure CNI Overlay. Se você precisar de acesso direto ao IP do pod a partir de redes conectadas e tiver requisitos de eficiência ou escalabilidade, considere usar Sub-rede de Pods do Azure CNI com Alocação Dinâmica de IP ou Sub-rede de Pods do Azure CNI com Alocação Estática de Blocos. A Sub-rede de nó do Azure CNI é uma opção legada; em geral, use-a apenas caso precise de uma VNet gerenciada pelo AKS para o cluster.