Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Escolha uma configuração de rede dos pods consoante a necessidade de os pods terem acesso IP direto a partir de redes conectadas e os seus requisitos de escala de endereços IP.
Precisas de acesso direto ao IP do pod?
A rede de pods controla como os pods obtêm endereços IP e define como comunicam entre si, com nós de cluster e destinos fora do cluster. O Kubernetes implementa rede pod através de um plugin Container Network Interface (CNI ), que gere endereços IP pod e conectividade de rede.
Ao configurar rede pod, é necessário planear a gestão de endereços IP (IPAM) e o encaminhamento e transporte (plano de dados).
Se as suas cargas de trabalho exigirem que os pods sejam acessíveis por IP privado a partir de redes ligadas ao cluster Azure Kubernetes Service (AKS) VNet, use um Modelo de Rede Plana. Caso contrário, use o Azure CNI Overlay.
Opções de gestão de endereços IP (IPAM)
Ao configurar o IPAM, pode escolher entre um Modelo de Rede Overlay com Azure CNI Overlay e um Modelo de Rede Plana com Azure CNI Pod Subnet ou Azure CNI Node Subnet:
A tabela seguinte compara as opções de IPAM disponíveis para a rede AKS pod, incluindo as suas principais funcionalidades e limites de escala.
| Opções de IPAM | Diagrama dos componentes de rede | Características e funcionalidades |
|---|---|---|
| Modelo de Rede de Sobreposição (com Azure CNI Overlay) |
|
IPs dos pods vêm de um intervalo de sobreposição que não faz parte do espaço VNet. • Redes altamente escaláveis, com até 5.000 nós e 200.000 pods por cluster. Os limites do nó, do pod por nó e do pod agregado são independentes. • O espaço de endereçamento da sobreposição dos pods pode ser reutilizado em clusters independentes. O CIDR pod não deve sobrepor-se a redes diretamente ligadas, incluindo VNets peered, redes ligadas via ExpressRoute ou VPN, e outras rotas que expõem espaço de endereçamento privado. • Suporte dual-stack (IPv4/IPv6). • Os pods não podem ser acessados diretamente de fora do cluster. |
| Modelo de Rede Flat (com Sub-rede do Pod CNI do Azure, ou Sub-rede de Node) |
|
• IPs de nós e pods provêm do espaço VNet. • Os pods podem ser acedidos pelos seus endereços IP privados a partir de redes ligadas. O Azure CNI Pod Subnet preserva o IP de origem do pod em VNets ligadas, enquanto os destinos fora da VNet do cluster veem o endereço IP de origem do nó com o Azure CNI Node Subnet. • As opções Azure CNI Pod Subnet incluem Alocação Dinâmica de IP para eficiência ou Alocação de Blocos Estáticos para escala. |
Considerações para opções de Modelo de Rede Plana
Tenha em mente as seguintes considerações ao decidir entre a Subnet Azure CNI Pod com Alocação Dinâmica de IP, a Subnet Azure CNI Pod com Alocação de Blocos Estáticos e a Subrede de Nó CNI do Azure:
| Opção de Modelo de Rede Plana | Considerações |
|---|---|
| Azure CNI Pod Subnet com Alocação Dinâmica de IP | • Requer sub-redes separadas para nós e pods, que podem ser dimensionadas e escaladas independentemente. • Aloca endereços IP pod aos nós a partir da sub-rede pod em lotes de 16. • Sujeito a limites de endereços IP privados configurados por VNet. |
| Sub-rede de Pods do Azure CNI com Atribuição de Bloco Estático | • Requer um planeamento cuidadoso, pois precisa de alocar um intervalo específico de IPs para os seus pods e garantir que não se sobrepõe a outras sub-redes. • Pode obter até 1.000.000 de IPs. • IPs podem não ser usados de forma tão eficiente, o que pode levar a desperdício. |
| Azure CNI Node Subnet | • Opção herdada que pode usar uma VNet gerida pelo AKS ou uma VNet e uma sub-rede geridas pelo cliente. • Os nós e os pods partilham a sub-rede dos nós, pelo que é necessário planear a capacidade com antecedência para nós, pods, expansão e atualizações. • Sujeito a limites de endereços IP privados configurados por VNet. |
Opções de encaminhamento e transporte (plano de dados)
Ao configurar o seu data plane, pode escolher entre Azure CNI Powered by Cilium, Azure iptables data plane e BYO CNI:
A tabela seguinte compara as opções de planos de dados disponíveis para a rede de pods AKS e as suas principais capacidades.
| Opções de plano de dados | Características e funcionalidades |
|---|---|
| Azure CNI alimentado por Cilium | • Maior escalabilidade e melhor desempenho para conjuntos de nós Linux. Os agrupamentos de nós do Windows não são suportados. • Aplicação integrada das políticas da rede Cilium. • A filtragem FQDN requer o Advanced Container Networking Services e o Kubernetes 1.29 ou superior. |
| Azure iptables | • Utilizar Calico para a aplicação das políticas de rede do Windows. O suporte ao Azure Network Policy Manager (NPM) termina a 30 de setembro de 2026 para Windows e a 30 de setembro de 2028 para Linux. Novas subscrições já não podem ativar o Azure NPM. • Para clusters Linux, use o Azure CNI Powered by Cilium em vez do Azure NPM. • Suporta Kubernetes NetworkPolicy. |
| BYO CNI | • Sem plugin CNI gerido instalado – pode usar qualquer opção que suporte AKS. • A Microsoft não suporta problemas relacionados com CNI. |
Recomendações de rede para pods do AKS
A nossa recomendação geral é usar o Azure CNI Overlay. Se precisar de acesso direto a pod IP a partir de redes ligadas e tiver requisitos de eficiência ou escala, considere usar a sub-rede Azure CNI Pod com Alocação Dinâmica de IP ou a sub-rede Azure CNI Pod com Alocação de Blocos Estáticos. A sub-rede de nós do Azure CNI é uma opção legada; em geral, utilize-a apenas se precisar de uma VNet gerida pelo AKS para o cluster.