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

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 no seu núcleo, o Kubernetes aproveita ao máximo a infraestrutura independente nos data centers sem incorrer em custos adicionais, provisionando novos nós somente quando for necessário.

Neste artigo, você aprenderá as recomendações de resiliência de zona no AKS, incluindo como:

• Torne os componentes do cluster AKS resilientes a zonas.
• Projete aplicativos sem estado para cenários de falha de zona.
• Escolha opções de redundância de armazenamento.
• Teste o comportamento do aplicativo e da plataforma durante falhas zonais.

Modos de cluster do AKS e resiliência de zona

O AKS dá suporte a dois modos de cluster:

• AKS Automatic, que fornece mais padrões de plataforma pré-configurados.
• AKS Standard, que fornece controle de operador direto mais amplo.

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

Para obter o comportamento completo dos recursos por modo, consulte a comparação entre os recursos do AKS Automatic e do AKS Standard.

Torne seus componentes do cluster do AKS resilientes à zona

As seções a seguir descrevem os principais pontos de decisão para resiliência de zona no AKS. Eles não são exaustivos. Você também deve validar a resiliência de zona para dependências como armazenamentos de dados, sistemas de identidade e serviços externos.

Criar clusters redundantes de zona e pools de nós

O AKS permite selecionar vários AZs durante a criação do cluster e do pool de nós. Em regiões que dão suporte a vários AZs, o plano de controle é distribuído automaticamente entre zonas. Os nós do pool de nós sã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, proporcionando resiliência em caso de falha de uma AZ.

Orientações sobre o modo cluster:

• AKS Automática: Muitas configurações padrão da plataforma são pré-configuradas. Você ainda deve validar que cargas de trabalho comercialmente críticas são distribuídas intencionalmente entre zonas e que o comportamento de falha atende aos requisitos.
• AKS Standard: Projete explicitamente a topologia do pool de nós, as configurações de dimensionamento e o comportamento dos domínios de falha.

O exemplo a seguir mostra como criar um cluster com três nós distribuídos em 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 de cada nó de agente dos rótulos:

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

O exemplo de saída a seguir mostra a região e a zona de disponibilidade de 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 de Kubernetes do Azure (AKS).

Certifique-se de que os pods estejam espalhados pelas AZs

A estratégia de posicionamento de pods é uma questão no nível da carga de trabalho tanto no AKS Automatic quanto no AKS Standard. Os padrões da plataforma não substituem os requisitos de topologia no nível da carga de trabalho.

A partir da versão 1.33 do Kubernetes, o Kube-Scheduler padrão no AKS é configurado para usar o valor 1 em MaxSkew para topology.kubernetes.io/zone:

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

Essa configuração visa a uma diferença de no máximo um pod entre as zonas, reduzindo a chance de que uma falha em uma zona cause uma interrupção na implantação.

Se a sua implantação tiver necessidades específicas de topologia, substitua esses padrões na especificação do pod. Você pode usar restrições de espalhamento de topologia de pods com base nos rótulos zone e hostname para distribuir os pods entre AZs dentro de uma região e entre hosts dentro das AZs.

Por exemplo, digamos que você tenha um cluster de quatro nós em que três pods rotulados app: mypod-app estejam localizados em node1, node2e node3, respectivamente. Se você quiser que a implantação de entrada seja hospedada em nós distintos o máximo possível, use um manifesto semelhante ao exemplo a seguir:

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, MaxSkewconsulte a documentação da Topologia do Pod do Kubernetes. Por exemplo, como nodeTaintsPolicy: Honor afeta a distribuição de pods.

Configurar a rede com reconhecimento da AZ

Se você tiver pods que atendam ao tráfego de rede, deverá fazer o balanceamento da 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 no seu cluster do AKS.

O Azure Load Balancer oferece suporte ao balanceamento de carga interno e externo e você pode configurá-lo para usar uma SKU Standard como balanceamento de carga com redundância de zona. SKU Standard é a SKU padrão no AKS e oferece suporte à resiliência regional com as 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 de SKU Standard redundante de zona não é afetado pela falha e permite que suas implantações continuem atendendo ao tráfego das zonas restantes. Você pode usar um balanceador de carga global, como Front Door ou Gerenciador de Tráfego, ou pode usar os balanceadores de carga entre regiões na frente dos seus clusters regionais do AKS para garantir que seu aplicativo não seja afetado por falhas regionais. Para criar um balanceador de carga de SKU Standard no AKS, consulte Usar um balanceador de carga padrão no Serviço de Kubernetes do Azure (AKS).

Para garantir que o tráfego de rede do 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 dão suporte às AZs:

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

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

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. A SKU Premium do Registro de Contêiner do Azure (ACR) oferece suporte à replicação geográfica e à redundância de zona opcionais. Esses recursos fornecem disponibilidade e reduzem a latência para operações regionais.

Garantir 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 no seu aplicativo mesmo que os componentes individuais do serviço falhem ou se as regiões do Azure ou AZs não estejam disponíveis. Para obter mais informações, confira Disponibilidade e redundância do Azure Key Vault.

Usar 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 o ajudam a alcançar as seguintes metas:

• Otimize o uso de recursos e a eficiência de custo aumentando ou reduzindo com base no uso da CPU e memória dos pods.
• Aprimore a tolerância e a recuperação de falhas adicionando mais nós ou pods quando ocorrer uma falha de zona.

Você pode usar o Dimensionador Automático de Pod Horizontal (HPA) e o Dimensionador Automático de Cluster para implementar o dimensionamento automático no AKS. O HPA dimensiona automaticamente o número de pods em uma implantação com base no uso da CPU observada, uso da memória, métricas personalizadas e métricas de outros serviços. O dimensionador automático de cluster ajusta o número de nós em um pool de nós automaticamente com base nos pods pendentes e nos pedidos de recursos desses pods.

Orientações sobre o modo cluster:

• AKS Automático: concentre-se em solicitações e limites de carga de trabalho, políticas de distribuição de pod e controles de interrupção para que o dimensionamento da plataforma pré-configurado possa recuperar o serviço durante o estresse zonal.
• AKS Standard: defina explicitamente os limites dos pools de nós, a política de escalonamento e as configurações do escalonador automático para se adequarem às restrições de agendamento com reconhecimento de zonas.

O recurso Karpenter Provider do AKS permite o provisionamento automático de nós usando Karpenter no cluster do AKS. Para obter mais informações, consulte a Visão geral do recurso provedor de Karpenter do AKS.

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

Estratégia de dimensionamento de zona pelo modo de cluster do AKS

Para o comportamento de expansão com reconhecimento de zona, alinhe seu modelo de pool de nós com restrições de agendador e seu modo de cluster.

AKS Standard

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

Por que isso importa:

• O Dimensionador Automático de Cluster simula o agendamento por pool de nós, e não por posicionamento de zona específico.
• Em um pool de nós multizona, o aumento da escala pode colocar um novo nó em uma zona que ainda viola restrições estritas de distribuição topológica, fazendo com que os pods permaneçam pendentes.
• Os Conjuntos de Dimensionamento de Máquinas Virtuais usam o balanceamento de zona de melhor esforço. Durante restrições na capacidade da zona ou eventos de indisponibilidade da zona, a alocação pode falhar e colocar o pool de nós em estado de espera.
• O uso de um pool de nós por zona melhora o controle do comportamento de dimensionamento específico da zona.

O Dimensionador Automático de Cluster não tem reconhecimento de zona e a alocação de zona é tratada pelo Conjuntos de Dimensionamento de Máquinas Virtuais subjacente e não pelo AKS. Essa prática recomendada acima fica ainda mais relevante ao usar restrições de propagação de topologia de pods baseadas em zona em um único pool de nós multizonais, pois restrições rigorosas podem deixar pods em um estado pendente, especialmente em regiões com restrição de capacidade ou durante situações de indisponibilidade de zona.

AKS Automático

O AKS Automatic usa o comportamento predefinido para nós gerenciados e os padrões de autoprovisionamento de nós. Você não pode assumir que cargas de trabalho críticas são resilientes à zona sem a política de nível de carga de trabalho.

Para serviços críticos, valide:

• O comportamento de propagação da topologia de pod entre zonas.
• Comportamento de recuperação durante a pressão zonal.
• Agendando resultados quando restrições estritas são usadas.
• Comportamento do aplicativo quando uma zona fica indisponível.

Criar um aplicativo sem estado

Quando um aplicativo se encontra sem estado, a lógica do aplicativo e dos dados 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 escalado para cima ou para baixo sem se preocupar com a perda de dados. Aplicativos sem estado são mais resilientes a falhas porque podem ser facilmente substituídos ou reagendados em um nó diferente em caso de falha de nó.

Ao criar um aplicativo sem estado com o AKS, você deve usar serviços gerenciados do Azure, como Bancos de Dados do Azure, Redis Gerenciados do Azure 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 arriscar a perda de dados ou afetar a experiência do usuário. Você pode usar as Implantações, Serviçose Investigações de Integridade do Kubernetes para gerenciar os pods sem estado e garantir a distribuição uniforme entre as zonas.

Tome sua decisão sobre o disco de armazenamento

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

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

A maneira como seu aplicativo replica dados pode influenciar sua escolha de disco. Se o 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 falhar, as outras AZs terão os dados mais recentes disponíveis para elas. Se a camada de aplicativo não lidar com essa replicação, os discos ZRS serão uma opção melhor, pois o Azure manipula 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 os discos de armazenamento no AKS, consulte Provisionar o armazenamento do Azure Disks no Serviço de Kubernetes do Azure (AKS).

Monitorar o desempenho do disco

Para garantir o desempenho ideal e a disponibilidade dos 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 problemas ou gargalos que possam afetar o desempenho do aplicativo. Se você observar problemas de desempenho consistentes, convém reconsiderar o tamanho ou o tipo do disco de armazenamento. Você pode usar o Azure Monitor para coletar e visualizar essas métricas e configurar alertas para notificá-lo sobre quaisquer problemas de desempenho.

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

Testar a resiliência da AZ

Método 1: Cordão e nós de drenagem em apenas uma AZ

Uma maneira de testar o cluster do AKS para resiliência da AZ é esvaziar um nó em uma zona e ver como ele afeta o tráfego até que ele faça failover para outra zona. Esse 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 comando kubectl drain para remover normalmente todos os pods de um nó e marcá-lo como não programado. 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 deste método:

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

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

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

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

Conteúdo relacionado

• O que é o AKS Automatic?
• Guia para clusters do AKS e armazenamento com redundância de zona