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

  • Artigo

A CNI (Interface de Rede de Contêiner do Azure) tradicional atribui um endereço IP de VNet a cada pod. Ela atribui esse endereço IP a partir de um conjunto pré-reservado de IPs em cada nó ou de uma sub-rede separada reservada para pods. Essa abordagem requer o planejamento de endereço IP, e pode levar ao esgotamento de endereços, o que causa dificuldades de dimensionamento de clusters à medida que as demandas do aplicativo aumentam.

Com a Sobreposição de CNI do Azure, os nós de cluster são implantados em uma sub-rede do Azure Rede Virtual (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. A NAT (Conversão de Endereços de Rede) usa o endereço IP do nó para acessar recursos fora do cluster. Essa solução poupa uma quantidade significativa de endereços IP de VNet e permite que você dimensione seu cluster para tamanhos grandes. Uma vantagem extra é que você pode reutilizar o CIDR privado em diferentes clusters do AKS, o que estende o espaço ip disponível para aplicativos em contêineres no AKS (Serviço de Kubernetes do Azure).

Visão geral da rede de sobreposição

Na rede de sobreposição, somente 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. Cada nó recebe um espaço de endereço /24 extraído do mesmo CIDR. Nós extra criados quando você escala horizontalmente um cluster automaticamente, recebem espaços de endereço /24 do mesmo CIDR. A CNI do Azure atribui IPs a pods por meio desse espaço /24.

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 é necessário provisionar rotas personalizadas na sub-rede do cluster ou usar um método de encapsulamento para túnel de tráfego entre os pods, o que proporciona um desempenho de conectividade entre os pods equivalente ao das VMs em uma VNet. As cargas de trabalho em execução nos pods nem sequer sabem que a manipulação do endereço de rede está acontecendo.

Um diagrama mostrando dois nós com três pods, cada um executando em uma rede de sobreposição. O tráfego de 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 da NAT. A CNI do Azure converte 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 encaminhe o tráfego para o destino. 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 Load Balancer do Kubernetes para torná-lo acessível na VNet.

Você pode fornecer a conectividade de saída com a Internet para pods de sobreposição usando um Load Balancer de SKU Padrão ou um Gateway da 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 com o cluster usando um controlador de entrada, como o Roteamento de aplicativo HTTP ou Nginx. Você não pode configurar a conectividade de entrada usando o Gateway de Aplicativo do Azure. Para detalhes, consulte Limitações com a Sobreposição de CNI do Azure.

Diferenças entre o Kubenet e a Sobreposição de CNI do Azure

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

Área Sobreposição de CNI do Azure Kubenet
Escalar o cluster 5.000 nós e 250 pods/nó 400 nós e 250 pods/nó
Configuração de rede Simples - não são necessárias configurações adicionais para rede de pods Complexo – Requer tabelas de rotas e UDRs na sub-rede de cluster para a rede do pod
Desempenho da conectividade do pod Desempenho em par com VMs em uma VNet Salto extra acrescenta pequena latência
Políticas de rede do Kubernetes Políticas de Rede do Azure, Calico, Cilium Calico
Plataformas de SO com suporte Linux e Windows Server 2022, 2019 Apenas Linux

Planejamento de endereço IP

  • Nós de cluster: ao configurar o cluster do AKS, verifique se as sub-redes de VNet têm espaço suficiente para crescer para dimensionamento futuro. Você pode atribuir cada pool de nós a uma sub-rede dedicada. Uma sub-rede/24 pode caber até 251 nós, pois os três primeiros endereços IP são reservados para tarefas de gerenciamento.
  • Pods: a solução de sobreposição atribui um espaço de endereço /24 para pods em cada nó do CIDR privado especificado durante a criação do cluster. O tamanho /24 é fixo e não pode ser aumentado ou reduzido. Você pode executar até 250 pods em um nó. Ao planejar o espaço de endereço do pod, verifique se o CIDR privado é grande o suficiente para fornecer espaços de endereço /24 para novos nós a fim de dar suporte à futura expansão do cluster.
    • Ao planejar o espaço de endereço IP para pods, considere os seguintes fatores:
      • O mesmo espaço do CIDR do pod pode ser usado em vários clusters do AKS independentes na mesma VNet.
      • O espaço so CIDR do pod não deve se sobrepor ao intervalo de sub-rede do cluster.
      • O espaço de CIDR do pod não deve se sobrepor a redes conectadas diretamente (como o peering de VNets, ExpressRoute ou VPN). Se tiver IPs de origem dentro do intervalo podCIDR, o tráfego externo precisará ser traduzido para um IP não sobreposto por meio de SNAT para se comunicar com o cluster.
  • Intervalo de endereços de serviço do Kubernetes: o tamanho do endereço de serviço do CIDR 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 do CIDR do pod, ao intervalo de sub-redes de cluster e ao intervalo de IP usado em VNets emparelhadas e redes locais.
  • Endereço IP do serviço de DNS do Kubernetes: Esse endereço IP está dentro do intervalo de endereços de serviço do Kubernetes que é usado pela descoberta do serviço de cluster. Não use o primeiro endereço IP no intervalo de endereços, pois esse endereço é usado para o endereço kubernetes.default.svc.cluster.local.

Grupos de segurança de rede

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

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

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

Se você quiser restringir o tráfego entre cargas de trabalho no cluster, recomendamos usar políticas de rede.

Máximo de pods 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 a Sobreposição de CNI do Azure é 250. O valor máximo que você pode especificar na Sobreposição de 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 se aplica apenas aos nós nesse pool de nós.

Como escolher um modelo de rede para usar

A CNI do Azure oferece duas opções de endereçamento IP para pods: a configuração tradicional que atribui IPs de VNet a pods e a Rede de sobreposição. A escolha de qual opção usar para seu cluster do AKS deve levar em conta o equilíbrio entre a flexibilidade e as necessidades de configuração avançada. As considerações a seguir ajudam a delinear quando cada modelo de rede pode ser o mais adequado.

Use a rede de sobreposição quando:

  • Você quer escalar para um grande número de Pods, mas tem um espaço de endereços IP limitado na sua VNet.
  • A maior parte da comunicação do pod estiver dentro do cluster.
  • Você não precisa de recursos avançados do AKS, como nós virtuais.

Use a opção de VNet tradicional quando:

  • Você tem espaço de endereço IP disponível.
  • A maior parte da comunicação do pod destina-se a recursos fora do cluster.
  • Os recursos fora do cluster precisam acessar pods diretamente.
  • Você precisa de recursos avançados do AKS, como nós virtuais.

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

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

  • Você não pode usar o Gateway de Aplicativo como um AGIC (Controlador de Entrada) para um cluster de sobreposição.
  • Não há suporte para Conjuntos de Disponibilidade de Máquinas Virtuais (VMAS) para Sobreposição.
  • Você não pode 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 da série DCasv5 ou DCadsv5.
  • Caso você esteja usando sua própria sub-rede para implantar o cluster, os nomes da sub-rede, da VNET e do 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 a regras de sintaxe de rótulo do Kubernetes.

Configurar clusters de sobreposição

Observação

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

Crie um cluster com a Sobreposição de CNI do Azure usando o comando az aks create. Use o argumento --network-plugin-mode para especificar um cluster de sobreposição. Se o CIDR do pod 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 de 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

Atualização de um cluster existente para a Sobreposição de CNI

Observação

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

  • O cluster está no Kubernetes versão 1.22 ou superior.
  • Não usa o recurso de alocação de IP de 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 Gerenciador de Políticas de Rede do Azure ou o Calico
  • Não usa nenhum pool de nós do Windows com o docker como o runtime do contêiner.

Observação

Como o domínio de roteamento ainda não tem suporte para ARM, a sobreposição de CNI ainda não tem suporte em nós de processadores baseados em ARM (ARM64).

Observação

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

Aviso

Antes do build 20348.1668 do sistema operacional Windows, havia limitação em torno de pods de sobreposição do Windows que executam incorretamente o SNAT dos pacotes de pods da rede do host, que teve um efeito mais prejudicial na atualização de clusters para Sobreposição. Para evitar esse problema, use o build do sistema operacional Windows maior ou igual a 20348.1668.

Aviso

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

O processo de atualização dispara cada pool de nós a ter a imagem recriada simultaneamente. Não há suporte para atualizar cada pool de nós separadamente para Sobreposição. Todas as interrupções de rede de cluster são semelhantes a uma atualização de imagem de nó ou atualização da versão do Kubernetes, onde uma nova imagem é criada de cada nó em um pool de nós.

Upgrade de cluster da CNI do Azure

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

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 parâmetro --pod-cidr é 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 VNet 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 a 10.0.0.0/8 ou ao CIDR de serviço existente no cluster.

Upgrade de cluster do Kubenet

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

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õem ao espaço IP da VNet, você não precisa especificar o parâmetro --pod-cidr e o CIDR do pod permanecerá o mesmo.

Observação

Ao atualizar do Kubenet para a Sobreposição de CNI, 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 de 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 gerenciadas (a tabela de rotas foi criada pelo AKS e reside 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 do 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 da rede virtual do Azure. Os pods recebem endereço IPv4 e IPv6 de um espaço de endereço logicamente diferente da sub-rede da rede virtual do Azure dos nós. A NAT (Conversão de Endereços de Rede) é configurada para que os pods possam alcançar 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

  • É necessário ter a CLI do Azure 2.48.0 ou posterior instalada.
  • Kubernetes versão 1.26.3 ou posterior.

Limitações

Não há suporte para os recursos a seguir com rede de pilha dupla:

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

Implantar um cluster do AKS de pilha dupla

Os atributos a seguir são fornecidos para dar suporte a clusters de pilha dupla:

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

Criar um cluster do 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. Criar um cluster do AKS de pilha dupla utilizando o comando az aks create com o parâmetro --ip-families 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 uma carga de trabalho de exemplo

Após a criação do cluster, você poderá implementar suas cargas de trabalho. Este artigo o orienta em um exemplo de implantação de carga de trabalho de um servidor da Web NGINX.

Implantar um servidor Web NGINX

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

Exponha a carga de trabalho através de um serviço do tipo LoadBalancer

Importante

Atualmente, há duas limitações relacionadas aos serviços IPv6 no AKS.

  • Azure Load Balancer envia investigações de integridade para destinos IPv6 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, de modo que o tráfego que flui para os serviços IPv6 implantados com externalTrafficPolicy: Cluster falha. Os serviços IPv6 devem ser implantados com externalTrafficPolicy: Local, o que faz com que kube-proxy responda à investigação no nó.
  • Antes do Kubernetes versão 1.27, somente o primeiro endereço IP de um serviço será provisionado para o balanceador de carga, portanto, um serviço de pilha dupla recebe apenas um IP público para sua família de IP listada pela primeira vez. 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 comando kubectl expose deployment nginx.

    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 mostrando que os serviços foram expostos.

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

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

    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 através de uma solicitação da Web de linha de comando a partir 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óximas etapas

Para saber como utilizar o AKS com seu próprio plug-in da CNI (Interface de Rede de Contêiner), consulte Trazer seu próprio plug-in da CNI (Interface de Rede de Contêiner).