Sub-rede de Pod da CNI (Interface de Rede de Contêiner do Azure)
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 doaks-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.
Azure Kubernetes Service