Recomendações de resiliência de zona para o Serviço Kubernetes do Azure (AKS)

A resiliência de zona é uma parte fundamental da execução de clusters Kubernetes de nível de produção. Com a escalabilidade em seu núcleo, o Kubernetes aproveita ao máximo a infraestrutura independente em data centers sem incorrer em custos adicionais, provisionando novos nós apenas quando necessário.

Neste artigo, você aprenderá sobre as várias recomendações para resiliência de zona no Serviço Kubernetes do Azure (AKS), incluindo como:

• Torne a zona de componentes do cluster AKS resiliente
• Projetar uma aplicação sem estado
• Tome a decisão sobre o disco de armazenamento
• Testar a resiliência da zona de disponibilidade (AZ)

Torne a zona de componentes do cluster AKS resiliente

As seções a seguir fornecem orientação sobre os principais pontos de decisão para tornar a zona de componentes do cluster AKS resiliente, mas não são exaustivas. Você deve considerar outros fatores com base em seus requisitos e restrições específicos e verificar suas outras dependências para garantir que elas estejam configuradas para resiliência de zona.

Criar clusters redundantes de zonas e pools de nós

O AKS permite que você selecione várias AZs durante a criação do cluster e do pool de nós. Quando você cria um cluster em uma região que tem várias AZs, o plano de controle é automaticamente distribuído por todas as AZs nessa região. No entanto, os nós no pool de nós estão espalhados apenas pelas AZs selecionadas. Essa abordagem garante que o plano de controle e os nós sejam distribuídos em várias AZs, fornecendo resiliência em caso de falha de AZ. Você pode configurar AZs usando o portal do Azure, a CLI do Azure ou os modelos do Azure Resource Manager.

O exemplo a seguir mostra como criar um cluster com três nós espalhados por três AZs usando a CLI do Azure:

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

Depois que o cluster for criado, você poderá usar o seguinte comando para recuperar a região e a zona de disponibilidade para cada nó do agente dos rótulos:

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

A saída de exemplo a seguir mostra a região e a zona de disponibilidade para cada nó de agente:

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

Para obter mais informações, consulte Usar zonas de disponibilidade no Serviço Kubernetes do Azure (AKS).

Certifique-se de que os pods estão espalhados pelas zonas de disponibilidade (AZs)

A partir da versão 1.33 do Kubernetes, conforme descrito abaixo, o Kube-Scheduler padrão no AKS é configurado para utilizar um valor de 1 para MaxSkew.

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

Essa configuração se desvia do padrão upstream, visando apenas uma única diferença de pod entre zonas. Como resultado, os pods são distribuídos de forma mais uniforme entre as zonas, reduzindo a probabilidade de que uma falha zonal resulte em uma interrupção da implantação correspondente.

No entanto, se a tua implementação tiver necessidades específicas de topologia, podes substituir os valores padrão acima, adicionando os teus próprios na especificação do pod. Podes usar restrições de distribuição de topologia de pod com base nos rótulos zone e hostname para distribuir pods entre AZs dentro de uma região e entre hosts dentro de AZs.

Por exemplo, digamos que você tenha um cluster de quatro nós onde três pods rotulados app: mypod-app estão localizados em node1, node2e node3 respectivamente. Se quiser que a nova implantação seja hospedada em nós distintos o mais possível, pode utilizar um manifesto semelhante ao exemplo que se segue:

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

Para obter mais informações sobre como configurar a distribuição de pods e entender as implicações de MaxSkew, consulte a documentação sobre a Topologia de Pods do Kubernetes. Por exemplo, como nodeTaintsPolicy: Honor afeta a distribuição dos pods.

Configurar rede com reconhecimento de AZ

Se você tiver pods que atendem ao tráfego de rede, deverá balancear a carga do tráfego em várias AZs para garantir que seu aplicativo esteja altamente disponível e resiliente a falhas. Você pode usar o Azure Load Balancer para distribuir o tráfego de entrada entre os nós em seu cluster AKS.

O Azure Load Balancer dá suporte ao balanceamento de carga interno e externo, e você pode configurá-lo para usar uma SKU padrão para balanceamento de carga com redundância de zona. O SKU padrão é o SKU padrão no AKS e suporta resiliência regional com zonas de disponibilidade para garantir que seu aplicativo não seja afetado por uma falha de região. No caso de um cenário de falha de zona, um balanceador de carga SKU Standard com redundância de zona não é afetado pela falha e permite que as suas implementações continuem a gerir o tráfego das zonas restantes. Você pode usar um balanceador de carga global, como Front Door ou Traffic Manager, ou pode usar balanceadores de carga entre regiões na frente de seus clusters AKS regionais para garantir que seu aplicativo não seja afetado por falhas regionais. Para criar um balanceador de carga SKU padrão no AKS, consulte Usar um balanceador de carga padrão no Serviço Kubernetes do Azure (AKS).

Para garantir que o tráfego de rede do seu aplicativo seja resiliente a falhas, você deve configurar a rede com reconhecimento de AZ para suas cargas de trabalho do AKS. O Azure oferece vários serviços de rede que suportam AZs:

• Gateway de VPN do Azure: você pode implantar gateways VPN e ExpressRoute em AZs do Azure para permitir melhor resiliência, escalabilidade e disponibilidade para gateways de rede virtual. Para obter mais informações, consulte Criar gateways de rede virtual com redundância de zona em zonas de disponibilidade.
• Azure Application Gateway v2: O Azure Application Gateway fornece um balanceador de carga L7 regional com suporte à zona de disponibilidade. Para obter mais informações, consulte Tráfego Web direto com o Gateway de Aplicativo do Azure.
• Azure Front Door: o Azure Front Door fornece um balanceador de carga L7 global e aproveita pontos de presença (POPs) ou CDN (Rede de Entrega de Conteúdo) do Azure. Para obter mais informações, consulte Locais POP do Azure Front Door.

Configurar um registro de contêiner com redundância de zona e replicado geograficamente

Para garantir que suas imagens de contêiner estejam altamente disponíveis e resilientes a falhas, você deve configurar um registro de contêiner com redundância de zona. O Azure Container Registry (ACR) Premium SKU suporta replicação geográfica e redundância de zona opcional. Esses recursos fornecem disponibilidade e reduzem a latência para operações regionais.

Garanta disponibilidade e redundância para chaves e segredos

O Azure Key Vault fornece várias camadas de redundância para garantir que suas chaves e segredos permaneçam disponíveis para seu aplicativo, mesmo se os componentes individuais do serviço falharem ou se as regiões ou AZs do Azure não estiverem disponíveis. Para obter mais informações, consulte Disponibilidade e redundância do Azure Key Vault.

Aproveite os recursos de dimensionamento automático

Você pode melhorar a disponibilidade e a resiliência do aplicativo no AKS usando recursos de dimensionamento automático, que ajudam a atingir os seguintes objetivos:

• Otimize a utilização de recursos e a eficiência de custos aumentando ou diminuindo a escala com base no uso de CPU e memória de seus pods.
• Melhore a tolerância a falhas e a recuperação adicionando mais nós ou pods quando ocorrer uma falha numa zona.

Você pode usar o Horizontal Pod Autoscaler (HPA) e o Cluster Autoscaler para implementar o dimensionamento automático no AKS. O HPA dimensiona automaticamente o número de pods em uma implantação com base na utilização observada da CPU, utilização da memória, métricas personalizadas e métricas de outros serviços. O Autoscaler de cluster ajusta automaticamente o número de nós em um pool de nós com base nas solicitações de recursos dos pods em execução nos nós. Se você quiser usar os dois dimensionadores automáticos juntos, verifique se os pools de nós com o autoscaler ativado abrangem várias zonas. Se o pool de nós estiver em uma única zona e essa zona ficar inativa, o autoscaler não poderá dimensionar o cluster entre zonas.

A funcionalidade de pré-visualização do AKS Karpenter Provider permite o provisionamento automático de nós usando o Karpenter no seu cluster AKS. Para mais informações, consulte a visão geral do recurso AKS Karpenter Provider.

O complemento Kubernetes Event-driven Autoscaling (KEDA) para AKS aplica o dimensionamento automático controlado por eventos para dimensionar seu aplicativo com base em métricas de serviços externos para atender à demanda. Para obter mais informações, consulte Instalar o complemento KEDA no Serviço Kubernetes do Azure (AKS).

Projetar uma aplicação sem estado

Quando uma aplicação é sem estado, a lógica e os dados da aplicação são dissociados e os pods não armazenam dados persistentes ou de sessão nos seus discos locais. Esse design permite que o aplicativo seja facilmente dimensionado para cima ou para baixo sem se preocupar com a perda de dados. Os aplicativos sem estado são mais resistentes a falhas porque podem ser facilmente substituídos ou reprogramados em um nó diferente em caso de falha de um nó.

Ao projetar um aplicativo sem estado com o AKS, você deve usar serviços gerenciados do Azure, como Bancos de Dados do Azure, Cache do Azure para Redis ou Armazenamento do Azure para armazenar os dados do aplicativo. O uso desses serviços garante que seu tráfego possa ser movido entre nós e zonas sem correr o risco de perda de dados ou afetar a experiência do usuário. Você pode usar Implantações, Serviços e Probes de Saúde do Kubernetes para gerir pods sem estado e garantir uma distribuição uniforme entre zonas.

Tome a decisão sobre o disco de armazenamento

Escolha o tipo de disco certo com base nas necessidades do aplicativo

O Azure oferece dois tipos de discos para armazenamento persistente: LRS (armazenamento com redundância local) e ZRS (armazenamento redundante de zona). O LRS replica seus dados em um único AZ. O ZRS replica seus dados em várias AZs dentro de uma região. A partir da versão 1.29 do AKS, a classe de armazenamento padrão usa discos ZRS para armazenamento persistente. Para obter mais informações, consulte Classes de armazenamento integradas do AKS.

A maneira como seu aplicativo replica dados pode influenciar sua escolha de disco. Se seu aplicativo estiver localizado em várias zonas e replicar os dados de dentro do aplicativo, você poderá obter resiliência com um disco LRS em cada AZ, pois se uma AZ ficar inativa, as outras AZs terão os dados mais recentes disponíveis para elas. Se sua camada de aplicativo não lidar com essa replicação, os discos ZRS serão uma escolha melhor, pois o Azure lida com a replicação na camada de armazenamento.

A tabela a seguir descreve os prós e contras de cada tipo de disco:

Para obter mais informações sobre os tipos de disco LRS e ZRS, consulte Redundância do Armazenamento do Azure. Para provisionar discos de armazenamento no AKS, consulte Provisionar armazenamento de discos do Azure no Serviço Kubernetes do Azure (AKS).

Monitorar o desempenho do disco

Para garantir o desempenho e a disponibilidade ideais de seus discos de armazenamento no AKS, você deve monitorar as principais métricas, como IOPS, taxa de transferência e latência. Essas métricas podem ajudá-lo a identificar quaisquer problemas ou gargalos que possam afetar o desempenho do seu aplicativo. Se você notar algum problema de desempenho consistente, convém reconsiderar o tipo ou o tamanho do disco de armazenamento. Você pode usar o Azure Monitor para coletar e visualizar essas métricas e configurar alertas para notificá-lo de quaisquer problemas de desempenho.

Para obter mais informações, consulte Monitorar o Serviço Kubernetes do Azure (AKS) com o Azure Monitor.

Teste de resiliência de AZ

Método 1: Isolar e esvaziar os nós numa única AZ

Uma maneira de testar o cluster AKS quanto à resiliência AZ é drenar um nó em uma zona e ver como ele afeta o tráfego até que ele faça failover para outra zona. Este método simula um cenário do mundo real em que uma zona inteira está indisponível devido a um desastre ou interrupção. Para testar esse cenário, você pode usar o kubectl drain comando para remover graciosamente todos os pods de um nó e marcá-lo como não escalonável. Em seguida, você pode monitorar o tráfego e o desempenho do cluster usando ferramentas como o Azure Monitor ou o Prometheus.

A tabela a seguir descreve os prós e contras desse método:

Método 2: Simular uma falha AZ usando o Azure Chaos Studio

Outra maneira de testar seu cluster AKS para resiliência AZ é injetar falhas em seu cluster e observar o impacto em seu aplicativo usando o Azure Chaos Studio. O Azure Chaos Studio é um serviço que permite criar e gerenciar experimentos de caos em recursos e serviços do Azure. Você pode usar o Chaos Studio para simular uma falha AZ criando um experimento de injeção de falha direcionado a uma zona específica e interrompe ou reinicia as máquinas virtuais (VMs) nessa zona. Em seguida, você pode medir a disponibilidade, a latência e a taxa de erro do seu aplicativo usando métricas e logs.

A tabela a seguir descreve os prós e contras desse método:

Para obter mais informações, consulte O que é o Azure Chaos Studio?.

Próximos passos

Para obter mais detalhes de implementação, consulte o Guia sobre clusters e armazenamento de zona redundantes AKS.