Esta página foi traduzida pela API Cloud Translation.

Simular uma falha de zona em clusters regionais do GKE

Standard

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 doGoogle 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 os seguintes componentes faturáveis 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

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.

If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

To initialize the gcloud CLI, run the following command:

gcloud init

Create or select a Google Cloud 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.

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

Enable the Kubernetes Engine API, Compute Engine APIs:

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

Install the Google Cloud CLI.

If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

To initialize the gcloud CLI, run the following command:

gcloud init

Create or select a Google Cloud 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.

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

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:

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.

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

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:

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/

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
```
Aguarde até que os pods estejam prontos:
```
kubectl get pods
```

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

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}'
```
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.

Um balanceador de carga direciona o tráfego para um cluster regional que é executado em três zonas. Cada zona tem dois nós.

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:

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.

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.

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:

Um balanceador de carga direciona o tráfego para um cluster regional que é executado em três pools de nós. O pool de nós padrão é executado em todas as zonas, e os outros dois pools de nós são executados em uma única zona.

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:

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.

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.

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:

Um balanceador de carga direciona o tráfego para um cluster regional que é executado em três zonas. Cada zona contém dois nós, e os pods de aplicativo de amostra do Cymbal Bank são executados em todas as zonas e nós.

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:

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

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.

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.

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.

Limpar

Para evitar cobranças na sua conta Google Cloud pelos recursos usados neste tutorial:

Excluir o projeto

A maneira mais fácil de eliminar o faturamento é excluir o projeto criado 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.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
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

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.

Simular uma falha de zona em clusters regionais do GKE Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Objetivos

Custos

Antes de começar

Criar um cluster padrão regional

Implantar um aplicativo de microsserviços de amostra

Simular uma falha de zona

Reduzir zonas do pool de nós

Usar um pool de nós de zona única

Restringir e drenar nós em uma zona

Limpar

Excluir o projeto

A seguir

Simular uma falha de zona em clusters regionais do GKE