Simular un fallo de zona en clústeres regionales de GKE

Estándar

---

Un requisito normativo habitual es que una empresa pueda demostrar su capacidad de recuperación ante desastres. En el caso de las aplicaciones que se ejecutan en la nube, este requisito incluye la fiabilidad y la disponibilidad de los servicios cuando los servidores alojados en una zona no están disponibles durante un periodo. Este documento está dirigido a administradores y arquitectos, operadores y administradores de copias de seguridad y recuperación ante desastres (DR) que quieran saber cómo simular una conmutación por error de zona al usar un clúster regional estándar de Google Kubernetes Engine (GKE).

Los clústeres regionales de GKE se crean en una región elegida por el usuario y ejecutan el plano de control en máquinas virtuales situadas en varias zonas de la región elegida. Los clústeres de Autopilot de GKE siempre son regionales, mientras que los clústeres Estándar de GKE pueden ser regionales o zonales. En este tutorial se usa un clúster regional estándar de GKE. Los nodos del clúster se comunican con el plano de control a través de un balanceador de carga, lo que significa que la ubicación del nodo y la de la VM del plano de control no siempre coinciden. En la consolaGoogle Cloud , no puedes inhabilitar una zona concreta cuando usas un clúster regional. Para obtener más información, consulta la arquitectura de clústeres de GKE.

En este tutorial se describen tres métodos diferentes para simular un fallo de zona. Puedes simular un error de zona y verificar la respuesta correcta de la aplicación mediante el método que necesites para cumplir los requisitos.

Los métodos de este documento también se aplican a los clústeres zonales, incluidos los de una sola zona y los multizonales. Estos métodos solo afectan a los nodos de las zonas de destino y no al plano de control de GKE.

Objetivos

• Crea un clúster estándar regional de GKE con la configuración predeterminada.
• Despliega una aplicación de microservicios de ejemplo en el clúster regional.
• Simula una interrupción de la zona con uno de estos tres métodos:
  • Reduce las zonas del grupo de nodos en un clúster regional.
  • Usa un grupo de nodos de una sola zona.
  • Cordon and drain the target failure-zone's nodes.
• Verifica la disponibilidad de los microservicios.

Costes

En este tutorial se usan los siguientes componentes facturables de Google Cloud:

• Compute Engine
• Clúster en modo estándar de GKE

Usa la calculadora de precios para generar una estimación de costes en función del uso previsto.

Antes de empezar

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.

Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

Para inicializar gcloud CLI, ejecuta el siguiente 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.

Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

Para inicializar gcloud CLI, ejecuta el siguiente 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

Crear un clúster estándar regional

Antes de simular un fallo de zona, crea un clúster regional con un grupo de nodos multizona. El plano de control y los nodos del clúster se replican en varias zonas de la región especificada.

Usa Google Cloud CLI para crear el clúster:

1. Crea un clúster estándar de GKE con la configuración predeterminada:

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

   Sustituye los siguientes parámetros:

   • CLUSTER_NAME: el nombre del clúster.
   • CONTROL_PLANE_LOCATION: la región de Compute Engine del plano de control de tu clúster, como us-central1.

   GKE tarda unos minutos en crear el clúster y verificar que todo funciona correctamente. Se crean dos nodos en cada zona de la región que especifiques.

2. Comprueba las zonas de cada nodo creado en el paso anterior:

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

   La salida tiene el siguiente aspecto:

   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. Conéctate al clúster:

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

Desplegar una aplicación de microservicios de ejemplo

Para ver el efecto de la conmutación por error simulada en este documento, implementa una aplicación de ejemplo basada en microservicios en tu clúster. En este documento, usarás la aplicación de ejemplo Cymbal Bank:

1. En tu shell, clona el siguiente repositorio de GitHub y cambia al directorio:

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

2. Despliega la aplicación de ejemplo Cymbal Bank en el clúster de GKE que has creado en la sección anterior:

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

3. Espera a que los pods estén listos:

   kubectl get pods
   

4. Al cabo de unos minutos, los pods deberían estar en 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. Cuando todos los pods estén en estado Running, obtén la dirección IP externa del servicio frontend:

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

6. En una ventana del navegador web, abre la dirección IP que se muestra en el resultado del comando kubectl get service para acceder a tu instancia de Cymbal Bank.

   Las credenciales predeterminadas se rellenan automáticamente, por lo que puedes iniciar sesión en la aplicación y consultar algunas de las transacciones y los saldos de ejemplo. No tienes que hacer nada más que confirmar que Cymbal Bank se ejecuta correctamente. Puede que los Servicios tarden un par de minutos en iniciarse correctamente y permitirte iniciar sesión. Espera hasta que todos los pods estén en estado Running y puedas iniciar sesión correctamente en el sitio de Cymbal Bank antes de pasar a la siguiente sección y simular un fallo de zona.

Simular un fallo de zona

En esta sección, simularás un fallo en una de las zonas. Hay tres formas diferentes de simular esta conmutación por error. Solo tienes que elegir un método. Simula un fallo de zona y verifica la respuesta correcta de la aplicación con el método que necesites para cumplir los requisitos.

Nota: Si tus aplicaciones contienen cargas de trabajo con estado, como bases de datos, asegúrate de que los datos se almacenen en un volumen de disco persistente independiente y de que las réplicas de lectura se implementen en varias zonas. Comprueba este almacenamiento de datos antes de eliminar un grupo de nodos (simula un fallo de zona) o considera la posibilidad de usar un disco persistente regional. Para disfrutar de una protección adicional, también puedes usar Backup for GKE. La coherencia y la fiabilidad de los datos de StatefulSets, así como la estrategia de mitigación, no se tratan en este documento. Si no tienes en cuenta estos factores de almacenamiento, corres el riesgo de perder datos. Consulta la documentación de tu base de datos o aplicación con estado específica, como PostgreSQL, SQL Server, MongoDB, Redis o Cassandra, para obtener información sobre las estrategias de alta disponibilidad y recuperación ante desastres recomendadas.

Reducir las zonas de un grupo de nodos

De forma predeterminada, un grupo de nodos de un clúster regional tiene nodos que abarcan todas las zonas de su región. En el siguiente diagrama, Cloud Load Balancing distribuye el tráfico a un grupo de nodos que abarca tres zonas. Cada zona tiene dos nodos y tus pods pueden ejecutarse en nodos de cualquiera de estas zonas.



En esta sección, simularás un fallo de zona actualizando el grupo de nodos para que solo se ejecute en dos de las tres zonas. Con este enfoque, se verifica que tu aplicación pueda responder a la pérdida de una zona redistribuyendo correctamente los pods y el tráfico entre otras zonas.

Para actualizar el grupo de nodos de forma que solo se ejecute en determinadas zonas y simular un fallo, sigue estos pasos:

1. Comprueba la disponibilidad de los clústeres y servicios regionales:

   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'
   

   El resultado es similar al siguiente ejemplo:

   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
   

   En este ejemplo, todas las cargas de trabajo de Cymbal Bank se implementan en todas las zonas. Para simular un fallo, inhabilita una de las zonas, como asia-southeast1-c, en la que se haya implementado el servicio frontend.

2. Simula una interrupción del servicio en una zona. Actualiza el grupo de nodos (default-pool) para que solo especifique dos de las tres zonas:

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

   Sustituye ZONE_A, ZONE_B por las dos zonas en las que quieras que siga ejecutándose el grupo de nodos.

3. Verifica la disponibilidad de los microservicios después de actualizar el grupo de nodos:

   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'
   

   La salida debería tener este aspecto:

   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
   

   En este ejemplo de salida, asia-southeast1-c ya no se usa. El servicio frontend al que accedes desde un navegador con la URL http://EXTERNAL_IP sigue estando disponible. Un usuario podrá seguir haciendo depósitos y pagos aunque una de las zonas ya no esté disponible.

Usar un grupo de nodos de una sola zona

En esta sección, simularás un fallo de zona eliminando dos de los grupos de nodos. Con este enfoque, se verifica que tu aplicación puede responder a la pérdida de un grupo de nodos redistribuyendo correctamente los pods y el tráfico en un grupo de nodos de otra zona. Para simular una interrupción de la zona en un clúster regional, amplía el clúster básico que has creado anteriormente ejecutando la aplicación Cymbal Bank en varios grupos de nodos. Este método de simulación de la interrupción de la zona refleja con mayor precisión un fallo real de la zona que el primer ejemplo de actualización de las zonas activas en un grupo de nodos, ya que es más habitual que haya varios grupos de nodos en un clúster:



El clúster que creará en esta sección para simular un fallo de un grupo de nodos de una sola zona incluye los siguientes componentes:

• Grupo de nodos predeterminado: se suele crear al crear un clúster estándar de GKE regional. Es un grupo de nodos multizona (default-pool).

  Este clúster con un solo default-pool es el que has creado anteriormente en este documento.

• Grupos de nodos adicionales (zonal-node-pool-1 y zonal-node-pool-2) que también ejecutan servicios para la aplicación de ejemplo Cymbal Bank.

Las líneas de puntos del diagrama muestran cómo el tráfico solo se sirve en zonal-node-pool-2 después de simular un fallo en default-pool y zonal-node-pool-1.

Para crear grupos de nodos adicionales y simular un fallo, sigue estos pasos:

1. Comprueba la disponibilidad del clúster 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'
   

   El resultado es similar al siguiente ejemplo:

   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
   

   En este ejemplo de salida, todos los pods de Cymbal Bank se implementan en todas las zonas del mismo clúster y se ejecutan en el default-pool.

2. Crea dos grupos de nodos de una sola zona:

   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
   

   Sustituye ZONE_A y ZONE_B por las dos zonas en las que quieras que se ejecuten los nuevos grupos de nodos de una sola zona.

3. Para simular un fallo de zona, elimina el grupo de nodos regional default-pool y uno de los nuevos grupos de nodos de una sola zona:

   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 el proceso de eliminación de node-pool, las cargas de trabajo se cierran y se reprograman en otro grupo de nodos disponible. Cuando se produce este proceso, los servicios y las implementaciones no están disponibles. Esto significa que deben especificarse periodos de inactividad para los informes o la documentación de recuperación ante desastres.

   Verifica que los microservicios sigan estando disponibles:

   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'
   

   La salida debería ser similar al siguiente ejemplo:

   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
   

   En este ejemplo, como default-pool y zonal-node-pool-1 ya no existen, todos los servicios se ejecutan en zonal-node-pool-2.

Poner en cuarentena y drenar nodos de una zona

En esta sección, acordonas y drenas nodos específicos de tu clúster. Aísla y drena todos los nodos de una sola zona, lo que simula la pérdida de los pods que se ejecutan en esos nodos de la zona:



En este diagrama, acordonas y purgas los nodos de la primera zona. Los nodos de las otras dos zonas siguen funcionando. Con este enfoque, se verifica que tu aplicación pueda responder a la pérdida de todos los nodos de una zona redistribuyendo correctamente los pods y el tráfico entre los nodos que se ejecutan en otras zonas.

Para acordonar y drenar los nodos de una de las zonas, simulando un fallo, sigue estos pasos:

1. Comprueba la disponibilidad del clúster regional y de los servicios. Consulta los nombres de los nodos de la zona de fallo de destino. Quieres especificar una zona en la que se ejecuten los pods de frontend:

   kubectl get pods -o wide
   

   La salida debería tener este aspecto:

   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. Asocia los pods que se muestran en el resultado anterior con la zona del nodo:

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

   La salida debería tener este aspecto:

   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
   

   En el resultado del ejemplo anterior, los pods de frontend se encuentran en regional-cluster-1-default-pool-node1 en la zona asia-southeast1-b.

   En el siguiente paso, traza todos los nodos de la zona asia-southeast1-b, que en este ejemplo son regional-cluster-1-default-pool-node1 y regional-cluster-1-default-pool-node2.

3. Aísla y vacía los nodos de destino de una de las zonas. En este ejemplo, se trata de los dos nodos de 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 los nodos como no programables y simula fallos de nodos. Kubernetes reprograma los pods en otros nodos de las zonas que funcionan.

4. Fíjate en dónde se han reprogramado los nuevos pods de frontend y otros pods de ejemplo de Cymbal Bank que se estaban ejecutando en el nodo de la zona de fallo:

   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'
   

   La salida debería tener este aspecto:

   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
   

   En este ejemplo de salida, no hay pods de ejemplo de Cymbal Bank que se ejecuten en nodos acordonados y todos los pods ahora solo se ejecutan en las otras dos zonas.

   Los presupuestos de interrupciones de pods (PDBs) de los nodos pueden bloquear el drenaje de nodos. Evalúa las políticas de PDB antes de realizar la acción de acordonamiento y drenaje. Para obtener más información sobre los PDBs y su relación con la gestión de interrupciones, consulta cómo asegurar la fiabilidad y el tiempo de actividad de tu clúster de GKE.

   Nota: Después de simular el fallo, puedes usar kubectl uncordon para permitir que los pods se vuelvan a programar en los nodos.

Limpieza

Para evitar que se apliquen cargos en tu cuenta de Google Cloud por los recursos utilizados en este tutorial, sigue estas instrucciones:

Eliminar el proyecto

La forma más fácil de evitar que te cobren es eliminar el proyecto que has creado para el tutorial.

Precaución: Eliminar un proyecto tiene los siguientes efectos:

• Se elimina todo el contenido del proyecto. Si has usado un proyecto que ya existía para las tareas de este documento, cuando lo elimines, también se eliminará cualquier otro trabajo que hayas realizado en él.
• Se pierden los IDs de proyecto personalizados. Cuando creaste este proyecto, es posible que hayas creado un ID de proyecto personalizado que quieras usar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, elimina los recursos seleccionados dentro del proyecto en lugar de eliminar todo el proyecto.

Si tienes previsto consultar varias arquitecturas, tutoriales o guías de inicio rápido, reutilizar los proyectos puede ayudarte a no superar los límites de cuota de proyectos.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Siguientes pasos

• Consulta cómo simular una interrupción de una zona en un grupo de instancias gestionado (MIG) regional.
• Consulta información sobre la recuperación tras fallos Google Cloud.
• Configura PostgreSQL de alta disponibilidad en varias zonas.
• Consideraciones sobre la cobertura para interrupciones de pods.
• Consulta las diferencias entre los discos persistentes zonales y regionales.
• Consulta cómo ejecutar bases de datos de alta disponibilidad en GKE.
• Consulta más información sobre las prácticas recomendadas de recuperación tras desastres en Google Cloud.
• Consulta información sobre Copia de seguridad de GKE.