Configurar a rede de Sobreposição do Azure CNI no Azure Kubernetes Service (AKS)

A CNI (Interface de Rede de Contêiner) tradicional do Azure atribui um endereço IP de rede virtual a cada pod. Ele atribui esse endereço IP a partir de um conjunto pré-reservado de IPs em cada nó ou uma sub-rede separada reservada para pods. Essa abordagem requer planejamento de endereços IP e pode levar à exaustão do endereço, o que introduz dificuldades no dimensionamento de clusters à medida que as demandas de aplicativos crescem.

Com a Sobreposição CNI do Azure, os nós de cluster são implantados em uma sub-rede da Rede Virtual do Azure (VNet). Os pods recebem endereços IP de um CIDR privado logicamente diferente da VNet que hospeda os nós. O tráfego de pod e nó dentro do cluster usa uma rede de sobreposição. Network Address Translation (NAT) usa o endereço IP do nó para alcançar recursos fora do cluster. Essa solução salva uma quantidade significativa de endereços IP de rede virtual e permite dimensionar o cluster para tamanhos grandes. Uma vantagem extra é que você pode reutilizar o CIDR privado em diferentes clusters AKS, o que estende o espaço IP disponível para aplicativos em contêineres no Serviço Kubernetes do Azure (AKS).

Visão geral da rede de sobreposição

Na rede de sobreposição, apenas os nós de cluster do Kubernetes recebem IPs de sub-redes. Os pods recebem IPs de um CIDR privado fornecido no momento da criação do cluster. A cada nó é atribuído um /24 espaço de endereço esculpido a partir do mesmo CIDR. Os nós extras criados quando você dimensiona um cluster recebem /24 automaticamente espaços de endereço do mesmo CIDR. O Azure CNI atribui IPs a pods a partir deste /24 espaço.

Um domínio de roteamento separado é criado na pilha de Rede do Azure para o espaço CIDR privado do pod, que cria uma rede de sobreposição para comunicação direta entre pods. Não há necessidade de provisionar rotas personalizadas na sub-rede do cluster ou usar um método de encapsulamento para encapsular o tráfego entre pods, o que fornece desempenho de conectividade entre pods no mesmo nível das VMs em uma VNet. As cargas de trabalho em execução dentro dos pods nem sequer estão cientes de que a manipulação de endereços de rede está acontecendo.

A comunicação com pontos de extremidade fora do cluster, como VNets locais e emparelhadas, acontece usando o IP do nó por meio de NAT. O Azure CNI traduz o IP de origem (IP de sobreposição do pod) do tráfego para o endereço IP primário da VM, o que permite que a pilha de Rede do Azure roteie o tráfego para o destino. Os pontos de extremidade fora do cluster não podem se conectar diretamente a um pod. Você precisa publicar o aplicativo do pod como um serviço de balanceador de carga do Kubernetes para torná-lo acessível na rede virtual.

Você pode fornecer conectividade de saída (saída) à Internet para pods de sobreposição usando um balanceador de carga SKU padrão ou um gateway NAT gerenciado. Você também pode controlar o tráfego de saída direcionando-o para um firewall usando Rotas Definidas pelo Usuário na sub-rede do cluster.

Você pode configurar a conectividade de entrada para o cluster usando um controlador de entrada, como o roteamento de aplicativos Nginx ou HTTP. Não é possível configurar a conectividade de entrada usando o Gateway de Aplicativo do Azure. Para obter detalhes, consulte Limitações com a sobreposição CNI do Azure.

Diferenças entre Kubenet e Azure CNI Overlay

Como a Sobreposição CNI do Azure, o Kubenet atribui endereços IP a pods de um espaço de endereço logicamente diferente da VNet, mas tem dimensionamento e outras limitações. A tabela abaixo fornece uma comparação detalhada entre Kubenet e Azure CNI Overlay. Se você não quiser atribuir endereços IP VNet a pods devido à escassez de IP, recomendamos usar a Sobreposição CNI do Azure.

Planeamento de endereços IP

• Nós de cluster: Ao configurar seu cluster AKS, certifique-se de que suas sub-redes VNet tenham espaço suficiente para crescer para dimensionamento futuro. Você pode atribuir cada pool de nós a uma sub-rede dedicada. Uma /24sub-rede pode acomodar até 251 nós, uma vez que os três primeiros endereços IP são reservados para tarefas de gerenciamento.
• Pods: A solução Overlay atribui um /24 espaço de endereço para pods em cada nó do CIDR privado especificado durante a criação do cluster. O /24 tamanho é fixo e não pode ser aumentado ou diminuído. Você pode executar até 250 pods em um nó. Ao planejar o espaço de endereçamento do pod, verifique se o CIDR privado é grande o suficiente para fornecer /24 espaços de endereçamento para novos nós para suportar a expansão futura do cluster.
  • Ao planejar o espaço de endereço IP para pods, considere os seguintes fatores:
    • O mesmo espaço CIDR pod pode ser usado em vários clusters AKS independentes na mesma VNet.
    • O espaço CIDR do pod não deve se sobrepor ao intervalo de sub-rede do cluster.
    • O espaço CIDR do pod não deve se sobrepor a redes conectadas diretamente (como emparelhamento VNet, Rota Expressa ou VPN). Se o tráfego externo tiver IPs de origem no intervalo podCIDR, ele precisará de conversão para um IP não sobreposto via SNAT para se comunicar com o cluster.
• Intervalo de endereços de serviço do Kubernetes: o tamanho do CIDR de endereço de serviço depende do número de serviços de cluster que você planeja criar. Deve ser menor que /12. Esse intervalo não deve se sobrepor ao intervalo CIDR do pod, ao intervalo de sub-rede do cluster e ao intervalo de IP usados em redes virtuais emparelhadas e redes locais.
• Endereço IP do serviço DNS do Kubernetes: esse endereço IP está dentro do intervalo de endereços do serviço Kubernetes usado pela descoberta do serviço de cluster. Não use o primeiro endereço IP no seu intervalo de endereços, pois esse endereço é usado para o kubernetes.default.svc.cluster.local endereço.

Grupos de segurança de rede

O tráfego de pod para pod com a sobreposição CNI do Azure não é encapsulado e as regras do grupo de segurança de rede de sub-rede são aplicadas. Se a sub-rede NSG contiver regras de negação que possam afetar o tráfego CIDR do pod, certifique-se de que as seguintes regras estejam em vigor para garantir a funcionalidade adequada do cluster (além de todos os requisitos de saída do AKS):

• Tráfego do nó CIDR para o nó CIDR em todas as portas e protocolos
• Tráfego do nó CIDR para o pod CIDR em todas as portas e protocolos (necessário para roteamento de tráfego de serviço)
• Tráfego do pod CIDR para o pod CIDR em todas as portas e protocolos (necessário para pod to pod e pod para tráfego de serviço, incluindo DNS)

O tráfego de um pod para qualquer destino fora do bloco CIDR do pod utiliza o SNAT para definir o IP de origem para o IP do nó onde o pod é executado.

Se desejar restringir o tráfego entre cargas de trabalho no cluster, recomendamos o uso de diretivas de rede.

Pods máximos por nó

Você pode configurar o número máximo de pods por nó no momento da criação do cluster ou ao adicionar um novo pool de nós. O padrão para o Azure CNI Overlay é 250. O valor máximo que você pode especificar na Sobreposição CNI do Azure é 250 e o valor mínimo é 10. O valor máximo de pods por nó configurado durante a criação de um pool de nós aplica-se apenas aos nós desse pool de nós.

Escolher um modelo de rede a utilizar

O Azure CNI oferece duas opções de endereçamento IP para pods: A configuração tradicional que atribui IPs VNet a pods e rede de sobreposição. A escolha de qual opção usar para seu cluster AKS é um equilíbrio entre flexibilidade e necessidades de configuração avançada. As considerações a seguir ajudam a descrever quando cada modelo de rede pode ser o mais apropriado.

Use a rede de sobreposição quando:

• Você gostaria de dimensionar para um grande número de pods, mas tem espaço de endereço IP limitado em sua rede virtual.
• A maior parte da comunicação do pod está dentro do cluster.
• Você não precisa de recursos avançados do AKS, como nós virtuais.

Use a opção VNet tradicional quando:

• Você tem espaço de endereço IP disponível.
• A maior parte da comunicação do pod é para recursos fora do cluster.
• Os recursos fora do cluster precisam alcançar os pods diretamente.
• Você precisa de recursos avançados do AKS, como nós virtuais.

Limitações com a sobreposição CNI do Azure

A sobreposição CNI do Azure tem as seguintes limitações:

• Não é possível usar o Application Gateway como um AGIC (Ingress Controller) para um cluster de sobreposição.
• Não é possível usar o Application Gateway for Containers para um cluster de sobreposição.
• Os Conjuntos de Disponibilidade de Máquina Virtual (VMAS) não são suportados para Sobreposição.
• Não é possível usar máquinas virtuais da série DCsv2 em pools de nós. Para atender aos requisitos de computação confidencial, considere usar VMs confidenciais das séries DCasv5 ou DCadsv5.
• Caso você esteja usando sua própria sub-rede para implantar o cluster, os nomes da sub-rede, VNET e grupo de recursos que contém a VNET devem ter 63 caracteres ou menos. Isso vem do fato de que esses nomes serão usados como rótulos em nós de trabalho do AKS e, portanto, estão sujeitos às regras de sintaxe de rótulos do Kubernetes.

Configurar clusters de sobreposição

Crie um cluster com a Sobreposição CNI do Azure usando o az aks create comando. Certifique-se de usar o argumento --network-plugin-mode para especificar um cluster de sobreposição. Se o pod CIDR não for especificado, o AKS atribuirá um espaço padrão: viz. 10.244.0.0/16.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --pod-cidr 192.168.0.0/16 \
    --generate-ssh-keys

Adicionar um novo pool de nós a uma sub-rede dedicada

Depois de criar um cluster com a Sobreposição CNI do Azure, você pode criar outro pool de nós e atribuir os nós a uma nova sub-rede da mesma VNet. Essa abordagem pode ser útil se você quiser controlar os IPs de entrada ou saída do host de/para destinos na mesma VNET ou VNets emparelhadas.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add --resource-group $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Atualizar um cluster existente para a Sobreposição CNI

O processo de atualização aciona cada pool de nós para ser recriado simultaneamente. Não há suporte para a atualização de cada pool de nós separadamente para Overlay. Quaisquer interrupções na rede de cluster são semelhantes a uma atualização de imagem de nó ou atualização de versão do Kubernetes, em que cada nó em um pool de nós é recriado.

Atualização do Cluster CNI do Azure

Atualize um cluster CNI do Azure existente para usar a sobreposição usando o az aks update comando.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

O --pod-cidr parâmetro é necessário ao atualizar da CNI herdada porque os pods precisam obter IPs de um novo espaço de sobreposição, que não se sobrepõe à sub-rede de nó existente. O CIDR do pod também não pode se sobrepor a nenhum endereço VNet dos pools de nós. Por exemplo, se o endereço da rede virtual for 10.0.0.0/8 e os nós estiverem na sub-rede 10.240.0.0/16, o --pod-cidr não poderá se sobrepor ao 10.0.0.0/8 ou ao CIDR de serviço existente no cluster.

Atualização do Kubenet Cluster

Atualize um cluster Kubenet existente para usar a sobreposição CNI do Azure usando o az aks update comando.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay 

Como o cluster já está usando um CIDR privado para pods que não se sobrepõe ao espaço IP da VNet, você não precisa especificar o --pod-cidr parâmetro e o Pod CIDR permanecerá o mesmo se o parâmetro não for usado.

Rede de pilha dupla

Você pode implantar seus clusters AKS em um modo de pilha dupla ao usar a rede de sobreposição e uma rede virtual do Azure de pilha dupla. Nessa configuração, os nós recebem um endereço IPv4 e IPv6 da sub-rede de rede virtual do Azure. Os pods recebem um endereço IPv4 e IPv6 de um espaço de endereçamento logicamente diferente para a sub-rede de rede virtual do Azure dos nós. A tradução de endereços de rede (NAT) é configurada para que os pods possam chegar aos recursos na rede virtual do Azure. O endereço IP de origem do tráfego é NAT para o endereço IP primário do nó da mesma família (IPv4 para IPv4 e IPv6 para IPv6).

Pré-requisitos

• Você deve ter a CLI do Azure 2.48.0 ou posterior instalada.
• Kubernetes versão 1.26.3 ou superior.

Limitações

Os seguintes recursos não são suportados com rede de pilha dupla:

• Políticas de rede do Azure
• Políticas de rede Calico
• NAT Gateway
• Complemento de nós virtuais

Implantar um cluster AKS de pilha dupla

Os seguintes atributos são fornecidos para suportar clusters de pilha dupla:

• --ip-families: Usa uma lista separada por vírgulas de famílias IP para habilitar no cluster.
  • Apenas ipv4 ou ipv4,ipv6 são suportados.
• --pod-cidrs: Usa uma lista separada por vírgulas de intervalos de IP de notação CIDR para atribuir IPs de pod.
  • A contagem e a ordem dos intervalos nesta lista devem corresponder ao valor fornecido a --ip-families.
  • Se nenhum valor for fornecido, o valor 10.244.0.0/16,fd12:3456:789a::/64 padrão será usado.
• --service-cidrs: Usa uma lista separada por vírgulas de intervalos de IP de notação CIDR para atribuir IPs de serviço.
  • A contagem e a ordem dos intervalos nesta lista devem corresponder ao valor fornecido a --ip-families.
  • Se nenhum valor for fornecido, o valor 10.0.0.0/16,fd12:3456:789a:1::/108 padrão será usado.
  • A sub-rede IPv6 atribuída a --service-cidrs não pode ser maior que um /108.

Criar um cluster AKS de pilha dupla

1. Crie um grupo de recursos do Azure para o cluster usando o comando [az group create][az-group-create].

   az group create --location <region> --name <resourceGroupName>
   

2. Crie um cluster AKS de pilha dupla usando o az aks create comando com o --ip-families parâmetro definido como ipv4,ipv6.

   az aks create \
       --location <region> \
       --resource-group <resourceGroupName> \
       --name <clusterName> \
       --network-plugin azure \
       --network-plugin-mode overlay \
       --ip-families ipv4,ipv6 \
       --generate-ssh-keys
   

Criar um exemplo de carga de trabalho

Depois que o cluster tiver sido criado, você poderá implantar suas cargas de trabalho. Este artigo orienta você por um exemplo de implantação de carga de trabalho de um servidor Web NGINX.

Implantar um servidor Web NGINX

O complemento de roteamento de aplicativo é a maneira recomendada de entrada em um cluster AKS. Para obter mais informações sobre o complemento de roteamento de aplicativo e um exemplo de como implantar um aplicativo com o addon, consulte Ingresso NGINX gerenciado com o complemento de roteamento de aplicativo.

Expor a carga de trabalho por meio de um LoadBalancer tipo de serviço

Rede de pilha dupla com o Azure CNI Powered by Cilium - (Pré-visualização)

Você pode implantar seus clusters AKS de pilha dupla com o Azure CNI Powered by Cilium. Isso também permite que você controle seu tráfego IPv6 com o mecanismo de diretiva de rede Cilium.

Pré-requisitos

• Você deve ter a versão mais recente da extensão de visualização do AKS.
• Você deve ter o Kubernetes versão 1.29 ou superior.

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

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

  az extension add --name aks-preview
  

• Atualize para a versão mais recente da extensão lançada usando o az extension update comando.

  az extension update --name aks-preview
  

Registrar o sinalizador de recurso 'AzureOverlayDualStackPreview'

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

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

   Leva alguns minutos para que o status mostre Registrado.

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

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

3. 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 clusters de sobreposição com o Azure CNI Powered by Cilium

Crie um cluster com a Sobreposição CNI do Azure usando o az aks create comando. Certifique-se de usar o argumento --network-dataplane cilium para especificar o dataplane do Cilium.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

Para obter mais informações sobre o Azure CNI Powered by Cilium, consulte Azure CNI Powered by Cilium.

Grupos de nós do Windows de rede de pilha dupla - (Visualização)

Você pode implantar seus clusters AKS de pilha dupla com pools de nós do Windows.

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

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

  az extension add --name aks-preview
  

• Atualize para a versão mais recente da extensão lançada usando o az extension update comando.

  az extension update --name aks-preview
  

Registrar o sinalizador de recurso 'AzureOverlayDualStackPreview'

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

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

   Leva alguns minutos para que o status mostre Registrado.

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

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

3. 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 um cluster de sobreposição

Crie um cluster com a Sobreposição CNI do Azure usando o az aks create comando.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --ip-families ipv4,ipv6 \
    --generate-ssh-keys\

Adicionar um pool de nós do Windows ao cluster

Adicione um pool de nós do Windows ao cluster usando o comando [az aks nodepool add][az-aks-nodepool-add].

az aks nodepool add \
    --resource-group $resourceGroup \
    --cluster-name $clusterName \
    --os-type Windows \
    --name winpool1 \
    --node-count 2

Próximos passos

Para saber como utilizar o AKS com seu próprio plug-in CNI (Container Network Interface), consulte Bring your own Container Network Interface (CNI).