Tutorial: Testar a resiliência da zona do AKS com um cenário

Neste tutorial de cenário do Azure Chaos Studio, use Chaos Studio Workspaces para testar a resiliência de um aplicativo de exemplo do AKS (Serviço de Kubernetes do Azure) a uma falha de zona. Implante o aplicativo em um cluster de teste com redundância de zona e execute Compute Zone Down na infraestrutura de nós do cluster. A primeira execução expõe um front-end vinculado a uma única zona. Corrija o posicionamento do pod, execute novamente o Cenário e compare a disponibilidade do aplicativo e os relatórios de cenário.

Este tutorial é uma boa primeira demonstração e reutiliza o aplicativo de exemplo demonstração da loja do AKS dos guias de início rápido do AKS, portanto não há nenhum registro de contêineres nem etapa de compilação. Reserve cerca de uma hora: a criação do cluster mais duas execuções de cenário com cerca de 5 minutos cada.

Neste tutorial, você aprenderá como:

Este tutorial foi elaborado com foco em uma demonstração funcional. Para os conceitos por trás de cada etapa, as ressalvas de interromper a infraestrutura que o AKS gerencia para você e como interpretar os resultados em uma carga de trabalho real, consulte Testar a resiliência da carga de trabalho no AKS com Chaos Studio.

Pré-requisitos

• Uma assinatura do Azure. Se você ainda não tiver uma conta do Azure, crie uma conta gratuita antes de começar.
• CLI do Azure, kubectle kubeloginPython 3 (somente biblioteca padrão – sem pacotes para instalar). Azure Cloud Shell tem todos os quatro pré-instalados. Se você trabalha localmente, instale kubectl usando az aks install-cli e kubelogin separadamente.
• O provedor de recursos Microsoft.Chaos registrado em sua assinatura. Para obter instruções de registro, consulte os pré-requisitos de início rápido dos Workspaces.

Criar um cluster AKS com redundância de zona

Um teste de falha de zona só faz sentido para um cluster projetado para resistir a esse tipo de falha; por isso, crie um cluster com três nós distribuídos em três zonas de disponibilidade. Este exemplo usa o Leste dos EUA 2; qualquer região com zonas de disponibilidade funciona.

1. Crie um grupo de recursos e o cluster:

   az group create --name chaos-demo-rg --location eastus2
   
   az aks create \
     --resource-group chaos-demo-rg \
     --name chaos-demo-aks \
     --node-count 3 \
     --zones 1 2 3 \
     --generate-ssh-keys
   

   A criação do cluster leva alguns minutos.

2. Em uma nova sessão de Cloud Shell, kubectl ainda não está conectado a nenhum cluster. Defina sua assinatura, obtenha as credenciais e converta o kubeconfig para autenticação do Microsoft Entra antes de executar qualquer comando kubectl:

   az account set --subscription <SUBSCRIPTION_ID>
   az aks get-credentials --resource-group chaos-demo-rg --name chaos-demo-aks
   kubelogin convert-kubeconfig -l azurecli
   

   Substitua sua ID de assinatura por <SUBSCRIPTION_ID>. Ignore az account set se a assinatura já for a ativa. A kubelogin etapa é necessária mesmo em uma nova sessão de Cloud Shell – sem ela, o primeiro kubectl comando em um cluster autenticado pela Entra falha com um erro de autenticação.

3. Verifique se os nós abrangem três zonas:

   kubectl get nodes -L topology.kubernetes.io/zone
   

   A coluna ZONE mostra um nó em cada zona, como eastus2-1, eastus2-2 e eastus2-3. O número da zona após o nome da região é o que você direciona posteriormente na configuração do cenário.

Implantar o aplicativo de exemplo

A demo da loja do AKS é uma pequena vitrine de varejo com um front-end web, um serviço de produtos, um serviço de pedidos e uma fila do RabbitMQ. Suas imagens de contêiner são públicas, portanto, você pode implantá-la com um único comando.

1. Implante o aplicativo:

   kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/2.2.0/aks-store-quickstart.yaml
   

   O manifesto implanta todos os componentes com uma única réplica. O cluster tem redundância de zona, mas a aplicação não. Este tutorial expõe e corrige essa lacuna de resiliência.

2. Aguarde até que o front-end obtenha um endereço IP público:

   kubectl get service store-front --watch
   

   Quando o valor de EXTERNAL-IP mudar de <pending> para um endereço IP público, pressione Ctrl+C para interromper o monitoramento.

3. Abra http://<EXTERNAL-IP> em um navegador e confirme o carregamento da loja. Mantenha essa guia aberta. É uma visualização secundária da saúde do aplicativo durante o teste — o monitor que você inicia mais tarde é o monitor principal.

Para saber como o aplicativo em si é criado e implantado, consulte a série de tutoriais do AKS.

Fixe o front-end em uma única zona para uma demonstração determinística

Sem uma fixação deliberada, o agendador pode colocar a única réplica do front-end em qualquer zona, e um simples reagendamento pode acontecer tão rapidamente que o impacto passe despercebido. Vincular a réplica a uma zona conhecida torna o alvo previsível e permite observar a falha sempre que você executa a demonstração.

1. Encontre o nó no qual o pod store-front está em execução no momento e leia o rótulo de zona desse nó:

   STORE_NODE="$(kubectl get pods -l app=store-front -o jsonpath='{.items[0].spec.nodeName}')"
   PIN_ZONE="$(kubectl get node "$STORE_NODE" -o jsonpath="{.metadata.labels['topology\.kubernetes\.io/zone']}")"
   echo "$PIN_ZONE"
   

   PIN_ZONE é o rótulo de zona completa, como eastus2-1. Mantenha essa sessão do shell aberta - você reutiliza esse valor para o monitor e, posteriormente, para a configuração do cenário (que solicita apenas o número, a parte após o último hífen - por exemplo, 1 em eastus2-1).

2. Aplique um patch na implantação store-front para exigir o agendamento nessa zona e adicione uma anotação que indique que o patch é um padrão apenas para demonstração:

   kubectl patch deployment store-front --patch "$(cat <<EOF
   {
     "metadata": {
       "annotations": {
         "chaos-demo.aks-zone-down-demo/deliberate-anti-pattern": "Pins the single front-end replica to zone ${PIN_ZONE} so run 1 is deterministic. Removed as part of the fix later in this tutorial - do not carry this pin into a real deployment."
       }
     },
     "spec": {
       "template": {
         "spec": {
           "affinity": {
             "nodeAffinity": {
               "requiredDuringSchedulingIgnoredDuringExecution": {
                 "nodeSelectorTerms": [
                   {
                     "matchExpressions": [
                       {"key": "topology.kubernetes.io/zone", "operator": "In", "values": ["${PIN_ZONE}"]}
                     ]
                   }
                 ]
               }
             }
           }
         }
       }
     }
   }
   EOF
   )"
   
   kubectl rollout restart deployment/store-front
   kubectl rollout status deployment/store-front --timeout=300s
   

3. Confirme que a fixação foi mantida: a réplica deve retornar a um nó em $PIN_ZONE:

   STORE_NODE="$(kubectl get pods -l app=store-front -o jsonpath='{.items[0].spec.nodeName}')"
   STORE_ZONE="$(kubectl get node "$STORE_NODE" -o jsonpath="{.metadata.labels['topology\.kubernetes\.io/zone']}")"
   echo "Pod is in zone: $STORE_ZONE (expected $PIN_ZONE)"
   

   Se os dois valores não forem iguais, repita a etapa anterior — a execução 1 não será determinística até que eles sejam iguais.

Baixar e iniciar o monitor de demonstração

Uma inspeção kubectl apenas no terminal é lenta demais e é facilmente perdida durante uma demonstração ao vivo. O sinal da própria loja virtual não se move em sincronia com o do cluster. Este tutorial usa um script de monitor de Python pequeno do repositório de exemplos Chaos Studio como a principal maneira de assistir à execução.

1. Baixe o monitor e o script de verificação de correção:

   curl -O https://raw.githubusercontent.com/microsoft/chaos-studio/f9573c943694e88cf3aacbca38debe84fa91a62c/samples/aks-zone-down-demo/monitor.py
   curl -O https://raw.githubusercontent.com/microsoft/chaos-studio/f9573c943694e88cf3aacbca38debe84fa91a62c/samples/aks-zone-down-demo/verify-fix.sh
   chmod +x verify-fix.sh
   

   Esses links estão vinculados a um commit específico, assim continuam funcionando independentemente de alterações posteriores no exemplo. Depois que a solicitação de pull em questão for mesclada, as revisões posteriores deste tutorial poderão passar para uma versão com tag.

2. Inicie o monitor, apontando para o IP externo da loja virtual e para a zona que você definiu na seção anterior:

   python3 monitor.py --storefront-url http://<EXTERNAL-IP> --target-zone "$PIN_ZONE"
   

   O monitor usa apenas a biblioteca padrão Python, portanto, não há mais nada para instalar. Por padrão, verifica a cada 5 segundos - configurável com --interval ou a variável de ambiente MONITOR_INTERVAL_SECONDS. Esse valor padrão é alto o suficiente para resolver a ordenação dos sinais sem consultar a API do Kubernetes nem a loja virtual de forma agressiva demais.

3. Em Cloud Shell, selecione Visualização da Web e defina a porta como 8787 para abrir o monitor em uma guia do navegador. Se você estiver executando localmente, abra http://localhost:8787 em vez disso.

   A página de monitoramento agora é sua exibição principal para as duas execuções. Ele mostra quatro sinais:

   • Status HTTP da loja virtual - uma solicitação com contorno de cache para a loja virtual, para que você veja um status em tempo real de acessível/inacessível em vez de um sucesso em cache.
   • Status do nó na zona de destino - se o nó na sua zona de destino é Ready ou NotReady.
   • Posicionamento do pod front-end - que pods store-front estão em execução e em qual zona cada um está.
   • Histórico de transição – uma linha do tempo contínua de cada mudança de estado acima, com marcas de data e hora, para que você possa revisar a sequência após o fim da execução, em vez de depender do que percebeu em tempo real.

   Em caso de falha de uma verificação em kubectl ou na API do Kubernetes (por exemplo, se o servidor da API ficar inacessível por um breve período ou se o kubeconfig ficar desatualizado), o monitor exibe uma faixa vermelha visível indicando o erro, em vez de deixar o indicador afetado preso no estado "verificando". O restante do painel continuará mostrando o último estado válido conhecido e o histórico enquanto o banner estiver ativo. Trate o aviso como um sinal em si: ele significa que o monitor perdeu visibilidade, não que o recurso que ele está monitorando está íntegro.

Criar um espaço de trabalho no escopo do grupo de recursos de infraestrutura

O AKS coloca os conjuntos de dimensionamento de máquinas virtuais dos nós do cluster em um grupo de recursos de infraestrutura separado (nomeado por padrão com um nome iniciado por MC_), não no grupo de recursos que contém o recurso do cluster. Defina o escopo do workspace como o grupo de recursos de infraestrutura para que ele descubra os nós. Para a contextualização, consulte Por que um espaço de trabalho com escopo no seu cluster do AKS não localiza destinos de computação.

1. Localize o nome do grupo de recursos de infraestrutura:

   az aks show --resource-group chaos-demo-rg --name chaos-demo-aks --query nodeResourceGroup -o tsv
   

2. No portal Azure, pesquise Chaos Studio, selecione Workspaces e, em seguida, selecione Criar.

3. Na guia Noções básicas , selecione o chaos-demo-rg grupo de recursos, nomeie o workspace chaos-demo-workspacee escolha uma região com suporte. A região do workspace não precisa corresponder à região do cluster.

4. Na guia Escopo , selecione Grupo de recursos como o tipo de escopo e selecione o grupo de recursos de infraestrutura na etapa 1.

5. Na guia Identidade, escolha Atribuído pelo sistema.

6. Selecione Revisar + criar>Criar e depois Ir para o recurso.

   Após a conclusão da descoberta, o conjunto de dimensionamento de máquinas virtuais do nó do cluster (denominado aks-nodepool1-12345678-vmss) aparece como um recurso descoberto.

7. Se o portal exibir um banner informando que a identidade não tem permissões de leitura no escopo do espaço de trabalho, selecione Atribuir a função Leitor no escopo do espaço de trabalho. Para criar atribuições de função, você precisa ter direitos de Proprietário ou de Administrador de Acesso do Usuário no grupo de recursos de infraestrutura.

Você concede à identidade as funções de que o próprio cenário precisa na próxima seção, em que a validação informa exatamente o que está faltando. Para obter um passo a passo completo de cada etapa de criação do workspace, consulte o início rápido do workspace.

Executar o cenário e ver o aplicativo falhar

O cenário Zona de Computação Inativa simula uma falha em uma zona de disponibilidade ao desligar as instâncias do conjunto de dimensionamento de máquinas virtuais em uma zona de destino durante o período configurado. As instâncias são reiniciadas quando a duração da ação termina.

1. No espaço de trabalho, selecione Cenários e, em seguida, selecione Compute Zone Down na biblioteca de cenários.

2. Configure o cenário. Para a zona de disponibilidade, insira o número de $PIN_ZONE (a parte após o último hífen, por exemplo 1 , em eastus2-1). Defina a duração como 5 minutos – tempo suficiente para ver os sinais do front-end da loja virtual, do nó e do pod se estabilizarem, sem precisar esperar demais. Este valor de 5 minutos foi definido para esta demonstração específica; outros tipos de cenário têm suas próprias orientações de duração, de acordo com o que testam. Por exemplo, um cenário criado em torno do comportamento de cache DNS precisa de uma duração longa o suficiente para exceder o TTL de cache do registro, que pode ser muito maior do que 5 minutos. Selecione Guardar configuração.

3. A validação verifica se a identidade gerenciada do workspace pode executar todas as ações que o cenário precisa nos recursos de destino. Se a validação relatar permissões ausentes, selecione Corrigir Permissões na página de configuração do cenário para conceder à identidade as funções internas recomendadas. Para esse cenário, esse é o Colaborador da Máquina Virtual no conjunto de dimensionamento de máquinas virtuais do nó. Para atribuir as funções você mesmo ou usar funções personalizadas de privilégios mínimos em vez das funções internas, consulte Permissões e identidade em workspaces do Chaos Studio e Usar funções personalizadas de privilégios mínimos com workspaces do Chaos Studio.

   Se uma função necessária ainda estiver ausente no tempo de execução, a execução será iniciada de qualquer maneira, mas as ações de desligamento falharão com um erro de permissões no relatório de cenário.

4. Selecione Executar e confirme.

Pode levar alguns minutos após o início da execução para que o desligamento entre em vigor; portanto, não se assuste se nada mudar no monitor imediatamente. Em seguida, observe a página de monitoramento:

• O sinal HTTP da loja virtual e o status do nó de destino não mudam ao mesmo tempo. O sinal no nível do aplicativo é o que os usuários realmente experimentam e é o único a tratar como primário; os sinais de nó e pod são a contabilidade interna do cluster que se atualiza posteriormente. Espere que a interface da loja virtual apareça como inacessível bem antes de o nó mostrar NotReady — essa diferença é normal; trata-se de propagação assíncrona do sinal, não de um problema na demonstração.
• O status do nó de destino é alterado para NotReady.
• Como o front-end está vinculado a essa zona, sua única réplica não pode ser executada em outro lugar. A loja virtual permanece inacessível até que o Kubernetes possa reagendar o pod – o que, com o pino no local, só acontece quando o nó de destino é retornado ou você altera a restrição de posicionamento. Não confie em um valor fixo de inatividade aqui; consulte o histórico de transições do monitor para ver o que realmente aconteceu na sua execução.

Este resultado é a descoberta. O cluster era redundante entre zonas, mas a escolha de posicionamento do aplicativo transformou uma falha de zona em uma indisponibilidade sem prazo definido, enquanto essa restrição permanecesse em vigor. O histórico de mudanças de estado do monitor é o registro exato de quando a loja virtual ficou indisponível e, mais tarde, quando voltou a ficar disponível.

Solução de problemas: o impacto não está visível

Se o monitor mostrar que a loja virtual continua acessível durante toda a execução 1, verifique os itens a seguir antes de concluir que o cenário não funcionou:

• Confirme se a fixação surtiu efeito. Execute kubectl get pods -l app=store-front -o wide e verifique se o nó do pod está em $PIN_ZONE. Se o patch não tiver sido aplicado, o agendador poderá ter colocado a réplica em outro lugar. Um reagendamento simples durante a interrupção pode ser rápido o suficiente para você perdê-lo sem o pino.
• Confirme se o monitor está observando a zona e a URL certas. Reinicie monitor.py com o valor exato --target-zone e a URL da loja do seu cluster. Um valor obsoleto ou digitado incorretamente exibe um status "saudável" enganoso.
• Verifique o relatório do cenário para ações Skipped. Se as ações de desligamento mostrarem Skipped em vez de Succeeded, a execução não encontrou alvos correspondentes na zona de destino. Consulte Interpretar os resultados.
• Dê mais alguns segundos. A ação de desligamento em si leva pouco tempo para surtir efeito após o início da execução. O histórico de transições do monitor mostra os registros exatos de data e hora assim que ocorrem.

Corrigir a implantação e verificá-la

Agora substitua o pino de zona única deliberada por uma correção real em escala de cluster: três réplicas, restritas a uma por zona.

1. Remova o marcador de zona que você adicionou antes:

   kubectl patch deployment store-front --type=merge --patch '{"spec":{"template":{"spec":{"affinity":null}}}}'
   

2. Escale o front-end para três réplicas e adicione uma restrição de propagação de topologia que exija uma réplica por zona em vez de apenas preferi-la:

   kubectl patch deployment store-front --patch '{"spec":{"replicas":3,"template":{"spec":{"topologySpreadConstraints":[{"maxSkew":1,"topologyKey":"topology.kubernetes.io/zone","whenUnsatisfiable":"DoNotSchedule","labelSelector":{"matchLabels":{"app":"store-front"}}}]}}}}'
   

   whenUnsatisfiable: DoNotSchedule faz com que a distribuição de uma réplica por zona seja um requisito difícil. Uma réplica que não consegue atendê-la permanece Pending em vez de ser alocada em uma zona que já tenha uma réplica. Essa é uma compensação deliberada - garante a cobertura da zona da qual este teste depende, ao custo de uma réplica potencialmente permanecer não programada se uma zona temporariamente não tiver espaço. ScheduleAnyway permitiria que o agendador ignorasse a restrição quando sob pressão, que é exatamente o modo de falha que esta correção elimina.

3. Verifique a correção antes de confiar nela. Execute o script de verificação. Ele aguarda o término da implantação para que pods obsoletos da revisão anterior com uma única réplica não sejam contabilizados e, depois, confirma que cada zona tem pelo menos um pod Readystore-front:

   ./verify-fix.sh
   

   Uma chamada kubectl, uma solicitação de API ou o JSON que ela retorna pode falhar transitoriamente — um tempo limite breve, uma queda de conexão — sem que isso signifique que a correção em si falhou. O script repete após essas falhas transitórias até atingir seu próprio tempo limite, em vez de encerrar após a primeira falha. Somente após esse tempo limite, o processo é encerrado com um status diferente de zero e uma mensagem de diagnóstico indicando qual zona ainda não tem uma réplica pronta. Não prossiga para executar 2 até que ela seja aprovada. Um resultado positivo é o que torna "uma réplica por zona" um fato comprovado, em vez de uma suposição inferida a partir do comando patch.

Executar o cenário novamente e comparar

1. No espaço de trabalho, execute novamente o cenário Indisponibilidade da zona de computação com a mesma zona de destino e a mesma duração de 5 minutos.

2. Assista ao monitor. O nó de destino ainda fica NotReady e inclui a réplica store-front, mas a loja virtual continua respondendo, atendida pelas réplicas nas zonas restantes. A alegação em teste é disponibilidade sustentada mesmo durante a indisponibilidade da zona, comprovada pelo histórico contínuo do monitor — não zero solicitações perdidas, nem que o monitor apresente um estado íntegro ininterrupto durante todo o período. Uma breve interrupção ainda é possível enquanto o Azure Load Balancer converge para as réplicas saudáveis restantes; uma execução com êxito mostra uma breve oscilação de convergência, não uma indisponibilidade que se prolongue por toda a duração da interrupção. O tempo que essa convergência leva varia conforme o ambiente, portanto não dependa de um limite de tempo fixo — use o histórico de transições do monitor para distinguir uma oscilação momentânea de uma indisponibilidade persistente.

Os componentes de réplica única ainda podem sofrer uma breve interrupção. Se o nó da fila do RabbitMQ estiver na zona de destino, o envio de pedidos fica prejudicado enquanto o pod se recupera. Identificar o próximo componente mais fraco e decidir se vale a pena corrigi-lo é exatamente o ciclo que os testes de caos foram projetados para impulsionar.

Comparar os relatórios de cenário

1. No espaço de trabalho, selecione Histórico de execuções. Agora você tem duas execuções finalizadas do mesmo cenário.

2. Selecione cada execução e, em seguida, selecione Gerar relatório. Confirme se as ações de desligamento mostram o status Bem-sucedido em ambas, o que significa que cada execução encontrou instâncias na zona alvo e as interrompeu. Se as ações mostrarem Ignorado, a execução não encontrou destinos correspondentes. As causas usuais incluem um escopo que não inclui o grupo de recursos de infraestrutura ou uma zona de destino que não contém nós. Para obter mais informações, consulte Testar a resiliência da carga de trabalho no AKS com Chaos Studio.

3. Observe que ambos os relatórios parecem iguais, embora os resultados do aplicativo tenham sido opostos. Concluído com êxito significa que a interrupção foi aplicada - isso não significa que o aplicativo permaneceu íntegro. O relatório prova o que ocorreu a interrupção e quando; o histórico de transição do monitor é o que prova o comportamento do aplicativo em resposta. Combinar os dois é assim que você transforma uma execução em evidência: o relatório registra a data e a hora da falha, e o monitor mostra a diferença entre o antes e o depois que a correção fez.

Você pode baixar os relatórios como evidência de antes e depois para revisões de resiliência. Para obter detalhes, consulte os relatórios de cenário.

Limpar os recursos

Exclua o grupo de recursos para remover o cluster, o aplicativo de exemplo e o workspace. Excluir o cluster também exclui seu grupo de recursos de infraestrutura.

az group delete --name chaos-demo-rg --yes --no-wait

Relatar problemas e solicitar recursos

Azure Chaos Studio é desenvolvido ao ar livre. Para relatar um bug, solicitar um recurso ou fazer uma pergunta sobre workspaces, cenários ou a extensão CLI do Azure, abra um problema no repositório Chaos Studio no GitHub. Ao apresentar um problema, você pode acompanhar seu progresso e ver solicitações de outros clientes.

Próximas Etapas 

• Testar a resiliência da carga de trabalho no AKS com Chaos Studio abrange as limitações e as diretrizes de interpretação para executar esse teste em relação a uma carga de trabalho real.
• Para tornar objetiva a aprovação ou reprovação de uma carga de trabalho real, combine as execuções de cenário com testes de disponibilidade do Application Insights e seus próprios indicadores de nível de serviço, em vez de uma aba do navegador.
• Tutorial: executar um cenário de failover de zona para baixo do PostgreSQL adiciona um failover de camada de dados ao mesmo padrão de interrupção.
• Cenários em Azure Chaos Studio descreve a biblioteca de cenários completa.
• O repositório Chaos Studio GitHub tem scripts de implantação para este exemplo (incluindo os scripts de monitoramento e verificação usados neste tutorial), cenários personalizados compartilháveis e um plug-in da CLI Copilot para direcionar Chaos Studio de GitHub Copilot.