Configurar a Rede CNI do Azure para alocação estática de blocos CIDR e suporte avançado de sub-rede no Serviço Kubernetes do Azure (AKS) - (Pré-visualização)
Uma limitação da Alocação Dinâmica de IP CNI do Azure é a escalabilidade do tamanho da sub-rede do pod além de uma sub-rede /16. Mesmo com uma sub-rede grande, clusters grandes ainda podem ser limitados a pods de 65k devido a um limite de mapeamento de endereço do Azure. O novo recurso de alocação de bloco estático no Azure CNI resolve esse problema atribuindo blocos CIDR a nós em vez de IPs individuais.
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 nova solução.
Este artigo mostra como usar a Rede CNI do Azure para alocação estática de CIDRs e suporte aprimorado de sub-rede no AKS.
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 com extensão aks-preview da versão '2.0.0b2' ou posteriorSe 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
az aks enable-addons
comando, conforme mostrado no exemplo a seguir:Registre o sinalizador de recurso de nível de assinatura para 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 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
Planejar seu endereçamento IP é mais flexível e granular. Como os nós e pods são dimensionados de forma independente, seus espaços de endereço também podem ser planejados 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.
Nesse cenário, blocos CIDR de /28 (16 IPs) são alocados para nós com base na configuração '--max-pod' 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.
Assim, ao determinar e planejar seus IPs, é essencial definir sua configuração '--max-pods' e ela pode ser calculada melhor como abaixo: max_pods_per_node = (16 * N) - 1
em que N é qualquer número inteiro positivo superior a 0
Valores ideais sem desperdício de IP exigiriam que o valor máximo de pods estivesse 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 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.
Parâmetros de implantação
Os parâmetros de implantação para configurar a rede CNI básica do Azure no AKS são todos válidos, com duas exceções:
- O parâmetro vnet subnet id agora se refere à sub-rede relacionada aos nós do cluster.
- O parâmetro pod subnet id é usado para especificar a sub-rede cujos endereços IP serão alocados estática ou dinamicamente para pods no pool de nós.
- O parâmetro pod ip allocation mode especifica se a alocação de blocos dinâmicos individuais ou estáticos deve ser usada.
Antes de começar
- Se estiver usando a CLI do Azure, você precisará da
aks-preview
extensão. Consulte Instalar a extensão da CLI doaks-preview
Azure. - Se estiver usando ARM ou a API REST, a versão da API AKS deve ser 2024-01-02-preview ou posterior.
Instalar a extensão da CLI do aks-preview
Azure
Instale a
aks-preview
extensão usando oaz extension add
comando.az extension add --name aks-preview
Atualize para a versão mais recente da extensão usando o
az extension update
comando. A extensão deve ter uma versão de '2.0..0b2' ou posterioraz extension update --name aks-preview
Registrar o sinalizador de AzureVnetScalePreview
recurso
Registre o
AzureVnetScalePreview
sinalizador de recurso usando oaz feature register
comando.az feature register --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"
Leva alguns minutos para que o status mostre Registrado.
Verifique o status do registro usando o
az feature show
comando.az feature show --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"
Quando o status refletir Registrado, atualize o registro do provedor de recursos Microsoft.ContainerService usando o
az provider register
comando.az provider register --namespace Microsoft.ContainerService
Configurar a rede com alocação estática de blocos CIDR e suporte aprimorado a sub-redes - CLI do Azure
O uso da alocação estática de blocos CIDR em seu cluster é semelhante ao método padrão para configurar um cluster Azure CNI para alocação dinâmica de IP. O exemplo a seguir mostra como criar uma nova rede virtual com uma sub-rede para nós e uma sub-rede para pods e criar um cluster que usa o Azure CNI com alocação estática de blocos CIDR. Certifique-se de substituir variáveis como $subscription
por seus valores.
Crie a 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 do nó usando --vnet-subnet-id
, a sub-rede pod usando --pod-subnet-id
, o --pod-ip-allocation-mode
para definir o modo de alocação 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
Adicionando pool de nós
Ao adicionar o pool de nós, faça referência à sub-rede do nó usando --vnet-subnet-id
, a sub-rede pod usando --pod-subnet-id
e o 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 CIDR e perguntas frequentes sobre suporte de sub-rede aprimorado
Posso atribuir várias sub-redes pod 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/cluster diferente podem compartilhar a mesma sub-rede.
Posso atribuir sub-redes Pod de uma VNet diferente?
Não, a sub-rede do pod deve ser da mesma VNet que o cluster.
Alguns pools de nós em um cluster podem usar alocação IP dinâmica enquanto outros usam a nova alocação de bloco estático?
Sim, diferentes pools de nós podem usar diferentes modos de alocação. No entanto, uma vez que uma sub-rede é usada em um modo de alocação, ela só pode ser usada no mesmo modo de alocação em todos os pools de nós que está associada.
Próximos passos
Saiba mais sobre redes no AKS nos seguintes artigos:
Azure Kubernetes Service