Rede de Sobreposição da Interface de Rede de Contêineres do Azure (CNI)

Com a Sobreposição de CNI do Azure, os nós de cluster são implantados em uma sub-rede do Azure Rede Virtual (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. A NAT (Conversão de Endereços de Rede) usa o endereço IP do nó para acessar recursos fora do cluster. Essa solução poupa uma quantidade significativa de endereços IP de VNet e permite que você dimensione seu cluster para tamanhos grandes. Uma vantagem extra é que você pode reutilizar o CIDR privado em diferentes clusters do AKS, o que estende o espaço ip disponível para aplicativos em contêineres no AKS (Serviço de Kubernetes do Azure).

Visão geral da rede de sobreposição

Na rede de sobreposição, somente 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. 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 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 é necessário provisionar rotas personalizadas na sub-rede do cluster ou usar um método de encapsulamento para túnel de tráfego entre os pods, o que proporciona um desempenho de conectividade entre os pods equivalente ao das VMs em uma VNet. As cargas de trabalho em execução nos pods nem sequer sabem que a manipulação do endereço 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 da NAT. A CNI do Azure converte 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 encaminhe o tráfego para o destino. 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 Load Balancer do Kubernetes para torná-lo acessível na VNet.

Você pode fornecer a conectividade de saída com a Internet para pods de sobreposição usando um Load Balancer de SKU Padrão ou um Gateway da 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 com o cluster usando um controlador de entrada, como o Roteamento de aplicativo HTTP ou Nginx. Você não pode configurar a conectividade de entrada usando o Gateway de Aplicativo do Azure. Para detalhes, consulte Limitações com a Sobreposição de CNI do Azure.

Diferenças entre o Kubenet e a Sobreposição de CNI do Azure

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

Planejamento de endereço IP

Nós de cluster

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

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

Pods

A solução Sobreposição atribui um espaço de endereço /24 para os pods em todos os nós a partir do CIDR privado que você especifica durante a criação do cluster. O tamanho /24 é 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 IP para pods, considere os seguintes fatores:

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

Intervalo de endereços de serviço do Kubernetes

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

Endereço IP do serviço DNS do Kubernetes

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

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 são aplicadas. Se o NSG de sub-rede contiver regras de negação que afetam o tráfego CIDR do pod, verifique se as regras a seguir estão em vigor para garantir a funcionalidade de cluster adequada (além de todos os requisitos de saída do AKS):

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

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

Se você quiser restringir o tráfego entre cargas de trabalho no cluster, recomendamos usar políticas de rede.

Máximo de pods 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 da Sobreposição de 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 se aplica apenas aos nós nesse pool de nós.

Como escolher um modelo de rede para usar

A CNI do Azure oferece duas opções de endereçamento IP para pods: a configuração tradicional que atribui IPs de VNet a pods e a Rede de sobreposição. A escolha de qual opção usar para seu cluster do AKS deve levar em conta o equilíbrio entre a flexibilidade e as necessidades de configuração avançada. As considerações a seguir ajudam a delinear quando cada modelo de rede pode ser o mais adequado.

Use a rede de sobreposição quando:

• Você quer escalar para um grande número de Pods, mas tem um espaço de endereços IP limitado na sua VNet.
• 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 a opção de VNet tradicional quando:

• Você tem espaço de endereço IP disponível.
• A maior parte da comunicação do pod destina-se a 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.

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

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

• Você não pode usar o Gateway de Aplicativo como um Controlador de Entrada (AGIC).
• Não há suporte para os Conjuntos de Disponibilidade de Máquina Virtual (VMAS).
• 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 implementar o cluster, os nomes da sub-rede, da VNet e do grupo de recursos que contém a VNet devem 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.