Compartilhar via

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

  • Artigo

A Sub-rede de Pod da CNI do Azure atribui endereços IP a pods de uma sub-rede separada nos nós de cluster. Esse recurso está disponível em dois modos: Alocação de IP Dinâmico e Alocação de Bloco Estático (Versão Prévia).

Pré-requisitos

Observação

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

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

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

  • Não há suporte para os clusters do mecanismo do AKS e do tipo DIY.

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

  • Registre o sinalizador de recurso no nível da assinatura para a sua assinatura: 'Microsoft.ContainerService/AzureVnetScalePreview'.

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

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

Modo de alocação de IP dinâmico

A alocação de IP dinâmico ajuda a atenuar problemas de esgotamento do endereço IP de pod, alocando IPs de pod de uma sub-rede separada da sub-rede que hospeda o cluster do AKS.

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

  • Melhor utilização de IPs: os IPs são alocados dinamicamente para os pods do cluster da sub-rede de pods. Isso leva a uma melhor utilização de IPs no cluster em comparação com a solução CNI tradicional, que faz a alocação estática de IPs para cada nó.
  • Escalonável e flexível: as sub-redes de nó e de pods podem ser dimensionadas de forma independente. Uma única sub-rede de pods pode ser compartilhada entre vários pools de nós de um cluster ou em vários clusters do AKS implantados na mesma VNet. Você também pode configurar uma sub-rede de pods separada para um pool de nós.
  • Alto desempenho: como pods são atribuídos a IPs de VNets, eles têm conectividade direta com outros recursos e pods de clusters na VNet. A solução dá suporte a clusters muito grandes sem degradação no desempenho.
  • Políticas de VNet separadas para pods: como os pods têm uma sub-rede separada, você pode configurar para eles políticas de VNet separadas que são diferentes das políticas de nós. Isso permite muitos cenários úteis, como permitir a conectividade com a Internet apenas para pods e não para nós, corrigindo o IP de origem para o pod em um pool de nós usando um Gateway da NAT do Azure e usando 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.

planejar o endereçamento IP

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

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

O planejamento de endereço IP para os serviços do Kubernetes e a Ponte do Docker permanecem inalterados.

Modo de alocação de bloco estático (Versão Prévia)

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

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

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

Limitações

Abaixo estão algumas das limitações do uso da Alocação Estática de Blocos da CNI do Azure:

  • A versão mínima do Kubernetes necessária é 1.28
  • O tamanho máximo de sub-rede com suporte é x.x.x.x/12 — aprox. 1 milhão de IPs
  • Somente um único modo de operação pode ser usado para cada sub-rede. Se usar o modo de Alocação Estática de Blocos, uma sub-rede não poderá usar o modo de Alocação Dinâmica de IPs em um cluster ou pool de nós diferente com a mesma sub-rede e vice-versa.
  • Tem suporte apenas em novos clusters ou ao adicionar pools de nós com uma sub-rede diferente aos clusters existentes. A migração ou atualização de clusters ou pools de nós existentes não tem suporte.
  • Em todos os blocos de CIDR atribuídos a um nó no pool de nós, um IP será selecionado como o IP primário do nó. Portanto, os administradores de rede que selecionam o valor --max-pods devem tentar usar o cálculo abaixo para atender melhor às suas necessidades e obter um uso ideal de IPs na sub-rede:

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

Disponibilidade de região

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

  • Sul dos EUA
  • Leste dos EUA 2
  • Oeste dos EUA
  • Oeste dos EUA 2

planejar o endereçamento IP

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

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

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

Valores ideais sem desperdício de IPs requerem que o valor máximo de pods esteja em conformidade com a expressão acima.

Confira os casos de exemplo a seguir:

Caso de exemplo max_pods Blocos de 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
Alto desperdício (não recomendado) 32 3 (16 * 3) - 1 = 48 - 1 = 47 47 - 32 = 15

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

Observação

Verifique se a sua VNet tem um espaço de endereços contíguos suficientemente grande para dar suporte à escala do seu cluster.