Zonas de disponibilidade no Serviço Kubernetes do Azure (AKS)
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:
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
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
paratrue
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:
- Consulte Cotas, restrições de tamanho de máquina virtual e disponibilidade de região no AKS.
- O número de zonas de disponibilidade usadas não pode ser alterado após a criação do pool de nós.
- A maioria das regiões suporta zonas de disponibilidade. Uma lista pode ser encontrada aqui.
Próximos passos
- Saiba mais sobre o pool de nós do sistema
- Saiba mais sobre os pools de nós de usuário
- Saiba mais sobre Load Balancers
- Práticas recomendadas para continuidade de negócios e recuperação de desastres no AKS
Azure Kubernetes Service