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.
Azure CNI Overlay é um modelo de rede para o AKS (Serviço de Kubernetes do Azure) que fornece gerenciamento eficiente de endereços IP e comunicação de pods de alto desempenho. Este artigo fornece uma visão geral do Azure CNI Overlay, incluindo sua arquitetura, planejamento de endereços IP e diferenças em relação ao modelo de rede kubenet tradicional.
Como funciona a rede de sobreposição do Azure CNI
O modelo plano do Azure Container Networking Interface (CNI) atribui um endereço IP de rede virtual a cada pod. Sub-rede do pod da CNI do Azure atribui IPs aos pods de uma sub-rede separada reservada para os pods. Sub-rede do nó da CNI do Azure (legado) atribui aos pods endereços IP da sub-rede do nó. Essas opções de rede simples exigem planejamento de endereço IP de rede virtual e podem levar ao esgotamento de endereços, o que apresenta dificuldades para dimensionar seus clusters à medida que as demandas do aplicativo aumentam.
Na rede de sobreposição, somente os nós de cluster do Kubernetes recebem IPs de sub-redes. Os pods recebem IPs de um intervalo Roteamento de domínio interno sem classe (CIDR) privado, fornecido no momento da criação do cluster. Cada nó recebe um espaço de endereço /24 extraído do mesmo CIDR. Nós extra criados quando você escala horizontalmente um cluster automaticamente, recebem espaços de endereço /24 do mesmo CIDR. A CNI do Azure atribui IPs a pods por meio desse espaço /24.
Um domínio de roteamento separado é criado na estrutura de rede do Azure para o espaço CIDR privado do pod. Esse domínio cria uma rede sobreposta para comunicação direta entre pods. Não é necessário provisionar rotas personalizadas na sub-rede do cluster ou usar um método de encapsulamento para tunelamento de tráfego entre pods, o que proporciona um desempenho de conectividade entre pods comparável ao das VMs (máquinas virtuais) em uma rede virtual. As cargas de trabalho em execução nos pods nem sequer estão cientes de que a manipulação de endereço de rede está acontecendo.
A comunicação com pontos de extremidade fora do cluster, como redes virtuais locais e emparelhadas, usa o IP do nó por meio da conversão de endereços de rede (NAT). A CNI do Azure converte o IP de origem do tráfego (o IP de sobreposição do pod) no endereço IP primário da VM do nó. Essa tradução permite que a pilha de Rede do Azure encaminhe o tráfego para o destino.
Endpoints fora do cluster não podem se conectar diretamente a um pod. Para tornar um aplicativo acessível, exponha-o por meio de um serviço kubernetes ou camada de roteamento de aplicativo, como um serviço LoadBalancer ou um controlador de entrada. Para obter mais informações, consulte Planejar a rede de aplicativos para AKS.
Você pode providenciar a saída da conectividade com a Internet para pods de sobreposição usando um Load Balancer padrão ou um Gateway da NAT Gerenciado. Você também pode controlar o tráfego de saída direcionando-o para um firewall por meio de rotas definidas pelo usuário na sub-rede do cluster.
Você pode configurar a conectividade de entrada com o cluster usando um controlador de entrada, como o Gateway de Aplicativo para Contêineres, o NGINX ou o complemento de roteamento de aplicativos.
Diferenças entre kubenet e Azure CNI Overlay
Assim como a sobreposição de CNI do Azure, o Kubenet atribui endereços IP a pods de um espaço de endereço logicamente diferente da rede virtual, mas tem dimensionamento e outras limitações. A tabela a seguir fornece uma comparação detalhada entre kubenet e Azure CNI Overlay:
Importante
A partir de 31 de março de 2028, o AKS (Serviço de Kubernetes do Azure) não dá mais suporte à rede kubenet. Para evitar interrupções de serviço, atualize para a rede de sobreposição da CNI (Interface de Rede de Contêiner do Azure) antes da data de fim do suporte. Para obter mais informações sobre essa desativação, consulte o problema de desativação do GitHub e o anúncio de desativação do Azure Updates. Para se manter informado sobre anúncios e atualizações, acompanhe as notas de lançamento do AKS.
| Área | CNI Overlay do Azure | kubenet (legado) |
|---|---|---|
| Máximo de nós por cluster | 5.000 nós | 400 nós |
| Máximo de pods por nó | 250 pods (máximo de 110 recomendados para contêineres de Windows Server) | 250 pods |
| Configuração de rede | Simples - não são necessárias configurações adicionais para rede de pods | Complexo – requer tabelas de rotas e rotas definidas pelo usuário na sub-rede do cluster para rede de pods |
| Desempenho da conectividade do pod | Desempenho compatível com VMs em uma rede virtual | Salto extra acrescenta pequena latência |
| Políticas de rede do Kubernetes | Azure CNI alimentado por Cilium (recomendado) ou o plano de dados Azure iptables com o Calico ou o NPM (Azure Network Policy Manager) | Calicó |
| Plataformas de SO com suporte | Linux, Windows Server 2025, Windows Server 2022 | Apenas Linux |
Os valores máximos de nós e de pods por nó são limites independentes. Não os multiplique para determinar a capacidade agregada de pods suportada por um cluster. Ao planejar a escala do cluster, examine as cotas e os limites de serviço do AKS e as diretrizes de escalabilidade de cluster grande. A camada do plano de controle, o comportamento da carga de trabalho e outros limites de serviço afetam a escala alcançável.
O Azure CNI com tecnologia Cilium oferece um plano de dados eBPF com aplicação integrada de políticas de rede do Cilium. Com o plano de dados Azure iptables, você pode usar Calico ou Azure NPM, mas Azure NPM não tem mais suporte em nós Windows a partir de 30 de setembro de 2026 e o suporte em nós do Linux termina em 30 de setembro de 2028. Para obter recomendações atuais e diretrizes de migração, consulte as opções de política de rede no AKS.
Observação
Se você não quiser atribuir endereços IP da rede virtual a pods devido à escassez de IPs, recomendamos usar o Azure CNI Overlay.
Planejamento de endereço IP
As seções a seguir fornecem orientações sobre como planejar seu espaço de endereço IP para Azure CNI Overlay.
Nós de cluster
Ao configurar seu cluster do AKS com Azure CNI Overlay, verifique se as sub-redes da sua rede virtual têm espaço suficiente para futuras expansões. Você pode atribuir cada pool de nós a uma sub-rede dedicada. Uma /24 sub-rede contém 256 endereços IP. Azure reserva os quatro primeiros e últimos endereços IP, deixando 251 endereços utilizáveis. Ao dimensionar a sub-rede, reserve também espaço de endereço para operações de atualização e escala e outros recursos na sub-rede.
Cápsulas
O tamanho /24 que o Azure CNI Overlay atribui é fixo e não pode ser aumentado ou reduzido. Você pode executar até 250 pods em um nó. Ao planejar o espaço de endereço do pod, verifique se o CIDR privado é grande o suficiente para fornecer /24 espaços de endereço para novos nós para dar suporte à futura expansão do cluster.
Ao planejar o espaço de endereço IP para pods, considere os seguintes fatores:
- Você pode usar o mesmo espaço de pod CIDR em vários clusters independentes do AKS dentro da mesma rede virtual.
- O espaço do CIDR do pod não deve se sobrepor à faixa de sub-rede do cluster.
- O espaço CIDR do pod não deve se sobrepor a redes conectadas diretamente, como emparelhamento de rede virtual, Azure ExpressRoute ou VPN. Se o tráfego externo tiver IPs de origem no intervalo CIDR do pod, ele precisará de tradução para um IP não sobreposto por meio da SNAT Conversão de Endereços de Rede de Origem (SNAT) para se comunicar com o cluster.
- Em c clusters de Sobreposição da CNI do Azure com apenas nós Linux, você pode expandir o CIDR dos pods para um superconjunto contíguo maior que contém o intervalo original. Não há suporte para redução ou substituição do intervalo. A expansão também não é compatível com cenários com Windows ou nós híbridos, CIDRs IPv6 de pods nem múltiplos blocos CIDR de pods.
Intervalo de endereços de serviço do Kubernetes
O tamanho do endereço de serviço CIDR 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-redes de cluster e ao intervalo de IP usado em redes virtuais emparelhadas e redes locais.
Observação
A partir do Kubernetes 1.33, você pode estender o intervalo de IP do serviço após a criação do cluster usando o ServiceCIDR recurso kubernetes. Para obter mais informações, consulte Estender intervalos de IP do serviço na documentação do Kubernetes.
Endereço IP do serviço Kubernetes para DNS
O endereço IP para DNS dentro do intervalo de endereços de serviço do Kubernetes que a descoberta do serviço de cluster usa. Não use o primeiro endereço IP no intervalo de endereços, pois esse endereço é usado para o kubernetes.default.svc.cluster.local endereço.
Importante
Os CIDRs de pod compatíveis podem utilizar o espaço de endereços para uso privado RFC 1918 ou o espaço de endereços compartilhado RFC 6598. Embora Azure não bloqueie o uso de intervalos de IP públicos, eles estão fora do escopo de suporte do Microsoft. Use um intervalo não público que não se sobreponha para o CIDR do pod.
Ao usar Azure CNI no modo de sobreposição, verifique se o CIDR do pod não se sobrepõe a nenhum endereço IP externo ou redes (como redes locais, redes virtuais emparelhadas ou ExpressRoute). Se um host externo usar um IP dentro do CIDR do pod, os pacotes destinados a esse host do pod poderão ser redirecionados para a rede overlay e sofrer SNAT pelo nó. Essa situação faz com que o ponto de extremidade externo se torne inacessível.
Grupos de segurança de rede
O tráfego de pod para pod com a Sobreposição de CNI do Azure não é encapsulado, e as regras de sub-rede do grupo de segurança de rede (NSG) são aplicadas. Se o NSG de sub-rede contiver regras de negação que impactariam o tráfego CIDR do pod, verifique se as regras a seguir estão em vigor para assegurar a funcionalidade adequada do cluster (além de todos os requisitos de saída do AKS):
| Source | Destino | Portas e protocolos | Purpose |
|---|---|---|---|
| CIDR do nó | CIDR do nó | Todas as portas e protocolos | Comunicação nó para nó |
| CIDR do nó | CIDR do pod | Todas as portas e protocolos | Roteamento de tráfego de serviço |
| CIDR do pod | CIDR do pod | Todas as portas e protocolos | Tráfego entre os pods e de pods para serviços, incluindo DNS |
O tráfego de um pod para qualquer destino fora do bloco CIDR do pod usa SNAT para definir o IP de origem para o IP do nó onde o pod está sendo executado.
Se você quiser restringir o tráfego entre cargas de trabalho no cluster, recomendamos o uso de políticas de rede.
Máximo de pods por nó
Você pode configurar o número máximo de pods por nó quando você cria o cluster ou adiciona um novo pool de nós.
| Setting | Valor |
|---|---|
| Default | 250 |
| Máximo | 250 |
| Mínimo | 10 |
O valor para o máximo de pods por nó que você configura durante a criação de um pool de nós se aplica apenas aos nós nesse pool de nós.
Para os contêineres do Windows Server, o valor máximo recomendado é de 110 pods por nó. Esse valor de operação recomendado é menor do que o máximo configurável de 250 pods por nó da sobreposição de CNI do Azure. Para obter mais informações, consulte cotas e limites de serviço do AKS.
Escolhendo um modelo de rede
Utilize uma rede de sobreposição quando:
- Você deseja dimensionar para um grande número de pods, mas é limitado pelo espaço de endereço IP em sua rede virtual.
- A maior parte da comunicação do pod estiver dentro do cluster.
- Você não precisa de recursos avançados do AKS, como nós virtuais.
Use rede plana quando:
- Você tem espaço de endereço IP disponível.
- A maior parte da comunicação do pod é com recursos fora do cluster.
- Os recursos fora do cluster precisam acessar pods diretamente.
- Você precisa de recursos avançados do AKS, como nós virtuais.
A CNI do Azure oferece a sobreposição de CNI do Azure para rede de sobreposição e a sub-rede de pod do CNI do Azure ou sub-rede de pod do CNI do Azure (legado) para rede plana. Para obter uma comparação detalhada dessas opções de gerenciamento de endereço IP, consulte Planejar a rede de pods para AKS.
Limitações da sobreposição de Azure CNI
A sobreposição de CNI do Azure tem as seguintes limitações:
- Não há suporte para conjuntos de disponibilidade de VM.
- Você não pode 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 da série 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 são usados como rótulos em nós de trabalho do AKS, portanto, estão sujeitos a regras de sintaxe do Kubernetes para rótulos.
Conteúdo relacionado
Para começar com o Azure CNI Overlay no AKS, consulte os seguintes artigos: