Simule uma falha de zona em clusters regionais do GKE

Padrão

---

Um requisito regulamentar comum é que uma empresa possa demonstrar a sua capacidade de recuperação de desastres (DR). Para aplicações executadas na nuvem, este requisito inclui a fiabilidade e a disponibilidade dos serviços quando os servidores alojados numa zona ficam indisponíveis durante um período. Este documento destina-se a administradores e arquitetos, operadores e administradores de cópias de segurança e recuperação de desastres (DR) que querem saber como simular uma comutação por falha de zona quando usam um cluster regional padrão do Google Kubernetes Engine (GKE).

Os clusters regionais do GKE são criados numa região escolhida pelo utilizador e executam o plano de controlo em VMs situadas em várias zonas na região escolhida. Os clusters do GKE Autopilot são sempre regionais, e os clusters do GKE Standard podem ser regionais ou zonais. Este tutorial usa um cluster regional padrão do GKE. Os nós do cluster comunicam com o plano de controlo através de um equilibrador de carga, o que significa que a localização do nó e a localização da VM do plano de controlo nem sempre correspondem. Na Google Cloud consola, não pode desativar uma zona específica quando usa um cluster regional. Para mais informações, consulte o artigo Arquitetura do cluster do GKE.

Este tutorial apresenta três métodos diferentes para simular uma falha de zona. Pode simular uma falha de zona e validar a resposta correta da aplicação através do método necessário para fins de conformidade.

Os métodos neste documento também se aplicam a clusters zonais, incluindo os de zona única e multizonais. Estes métodos só afetam os nós nas zonas segmentadas e o plano de controlo do GKE não é afetado.

Objetivos

• Crie um cluster padrão do GKE regional com a configuração predefinida.
• Implemente uma aplicação de microsserviços de exemplo no cluster regional.
• Simule uma indisponibilidade de zona através de um dos três métodos seguintes:
  • Reduza as zonas do node pool num cluster regional.
  • Use um node pool de zona única.
  • Isolar e drenar os nós da zona de falha alvo.
• Verifique a disponibilidade dos microsserviços.

Custos

Este tutorial usa os seguintes componentes faturáveis do Google Cloud:

• Compute Engine
• Cluster do modo Standard do GKE

Use a Calculadora de preços para gerar uma estimativa de custos com base na sua utilização projetada.

Antes de começar

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Install the Google Cloud CLI.

Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Create or select a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

• Create a Google Cloud project:

  gcloud projects create PROJECT_ID

  Replace PROJECT_ID with a name for the Google Cloud project you are creating.

• Select the Google Cloud project that you created:

  gcloud config set project PROJECT_ID

  Replace PROJECT_ID with your Google Cloud project name.

Verify that billing is enabled for your Google Cloud project.

Enable the Kubernetes Engine API, Compute Engine APIs:

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

gcloud services enable container.googleapis.com compute.googleapis.com

Install the Google Cloud CLI.

Se estiver a usar um fornecedor de identidade (IdP) externo, tem primeiro de iniciar sessão na CLI gcloud com a sua identidade federada.

Para inicializar a CLI gcloud, execute o seguinte comando:

gcloud init

Create or select a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

• Create a Google Cloud project:

  gcloud projects create PROJECT_ID

  Replace PROJECT_ID with a name for the Google Cloud project you are creating.

• Select the Google Cloud project that you created:

  gcloud config set project PROJECT_ID

  Replace PROJECT_ID with your Google Cloud project name.

Verify that billing is enabled for your Google Cloud project.

Enable the Kubernetes Engine API, Compute Engine APIs:

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

gcloud services enable container.googleapis.com compute.googleapis.com

Crie um cluster padrão regional

Antes de simular uma falha de zona, crie um cluster regional com um conjunto de nós multizona. O painel de controlo e os nós do cluster são replicados em várias zonas na região especificada.

Use a Google Cloud CLI para criar o cluster:

1. Crie um novo cluster padrão do GKE com a configuração predefinida:

   gcloud container clusters create CLUSTER_NAME \
     --location CONTROL_PLANE_LOCATION \
     --num-nodes 2
   

   Substitua os seguintes parâmetros:

   • CLUSTER_NAME: o nome do cluster.
   • CONTROL_PLANE_LOCATION: a região do Compute Engine do plano de controlo do seu cluster, como us-central1.

   O GKE demora alguns minutos a criar o cluster e a verificar se tudo funciona corretamente. São criados dois nós em cada zona da região que especificar.

2. Verifique as zonas de cada nó criado no passo anterior:

   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   O resultado tem o seguinte aspeto:

   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node1   asia-southeast1-c   10.128.0.37
   regional-cluster-1-default-pool-node2   asia-southeast1-c   10.128.0.36
   regional-cluster-1-default-pool-node3   asia-southeast1-b   10.128.0.38
   regional-cluster-1-default-pool-node4   asia-southeast1-b   10.128.0.33
   regional-cluster-1-default-pool-node5   asia-southeast1-a   10.128.0.35
   regional-cluster-1-default-pool-node6   asia-southeast1-a   10.128.0.34
   

3. Ligue-se ao cluster:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location CONTROL_PLANE_LOCATION
   

Implemente uma aplicação de microsserviços de exemplo

Para ver o efeito da comutação por falha simulada neste documento, implemente uma aplicação de exemplo baseada em microsserviços no seu cluster. Neste documento, usa a aplicação de exemplo Cymbal Bank:

1. Na shell, clone o seguinte repositório do GitHub e mude para o diretório:

   git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
   cd bank-of-anthos/
   

2. Implemente a aplicação de exemplo Cymbal Bank no cluster do GKE que criou na secção anterior:

   kubectl apply -f ./extras/jwt/jwt-secret.yaml
   kubectl apply -f ./kubernetes-manifests
   

3. Aguarde até que os pods estejam prontos:

   kubectl get pods
   

4. Após alguns minutos, deve ver os pods no estado Running:

   NAME                                  READY   STATUS    RESTARTS   AGE
   accounts-db-0                         1/1     Running   0          16s
   balancereader-7dc7d9ff57-sstm5        0/1     Running   0          15s
   contacts-7ddc76d94-rr28x              0/1     Running   0          14s
   frontend-747b84bff4-2mtlv             0/1     Running   0          13s
   ledger-db-0                           1/1     Running   0          13s
   ledgerwriter-f6cc7889d-9qjfg          0/1     Running   0          13s
   loadgenerator-57d4cb57cc-zqvqb        1/1     Running   0          13s
   transactionhistory-5dd7c7fd77-lwkv8   0/1     Running   0          12s
   userservice-cd5ddb4bb-wwhml           0/1     Running   0          12s
   

5. Quando todos os pods estiverem no estado Running, obtenha o endereço IP externo do serviço de front-end:

   kubectl get service frontend | awk '{print $4}'
   

6. Numa janela do navegador de Internet, abra o endereço IP apresentado no resultado do comando kubectl get service para aceder à sua instância do Cymbal Bank.

   As credenciais predefinidas são preenchidas automaticamente, para que possa iniciar sessão na app e explorar algumas das transações e saldos de exemplo. Não tem de tomar medidas específicas, exceto confirmar que o Cymbal Bank é executado com êxito. Pode demorar alguns minutos até que todos os serviços sejam iniciados corretamente e lhe permitam iniciar sessão. Aguarde até que todos os pods estejam no estado Running e consiga iniciar sessão com êxito no site do Cymbal Bank antes de avançar para a secção seguinte e simular uma falha de zona.

Simule uma falha de zona

Nesta secção, simula uma falha com uma das zonas. Existem três formas diferentes de simular esta comutação por falha. Só tem de escolher um método. Simule uma falha de zona e valide a resposta correta da aplicação através do método necessário para fins de conformidade.

Nota: se as suas aplicações contiverem cargas de trabalho com estado, como bases de dados, certifique-se de que os dados são armazenados num volume de disco persistente separado e que as réplicas de leitura são implementadas em várias zonas. Verifique este armazenamento de dados antes de eliminar um conjunto de nós (simule uma falha de zona) ou considere usar o disco persistente regional. Para proteção adicional, também pode usar a cópia de segurança do GKE. A consistência, a fiabilidade e a estratégia de mitigação dos dados dos StatefulSets estão fora do âmbito deste documento. Se não tiver em conta estes fatores de armazenamento, existe o risco de potencial perda de dados. Consulte a documentação da sua base de dados ou aplicação com estado específica, como PostgreSQL, SQL Server, MongoDB, Redis ou Cassandra, para saber mais sobre as respetivas estratégias de alta disponibilidade e recuperação de desastres recomendadas.

Reduza as zonas do node pool

Por predefinição, um conjunto de nós de um cluster regional tem nós que abrangem todas as zonas da respetiva região. No diagrama seguinte, o Cloud Load Balancing distribui o tráfego para um conjunto de nós que abrange três zonas. Cada zona tem dois nós e os seus Pods podem ser executados em nós em qualquer uma destas zonas.



Nesta secção, simula uma falha de zona atualizando o node pool para ser executado apenas em duas das três zonas. Esta abordagem verifica se a sua aplicação consegue responder à perda de uma zona redistribuindo corretamente os pods e o tráfego por outras zonas.

Para atualizar o conjunto de nós para ser executado apenas em determinadas zonas e simular uma falha, conclua os seguintes passos:

1. Verifique a disponibilidade do cluster regional e dos serviços:

   kubectl get po -o wide \
   kubectl get node -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 resultado:

   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          6m30s   10.28.1.5   regional-cluster-1-default-pool-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          6m30s   10.28.5.6   regional-cluster-1-default-pool-node1
   contacts-7ddc76d94-qv4x5              1/1     Running   0          6m29s   10.28.4.6   regional-cluster-1-default-pool-node2
   frontend-747b84bff4-xvjxq             1/1     Running   0          6m29s   10.28.3.6   regional-cluster-1-default-pool-node6
   ledger-db-0                           1/1     Running   0          6m29s   10.28.5.7   regional-cluster-1-default-pool-node1
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          6m29s   10.28.1.6   regional-cluster-1-default-pool-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          6m29s   10.28.4.7   regional-cluster-1-default-pool-node2
   transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          6m29s   10.28.3.7   regional-cluster-1-default-pool-node6
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          6m28s   10.28.5.8   regional-cluster-1-default-pool-node1
   
   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.6
   regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.7
   regional-cluster-1-default-pool-node2   asia-southeast1-a   10.148.0.8
   regional-cluster-1-default-pool-node1   asia-southeast1-a   10.148.0.9
   regional-cluster-1-default-pool-node3   asia-southeast1-b   10.148.0.5
   regional-cluster-1-default-pool-node4   asia-southeast1-b   10.148.0.4
   

   Neste exemplo, todas as cargas de trabalho do Cymbal Bank estão implementadas em todas as zonas. Para simular uma falha, desative uma das zonas, como asia-southeast1-c, onde o serviço de front-end está implementado.

2. Simule uma indisponibilidade de zona. Atualize o node pool existente (default-pool) para especificar apenas duas das três zonas:

     gcloud container node-pools update default-pool \
       --cluster=CLUSTER_NAME \
       --node-locations=ZONE_A, ZONE_B \
       --location=CONTROL_PLANE_LOCATION
   

   Substitua ZONE_A, ZONE_B pelas duas zonas onde quer que o conjunto de nós continue a ser executado.

3. Valide a disponibilidade dos microsserviços depois de atualizar o conjunto de nós:

   kubectl get po -o wide
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   O resultado deve ser semelhante ao seguinte exemplo:

   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node2   asia-southeast1-a   10.148.0.8
   regional-cluster-1-default-pool-node1   asia-southeast1-a   10.148.0.9
   regional-cluster-1-default-pool-node3   asia-southeast1-b   10.148.0.5
   regional-cluster-1-default-pool-node4   asia-southeast1-b   10.148.0.4
   
   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          28m     10.28.1.5   regional-cluster-1-default-pool-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          28m     10.28.5.6   regional-cluster-1-default-pool-node1
   contacts-7ddc76d94-qv4x5              1/1     Running   0          28m     10.28.4.6   regional-cluster-1-default-pool-node2
   frontend-747b84bff4-mdnkd             1/1     Running   0          9m21s   10.28.1.7   regional-cluster-1-default-pool-node3
   ledger-db-0                           1/1     Running   0          28m     10.28.5.7   regional-cluster-1-default-pool-node1
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   regional-cluster-1-default-pool-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          28m     10.28.4.7   regional-cluster-1-default-pool-node2
   transactionhistory-5dd7c7fd77-w2vqs   1/1     Running   0          9m20s   10.28.4.8   regional-cluster-1-default-pool-node2
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          28m     10.28.5.8   regional-cluster-1-default-pool-node1
   

   Neste exemplo de saída, asia-southeast1-c já não está a ser usado. O serviço de front-end ao qual acede a partir de um navegador com o URL http://EXTERNAL_IP continua acessível. Um utilizador continua a poder realizar ações de depósito e pagamento, mesmo que uma das zonas já não esteja disponível.

Use um node pool de zona única

Nesta secção, vai simular uma falha de zona eliminando dois node pools. Esta abordagem verifica se a sua aplicação consegue responder à perda de um conjunto de nós redistribuindo corretamente os pods e o tráfego num conjunto de nós noutra zona. Para simular uma indisponibilidade de zona num cluster regional, expande o cluster básico criado anteriormente, executando a aplicação Cymbal Bank em vários node pools. Este método de simulação da interrupção da zona reflete mais de perto uma falha real da zona do que o primeiro exemplo de atualização das zonas ativas num conjunto de nós, uma vez que é mais comum existirem vários conjuntos de nós num cluster:



O cluster que cria nesta secção para simular uma falha do conjunto de nós de zona única inclui os seguintes componentes:

• Node pool predefinido, normalmente criado quando cria um cluster padrão do GKE regional, que é um node pool multizonal (default-pool).

  Este cluster com o único default-pool é o que criou anteriormente neste documento.

• Pools de nós adicionais (zonal-node-pool-1 e zonal-node-pool-2) que também executam serviços para a aplicação de exemplo Cymbal Bank.

As linhas tracejadas no diagrama mostram como o tráfego só é publicado zonal-node-pool-2 depois de simular uma falha em default-pool e zonal-node-pool-1.

Para criar pools de nós adicionais e simular uma falha, conclua os seguintes passos:

1. Verifique a disponibilidade do cluster regional:

   gcloud container node-pools list \
       --cluster=CLUSTER_NAME \
       --location CONTROL_PLANE_LOCATION
   
   kubectl get node -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 resultado:

   NAME: default-pool
   MACHINE_TYPE: e2-medium
   DISK_SIZE_GB: 100
   NODE_VERSION: 1.27.8-gke.1067004
   
   NAME                                         ZONE.               INT_IP
   regional-cluster-1-default-pool-node5-pzmc   asia-southeast1-c   10.148.0.6
   regional-cluster-1-default-pool-node6-qf1l   asia-southeast1-c   10.148.0.7
   regional-cluster-1-default-pool-node2-dlk2   asia-southeast1-a   10.148.0.8
   regional-cluster-1-default-pool-node1-pkfd   asia-southeast1-a   10.148.0.9
   regional-cluster-1-default-pool-node3-6b6n   asia-southeast1-b   10.148.0.5
   regional-cluster-1-default-pool-node4-h0lc   asia-southeast1-b   10.148.0.4
   

   Neste exemplo de resultado, todos os pods do Cymbal Bank são implementados em todas as zonas no mesmo cluster e executados no default-pool existente.

2. Crie dois novos node pools de zona única:

   gcloud beta container node-pools create zonal-node-pool-1 \
     --cluster CLUSTER_NAME \
     --location CONTROL_PLANE_LOCATION \
     --num-nodes 4 \
     --node-locations ZONE_A
   
   gcloud beta container node-pools create zonal-node-pool-2 \
       --cluster CLUSTER_NAME \
       --location CONTROL_PLANE_LOCATION \
       --num-nodes 4 \
       --node-locations ZONE_B
   

   Substitua ZONE_A e ZONE_B pelas duas zonas onde quer que os novos conjuntos de nós de zona única sejam executados.

3. Para simular uma falha de zona, elimine o node pool regional default-pool e um dos novos node pools de zona única:

   gcloud container node-pools delete default-pool \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   
   gcloud container node-pools delete zonal-node-pool-1 \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   

   Durante o processo de eliminação do node-pool, as cargas de trabalho são encerradas e reagendadas para outro conjunto de nós disponível. Quando este processo ocorre, os serviços e as implementações não estão disponíveis. Este comportamento significa que as janelas de tempo de inatividade têm de ser especificadas para a criação de relatórios ou a documentação de recuperação de desastres.

   Verifique a disponibilidade contínua dos microsserviços:

   kubectl get po -o wide \
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   O resultado deve ser semelhante ao seguinte exemplo:

   NAME                                  ZONE                INT_IP
   regional-cluster-1-node-pool3-node1   asia-southeast1-b   10.148.0.8
   regional-cluster-1-node-pool3-node2   asia-southeast1-b   10.148.0.9
   regional-cluster-1-node-pool3-node3   asia-southeast1-b   10.148.0.5
   regional-cluster-1-node-pool3-node4   asia-southeast1-b   10.148.0.4
   
   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          28m     10.28.1.5   regional-cluster-1-zonal-node-pool-2-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          28m     10.28.5.6   regional-cluster-1-zonal-node-pool-2-node1
   contacts-7ddc76d94-qv4x5              1/1     Running   0          28m     10.28.4.6   regional-cluster-1-zonal-node-pool-2-node2
   frontend-747b84bff4-mdnkd             1/1     Running   0          9m21s   10.28.1.7   regional-cluster-1-zonal-node-pool-2-node3
   ledger-db-0                           1/1     Running   0          28m     10.28.5.7   regional-cluster-1-zonal-node-pool-2-node4
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   regional-cluster-1-zonal-node-pool-2-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          28m     10.28.4.7   regional-cluster-1-zonal-node-pool-2-node2
   transactionhistory-5dd7c7fd77-w2vqs   1/1     Running   0          9m20s   10.28.4.8   regional-cluster-1-zonal-node-pool-2-node2
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          28m     10.28.5.8   regional-cluster-1-zonal-node-pool-2-node1
   

   Neste exemplo de saída, como o default-pool e o zonal-node-pool-1 já não existem, todos os serviços são executados em zonal-node-pool-2.

Restrinja e drene nós numa zona

Nesta secção, isola e esvazia nós específicos no cluster. Isola e esgota todos os nós numa única zona, o que simula a perda dos pods que são executados nesses nós na zona:



Neste diagrama, isola e esvazia os nós na primeira zona. Os nós nas outras duas zonas continuam a ser executados. Esta abordagem verifica se a sua aplicação consegue responder à perda de todos os nós numa zona redistribuindo corretamente os pods e o tráfego entre os nós que são executados noutras zonas.

Para isolar e esvaziar os nós numa das zonas, simulando uma falha, conclua os seguintes passos:

1. Verifique a disponibilidade do cluster regional e dos serviços. Analise os nomes dos nós da zona de falha do destino. Quer especificar uma zona onde os pods de front-end são executados:

   kubectl get pods -o wide
   

   O resultado deve ser semelhante ao seguinte exemplo:

   NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE
   accounts-db-0                         1/1     Running   0          4m7s    10.96.4.4    regional-cluster-1-default-pool-node2
   balancereader-7dc7d9ff57-lv4z7        1/1     Running   0          4m7s    10.96.1.5    regional-cluster-1-default-pool-node1
   contacts-7ddc76d94-wxvg5              1/1     Running   0          4m7s    10.96.6.11   regional-cluster-1-default-pool-node3
   frontend-747b84bff4-gvktl             1/1     Running   0          4m7s    10.96.1.4    regional-cluster-1-default-pool-node1
   ledger-db-0                           1/1     Running   0          4m7s    10.96.4.5    regional-cluster-1-default-pool-node2
   ledger-db-1                           1/1     Running   0          3m50s   10.96.0.13   regional-cluster-1-default-pool-node5
   ledgerwriter-f6cc7889d-4hqbm          1/1     Running   0          4m6s    10.96.0.12   regional-cluster-1-default-pool-node5
   loadgenerator-57d4cb57cc-fmq52        1/1     Running   0          4m6s    10.96.4.6    regional-cluster-1-default-pool-node2
   transactionhistory-5dd7c7fd77-72zpx   1/1     Running   0          4m6s    10.96.6.12   regional-cluster-1-default-pool-node3
   userservice-cd5ddb4bb-b7862           1/1     Running   0          4m6s    10.96.1.6    regional-cluster-1-default-pool-node1
   

2. Associe os pods indicados no resultado anterior à zona do nó:

   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   O resultado deve ser semelhante ao seguinte exemplo:

   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node1   asia-southeast1-b   10.148.0.41
   regional-cluster-1-default-pool-node2   asia-southeast1-b   10.148.0.42
   regional-cluster-1-default-pool-node3   asia-southeast1-a   10.148.0.37
   regional-cluster-1-default-pool-node4   asia-southeast1-a   10.148.0.38
   regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.40
   regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.39
   

   No exemplo de saída anterior, os pods de front-end estão localizados em regional-cluster-1-default-pool-node1 na zona asia-southeast1-b.

   No passo seguinte, rastreia todos os nós na zona asia-southeast1-b, que, neste exemplo, são regional-cluster-1-default-pool-node1 e regional-cluster-1-default-pool-node2

3. Isolar e esvaziar os nós de destino numa das zonas. Neste exemplo, são os dois nós em asia-southeast1-b:

   kubectl drain regional-cluster-1-default-pool-node1 \
       --delete-emptydir-data --ignore-daemonsets
   
   kubectl drain regional-cluster-1-default-pool-node2 \
       --delete-emptydir-data --ignore-daemonsets
   

   Este comando marca os nós como não agendáveis e simula falhas de nós. O Kubernetes reagenda os pods para outros nós em zonas em funcionamento.

4. Veja onde os novos pods de front-end e outros pods de exemplo do Cymbal Bank que estavam anteriormente em execução no nó na zona de falha foram reagendados:

   kubectl get po -o wide
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   O resultado deve ser semelhante ao seguinte exemplo:

   NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE
   accounts-db-0                         1/1     Running   0          4m7s    10.96.4.4    regional-cluster-1-default-pool-node4
   balancereader-7dc7d9ff57-lv4z7        1/1     Running   0          4m7s    10.96.1.5    regional-cluster-1-default-pool-node6
   contacts-7ddc76d94-wxvg5              1/1     Running   0          4m7s    10.96.6.11   regional-cluster-1-default-pool-node3
   frontend-747b84bff4-gvktl             1/1     Running   0          4m7s    10.96.1.4    regional-cluster-1-default-pool-node3
   ledger-db-0                           1/1     Running   0          4m7s    10.96.4.5    regional-cluster-1-default-pool-node6
   ledger-db-1                           1/1     Running   0          3m50s   10.96.0.13   regional-cluster-1-default-pool-node5
   ledgerwriter-f6cc7889d-4hqbm          1/1     Running   0          4m6s    10.96.0.12   regional-cluster-1-default-pool-node5
   loadgenerator-57d4cb57cc-fmq52        1/1     Running   0          4m6s    10.96.4.6    regional-cluster-1-default-pool-node4
   transactionhistory-5dd7c7fd77-72zpx   1/1     Running   0          4m6s    10.96.6.12   regional-cluster-1-default-pool-node3
   userservice-cd5ddb4bb-b7862           1/1     Running   0          4m6s    10.96.1.6    regional-cluster-1-default-pool-node3
   
   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node3   asia-southeast1-a   10.148.0.37
   regional-cluster-1-default-pool-node4   asia-southeast1-a   10.148.0.38
   regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.40
   regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.39
   

   Neste exemplo de resultado, não existem exemplos de pods do Cymbal Bank que sejam executados em nós isolados, e todos os pods são agora executados apenas nas outras duas zonas.

   Os orçamentos de interrupção de pods (PDBs) nos nós podem bloquear a drenagem de nós. Avalie as políticas de PDB antes da ação de isolamento e esgotamento. Para compreender melhor o PDB e a respetiva relação com a gestão de interrupções, veja como garantir a fiabilidade e o tempo de atividade do seu cluster do GKE.

   Nota: depois de simular a falha, pode usar kubectl uncordon para permitir que os pods sejam agendados novamente nos nós.

Limpar

Para evitar incorrer em custos na sua Google Cloud conta pelos recursos usados neste tutorial:

Elimine o projeto

A forma mais fácil de eliminar a faturação é eliminar o projeto que criou para o tutorial.

Atenção: a eliminação de um projeto tem os seguintes efeitos:

• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar o projeto inteiro.

Se planeia explorar várias arquiteturas, tutoriais ou inícios rápidos, a reutilização de projetos pode ajudar a evitar exceder os limites de quota de projetos.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

O que se segue?

• Saiba como simular uma indisponibilidade de zona para um grupo de instâncias gerido (MIG) regional.
• Saiba mais sobre a recuperação de desastres no Google Cloud.
• Configure o PostgreSQL de alta disponibilidade em várias zonas.
• Considerações sobre o orçamento de interrupção de pods.
• Saiba mais sobre os discos persistentes zonais versus regionais.
• Saiba como executar bases de dados de alta disponibilidade no GKE.
• Saiba mais sobre as práticas recomendadas de recuperação de desastres no Google Cloud.
• Saiba mais sobre a cópia de segurança do GKE.