Compartilhar via

Configurar a Rede da CNI do Azure para uma alocação estática de blocos de CIDR e suporte aprimorado a sub-redes no Serviço de Kubernetes do Azure (AKS)

  • Artigo

Uma limitação da Alocação Dinâmica de IP da CNI do Azure é a escalabilidade do tamanho da sub-rede de pods para além de uma sub-rede /16. Mesmo com uma sub-rede grande, os clusters grandes podem continuar limitados a 65 mil pods devido a um limite de mapeamento de endereços do Azure. A nova funcionalidade de alocação estática de blocos na CNI do Azure resolve esse problema atribuindo blocos de CIDR aos Nós em vez de a IPs individuais.

Ele 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 nova solução.

Este artigo mostra como usar a Rede da CNI do Azure para a alocação estática de CIDRs e o suporte aprimorado à sub-rede no AKS.

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.

  • Versão 2.37.0 da CLI do Azure ou posterior com a extensão aks-preview da versão "2.0.0b2" ou posterior

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

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

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

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
    em que 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

Planejar seu endereçamento IP é mais flexível e mais granular. Como os nós e os pods são dimensionados de forma independente, seus espaços de endereço também podem ser planejados 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.

Nesse cenário, blocos de CIDR de /28 (16 IPs) são alocados para os nós com base na sua configuração "--max-pod" 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.

Portanto, ao determinar e planejar seus IPs, é essencial definir sua configuração "--max-pods". Confira abaixo a melhor maneira de calculá-la: max_pods_per_node = (16 * N) - 1 onde N é qualquer número 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.

  • Exemplo 1: max_pods = 30, Blocos CIDR alocados por nó = 2, Total de IPs disponíveis para pods = (16 * 2) - 1 = 32 - 1 = 31, Desperdício de IP por nó = 31 - 30 = 1 [Baixo desperdício – Caso Aceitável]
  • Exemplo 2: max_pods = 31, Blocos CIDR alocados por nó = 2, Total de IPs disponíveis para pods = (16 * 2) - 1 = 32 - 1 = 31, Desperdício de IP por nó = 31 - 31 = 0 [Caso Ideal]
  • Exemplo 3: max_pods = 32, Blocos CIDR alocados por nó = 3, Total de IPs disponíveis para pods = (16 * 3) - 1 = 48 - 1 = 47, Desperdício de IP por nó = 47 - 32 = 15 [Alto Desperdício – Caso Não Recomendado]

O planejamento de IPs para 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.

Parâmetros de implantação

Os parâmetros de implantação para configurar a rede básica de CNI do Azure no AKS são válidos, com duas exceções:

  • O parâmetro id de sub-rede de vnet agora faz referência à sub-rede relacionada aos nós do cluster.
  • O parâmetro ID de sub-rede de pods é usado para especificar a sub-rede cujos endereços IP serão alocados estaticamente ou dinamicamente para os pods no pool de nós.
  • O parâmetro modo de alocação de IP para pods especifica se deve ser usada a alocação estática ou dinâmica individual de blocos.

Antes de começar

  • Se estiver usando a CLI do Azure, você precisará da extensão aks-preview. Confira Instalar a extensão da CLI do Azure aks-preview.
  • Se estiver usando o ARM ou a API REST, a versão da API do AKS precisa ser 2024-01-02-preview ou posterior.

Instale a extensão aks-preview da CLI do Azure

  1. Instale a extensão aks-preview usando o comando az extension add.

    az extension add --name aks-preview

  2. Atualize para a última versão da extensão usando o comando az extension update. A extensão deve ter uma versão "2.0..0b2" ou posterior

    az extension update --name aks-preview

Registrar o sinalizador de recurso AzureVnetScalePreview

  1. Registre o sinalizador de recurso AzureVnetScalePreview usando o comando az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"

    Demora alguns minutos para o status exibir Registrado.

  2. Verifique o status do registro usando o comando az feature show.

    az feature show --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"

  3. Quando o status reflete Registrado, atualize o registro do provedor de recursos Microsoft.ContainerService usando o comando az provider register.

    az provider register --namespace Microsoft.ContainerService

Configurar a rede com alocação estática de blocos de CIDR e suporte aprimorado à sub-rede: CLI do Azure

O uso da alocação estática de blocos de CIDR no seu cluster é semelhante ao método padrão para configurar uma CNI do Azure de cluster para a alocação dinâmica de IP. O exemplo a seguir descreve a criação de uma nova rede virtual com uma sub-rede para nós e uma sub-rede para pods e a criação de um cluster que usa a CNI do Azure com alocação estática de blocos de CIDR. Certifique-se de substituir as variáveis como $subscription por seus próprios valores.

Crie uma rede virtual com duas sub-redes.

resourceGroup="myResourceGroup"
vnet="myVirtualNetwork"
location="myRegion"

# Create the resource group
az group create --name $resourceGroup --location $location

# Create our two subnet network 
az network vnet create --resource-group $resourceGroup --location $location --name $vnet --address-prefixes 10.0.0.0/8 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name nodesubnet --address-prefixes 10.240.0.0/16 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name podsubnet --address-prefixes 10.40.0.0/13 -o none

Crie o cluster fazendo referência à sub-rede de nós usando --vnet-subnet-id, a sub-rede de pods usando --pod-subnet-id, --pod-ip-allocation-mode para definir o modo de alocação de IP e habilite o complemento de monitoramento.

clusterName="myAKSCluster"
subscription="aaaaaaa-aaaaa-aaaaaa-aaaa"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --max-pods 250 \
    --node-count 2 \
    --network-plugin azure \
    --pod-ip-allocation-mode StaticBlock \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/nodesubnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/podsubnet \
    --enable-addons monitoring \
    --generate-ssh-keys

Adicionar pool de nós

Ao adicionar o pool de nós, faça referência à sub-rede de nós usando --vnet-subnet-id, à sub-rede de pods usando --pod-subnet-id e ao modo de alocação usando "--pod-ip-allocation-mode". O exemplo a seguir cria duas novas sub-redes que são referenciadas na criação de um novo pool de nós:

az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name node2subnet --address-prefixes 10.242.0.0/16 -o none 
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name pod2subnet --address-prefixes 10.243.0.0/16 -o none 

az aks nodepool add --cluster-name $clusterName -g $resourceGroup  -n newnodepool \
    --max-pods 250 \
    --node-count 2 \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/node2subnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/pod2subnet \
    --pod-ip-allocation-mode StaticBlock \
    --no-wait

Alocação estática de blocos de CIDR e perguntas frequentes sobre o suporte à sub-rede aprimorado

  • Posso atribuir várias sub-redes de pods a um cluster?

    Várias sub-redes podem ser atribuídas a um cluster, mas apenas uma sub-rede pode ser atribuída a cada pool de nós. Pools de nós diferentes no mesmo cluster ou em um cluster diferente podem compartilhar a mesma sub-rede.

  • Posso atribuir sub-redes de pods de uma VNet diferente?

    Não, a sub-rede de pods deve ser da mesma VNet que o cluster.

  • É possível que alguns pools de nós em um cluster usem a Alocação Dinâmica de IP enquanto outros usam a nova Alocação Estática de Blocos?

    Sim, pools de nós diferentes podem usar modos de alocação diferentes. No entanto, após ser usada em um modo de alocação, uma sub-rede só pode ser usada no mesmo modo de alocação em todos os pools de nós associados.

Próximas etapas

Saiba mais sobre a rede no AKS nos seguintes artigos: