Partilhar via

Zonas de disponibilidade no Serviço Kubernetes do Azure (AKS)

  • Artigo

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

O uso do 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 incorre em custos adicionais.

Este artigo mostra como configurar os recursos do AKS para usar zonas de disponibilidade.

Recursos do AKS

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

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

Plano de controle AKS

A Microsoft hospeda o plano de controle AKS, o servidor de 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 cluster são implantados em um grupo de recursos gerenciado em sua assinatura do Azure. Por padrão, esse grupo de recursos é prefixado com MC_, para Cluster Gerenciado e contém os seguintes recursos:

Conjuntos de nós

Os pools de nós são criados como um Conjunto de Escala de Máquina Virtual em sua Assinatura do Azure.

Quando você cria um cluster AKS, um pool de nós do sistema é necessário e criado automaticamente. Ele hospeda pods críticos do sistema, 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 pelas quais os pools de nós podem ser implantados:

  • Abrangência da zona
  • Zona alinhada
  • Regional

Diagrama que mostra a distribuição do nó AKS entre 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.

Abrangência da zona

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

# 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ê precisar de latência mais baixa entre nós. Ele também fornece um controle mais granular sobre operações de dimensionamento ou ao usar o autoscaler de cluster.

Nota

  • Se uma única carga de trabalho for implantada em pools de nós, recomendamos a configuração --balance-similar-node-groups para true manter uma distribuição equilibrada de nós entre zonas para suas cargas de trabalho durante as 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 em 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 aterrissem 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 locais de 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

Implementações

Pods

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

Conforme documentado em Rótulos, anotações e manchas conhecidos, o Kubernetes usa o topology.kubernetes.io/zone rótulo para distribuir automaticamente pods em um controlador ou serviço de replicação nas diferentes zonas disponíveis.

Para exibir em quais nós pods 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 o ZRS (Zone-Redundant-Storage) para declarações de volume persistentes.

Esses discos são replicados entre zonas, a fim de aumentar a resiliência de seus aplicativos e proteger seus dados contra falhas de datacenter.

Um exemplo de uma declaração de volume persistente que usa SSD padrão 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 skuname parâmetro definido como LRS (Armazenamento Localmente Redundante). Em seguida, você pode usar a nova classe de armazenamento em sua Reivindicação de Volume Persistente (PVC).

Embora os discos LRS sejam mais baratos, eles não são redundantes de zona, e anexar um disco a um nó em uma zona diferente não é suportado.

Um exemplo de uma classe de armazenamento SSD padrão 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 Balanceador de Carga Padrão 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 íntegros.

Um exemplo de Serviço que usa o Balanceador de Carga do Azure:

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 Basic Load Balancer será aposentado. Para obter mais informações, veja o anúncio oficial. Se você estiver usando o Basic Load Balancer, certifique-se de atualizar para o Standard Load Balancer antes da data de desativação.

Limitações

As seguintes limitações se aplicam ao usar zonas de disponibilidade:

Próximos passos