Este conjunto de tutoriais é destinado a administradores e operadores de TI que querem implantar, executar e gerenciar ambientes de aplicativos modernos executados no Google Kubernetes Engine (GKE). À medida que avança neste conjunto de tutoriais, você aprende a configurar o monitoramento e alertas, escalonar cargas de trabalho e simular falhas. Tudo isso usando o aplicativo de microsserviços de exemplo Cymbal Bank:
- Criar um cluster e implantar um aplicativo de exemplo
- Monitorar com o Google Cloud Managed Service para Prometheus
- Escalonar cargas de trabalho
- Simular uma falha (este tutorial)
Visão geral e objetivos
Os aplicativos precisam tolerar interrupções e falhas. Esse recurso permite que os usuários continuem acessando os aplicativos mesmo quando há um problema. O aplicativo de amostra do Cymbal Bank foi projetado para lidar com falhas e continuar em execução, sem que você precise solucionar problemas e corrigir erros. Para fornecer essa resiliência, os clusters regionais do GKE distribuem nós de computação entre as zonas, e o controlador do Kubernetes responde automaticamente a problemas de serviço no cluster.
Neste tutorial, você vai aprender a simular uma falha no Google Cloud e conferir como os serviços do aplicativo no cluster do GKE respondem. Você aprenderá a concluir as seguintes tarefas:
- Revisar a distribuição de nós e Serviços
- Simular uma falha de nó ou zona
- Verificar se os serviços continuam sendo executados nos nós restantes.
Custos
Ao ativar o GKE e implantar o aplicativo de exemplo do Cymbal Bank para esta série de tutoriais, você receberá cobranças por cluster do GKE no Google Cloud, conforme listado na nossa página de preços, até desativar o GKE ou excluir o projeto.
Você também é responsável por outros custos incorridos do Google Cloud durante a execução do aplicativo de amostra do Cymbal Bank, como cobranças de VMs do Compute Engine.
Antes de começar
Para aprender a simular uma falha, conclua o primeiro tutorial para criar um cluster do GKE que use o Autopilot e implantar o aplicativo baseado em microsserviços de amostra do Cymbal Bank.
Recomendamos que você conclua este conjunto de tutoriais para aplicativos escalonáveis em ordem. À medida que avança no conjunto de tutoriais, você aprende novas habilidades e usa outros produtos e serviços do Google Cloud.
Revisar a distribuição de nós e Serviços
No Google Cloud, uma região é uma localização geográfica específica em que é possível
hospedar seus recursos. Regiões têm três ou mais zonas. Por exemplo, o
us-central1 indica uma região no Centro-Oeste dos Estados
que tem várias zonas, comous-central1-a .us-central1-b e
us-central1-c. As zonas têm conexões de rede de muita largura de banda
e baixa latência com outras zonas na mesma região.
Para implantar aplicativos tolerantes a falhas que tenham alta disponibilidade, o Google recomenda que você implante aplicativos em várias zonas e regiões. Essa abordagem ajuda a proteger contra falhas inesperadas de componentes, incluindo uma zona ou região.
Quando você criou o cluster do GKE no primeiro tutorial, alguns valores de configuração padrão foram usados. Por padrão, um cluster do GKE que usa o Autopilot cria e executa nós que abrangem várias zonas da região especificada. Essa abordagem significa que o aplicativo de amostra do Cymbal Bank já está implantado em várias zonas, o que ajuda a proteger contra falhas inesperadas.
Verifique a distribuição de nós no cluster do GKE:
kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'O resultado é semelhante ao exemplo de saída a seguir, que mostra que os nós estão espalhados por todas as três zonas na região:
NAME ZONE INT_IP scalable-apps-pool-2-node5 us-central1-c 10.148.0.6 scalable-apps-pool-2-node6 us-central1-c 10.148.0.7 scalable-apps-pool-2-node2 us-central1-a 10.148.0.8 scalable-apps-pool-2-node1 us-central1-a 10.148.0.9 scalable-apps-pool-2-node3 us-central1-b 10.148.0.5 scalable-apps-pool-2-node4 us-central1-b 10.148.0.4Verifique a distribuição dos serviços de aplicativo de amostra do Cymbal Bank nos nós de cluster do GKE:
kubectl get pods -o wideO exemplo de saída a seguir mostra que os serviços estão distribuídos entre nós no cluster. Na etapa anterior para verificar como os nós estão distribuídos, esta saída mostra que os Serviços são executados entre as zonas na região:
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 6m30s 10.28.1.5 scalable-apps-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 6m30s 10.28.5.6 scalable-apps-pool-2-node1 contacts-7ddc76d94-qv4x5 1/1 Running 0 6m29s 10.28.4.6 scalable-apps-pool-2-node2 frontend-747b84bff4-xvjxq 1/1 Running 0 6m29s 10.28.3.6 scalable-apps-pool-2-node6 ledger-db-0 1/1 Running 0 6m29s 10.28.5.7 scalable-apps-pool-2-node1 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 6m29s 10.28.1.6 scalable-apps-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 6m29s 10.28.4.7 scalable-apps-pool-2-node2 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 6m29s 10.28.3.7 scalable-apps-pool-2-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 6m28s 10.28.5.8 scalable-apps-pool-2-node1
Simular uma interrupção
O Google projeta zonas para minimizar o risco de falhas correlacionadas causadas por interrupções de infraestrutura física, como energia, resfriamento ou rede. No entanto, problemas inesperados podem acontecer. Se um nó ou uma zona ficar indisponível, você quer que os Serviços continuem a ser executados em outros nós ou em zonas da mesma região.
O controlador do Kubernetes monitora o status dos nós, serviços e implantações no cluster. Em caso de interrupção inesperada, o controlador reinicia os recursos afetados e o tráfego é roteado para os nós de trabalho.
Para simular uma interrupção neste tutorial, você delimita e drena os nós em uma das suas zonas. Essa abordagem simula o que acontece quando um nó falha ou quando uma zona inteira tem um problema. O controlador do Kubernetes reconhecerá que alguns serviços não estão mais disponíveis e precisam ser reiniciados em nós em outras zonas:
Restrinja e drene os nós em uma das zonas. O exemplo a seguir segmenta os dois nós em
us-central1-a:kubectl drain scalable-apps-pool-2-node1 \ --delete-emptydir-data --ignore-daemonsets kubectl drain scalable-apps-pool-2-node2 \ --delete-emptydir-data --ignore-daemonsetsEsse comando marca os nós como não programáveis para que os pods não possam mais ser executados neles. O Kubernetes reprograma os pods para outros nós em zonas funcionais.
Verificar a resposta de falha simulada
Em um tutorial anterior desta série, você aprendeu como configurar a instância gerenciada do Prometheus no seu cluster do GKE para monitorar alguns dos Serviços e gerar alertas se houver algum problema. Se os pods estavam em execução nos nós na zona em que você simulou uma interrupção, você receberá mensagens de notificação do Slack nos alertas gerados pelo Prometheus. Esse comportamento mostra como criar um ambiente de aplicativo moderno que monitora a integridade das implantações, alerta se houver um problema e pode se ajustar automaticamente em caso de alterações ou falhas de carga.
Seu cluster do GKE responde automaticamente à interrupção simulada. Todos os Serviços nos nós afetados são reiniciados nos nós restantes.
Verifique novamente a distribuição de nós no cluster do GKE:
kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'O resultado é semelhante ao exemplo de saída a seguir, que mostra que os nós agora estão espalhados apenas por duas das zonas na região:
NAME ZONE INT_IP scalable-apps-pool-2-node5 us-central1-c 10.148.0.6 scalable-apps-pool-2-node6 us-central1-c 10.148.0.7 scalable-apps-pool-2-node3 us-central1-b 10.148.0.5 scalable-apps-pool-2-node4 us-central1-b 10.148.0.4O controlador do Kubernetes reconhece que dois dos nós não estão mais disponíveis e redistribui os serviços entre os nós disponíveis. Todos os serviços continuarão em execução.
Verifique a distribuição dos serviços de aplicativo de amostra do Cymbal Bank nos nós de cluster do GKE:
kubectl get pods -o wideO exemplo de saída a seguir mostra que os serviços estão distribuídos entre os nós restantes no cluster. Na etapa anterior para verificar como os nós são distribuídos, esta saída mostra que os Serviços agora são executados apenas em duas zonas na região:
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 28m 10.28.1.5 scalable-apps-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 9m21s 10.28.5.6 scalable-apps-pool-2-node5 contacts-7ddc76d94-qv4x5 1/1 Running 0 9m20s 10.28.4.6 scalable-apps-pool-2-node4 frontend-747b84bff4-xvjxq 1/1 Running 0 28m 10.28.3.6 scalable-apps-pool-2-node6 ledger-db-0 1/1 Running 0 9m24s 10.28.5.7 scalable-apps-pool-2-node3 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 28m 10.28.1.6 scalable-apps-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 9m21s 10.28.4.7 scalable-apps-pool-2-node5 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 28m 10.28.3.7 scalable-apps-pool-2-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 9m20s 10.28.5.8 scalable-apps-pool-2-node1Confira o
AGEdos serviços. No exemplo de saída anterior, alguns dos Serviços têm uma idade mais jovem do que outros no aplicativo de amostra Cymbal Bank. Esses serviços mais jovens foram executados anteriormente em um dos nós em que você simulou uma falha. O controlador do Kubernetes reiniciou esses serviços nos nós disponíveis.
Em um cenário real, você solucionaria o problema ou esperaria que o problema de manutenção subjacente fosse resolvido. Se você configurou o Prometheus para enviar mensagens do Slack com base em alertas, essas notificações serão enviadas. Também é possível repetir as etapas do tutorial anterior para escalonar recursos para ver como o cluster do GKE responde com aumento da carga quando apenas duas zonas estão disponíveis com a região. O cluster será escalonado verticalmente com as duas zonas restantes disponíveis.
Limpar
Para evitar cobranças na sua conta do Google Cloud pelos recursos usados neste tutorial, exclua o projeto criado.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
A seguir
Antes de começar a criar seu próprio ambiente de cluster do GKE semelhante ao que você aprendeu neste conjunto de tutoriais, analise algumas das considerações de produção.