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

Aplica-se a: ✔️ AKS Automatic ✔️ AKS Standard

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, aprende recomendações para a resiliência de zonas em AKS, incluindo como:

• Torne os componentes do cluster AKS resilientes em zonas.
• Projetar aplicações sem estado para cenários de falha de zona.
• Escolha opções de redundância de armazenamento.
• Testar o comportamento da aplicação e da plataforma durante falhas zonais.

Modos de cluster AKS e resiliência de zonas

O AKS suporta dois modos de cluster:

• AKS Automatic, que fornece mais predefinições pré-configuradas da plataforma.
• AKS Standard, que proporciona um controlo direto mais amplo para o operador.

Os princípios de resiliência de zonas neste artigo aplicam-se a ambos os modos de agrupamento. A principal diferença é a propriedade das operações da plataforma.

Para o comportamento completo das funcionalidades por modo, consulte a comparação de características AKS Automatic e AKS Standard.

Torne a zona de componentes do cluster AKS resiliente

As secções seguintes descrevem pontos-chave de decisão para a resiliência das zonas no AKS. Não são exaustivos. Deve também validar a resiliência das zonas para dependências como armazenamentos de dados, sistemas de identidade e serviços externos.

Criar clusters redundantes de zonas e pools de nós

O AKS permite-te selecionar múltiplas AZs durante a criação do cluster e do conjunto de nós. Em regiões que suportam múltiplos AZs, o plano de controlo é automaticamente distribuído por zonas. Os nós do conjunto de nós estão distribuídos pelas zonas 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.

Orientações sobre o modo de agrupamento:

• AKS Automático: Muitos valores predefinidos da plataforma estão pré-configurados. Deves ainda validar que as cargas de trabalho críticas para o negócio são intencionalmente distribuídas por zonas e que o comportamento de falhas cumpre os requisitos.
• Padrão AKS: Projetar explicitamente a topologia do pool de nós, definições de escalabilidade e comportamento no domínio de falhas.

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 estratégia de colocação dos pods é uma questão ao nível da carga de trabalho tanto no AKS Automatic como no AKS Standard. Os padrões de plataforma não substituem os requisitos de topologia ao nível da carga de trabalho.

A partir da versão 1.33 do Kubernetes, a Kube-Scheduler padrão no AKS está configurada para usar um MaxSkew valor de 1 para topology.kubernetes.io/zone:

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

Esta configuração visa no máximo uma diferença de um único pod entre zonas, reduzindo a probabilidade de uma falha zonal causar uma falha de implantação.

Se a implantação tiver necessidades específicas de topologia, substitua estes valores predefinidos na especificação do pod. Pode utilizar restrições de dispersão de topologia de pods com base nos rótulos zone e hostname para distribuir os pods por AZs dentro de uma região e por hosts dentro de cada AZ.

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 Balanceador de Carga do Azure para distribuir o tráfego de entrada entre os nós em seu cluster AKS.

O Balanceador de Carga do Azure 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.
• Gateway de Aplicação do Azure v2: O Gateway de Aplicação do Azure 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.

Utilizar funcionalidades de autoescalonamento

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 Cluster Autoscaler ajusta automaticamente o número de nós num pool de nós com base nos pods pendentes e nos pedidos de recursos dos pods pendentes.

Orientações sobre o modo de agrupamento:

• AKS Automatic: Concentre-se nos requisitos e limites das cargas de trabalho, nas políticas de distribuição de pods e nos controlos de disrupção, para que a escalabilidade pré-configurada da plataforma possa recuperar o serviço durante períodos de pressão numa zona.
• AKS Standard: Defina explicitamente os limites dos conjuntos de nós, a política de dimensionamento e as configurações do dimensionamento automático para se alinharem com as restrições de agendamento com reconhecimento de zona.

A funcionalidade AKS Karpenter Provider permite o autoprovisionamento de nós usando 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).

Estratégia de escalonamento de zonas pelo modo cluster AKS

Para um comportamento de escalonamento com reconhecimento de zona, alinhe o modelo do seu conjunto de nós com as restrições do escalonador e o modo do cluster.

Padrão AKS

Ao usar o Cluster Autoscaler com zonas de disponibilidade, uma boa prática comum é ter um pool de nós por zona. Pode definir --balance-similar-node-groups como True para manter uma distribuição equilibrada dos nós entre zonas durante o aumento de escala.

Por que isso é importante:

• O Cluster Autoscaler simula o escalonamento por pool de nós, não pelo posicionamento numa zona específica.
• Num conjunto de nós multizona, o aumento de escala pode colocar um novo nó numa zona que ainda viola restrições estritas de distribuição topológica, fazendo com que os pods fiquem pendentes.
• O Conjuntos de Dimensionamento de Máquinas Virtuais utiliza o equilíbrio de zonas de melhor esforço. Durante restrições de capacidade de zona ou eventos de redução de zona, a alocação pode falhar e colocar o pool de nós em recuo.
• Usar um conjunto de nós por zona melhora o controlo sobre o comportamento de escalabilidade específico de cada zona.

O Cluster Autoscaler não é consciente da zona, e a alocação de zonas é gerida pelos Conjuntos de Dimensionamento de Máquinas Virtuais subjacentes e não pelo AKS. Esta melhor prática torna-se ainda mais relevante quando se utilizam restrições de distribuição de topologia dos pods baseadas em zonas num único pool de nós multizona, pois restrições demasiado restritivas podem deixar os pods em estado pendente, especialmente em regiões com capacidade limitada ou durante cenários de indisponibilidade de zona.

AKS Automático

O AKS Automatic utiliza o comportamento predefinido dos nós geridos e as predefinições de aprovisionamento automático de nós. Não se pode assumir que cargas de trabalho críticas são resilientes à zona sem uma política ao nível da carga de trabalho.

Para serviços críticos, valide:

• A topologia dos pods espalha o comportamento entre as zonas.
• Comportamento de recuperação durante pressão zonal.
• Agendar resultados quando são usadas restrições rigorosas.
• Comportamento da aplicação quando uma zona se torna indisponível.

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 desenhar uma aplicação stateless com AKS, deve usar serviços Azure geridos, como Azure Databases, Azure Managed Redis ou Armazenamento do Azure, para armazenar os dados da aplicação. 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?.

Conteúdo relacionado

• O que é AKS Automatic?
• Guia sobre clusters AKS com redundância entre zonas e armazenamento