Configurar a rede de sobreposição do Azure CNI no serviço de Kubernetes do Azure (AKS)

Este artigo explica o processo de configuração, a configuração de rede dual-stack e um exemplo de implantação de carga de trabalho para Azure CNI Overlay em clusters do Azure Kubernetes Service (AKS). Para uma visão geral da rede Azure CNI Overlay, consulte Visão Geral da Azure CNI Overlay networking in Azure Kubernetes Service (AKS).

Importante

A partir de 30 de novembro de 2025, o Azure Kubernetes Service (AKS) deixou de suportar nem fornecer atualizações de segurança para o Azure Linux 2.0. A imagem da máquina virtual do Azure Linux 2.0 está congelada na versão 202512.06.0. A partir de 31 de março de 2026, as imagens dos nós serão removidas e não poderá ajustar o tamanho dos seus pools de nós. Migre para uma versão Azure Linux suportada atualizando os seus pools de nós para uma versão Kubernetes suportada ou migrando para o osSku AzureLinux3. Para mais informações, consulte a edição do Retirement GitHub e o anúncio de reforma do Azure Updates. Para se manter informado sobre anúncios e atualizações, siga as notas de lançamento do AKS.

Pré-requisitos

Uma assinatura do Azure. Se não tiver uma subscrição do Azure, crie uma conta gratuita antes de começar.
CLI do Azure versão 2.48.0 ou posterior. Para instalar ou atualizar a CLI do Azure, consulte Instalar a CLI do Azure.
Um grupo de recursos Azure existente. Se precisar de criar um, veja Criar grupos de recursos.
Se trouxer a sua própria rede virtual, reveja os pré-requisitos para a rede virtual.

Para redes dual-stack, usa uma versão Kubernetes suportada no AKS que esteja disponível na tua região.

Parâmetros-chave para Azure CNI Overlay AKS clusters

A tabela seguinte descreve os parâmetros-chave para configurar a rede Azure CNI Overlay em clusters AKS:

Parâmetro	Description
`--network-plugin`	Defina para `azure` para usar a interface de rede Azure Container Networking Interface (CNI).
`--network-plugin-mode`	Definir para `overlay` para ativar a rede Azure CNI Overlay. Esta definição aplica-se apenas quando `--network-plugin=azure`.
`--pod-cidr`	Especifique um bloco personalizado de pod Classless Inter-Domain Routing (CIDR) para o cluster. A predefinição é `10.244.0.0/16`.

O comportamento padrão para plugins de rede depende de se definir o --network-plugin explicitamente:

Se não especificar --network-plugin, o AKS é definido por padrão para Azure CNI Overlay.
Se especificar --network-plugin=azure e omitir --network-plugin-mode, o AKS usa intencionalmente o modo de rede virtual (sub-rede de nós) para garantir compatibilidade com versões anteriores.

Criar um cluster AKS com Azure CNI Overlay

Crie um cluster AKS Azure CNI Overlay utilizando o comando az aks create com --network-plugin=azure e --network-plugin-mode=overlay. Se não especificar um valor para --pod-cidr, o AKS atribui o valor padrão de 10.244.0.0/16.

az aks create \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --location $REGION \
  --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

Adicionar um pool de nós a uma sub-rede diferente dentro da mesma rede virtual para controlar os endereços IP dos nós de máquinas virtuais (VM) em relação ao tráfego de rede para a rede virtual ou recursos da rede virtual emparelhada.

Adicione um novo pool de nós ao cluster usando o az aks nodepool add comando e especifique o ID do recurso da sub-rede com o --vnet-subnet-id parâmetro. Por exemplo:

az aks nodepool add \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --name $NODE_POOL_NAME \
  --node-count 1 \
  --mode system \
  --vnet-subnet-id $SUBNET_RESOURCE_ID

Clusters AKS com Azure CNI Overlay e rede de dual-stack

Pode implementar os seus clusters Azure CNI Overlay AKS em modo dual-stack com uma rede virtual Azure. Nessa configuração, os nós recebem um endereço IPv4 e IPv6 da sub-rede de rede virtual do Azure. Os pods recebem endereços IPv4 e IPv6 provenientes de um espaço de endereçamento diferente do da sub-rede virtual Azure dos nós. A conversão de endereços de rede (NAT) é então configurada para que os pods possam alcançar recursos na rede virtual do Azure. O endereço IP de origem do tráfego é enviado NAT para o endereço IP principal do nó VM da mesma família (IPv4 para IPv4 e IPv6 para IPv6).

Nota

Também pode implementar clusters de rede dual-stack usando Azure CNI Powered by Cilium. Para mais informações, consulte Dual stack networking com Azure CNI Powered by Cilium.

Limitações do networking em pilha dupla

As seguintes funcionalidades não são suportadas com rede de pilha dupla:

Políticas de rede do Azure
Políticas de rede Calico
Gateway NAT Standard, que suporta apenas IPv4. Para saída dual-stack, use o StandardV2 NAT Gateway. O tipo de saída gerido managedNATGatewayV2 pelo AKS está em pré-visualização. Antes de usar o StandardV2, reveja as suas limitações conhecidas, a disponibilidade regional e os problemas conhecidos. Para orientações de configuração, consulte Criar um gateway NAT gerido ou atribuído pelo utilizador para o seu cluster AKS.
Complemento de nós virtuais

Parâmetros-chave para redes dual-stack

A tabela seguinte descreve os parâmetros-chave para configurar rede dual-stack nos clusters AKS do Azure CNI Overlay.

Parâmetro	Description
`--ip-families`	É necessária uma lista separada por vírgulas de famílias IP para ativar no cluster. Apenas `ipv4` e `ipv4,ipv6` são suportados.
`--pod-cidrs`	Utiliza uma lista separada por vírgulas de intervalos de IPs na notação Classless Inter-Domain Routing (CIDR) para atribuir IPs para pods. A contagem e a ordem dos intervalos nesta lista devem corresponder ao valor fornecido a `--ip-families`. Se não fornecer quaisquer valores, o parâmetro usa o valor padrão de `10.244.0.0/16,fd12:3456:789a::/64`.
`--service-cidrs`	Utiliza uma lista separada por vírgulas de intervalos de endereços IP em notação CIDR para a atribuição de IPs de serviço. A contagem e a ordem dos intervalos nesta lista devem corresponder ao valor fornecido a `--ip-families`. Se não fornecer quaisquer valores, o parâmetro usa o valor padrão de `10.0.0.0/16,fd12:3456:789a:1::/108`. A sub-rede IPv6 atribuída a `--service-cidrs` não pode ser maior que `/108`.

Crie um cluster AKS Azure CNI Overlay dual-stack (Linux)

Crie um grupo de recursos Azure para o cluster usando o az group create comando:
```
az group create --location $REGION --name $RESOURCE_GROUP
```

Crie um cluster AKS dual-stack utilizando o comando az aks create com o parâmetro --ip-families definido para ipv4,ipv6.

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

Crie um cluster AKS de overlay Azure CNI dual-stack (Windows)

Crie um cluster com Azure CNI Overlay usando o az aks create comando:

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

Adicione um pool de nós Windows ao cluster usando o az aks nodepool add comando:

az aks nodepool add \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --os-type Windows \
  --name $WINDOWS_NODE_POOL_NAME \
  --node-count 2

Implementar uma carga de trabalho de exemplo para o cluster AKS do Azure CNI Overlay

Implementar clusters AKS CNI Overlay de dual-stack com endereços IPv4/IPv6 em nós de máquinas virtuais. Este exemplo implementa um servidor web NGINX e expõe-o usando um LoadBalancer serviço com endereços IPv4 e IPv6.

Antes de expor a carga de trabalho, certifique-se de que uma implementação NGINX está a correr no seu cluster. Se ainda não tiver um, crie a implementação e espere que esteja pronta usando os seguintes comandos:

kubectl create deployment nginx --image=nginx
kubectl rollout status deployment/nginx

Nota

Recomendamos o uso do complemento de encaminhamento de aplicações para entrada em clusters AKS. No entanto, para fins de demonstração, este exemplo implementa um servidor web NGINX sem o complemento de encaminhamento de aplicações. Para mais informações sobre o complemento, consulte Entrada NGINX gerida com o complemento de roteamento de aplicações.

Expor a carga de trabalho usando um `LoadBalancer` serviço

Expõe a implementação NGINX usando comandos kubectl ou manifestos YAML.

Esta secção assume que uma implementação NGINX nomeada nginx está a correr no seu cluster. Para verificar se a implementação existe e está pronta, execute kubectl get deployment nginx e confirme que a coluna READY mostra todas as réplicas desejadas como prontas.

Importante

Atualmente, existem duas limitações que se aplicam aos serviços IPv6 no AKS:

O Balanceador de Carga do Azure envia testes de integridade para destinos IPv6 a partir de um endereço de link local. Nos pools de nós do Azure Linux, não se pode encaminhar este tráfego para um pod, por isso o tráfego destinado a serviços IPv6 implementados falha.externalTrafficPolicy: Cluster
Deve implementar serviços IPv6 com externalTrafficPolicy: Local, o que permite que kube-proxy responda à sonda no nó.

Implantação de Kubectl
Implementação YAML

Expor a implementação do NGINX usando o kubectl expose deployment nginx comando. O primeiro comando cria um serviço IPv4 LoadBalancer . O segundo comando cria um serviço IPv6 LoadBalancer e usa o --overrides JSON para definir ipFamilies e IPv6 o necessário externalTrafficPolicy para Local:
```
kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer
kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"externalTrafficPolicy":"Local","ipFamilies":["IPv6"]}}'
```
O seu resultado deve mostrar os serviços expostos. Por exemplo:
```
service/nginx-ipv4 exposed
service/nginx-ipv6 exposed
```

Depois de a implementação ser exposta e os LoadBalancer serviços totalmente provisionados, obtenha os endereços IP dos serviços usando o kubectl get services comando:

kubectl get services

A sua saída deve mostrar os serviços com os endereços IP atribuídos. Por exemplo:

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

Obtenha o IP do serviço usando o kubectl get services comando e defina-o para uma variável de ambiente:

O comando utiliza a expressão {.status.loadBalancer.ingress[0].ip} JSONPath para extrair o endereço IP externo da primeira entrada no campo de entrada do balanceador de carga do serviço e armazená-lo na SERVICE_IP variável.
```
SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
```
Verifique a funcionalidade usando uma curl requisição de um host compatível com IPv6. (O Azure Cloud Shell não é compatível com IPv6.)
```
curl -s "http://[${SERVICE_IP}]" | head -n5
```
A tua saída deve mostrar o HTML da página de boas-vindas do NGINX. Por exemplo:
```
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
```

Expõe a implementação NGINX usando um manifesto YAML. O exemplo seguinte cria dois LoadBalancer serviços: um para IPv4 e outro para IPv6. O serviço IPv6 é implementado com externalTrafficPolicy: Local, o que faz kube-proxy com que responda à sonda no nó.

---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx-ipv4
spec:
  externalTrafficPolicy: Cluster
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx-ipv6
spec:
  externalTrafficPolicy: Local # Deploying the IPv6 service with `externalTrafficPolicy: Local`, which causes `kube-proxy` to respond to the probe on the node
  ipFamilies:
    - IPv6
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: nginx
  type: LoadBalancer

Depois de a implementação ser exposta e os LoadBalancer serviços totalmente provisionados, obtenha os endereços IP dos serviços usando o kubectl get services comando:

kubectl get services

A sua saída deve mostrar os serviços com os endereços IP atribuídos. Por exemplo:

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

Para saber mais sobre a rede Azure CNI Overlay no AKS, consulte os seguintes artigos:

Comentários

Esta página foi útil?

Last updated on 2026-08-13