Partilhar via

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

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 \
    --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

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

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>

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.

Importante

Os recursos de visualização do AKS estão disponíveis em uma base de autosserviço e opt-in. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As visualizações do AKS são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço. Como tal, estas funcionalidades não se destinam a utilização em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

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.

Importante

Os recursos de visualização do AKS estão disponíveis em uma base de autosserviço e opt-in. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As visualizações do AKS são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço. Como tal, estas funcionalidades não se destinam a utilização em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

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 atualizar clusters existentes para a sobreposição CNI do Azure, consulte Atualizar modos IPAM do Serviço Kubernetes do Azure (AKS) e Tecnologia de Dataplane.

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