Compartilhar via

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

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 (Serviço de Kubernetes do Azure) com zonas de disponibilidade distribui fisicamente recursos entre diferentes zonas de disponibilidade em uma única região, melhorando a confiabilidade. Implantar nós em várias zonas não incorre em custos extras. Este artigo mostra como configurar recursos do AKS para usar zonas de disponibilidade.

Limitações e considerações

Tenha em mente as seguintes limitações e considerações ao usar zonas de disponibilidade no AKS:

Componentes de cluster do AKS

O diagrama a seguir mostra os vários componentes de um cluster do AKS, incluindo componentes do AKS hospedados pela Microsoft e componentes do AKS em sua assinatura do Azure.

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

Plano de controle do AKS

A Microsoft hospeda o plano de controle do AKS, o servidor de API do Kubernetes e serviços como scheduler e etcd como serviços gerenciados. 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 recursos descritos nas seções a seguir.

Pools de nós

Os pools de nodos são criados como conjuntos de dimensionamento de máquinas virtuais em sua assinatura do Azure.

Quando você cria um cluster do AKS, ele requer um pool de nós do sistema. Esse pool de nós é criado automaticamente e hospeda pods críticos do sistema, como CoreDNS e metrics-server. Você pode adicionar mais pools de nós de usuário ao cluster do AKS para hospedar seus aplicativos.

Você pode implantar pools de nós de três maneiras: abrangendo múltiplas zonas, alinhado a uma zona específica ou regional (sem usar zonas de disponibilidade).

O diagrama a seguir mostra a distribuição de nós entre zonas de disponibilidade em cada um dos três modelos:

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

As zonas de pool de nós do sistema são configuradas quando você cria um cluster ou pool de nós.

Pools de nós que abrangem múltiplas zonas

Em pools de nós que abrangem várias zonas, os nós são distribuídos em todas as zonas selecionadas. O AKS equilibra automaticamente o número de nós entre zonas. Se ocorrer uma interrupção de zona, os nós dentro da zona afetada poderão ser afetados, mas os nós em outras zonas de disponibilidade permanecerão inalterados.

Você pode especificar zonas usando o parâmetro --zones ao criar um cluster AKS usando o comando az aks create ou pool de nós usando o comando az aks nodepool add. Por exemplo:

# Create an AKS cluster with a zone-spanning system node pool in all three availability zones with one node in each availability zone
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1 2 3

# Add one new zone-spanning user node pool with two nodes in each availability zone
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a  --node-count 6 --zones 1 2 3

Grupos de nós alinhados à zona

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 as zonas para suas cargas de trabalho durante as operações de escala.

Nesta configuração, cada nó será alinhado (fixado) a uma zona específica. Você pode usar essa configuração quando precisar de latência mais baixa entre nós, controle mais granular sobre operações de dimensionamento ou quando estiver usando o dimensionador automático de cluster.

Os comandos a seguir criam três pools de nós para uma região com três zonas de disponibilidade usando o az aks nodepool add comando com o --zones parâmetro para especificar a zona para cada pool de nós:

# Add three new zone-aligned user node pools with 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

Pools de nós regionais

O modo regional é usado quando você não define uma atribuição de zona no modelo de implantação (por exemplo, "zones"=[] ou "zones"=null).

Nesta configuração, o pool de nós cria instâncias regionais (não fixadas à zona) e coloca instâncias implicitamente em toda a região. Não há garantia de que as instâncias sejam equilibradas ou distribuídas entre zonas, nem de que as instâncias estejam na mesma zona de disponibilidade. No raro caso de uma interrupção total na zona, qualquer instância dentro do pool de nós pode ser afetada.

Implantações

Cápsulas

O Kubernetes reconhece as zonas de disponibilidade do Azure e pode balancear os 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 na referência do Kubernetes Rótulos, anotações e taints conhecidos, 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 várias zonas disponíveis.

O parâmetro maxSkew descreve o grau de distribuição desigual dos pods. Supondo que haja três zonas e três réplicas, defina esse valor como 1 garante que cada zona tenha pelo menos um pod em execução. Por exemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-app
      containers:
      - name: my-container
        image: my-image

Armazenamento e volumes

Por padrão, o Kubernetes versões 1.29 e posteriores usam Azure Managed Disks que usam armazenamento com redundância de zona para PVCs (Declarações de Volume Persistente). Esses discos são replicados entre zonas para aprimorar a resiliência de seus aplicativos.

O exemplo a seguir mostra uma PVC que usa o SSD Standard do Azure no armazenamento com redundância de zona:

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 à zona, você pode criar uma nova classe de armazenamento com o skuname parâmetro definido como LRS (armazenamento com redundância local). Em seguida, você poderá usar a nova classe de armazenamento na sua PVC.

Embora os discos de armazenamento com redundância local sejam mais baratos, eles não são redundantes em nível de zona, e não é suportado anexar um disco a um nó em uma zona diferente.

O exemplo a seguir mostra uma classe de armazenamento SSD Standard com redundância local:

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

Balanceadores de carga

Importante

A partir de 30 de setembro de 2025, o AKS (Serviço de Kubernetes do Azure) não dá mais suporte ao Load Balancer Básico. Para evitar possíveis interrupções de serviço, recomendamos usar o Standard Load Balancer para novas implantações e atualizar quaisquer implantações existentes para o Standard Load Balancer. Para obter mais informações sobre essa desativação, consulte o problema de desativação do GitHub e o anúncio de desativação do Azure Updates. Para se manter informado sobre anúncios e atualizações, acompanhe as notas de lançamento do AKS.

O Kubernetes implanta o Azure Standard Load Balancer 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.

O exemplo a seguir mostra um 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

Validar locais dos nós de rede

Valide a distribuição de nós entre zonas de disponibilidade usando o seguinte kubectl get nodes comando:

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

Exemplo de saída:

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

Listar pods e nós em execução

Verifique quais pods e nós estão em execução usando o comando kubectl describe. Por exemplo:

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

Conteúdo relacionado

Para saber mais sobre confiabilidade no AKS, confira os seguintes artigos:

  • Last updated on