Simular uma falha de zona em clusters regionais do GKE

Padrão

---

Um requisito regulamentar comum é que uma empresa possa demonstrar a própria capacidade de recuperação de desastres (DR). Para aplicativos executados na nuvem, esse requisito inclui a confiabilidade e a disponibilidade dos serviços quando os servidores hospedados em uma zona ficam indisponíveis por um período. Este documento é destinado a administradores e arquitetos, operadores e administradores de backup e recuperação de desastres (DR) que querem saber como simular um failover de zona ao usar um cluster regional padrão do Google Kubernetes Engine (GKE) ,

Os clusters regionais do GKE são criados em uma região escolhida pelo usuário e executam o plano de controle em VMs em várias zonas dentro da região escolhida. Os clusters do Autopilot do GKE são sempre regionais, e os clusters do GKE Standard podem ser regionais ou zonais. Neste tutorial, usamos um cluster regional do GKE Standard. Os nós do cluster se comunicam com o plano de controle por um balanceador de carga, o que significa que o local do nó e o local da VM do plano de controle nem sempre correspondem. No console do Google Cloud, não é possível desativar uma zona específica ao usar um cluster regional. Para mais informações, consulte Arquitetura de clusters do GKE.

Neste tutorial, fornecemos três métodos diferentes para simular a falha de uma zona. Simule uma falha de zona e verifique a resposta correta do aplicativo usando o método necessário para seus fins de conformidade.

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

Objetivos

• Crie um cluster regional do GKE Standard usando a configuração padrão.
• Implante um aplicativo de microsserviços de amostra no cluster regional.
• Simule uma interrupção de zona usando um dos três métodos a seguir:
  • Reduza as zonas do pool de nós em um cluster regional.
  • Use um pool de nós de zona única.
  • Restrinja e drene os nós da zona de falha de destino.
• Verificar a disponibilidade dos microsserviços.

Custos

Neste tutorial, usamos o seguinte componente faturável do Google Cloud:

• Compute Engine
• Cluster do modo GKE Standard

Use a calculadora de preços para gerar uma estimativa de custo baseada na projeção de uso.

Antes de começar

1. 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.
2. Install the Google Cloud CLI.

3. To initialize the gcloud CLI, run the following command:

   gcloud init

4. Create or select a Google Cloud project.

   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.

5. Make sure that billing is enabled for your Google Cloud project.

6. Enable the Kubernetes Engine API, Compute Engine APIs:

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

7. Install the Google Cloud CLI.

8. To initialize the gcloud CLI, run the following command:

   gcloud init

9. Create or select a Google Cloud project.

   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.

10. Make sure that billing is enabled for your Google Cloud project.

11. Enable the Kubernetes Engine API, Compute Engine APIs:

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

Criar um cluster padrão regional

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

Use o Google Cloud CLI para criar o cluster:

1. Crie um novo cluster do GKE Standard usando a configuração padrão:

   gcloud container clusters create CLUSTER_NAME \
     --region REGION \
     --num-nodes 2
   

   Substitua os seguintes parâmetros:

   • CLUSTER_NAME: o nome do cluster.
   • REGION: a us-central1região do cluster, como .

   O GKE leva alguns minutos para criar o cluster e verificar se tudo funciona corretamente. Dois nós são criados em cada zona da região especificada.

2. Verifique as zonas de cada nó criado na etapa anterior:

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

   A resposta tem a aparência do exemplo a seguir.

   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. Conecte-se ao cluster:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --region REGION
   

Implantar um aplicativo de microsserviços de amostra

Para ver o efeito do failover simulado neste documento, implante um aplicativo de amostra baseado em microsserviços no cluster. Neste documento, você usa o aplicativo de exemplo Cymbal Bank:

1. No 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. Implante o aplicativo de amostra do Cymbal Bank no cluster do GKE que você criou na seçã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, os pods serão exibidos com o 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, receba o endereço IP externo do serviço do front-end:

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

6. Em uma janela do navegador da Web, abra o endereço IP mostrado na saída do comando kubectl get service para acessar sua instância do Cymbal Bank.

   As credenciais padrão são preenchidas automaticamente para que você possa fazer login no app e explorar algumas das transações e saldos de amostra. Nenhuma ação específica que você precisa tomar, além de confirmar se o Cymbal Bank é executado com sucesso. Pode levar um ou dois minutos para que todos os Serviços sejam iniciados corretamente e permitam que você faça login. Aguarde até que todos os pods estejam no estado Running e consiga fazer login no site do Cymbal Bank antes de passar para a próxima seção e simular uma falha de zona.

Simular uma falha de zona

Nesta seção, você simulará uma falha em uma das zonas. Há três maneiras diferentes de simular esse failover. Você só precisa escolher um método. Simule uma falha de zona e verifique a resposta correta do aplicativo usando o método que for necessário para seus fins de conformidade.

Observação: se os aplicativos tiverem cargas de trabalho com estado, como bancos de dados, verifique se os dados estão armazenados em um volume de disco permanente separado e se as réplicas de leitura estão implantados em várias zonas. Verifique esse armazenamento de dados antes de excluir um pool de nós (simule uma falha de zona) ou considere usar o Persistent Disk regional. Para mais proteção, também é possível usar o Backup para GKE. A consistência, a confiabilidade e a estratégia de mitigação de dados do StatefulSets estão fora do escopo deste documento. Se você não considerar esses fatores de armazenamento, há um risco de possível perda de dados. Consulte a documentação do banco de dados específico ou do aplicativo com estado, como PostgreSQL, SQL Server, MongoDB, Redis ou Cassandra para saber mais sobre as estratégias recomendadas de alta disponibilidade e recuperação de desastres.

Reduzir zonas do pool de nós

Por padrão, um pool de nós de um cluster regional tem nós que se estendem por todas as zonas da região dele. No diagrama a seguir, o Cloud Load Balancing distribui o tráfego para um pool de nós que abrange três zonas. Cada zona tem dois nós, e os pods podem ser executados em nós em qualquer uma dessas zonas.

Nesta seção, você simulará uma falha de zona atualizando o pool de nós para ser executado apenas em duas das três zonas. Essa abordagem verifica se o aplicativo pode responder à perda de uma zona redistribuindo corretamente os pods e o tráfego entre outras zonas.

Para atualizar o pool de nós para que ele seja executado apenas em determinadas zonas e simular falhas, siga estas etapas:

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 exemplo de saída a seguir:

   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 são implantadas em todas as zonas. Para simular uma falha, desative uma das zonas, como asia-southeast1-c, em que o serviço de front-end é implantado.

2. Simule uma interrupção de zona. Atualize o pool de nós atual (default-pool) para especificar apenas duas zonas das três zonas:

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

   Substitua ZONE_A, ZONE_B pelas duas zonas em que você quer que o pool de nós continue em execução.

3. Verifique a disponibilidade dos microsserviços depois de atualizar o pool 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'
   

   A saída será semelhante ao exemplo a seguir:

   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 não está mais em uso. O serviço de front-end acessado em um navegador com o URL http://EXTERNAL_IP ainda estará acessível. Um usuário ainda poderá realizar ações de depósito e pagamento, mesmo que uma das zonas não esteja mais disponível.

Usar um pool de nós de zona única

Nesta seção, você simulará uma falha de zona excluindo dois dos pools de nós. Essa abordagem verifica se o aplicativo pode responder à perda de um pool de nós redistribuindo corretamente os pods e o tráfego em um pool de nós em outra zona. Para simular uma interrupção de zona em um cluster regional, expanda o cluster básico criado anteriormente executando o aplicativo Cymbal Bank em vários pools de nós. Esse método para simular a interrupção de zona reflete mais precisamente uma falha de zona real do que o primeiro exemplo de atualização de zonas ativas em um pool de nós, já que é mais comum a existência de vários pools de nós em um cluster:

O cluster criado nesta seção para simular uma falha em um pool de nós de zona única inclui os seguintes componentes:

• O pool de nós padrão, geralmente criado quando você cria um cluster padrão do GKE regional, é um pool de nós multizonal (default-pool).

  Esse cluster com o único default-pool é o que você 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 o aplicativo de exemplo do Cymbal Bank.

As linhas pontilhadas no diagrama mostram como o tráfego só atende zonal-node-pool-2 depois que você simula uma falha em default-pool e zonal-node-pool-1.

Para criar mais pools de nós e simular falhas, siga estas etapas:

1. Verifique a disponibilidade do cluster regional:

   gcloud container node-pools list \
       --cluster=CLUSTER_NAME \
       --region REGION
   
   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 exemplo de saída a seguir:

   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 saída, todos os pods do Cymbal Bank são implantados em todas as zonas no mesmo cluster e executados no default-pool atual.

2. Crie dois novos pools de nós de zona única:

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

   Substitua ZONE_A e ZONE_B pelas duas zonas em que você quer que os novos pools de nós de zona única sejam executados.

3. Para simular uma falha de zona, exclua o pool de nós regional default-pool e um dos novos pools de nós de zona única:

   gcloud container node-pools delete default-pool \
       --cluster=CLUSTER_NAME \
       --region=REGION
   
   gcloud container node-pools delete zonal-node-pool-1 \
       --cluster=CLUSTER_NAME \
       --region=REGION
   

   Durante o processo de exclusão node-pool, as cargas de trabalho são encerradas e reprogramadas para outro pool de nós disponível. Quando esse processo acontece, os Serviços e as Implantações não ficam disponíveis. Esse comportamento significa que as janelas de inatividade precisam ser especificadas para relatórios ou documentação de DR.

   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'
   

   A saída será semelhante ao exemplo a seguir.

   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 a default-pool e o zonal-node-pool-1 não existem mais, todos os serviços são executados em zonal-node-pool-2.

Restringir e drenar nós em uma zona

Nesta seção, você restringe e drena nós específicos no cluster. Você restringe e drena todos os nós em uma única zona, o que simula a perda dos pods executados nesses nós em toda a zona:

Neste diagrama, você restringe e drena os nós na primeira zona. Os nós das outras duas zonas continuam em execução. Essa abordagem verifica se o aplicativo pode responder à perda de todos os nós em uma zona redistribuindo corretamente os pods e o tráfego entre os nós executados em outras zonas.

Para restringir e drenar os nós em uma das zonas, simulando uma falha, conclua as seguintes etapas:

1. Verifique a disponibilidade do cluster regional e dos serviços. Confira os nomes dos nós da zona de falha de destino. Você quer especificar uma zona em que os pods de front-end serão executados:

   kubectl get pods -o wide
   

   A saída será semelhante ao exemplo a seguir:

   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 listados na saída 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'
   

   A saída será semelhante ao exemplo a seguir:

   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.

   Na próxima etapa, você vai rastrear todos os nós na zona asia-southeast1-b, que neste exemplo de saída são regional-cluster-1-default-pool-node1 e regional-cluster-1-default-pool-node2.

3. Restrinja e drene os nós de destino em uma das zonas. Neste exemplo, estes 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
   

   Esse comando marca os nós como não programáveis e simula falhas de nós. O Kubernetes reprograma os pods para outros nós em zonas funcionais.

4. Confira onde os novos pods de front-end e outros exemplos de pods do Cymbal Bank que antes eram executados no nó na zona de falha agora estão reprogramados:

   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'
   

   A saída será semelhante ao exemplo a seguir:

   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 saída, não há exemplos de pods do Cymbal Bank executados em nós restritos, e todos os pods agora são executados apenas nas outras duas zonas.

   Os orçamentos de interrupção de pods (PDBs, na sigla em inglês) nos nós podem bloquear a drenagem de nós. Avalie as políticas do PDB antes da ação de restrição e drenagem. Para entender mais sobre o PDB e a relação dele com o gerenciamento de interrupções, confira como garantir a confiabilidade e o tempo de atividade do seu cluster do GKE.

   Observação: depois de simular a falha, é possível usar kubectl uncordon para permitir que os pods sejam programados nos nós novamente.
   .

Limpar

Para evitar cobranças dos recursos usados neste tutorial na conta do Google Cloud, siga estas etapas:

Exclua o projeto

A maneira mais fácil de eliminar o faturamento é excluir o projeto que você criou para o tutorial.

Cuidado: excluir um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
• Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

A seguir

• Saiba como simular uma interrupção de zona para um grupo gerenciado de instâncias (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 do orçamento de interrupção de pods.
• Saiba mais sobre discos permanentes zonais versus regionais.
• Saiba como executar bancos de dados de alta disponibilidade no GKE.
• Saiba mais sobre as práticas recomendadas para recuperação de desastres no Google Cloud.
• Saiba mais sobre o Backup para GKE.