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. A implantação de nós em várias zonas não gera custos adicionais. Para obter mais informações sobre os recursos de confiabilidade do AKS, incluindo zonas de disponibilidade, configurações de várias regiões, confiabilidade durante a manutenção do serviço e backup, consulte Confiabilidade no AKS.

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

Recursos do AKS

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

Plano de controle do 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 recursos mencionados 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, um pool de nós do sistema é necessário e é criado automaticamente. Ele hospeda pods de sistema críticos, como CoreDNS e metrics-server. Você pode adicionar mais pools de nós de usuário ao cluster do AKS para hospedar seus aplicativos.

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

• Extensão de zona
• Alinhado à zona
• Regional

As zonas do pool de nós do sistema são configuradas quando o cluster ou o pool de nós é criado.

Extensão de zona

Nessa configuração, os nós são distribuídos em todas as zonas selecionadas. Essas zonas são especificadas usando o --zones parâmetro.

# Create an AKS cluster, and create a zone-spanning system node pool 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 node pool, 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 automaticamente o número de nós entre zonas.

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

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

kubectl get nodes -o custom-columns='NAME:metadata.name, REGION:metadata.labels.topology\.kubernetes\.io/region, ZONE:metadata.labels.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

Alinhado à zona

Nesta configuração, cada nó será 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 node pools, 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 controle mais granular sobre operações de dimensionamento ou quando você está usando o dimensionador automático de cluster.

Regional (não usando zonas de disponibilidade)

O modo regional é usado quando a atribuição de zona não é definida 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 caso raro de uma interrupção total da zona, qualquer instância ou todas as instâncias no pool de nós poderão ser afetadas.

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

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

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   0
aks-nodepool1-34917322-vmss000001   eastus   0
aks-nodepool1-34917322-vmss000002   eastus   0

Implantações

Cápsulas

O Kubernetes tem conhecimento das zonas de disponibilidade do Azure e pode equilibrar 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 na referência do Kubernetes Rótulos, Anotações e Restrições Bem Conhecidos, o Kubernetes usa o rótulo topology.kubernetes.io/zone para distribuir automaticamente pods em um controlador de replicação ou serviço nas várias zonas disponíveis.

Para ver quais pods e nós estão em execução, execute o seguinte comando:

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

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

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, as versões do Kubernetes 1.29 e posteriores usam discos gerenciados do Azure usando o armazenamento com redundância de zona para Declarações de Volume Persistente.

Esses discos são replicados entre zonas, para aprimorar a resiliência de seus aplicativos. Essa ação ajuda a proteger seus dados contra falhas de datacenter.

O exemplo a seguir mostra uma Declaração de Volume Persistente que usa SSD Standard do Azure em 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ê pode usar a nova classe de armazenamento em sua Declaração de Volume Persistente.

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

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.

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

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

Limitações

As seguintes limitações se aplicam quando você está usando zonas de disponibilidade:

• Confira 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 poderá ser alterado após a criação do pool de nós.
• A maioria das regiões dá suporte a zonas de disponibilidade. Confira uma lista de regiões.

Conteúdo relacionado

• Saiba mais sobre confiabilidade no AKS.
• Saiba mais sobre pools de nós do sistema.
• Saiba mais sobre pools de nós de usuário.
• Saiba mais sobre balanceadores de carga.
• Obtenha as práticas recomendadas para continuidade dos negócios e recuperação de desastres no AKS.