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

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á sobre as várias recomendações de resiliência de zona no AKS (Serviço de Kubernetes do Azure), incluindo como:

• Torne seus componentes do cluster do AKS resilientes à zona
• Criar um aplicativo sem estado
• Tome sua decisão sobre o disco de armazenamento
• Testar a resiliência da zona de disponibilidade (AZ)

Torne seus componentes do cluster do AKS resilientes à zona

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

Criar clusters redundantes de zona 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ários AZs, o plano de controle é distribuído automaticamente por todos os AZs nessa região. No entanto, os nós no pool de nós são distribuídos apenas entre as AZs 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. Você pode configurar o 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 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 partir da versão 1.33 do Kubernetes, o Kube-Scheduler padrão no AKS é configurado para usar um MaxSkew valor de 1 para topology.kubernetes.io/zone como descrito abaixo:

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

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

No entanto, se sua implantação tiver necessidades de topologia específicas, você poderá substituir os valores padrão acima adicionando os seus próprios na especificação de pod. Você pode usar restrições de propagação de topologia de pod com base nos rótulos zone e hostname para espalhar os pods entre as AZs em uma região e entre os nós nas 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.

Aproveitar 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 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 automaticamente o número de nós em um pool de nós com base nas solicitações de recurso 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 dimensionador automático habilitado abrangem várias zonas. Se o pool de nós estiver em uma única zona e essa zona diminuir, o dimensionador automático não poderá dimensionar o cluster entre as zonas.

A versão prévia do recurso do Provedor de Karpenter do AKS permite o provisionamento automático de nós usando o 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).

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 os serviços gerenciados do Azure, Bancos de Dados do Azure, Cache do Azure para Redisou 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?.

Próximas etapas

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