Criar um cluster do AKS (Serviço de Kubernetes do Azure) que usa zonas de disponibilidade

Artigo
12/06/2023

Um cluster do AKS (Serviço de Kubernetes do Azure) distribui recursos como nós e armazenamento entre seções lógicas da infraestrutura subjacente do Azure. O uso de zonas de disponibilidades separa fisicamente os nós de outros nós implantados em diferentes zonas de disponibilidade. Os clusters do AKS implantados com várias zonas de disponibilidade configuradas em um cluster fornecem um nível mais alto de disponibilidade para proteger contra uma falha de hardware ou um evento de manutenção planejada.

Definindo pools de nós em um cluster para abranger várias zonas, os nós em um determinado pool de nós podem continuar operando mesmo se uma única zona ficar inoperante. Seus aplicativos podem continuar disponíveis mesmo se houver uma falha física em um único datacenter, se orquestrados para tolerar a falha de um subconjunto de nós.

Este artigo mostra como criar um cluster do AKS e distribuir os componentes do nó entre zonas de disponibilidade.

Antes de começar

Você precisará da CLI do Azure versão 2.0.76 ou posterior instalada e configurada. Execute az --version para encontrar a versão. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.

Limitações e disponibilidade de região

Os clusters do AKS podem usar zonas de disponibilidade em qualquer região do Azure que tenha zonas de disponibilidade.

As seguintes limitações se aplicam quando você cria um cluster do AKS usando zonas de disponibilidade:

Você só pode definir zonas de disponibilidade durante a criação do cluster ou pool de nós.
Não é possível atualizar um cluster de zona de não disponibilidade existente para usar zonas de disponibilidade depois de criar o cluster.
O tamanho do nó escolhido (SKU da VM) selecionado deve estar disponível em todas as zonas de disponibilidade selecionadas.
Clusters com zonas de disponibilidade habilitadas exigem o uso do Azure Standard Load Balancer para distribuição entre zonas. Você só pode definir esse tipo de balanceador de carga no momento da criação do cluster. Para saber mais e ver as limitações do Standard Load Balancer, confira Limitações da SKU do Azure Load Balancer Standard.

Suporte à zona de disponibilidade de disco do Azure

Volumes que usam os discos LRS gerenciados pelo Azure não são os recursos com redundância de zona, não há suporte para anexação entre zonas. Você precisa colocar volumes na mesma zona que o nó especificado que hospeda o pod de destino.
Os volumes que usam os discos ZRS gerenciados do Azure não são recursos com redundância de zona. Você pode agendar esses volumes em todos os nós de agente de zona e não de zona. Aqui está um exemplo de como criar uma classe de armazenamento usando o disco StandardSSD_ZRS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-csi-zrs
provisioner: disk.csi.azure.com
parameters:
  skuName: StandardSSD_ZRS  # or Premium_ZRS
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

O Kubernetes está ciente das zonas de disponibilidade do Azure desde a versão 1.12. É possível implantar um objeto PersistentVolumeClaim referenciando um Disco Gerenciado do Azure em um cluster do AKS de várias zonas e o Kubernetes cuida do agendamento de qualquer pod que declara esse PVC na zona de disponibilidade correta.

Modelos de Azure Resource Manager e zonas de disponibilidade

Ao criar um cluster do AKS, entenda os seguintes detalhes sobre como especificar zonas de disponibilidade em um modelo:

Se você definir explicitamente um valor nulo em um modelo, por exemplo, especificando "availabilityZones": null, o modelo do Resource Manager tratará a propriedade como se ela não existisse. Isso significa que o cluster não é implantado em uma zona de disponibilidade.
Se você não incluir a propriedade "availabilityZones": em seu modelo do Resource Manager, o cluster não será implantado em uma zona de disponibilidade.
Você não pode atualizar as configurações de zonas de disponibilidade em um cluster existente. O comportamento é diferente ao atualizar um cluster do AKS com modelos do Resource Manager. Se você definir explicitamente um valor nulo em seu modelo para zonas de disponibilidade e atualizar o cluster, isso não atualizará o cluster para zonas de disponibilidade. No entanto, se você omitir a propriedade de zonas de disponibilidade com sintaxe como "availabilityZones": [], a implantação tentará desabilitar as zonas de disponibilidade no cluster do AKS existente e falhará.

Visão geral das zonas de disponibilidade para clusters do AKS

As zonas de disponibilidade são uma oferta de alta disponibilidade que protege os aplicativos e dados contra falhas do 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. Para garantir a resiliência, há sempre mais de uma zona em todas as regiões habilitadas para zona. A separação física das zonas de disponibilidade dentro de uma região protege os aplicativos e os dados contra falhas do datacenter.

Para saber mais, confira O que são zonas de disponibilidade no Azure?.

Os clusters do AKS implantados usando zonas de disponibilidade podem distribuir nós entre várias zonas em uma única região. Por exemplo, um cluster na regiãoLeste dos EUA 2 pode criar nós em todas as três zonas de disponibilidade no Leste dos EUA 2. Essa distribuição de recursos de cluster do AKS melhora a disponibilidade do cluster, pois eles são resilientes à falha de uma zona específica.

AKS node distribution across availability zones

Se uma única zona ficar indisponível, seus aplicativos continuarão a ser executados em clusters configurados para distribuição entre várias zonas.

Observação

Ao implementar zonas de disponibilidade com o autoscaler de cluster, recomendamos usar um único pool de nós para cada zona. Você pode definir o --balance-similar-node-groups parâmetro para True manter uma distribuição equilibrada de nós entre zonas para suas cargas de trabalho durante as operações de expansão. Quando essa abordagem não é implementada, as operações de redução de escala podem interromper o equilíbrio de nós entre zonas.

Criar um cluster do AKS entre zonas de disponibilidade

Quando você cria um cluster usando o comando az aks create, o parâmetro --zones especifica em quais zonas de disponibilidade implantar os nós de agente. As zonas de disponibilidade nas quais os componentes do plano de controle gerenciado são implantados não são controladas por esse parâmetro. São distribuídos automaticamente em todas as zonas de disponibilidade (se houver) na região durante a implantação do cluster.

O exemplo abaixo criar um cluster do AKS chamado myAKSCluster no grupo de recursos chamado myResourceGroup com um total de três nós. Um nó de agente na zona 1, um em 2 e um em 3.

az group create --name myResourceGroup --location eastus2

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --generate-ssh-keys \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --node-count 3 \
    --zones 1 2 3

Leva alguns minutos para o cluster do AKS ser criado.

Ao decidir a qual zona um novo nó deve pertencer, um pool de nós do AKS especificado usa um melhor balanceamento de zona de esforço oferecido pelos Conjuntos de Dimensionamento de Máquinas Virtuais do Azure subjacentes. O pool de nós do AKS é “balanceado” quando cada zona tem o mesmo número de VMs ou +- uma VM em todas as outras zonas para o conjunto de dimensionamento.

Verificar a distribuição de nós entre zonas

Quando o cluster estiver pronto, liste a zona de disponibilidade em que os nós de agente no conjunto de dimensionamento estão.

Primeiro, obtenha as credenciais do cluster do AKS usando o comando az aks get-credentials:

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Em seguida, use o comando kubectl describe para listar os nós no cluster e filtrar os resultados com o valor topology.kubernetes.io/zone. O exemplo a seguir é para um shell Bash.

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

A saída de exemplo a seguir mostra os três nós distribuídos pela região especificada e zonas de disponibilidade, como eastus2-1 para a primeira zona de disponibilidade e eastus2-2 para a segunda zona de disponibilidade:

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3

À medida que você adiciona nós a um pool de agentes, a plataforma do Azure distribui automaticamente as VMs subjacentes entre as zonas de disponibilidade especificadas.

Com as versões 1.17.0 e posteriores do Kubernetes, o AKS usa o rótulo mais recente topology.kubernetes.io/zone e o failure-domain.beta.kubernetes.io/zone preterido. Você pode obter o mesmo resultado da execução do comando kubelet describe nodes na etapa anterior, executando o seguinte script:

kubectl get nodes -o custom-columns=NAME:'{.metadata.name}',REGION:'{.metadata.labels.topology\.kubernetes\.io/region}',ZONE:'{metadata.labels.topology\.kubernetes\.io/zone}'

O exemplo a seguir é semelhante à saída com mais detalhes:

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

Verificar a distribuição de pods entre zonas

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 testar o rótulo e dimensionar o cluster de 3 para 5 nós, execute o seguinte comando para verificar se o pod é distribuído corretamente:

az aks scale \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 5

Quando a operação de escala for concluída após alguns minutos, execute o comando kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone" em um shell Bash. A saída a seguir é semelhante aos resultados:

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3
Name:       aks-nodepool1-28993262-vmss000003
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000004
            topology.kubernetes.io/zone=eastus2-2

Agora você tem mais dois nós nas zonas 1 e 2. Você pode implantar um aplicativo que consiste em três réplicas. O exemplo a seguir usa NGINX:

kubectl create deployment nginx --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
kubectl scale deployment nginx --replicas=3

Exibindo os nós em que os pods estão em execução, você vê os pods em execução nos nós correspondentes a três zonas de disponibilidade diferentes. Por exemplo, com o comando kubectl describe pod | grep -e "^Name:" -e "^Node:" em um shell Bash, você verá a seguinte saída de exemplo:

Name:         nginx-6db489d4b7-ktdwg
Node:         aks-nodepool1-28993262-vmss000000/10.240.0.4
Name:         nginx-6db489d4b7-v7zvj
Node:         aks-nodepool1-28993262-vmss000002/10.240.0.6
Name:         nginx-6db489d4b7-xz6wj
Node:         aks-nodepool1-28993262-vmss000004/10.240.0.8

Como você pode ver na saída anterior, o primeiro pod está em execução no nó 0, localizado na zona de disponibilidade eastus2-1. O segundo pod está em execução no nó 2, que corresponde a eastus2-3 e o terceiro no nó 4, em eastus2-2. Sem nenhuma configuração adicional, o Kubernetes distribui os pods corretamente entre todas as três zonas de disponibilidade.

Próximas etapas

Esse artigo descreveu como criar um cluster do AKS usando zonas de disponibilidade. Para mais considerações sobre clusters altamente disponíveis, confira Melhores práticas para a continuidade dos negócios e recuperação de desastres no AKS.