Partilhar via

Sub-rede de Pod da Interface de Rede de Contêiner do Azure (CNI)

  • Artigo

A Sub-rede de Pod CNI do Azure atribui endereços IP a pods de uma sub-rede separada dos nós do cluster. Este recurso está disponível em dois modos: Alocação Dinâmica de IP e Alocação de Blocos Estáticos (Visualização).

Pré-requisitos

Nota

Ao usar a alocação de blocos estáticos de CIDRs, não há suporte para a exposição de um aplicativo como um Serviço de Link Privado usando um Serviço de Balanceador de Carga do Kubernetes.

  • Analise os pré-requisitos para configurar a rede CNI básica do Azure no AKS, pois os mesmos pré-requisitos se aplicam a este artigo.

  • Analise os parâmetros de implantação para configurar a rede CNI básica do Azure no AKS, pois os mesmos parâmetros se aplicam.

  • O mecanismo AKS e os clusters DIY não são suportados.

  • Versão da CLI 2.37.0 do Azure ou posterior e a aks-preview versão 2.0.0b2 de extensão ou posterior.

  • Registe o sinalizador de funcionalidade ao nível da subscrição para a sua subscrição: 'Microsoft.ContainerService/AzureVnetScalePreview'.

  • Se você tiver um cluster existente, precisará habilitar o complemento Container Insights para monitorar o uso da sub-rede IP. Você pode habilitar o Container Insights usando o az aks enable-addons comando, conforme mostrado no exemplo a seguir:

    az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>

Modo de alocação IP dinâmica

A alocação dinâmica de IP ajuda a mitigar os problemas de exaustão do endereço IP do pod alocando IPs de pod de uma sub-rede separada da sub-rede que hospeda o cluster AKS.

O modo de alocação IP dinâmica oferece os seguintes benefícios:

  • Melhor utilização de IP: os IPs são alocados dinamicamente para Pods de cluster a partir da sub-rede do Pod. Isso leva a uma melhor utilização de IPs no cluster em comparação com a solução CNI tradicional, que faz alocação estática de IPs para cada nó.
  • Escalável e flexível: as sub-redes de nós e pods podem ser dimensionadas de forma independente. Uma única sub-rede de pod pode ser compartilhada entre vários pools de nós de um cluster ou entre vários clusters AKS implantados na mesma VNet. Você também pode configurar uma sub-rede de pod separada para um pool de nós.
  • Alto desempenho: Como os pods recebem IPs de VNet, eles têm conectividade direta com outros pods de cluster e recursos na VNet. A solução suporta clusters muito grandes sem qualquer degradação no desempenho.
  • Políticas de VNet separadas para pods: como os pods têm uma sub-rede separada, você pode configurar políticas de VNet separadas para eles que são diferentes das políticas de nó. Isso permite muitos cenários úteis, como permitir conectividade com a Internet apenas para pods e não para nós, corrigir o IP de origem para pod em um pool de nós usando um Gateway NAT do Azure e usar NSGs (grupos de segurança de rede) para filtrar o tráfego entre pools de nós.
  • Políticas de rede do Kubernetes: as Políticas de Rede do Azure e o Calico funcionam com esse modo.

Planear o endereçamento IP

Com a alocação dinâmica de IP, nós e pods são dimensionados de forma independente, para que você possa planejar seus espaços de endereço separadamente. Como as sub-redes pod podem ser configuradas para a granularidade de um pool de nós, você sempre pode adicionar uma nova sub-rede ao adicionar um pool de nós. Os pods do sistema em um pool de cluster/nó também recebem IPs da sub-rede do pod, portanto, esse comportamento precisa ser considerado.

Os IPs são alocados aos nós em lotes de 16. A alocação de IP da sub-rede do pod deve ser planejada com um mínimo de 16 IPs por nó no cluster, pois os nós solicitam 16 IPs na inicialização e solicitam outro lote de 16 sempre que houver <8 IPs não alocados em sua alocação.

O planejamento de endereços IP para serviços Kubernetes e Docker Bridge permanece inalterado.

Modo de alocação de blocos estáticos (Visualização)

A alocação de blocos estáticos ajuda a mitigar possíveis limitações de dimensionamento de sub-rede de pod e mapeamento de endereços do Azure atribuindo blocos CIDR a nós em vez de IPs individuais.

O modo de alocação de blocos estáticos oferece os seguintes benefícios:

  • Melhor escalabilidade IP: os blocos CIDR são alocados estaticamente para os nós do cluster e estão presentes durante o tempo de vida do nó, em oposição à alocação dinâmica tradicional de IPs individuais com CNI tradicional. Isso permite o roteamento com base em blocos CIDR e ajuda a dimensionar o cluster limitar até 1 milhão de pods dos pods tradicionais de 65K por cluster. Sua Rede Virtual do Azure deve ser grande o suficiente para acomodar a escala do cluster.
  • Flexibilidade: As sub-redes de nós e pods podem ser dimensionadas de forma independente. Uma única sub-rede de pod pode ser compartilhada entre vários pools de nós de um cluster ou entre vários clusters AKS implantados na mesma VNet. Você também pode configurar uma sub-rede de pod separada para um pool de nós.
  • Alto desempenho: Como os pods recebem IPs de rede virtual, eles têm conectividade direta com outros pods e recursos de cluster na rede virtual.
  • Políticas de VNet separadas para pods: como os pods têm uma sub-rede separada, você pode configurar políticas de VNet separadas para eles que são diferentes das políticas de nó. Isso permite muitos cenários úteis, como permitir conectividade com a Internet apenas para pods e não para nós, corrigir o IP de origem para pod em um pool de nós usando um Gateway NAT do Azure e usar NSGs para filtrar o tráfego entre pools de nós.
  • Políticas de rede do Kubernetes: Cilium, Azure NPM e Calico funcionam com esta solução.

Limitações

Abaixo estão algumas das limitações de usar a alocação de Bloco Estático CNI do Azure:

  • A versão mínima do Kubernetes necessária é 1.28
  • O tamanho máximo de sub-rede suportado é x.x.x.x/12 ~ 1 milhão de IPs
  • Apenas um único modo de operação pode ser usado por sub-rede. Se uma sub-rede usa o modo de alocação de bloco estático, ela não pode ser usada no modo de alocação de IP dinâmico em um cluster ou pool de nós diferente com a mesma sub-rede e vice-versa.
  • Suporte apenas em novos clusters ou ao adicionar pools de nós com uma sub-rede diferente a clusters existentes. Não há suporte para migração ou atualização de clusters ou pools de nós existentes.
  • Em todos os blocos CIDR atribuídos a um nó no pool de nós, um IP será selecionado como o IP primário do nó. Assim, para administradores de rede que selecionam o valor, --max-pods tente usar o cálculo abaixo para melhor atender às suas necessidades e ter o uso ideal de IPs na sub-rede:

max_pods = (N * 16) - 1 onde N é qualquer número inteiro positivo e N> 0

Disponibilidade da região

Este recurso não está disponível nas seguintes regiões:

  • E.U.A. Sul
  • E.U.A. Leste 2
  • E.U.A. Oeste
  • E.U.A. Oeste 2

Planear o endereçamento IP

Com a alocação de blocos estáticos, nós e pods são dimensionados de forma independente, para que você possa planejar seus espaços de endereço separadamente. Como as sub-redes pod podem ser configuradas para a granularidade de um pool de nós, você sempre pode adicionar uma nova sub-rede ao adicionar um pool de nós. Os pods do sistema em um pool de cluster/nó também recebem IPs da sub-rede do pod, portanto, esse comportamento precisa ser considerado.

Os blocos CIDR de /28 (16 IPs) são alocados para nós com base na sua --max-pods configuração para o pool de nós, que define o número máximo de pods por nó. 1 IP é reservado em cada nó de todos os IPs disponíveis nesse nó para fins internos.

Ao planejar seus IPs, é importante definir sua --max-pods configuração usando o seguinte cálculo: max_pods_per_node = (16 * N) - 1, onde N é qualquer número inteiro positivo maior que 0.

Valores ideais sem desperdício de IP exigiriam que o valor máximo de pods estivesse em conformidade com a expressão acima.

Veja os seguintes exemplos de casos:

Caso de exemplo max_pods Blocos CIDR alocados por nó IP total disponível para pods Desperdício de IP para nó
Baixo desperdício (aceitável) 30 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 30 = 1
Caso ideal 31 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 31 = 0
Desperdício elevado (não recomendado) 32 3 (16 * 3) - 1 = 48 - 1 = 47 47 - 32 = 15

O planejamento de endereços IP para serviços Kubernetes permanece inalterado.

Nota

Certifique-se de que sua rede virtual tenha um espaço de endereçamento suficientemente grande e contíguo para suportar a escala do cluster.