Compartilhar via

Zonas de disponibilidade no Azure Kubernetes Service (AKS)

  • Artigo

Zonas de disponibilidade ajudam a proteger seus aplicativos e dados contra falhas no datacenter. As zonas são locais físicos exclusivos em uma região do Azure. Cada zona inclui um ou mais datacenters equipados com energia, resfriamento e rede independentes.

Usar o AKS com zonas de disponibilidade distribui fisicamente os recursos entre diferentes zonas de disponibilidade dentro de uma única região, melhorando a confiabilidade. A implantação de nós em várias zonas não gera custos adicionais.

Esse artigo mostra como configurar recursos do AKS para usar Zonas de Disponibilidade.

Recursos da AKS

Esse diagrama mostra os recursos do Azure que são criados quando você cria um cluster do AKS:

Diagrama que mostra vários componentes do AKS, mostrando os componentes do AKS hospedados pela Microsoft e os componentes do AKS na sua assinatura do Azure.

Plano de Controle AKS

A Microsoft hospeda o plano de controle do AKS, o servidor da API do Kubernetes e serviços como scheduler e etcd como um serviço gerenciado. A Microsoft replica o plano de controle em várias zonas.

Outros recursos do seu cluster são implantados em um grupo de recursos gerenciados na sua assinatura do Azure. Por padrão, esse grupo de recursos é prefixado com MC_, para Cluster Gerenciado, e contém os seguintes recursos:

Pools de nós

Os pools de nós são criados como um conjunto de dimensionamento de máquina virtual na sua assinatura do Azure.

Ao criar um cluster AKS, um pool de nós do sistema é necessário e criado automaticamente. Ele hospeda pods de sistema críticos, como CoreDNS e metrics-server. Mais pools de nós de usuário podem ser adicionados ao seu cluster AKS para hospedar seus aplicativos.

Há três maneiras de implantar pools de nós:

  • Abrangendo zona
  • Zona alinhada
  • Regional

Diagrama que mostra a distribuição dos nós do AKS entre as zonas de disponibilidade nos diferentes modelos.

Para o pool de nós do sistema, o número de zonas usadas é configurado quando o cluster é criado.

Abrangendo zona

Um conjunto de escala de abrangência de zona distribui nós por todas as zonas selecionadas, especificando essas zonas com o parâmetro --zones.

# Create an AKS Cluster, and create a zone spanning System Nodepool in all three AZs, one node in each AZ
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1, 2, 3
# Add one new zone spanning User Nodepool, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a  --node-count 6 --zones 1, 2, 3

O AKS equilibra o número de nós entre zonas automaticamente.

Se ocorrer uma interrupção zonal, os nós dentro da zona afetada podem ser afetados, enquanto os nós em outras zonas de disponibilidade permanecem inalterados.

Zona alinhada

Cada nó é alinhado (fixado) a uma zona específica. Para criar três pools de nós para uma região com três Zonas de Disponibilidade:

# # Add three new zone aligned User Nodepools, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-x  --node-count 2 --zones 1
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-y  --node-count 2 --zones 2
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-z  --node-count 2 --zones 3

Essa configuração pode ser usada quando você precisa de menor latência entre nós. Ele também fornece um controle mais granular sobre as operações de dimensionamento ou ao usar o cluster autoscaler.

Observação

  • Se uma única carga de trabalho for implantada em pools de nós, recomendamos definir --balance-similar-node-groups como true para manter uma distribuição equilibrada de nós entre zonas para suas cargas de trabalho durante operações de expansão.

Regional (não usando Zonas de Disponibilidade)

O modo regional é usado quando a atribuição de zona não está definida no modelo de implantação ("zones"=[] or "zones"=null).

Nessa configuração, o pool de nós cria instâncias regionais (não fixadas por zona) e coloca implicitamente instâncias em toda a região. Não há garantia de equilíbrio ou distribuição entre zonas, ou que as instâncias caiam na mesma zona de disponibilidade.

No caso raro de uma interrupção zonal completa, qualquer ou todas as instâncias dentro do pool de nós podem ser afetadas.

Para validar os locais dos nós, execute o seguinte comando:

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   eastus-1
aks-nodepool1-34917322-vmss000001   eastus   eastus-2
aks-nodepool1-34917322-vmss000002   eastus   eastus-3

Implantações

Pods

O Kubernetes está ciente das Zonas de Disponibilidade do Azure e pode balancear pods entre nós em diferentes zonas. Caso uma zona fique indisponível, o Kubernetes move os pods para longe dos nós afetados automaticamente.

Conforme documentado em Well-Known Labels, Annotations and Taints, o Kubernetes usa o rótulo de topology.kubernetes.io/zone para distribuir automaticamente os pods em um serviço ou controlador de replicação entre as diferentes zonas disponíveis.

Para visualizar em quais pods os nós estão sendo executados, execute o seguinte comando:

  kubectl describe pod | grep -e "^Name:" -e "^Node:"

O parâmetro “maxSkew” descreve o grau em que os Pods podem ser distribuídos de forma desigual. Supondo três zonas e três réplicas, definir esse valor como 1 garante que cada zona tenha pelo menos um pod em execução:

kind: Pod
apiVersion: v1
metadata:
  name: myapp
spec:
  replicas: 3
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule # or ScheduleAnyway
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Armazenamento e volumes

Por padrão, as versões 1.29 e posteriores do Kubernetes usam o Azure Managed Disks usando Zone-Redundant-Storage (ZRS) para declarações de volume persistentes.

Esses discos são replicados entre zonas para aumentar a resiliência dos seus aplicativos e proteger seus dados contra falhas no datacenter.

Um exemplo de uma reivindicação de volume persistente que usa SSD Standard no ZRS:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-csi
  #storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 5Gi

Para implantações alinhadas por zona, você pode criar uma nova classe de armazenamento com o parâmetro skuname definido como LRS (Armazenamento Redundante Local). Em seguida, você poderá usar a nova classe de armazenamento na PVC (Declaração de Volume Persistente).

Embora os discos LRS sejam mais baratos, eles não são redundantes em termos de zona e não há suporte para anexar um disco a um nó em uma zona diferente.

Um exemplo de uma classe de armazenamento SSD Standard LRS:

kind: StorageClass

metadata:
  name: azuredisk-csi-standard-lrs
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
  #skuname: PremiumV2_LRS

Balanceadores de Carga

O Kubernetes implanta um Standard Load Balancer do Azure por padrão, que equilibra o tráfego de entrada em todas as zonas de uma região. Se um nó ficar indisponível, o balanceador de carga redirecionará o tráfego para nós saudáveis.

Um exemplo de serviço que usa o Azure Load Balancer:

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080

Importante

Em 30 de setembro de 2025, o Balanceador de Carga Básico será desativado. Para saber mais, confira o anúncio oficial. Se você estiver usando o Balanceador de Carga Básico, certifique-se de atualizar para o Standard Load Balancer antes da data de descontinuação.

Limitações

As seguintes limitações se aplicam ao usar Zonas de Disponibilidade:

Próximas etapas