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

  • Artigo

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.

Um diagrama mostrando dois nós com três pods cada um em execução em uma rede de sobreposição. O tráfego do pod para pontos de extremidade fora do cluster é roteado via NAT.

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.

Área Sobreposição do Azure CNI Kubenet
Escala de cluster 5000 nós e 250 pods/nó 400 nós e 250 pods/nó
Configuração de rede Simples - sem configurações extras necessárias para rede pod Complexo - requer tabelas de rotas e UDRs na sub-rede do cluster para rede pod
Desempenho de conectividade do pod Desempenho em pé de igualdade com VMs em uma VNet Salto extra adiciona latência
Políticas de rede do Kubernetes Políticas de Rede do Azure, Calico, Cilium Calico
Plataformas de SO suportadas Linux e Windows Server 2022, 2019 Apenas Linux

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.
  • 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

Nota

Você deve ter a CLI versão 2.48.0 ou posterior para usar o --network-plugin-mode argumento. Para Windows, você deve ter a extensão mais recente aks-preview Azure CLI instalada e pode seguir as instruções abaixo.

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 -n $clusterName -g $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16

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  -g $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Atualizar um cluster existente para a Sobreposição CNI

Nota

Você pode atualizar um cluster CNI do Azure existente para Sobreposição se o cluster atender aos seguintes critérios:

  • O cluster está no Kubernetes versão 1.22+.
  • Não usa o recurso de alocação de IP do pod dinâmico.
  • Não tem políticas de rede habilitadas. O mecanismo de Política de Rede pode ser desinstalado antes da atualização, consulte Desinstalar o Azure Network Policy Manager ou o Calico
  • Não usa nenhum pool de nós do Windows com docker como tempo de execução do contêiner.

Nota

Como o domínio de roteamento ainda não é suportado para ARM, a sobreposição CNI ainda não é suportada em nós de processador baseados em ARM (ARM64).

Nota

A atualização de um cluster existente para a Sobreposição CNI é um processo não reversível.

Aviso

Antes do Windows OS Build 20348.1668, havia uma limitação em torno dos pods de sobreposição do Windows incorretamente SNATing pacotes de pods de rede host, o que tinha um efeito mais prejudicial para clusters atualizando para Overlay. Para evitar esse problema, use a compilação do sistema operacional Windows maior ou igual a 20348.1668.

Aviso

Se estiver usando uma configuração personalizada azure-ip-masq-agent para incluir intervalos de IP adicionais que não devem pacotes SNAT de pods, atualizar para a sobreposição CNI do Azure pode interromper a conectividade com esses intervalos. Os IPs de pod do espaço de sobreposição não serão acessíveis por nada fora dos nós do cluster. Além disso, para clusters suficientemente antigos, pode haver um ConfigMap remanescente de uma versão anterior do azure-ip-masq-agent. Se esse ConfigMap, chamado azure-ip-masq-agent-config, existir e não estiver intencionalmente no local, ele deverá ser excluído antes de executar o comando update. Se não estiver usando uma configuração personalizada do ip-masq-agent, somente o azure-ip-masq-agent-config-reconciled ConfigMap deverá existir em relação ao Azure ip-masq-agent ConfigMaps e isso será atualizado automaticamente durante o processo de atualização.

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.

Nota

Ao atualizar de Kubenet para CNI Overlay, a tabela de rotas não será mais necessária para roteamento de pod. Se o cluster estiver usando uma tabela de rotas fornecida pelo cliente, as rotas que estavam sendo usadas para direcionar o tráfego do pod para o nó correto serão excluídas automaticamente durante a operação de migração. Se o cluster estiver usando uma tabela de rotas gerenciada (a tabela de rotas foi criada pelo AKS e vive no grupo de recursos do nó), essa tabela de rotas será excluída como parte da migração.

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:

  • Windows Nodepools
  • 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 -l <region> -n <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 -l <region> -g <resourceGroupName> -n <clusterName> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --ip-families ipv4,ipv6

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

Importante

Existem atualmente duas limitações relativas aos serviços IPv6 no AKS.

  • O Azure Load Balancer envia testes de integridade para destinos IPv6 a partir de um endereço de link local. Nos pools de nós do Azure Linux, esse tráfego não pode ser roteado para um pod, portanto, o tráfego flui para serviços IPv6 implantados com externalTrafficPolicy: Cluster falha. Os serviços IPv6 devem ser implantados com , o que faz com externalTrafficPolicy: Localkube-proxy que responda à sonda no nó.
  • Antes da versão 1.27 do Kubernetes, apenas o primeiro endereço IP de um serviço será provisionado para o balanceador de carga, portanto, um serviço de pilha dupla só recebe um IP público para sua primeira família de IP listada. Para fornecer um serviço de pilha dupla para uma única implantação, crie dois serviços direcionados ao mesmo seletor, um para IPv4 e outro para IPv6. Isso não é mais uma limitação no kubernetes 1.27 ou posterior.

  1. Exponha a implantação do NGINX usando o kubectl expose deployment nginx comando.

    kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'

    Você recebe uma saída que mostra que os serviços foram expostos.

    service/nginx-ipv4 exposed
service/nginx-ipv6 exposed

  2. Depois que a implantação for exposta e os LoadBalancer serviços estiverem totalmente provisionados, obtenha os endereços IP dos serviços usando o kubectl get services comando.

    kubectl get services

    NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s

  3. Verifique a funcionalidade por meio de uma solicitação da Web de linha de comando de um host compatível com IPv6. O Azure Cloud Shell não é compatível com IPv6.

    SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -s "http://[${SERVICE_IP}]" | head -n5

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>

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).