Este conjunto de tutoriais destina-se a administradores de TI e operadores que querem implementar, executar e gerir ambientes de aplicações modernos que são executados no Google Kubernetes Engine (GKE). À medida que avança neste conjunto de tutoriais, vai aprender a configurar a monitorização e os alertas, dimensionar cargas de trabalho e simular falhas, tudo isto usando a aplicação de microsserviços de exemplo do Cymbal Bank:
- Crie um cluster e implemente uma aplicação de exemplo
- Monitorize com o serviço gerido do Google Cloud para Prometheus
- Dimensione cargas de trabalho
- Simule uma falha (este tutorial)
- Centralize a gestão da mudança
Vista geral e objetivos
As aplicações devem conseguir tolerar interrupções e falhas. Esta capacidade permite que os utilizadores continuem a aceder às suas aplicações, mesmo quando existe um problema. A aplicação de exemplo Cymbal Bank foi concebida para processar falhas e continuar a ser executada sem que tenha de resolver problemas e corrigir situações. Para oferecer esta resiliência, os clusters regionais do GKE distribuem nós de computação por zonas, e o controlador do Kubernetes responde automaticamente a problemas de serviço no cluster.
Neste tutorial, vai aprender a simular uma falha no Google Cloud e ver como os serviços de aplicação no cluster do GKE respondem. Aprende a concluir as seguintes tarefas:
- Reveja a distribuição de nós e serviços.
- Simular uma falha de nó ou zona.
- Confirme que os serviços continuam a ser executados nos restantes nós.
Custos
A ativação do GKE e a implementação da aplicação de exemplo do Cymbal Bank para esta série de tutoriais significa que incorre em custos por cluster para o GKE on Google Cloud , conforme indicado na nossa página de preços, até desativar o GKE ou eliminar o projeto.
Também é responsável por outros Google Cloud custos incorridos durante a execução da aplicação de exemplo do Cymbal Bank, como as cobranças das VMs do Compute Engine.
Antes de começar
Para saber como simular uma falha, tem de concluir o primeiro tutorial para criar um cluster do GKE que use o Autopilot e implementar a aplicação baseada em microsserviços de exemplo do Cymbal Bank.
Recomendamos que conclua este conjunto de tutoriais para apps escaláveis por ordem. À medida que avança no conjunto de tutoriais, aprende novas competências e usa produtos e serviços Google Cloud adicionais.
Reveja a distribuição de nós e serviços
No Google Cloud, uma região é uma localização geográfica específica onde pode
alojar os seus recursos. As regiões têm três ou mais zonas. Por exemplo, a região us-central1 denota uma região no centro-oeste dos Estados Unidos que tem várias zonas, como us-central1-a, us-central1-b e us-central1-c. As zonas têm ligações de rede de largura de banda elevada e baixa latência a outras zonas na mesma região.
Para implementar aplicações com tolerância a falhas e alta disponibilidade, a Google recomenda que implemente aplicações em várias zonas e regiões. Esta abordagem ajuda a proteger contra falhas inesperadas de componentes, até e incluindo uma zona ou uma região.
Quando criou o cluster do GKE no primeiro tutorial, foram usados alguns valores de configuração predefinidos. Por predefinição, um cluster do GKE que usa o Autopilot cria e executa nós que abrangem zonas da região que especificar. Esta abordagem significa que a aplicação de exemplo do Cymbal Bank já está implementada em várias zonas, o que ajuda a proteger contra falhas inesperadas.
Verifique a distribuição de nós no seu 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 seguinte exemplo de saída que mostra que os nós estão distribuídos pelas 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 da aplicação de exemplo do Cymbal Bank nos nós do cluster do GKE:
kubectl get pods -o wideO exemplo de saída seguinte mostra que os serviços estão distribuídos por nós no cluster. A partir do passo anterior para verificar como os nós estão distribuídos, esta saída mostra que os serviços são executados em várias 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
Simule uma indisponibilidade
A Google concebe zonas para minimizar o risco de falhas correlacionadas causadas por interrupções da infraestrutura física, como energia, refrigeração ou rede. No entanto, podem ocorrer problemas inesperados. Se um nó ou uma zona ficar indisponível, quer que os serviços continuem a ser executados noutros nós ou em zonas na mesma região.
O controlador do Kubernetes monitoriza o estado dos nós, dos serviços e das implementações no seu cluster. Se ocorrer uma indisponibilidade inesperada, o controlador reinicia os recursos afetados e o tráfego é encaminhado para nós em funcionamento.
Para simular uma indisponibilidade neste tutorial, isola e esvazia os nós numa das suas zonas. Esta abordagem simula o que acontece quando um nó falha ou quando uma zona inteira tem um problema. O controlador do Kubernetes deve reconhecer que alguns serviços já não estão disponíveis e têm de ser reiniciados em nós noutras zonas:
Isolar e esvaziar nós numa das zonas. O exemplo seguinte 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-daemonsetsEste comando marca os nós como não agendáveis para que os pods já não possam ser executados nestes nós. O Kubernetes reagenda os pods para outros nós em zonas em funcionamento.
Verifique a resposta de falha simulada
Num tutorial anterior desta série, aprendeu a configurar a instância do Prometheus gerida para o seu cluster do GKE de modo a monitorizar alguns dos serviços e gerar alertas se houver um problema. Se os pods estivessem a ser executados em nós na zona onde simulou uma indisponibilidade, recebe mensagens de notificação do Slack dos alertas gerados pelo Prometheus. Este comportamento mostra como pode criar um ambiente de aplicação moderno que monitoriza o estado de funcionamento das suas implementações, envia-lhe alertas se existir um problema e pode ajustar-se automaticamente a alterações de carga ou falhas.
O 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 seu 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 seguinte exemplo de saída que mostra que os nós estão agora distribuídos 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 já não estão disponíveis e redistribui os serviços pelos nós disponíveis. Todos os serviços devem continuar a ser executados.
Verifique a distribuição dos serviços da aplicação de exemplo do Cymbal Bank nos nós do cluster do GKE:
kubectl get pods -o wideO exemplo de saída seguinte mostra que os serviços estão distribuídos pelos nós restantes no cluster. A partir do passo anterior para verificar como os nós estão distribuídos, esta saída mostra que os serviços agora só são executados 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-node1Consulte os
AGEdos Serviços. No exemplo de saída anterior, alguns dos serviços têm uma idade inferior à de outros na aplicação de exemplo do Cymbal Bank. Estes serviços mais recentes foram executados anteriormente num dos nós onde simulou a falha. O controlador do Kubernetes reiniciou estes serviços nos nós disponíveis.
Num cenário real, resolveria o problema ou aguardaria pela resolução do problema de manutenção subjacente. Se configurou o Prometheus para enviar mensagens do Slack com base em alertas, vê estas notificações a serem recebidas. Também pode repetir opcionalmente os passos do tutorial anterior para dimensionar os recursos para ver como o cluster do GKE responde ao aumento da carga quando apenas duas zonas estão disponíveis na região. O cluster deve ser dimensionado com as duas zonas restantes disponíveis.
Limpar
Para evitar incorrer em custos na sua conta Google Cloud pelos recursos usados neste tutorial, elimine o projeto que criou.
- 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.
O que se segue?
Saiba como centralizar a gestão de alterações com a sincronização de configuração no próximo tutorial.