Simula una falla de zona en clústeres regionales de GKE

Estándar

---

Un requisito normativo común es que una empresa pueda demostrar su capacidad de recuperación ante desastres (DR). Para las aplicaciones que se ejecutan en la nube, este requisito incluye la confiabilidad y la disponibilidad de los servicios cuando los servidores alojados en una zona dejan de estar disponibles durante un período. Este documento está dirigido a los administradores y arquitectos, operadores y administradores de copias de seguridad y recuperación ante desastres (DR) que deseen aprender a simular una conmutación por error de zona cuando se usa un clúster regional Standard de Google Kubernetes Engine (GKE).

Los clústeres regionales de GKE se crean en la región elegida por el usuario y ejecutan el plano de control en las VMs ubicadas en varias zonas dentro de la región elegida. Los clústeres de GKE Autopilot siempre son regionales y los clústeres de GKE Standard pueden ser regionales o zonales. En este instructivo, se usa un clúster regional de GKE Standard. Los nodos del clúster se comunican con el plano de control a través de un balanceador de cargas, lo que significa que la ubicación del nodo y la ubicación de la VM del plano de control no siempre coinciden. En la consola de Google Cloud, no puedes inhabilitar una zona en particular cuando usas un clúster regional. Para obtener más información, consulta Arquitectura del clúster de GKE.

En este instructivo, se proporcionan tres métodos diferentes para simular una falla de zona. Puedes simular una falla de zona y verificar la respuesta correcta de la aplicación con el método necesario para tus propios fines de cumplimiento.

Los métodos de este documento también se aplican a los clústeres zonales, incluidos los de una zona o de varias zonas. Estos métodos solo afectan a los nodos en las zonas de destino y el plano de control de GKE no se ve afectado.

Objetivos

• Crear un clúster de GKE Standard regional a través de la configuración predeterminada.
• Implementar una aplicación de microservicios de muestra en el clúster regional.
• Simular una interrupción de zona a través de uno de los siguientes tres métodos:
  • Reducir las zonas del grupo de nodos en un clúster regional.
  • Usar un grupo de nodos de zona única.
  • Acordonar y desviar los nodos de la zona con fallas de destino.
• Verificar la disponibilidad de los microservicios.

Costos

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

• Compute Engine
• Clúster del modo GKE Standard

Usa la calculadora de precios para generar una estimación de los costos según el uso previsto.

Antes de comenzar

1. Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
2. Instala Google Cloud CLI.

3. Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

   gcloud init

4. Crea o selecciona un proyecto de Google Cloud.

   Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

   • Crea un proyecto de Google Cloud:

     gcloud projects create PROJECT_ID

     Reemplaza PROJECT_ID por un nombre para el proyecto de Google Cloud que estás creando.

   • Selecciona el proyecto de Google Cloud que creaste:

     gcloud config set project PROJECT_ID

     Reemplaza PROJECT_ID por el nombre del proyecto de Google Cloud.

5. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

6. Habilita las APIs de Kubernetes Engine API, Compute Engine:

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

7. Instala Google Cloud CLI.

8. Para inicializar la CLI de gcloud, ejecuta el siguiente comando:

   gcloud init

9. Crea o selecciona un proyecto de Google Cloud.

   Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

   • Crea un proyecto de Google Cloud:

     gcloud projects create PROJECT_ID

     Reemplaza PROJECT_ID por un nombre para el proyecto de Google Cloud que estás creando.

   • Selecciona el proyecto de Google Cloud que creaste:

     gcloud config set project PROJECT_ID

     Reemplaza PROJECT_ID por el nombre del proyecto de Google Cloud.

10. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

11. Habilita las APIs de Kubernetes Engine API, Compute Engine:

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

Crea un clúster de Standard regional

Antes de simular una falla de zona, crea un clúster regional con un grupo de nodos multizonal. 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 de GKE Standard nuevo a través de la configuración predeterminada:

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

   Reemplaza los siguientes parámetros:

   • CLUSTER_NAME: el nombre de tu clúster.
   • REGION: la región para tu clúster, como us-central1.

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

2. Verifica las zonas de cada nodo creadas 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'
   

   El resultado se ve como en el siguiente ejemplo:

   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 \
       --region REGION
   

Implementa una aplicación de microservicios de muestra

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

1. En tu shell, clona el repositorio de GitHub y cámbialo al directorio:

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

2. Implementa la aplicación de muestra de Cymbal Bank en el clúster de GKE que creaste 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. Después de unos minutos, deberías ver los Pods en el 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 de 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 propagan automáticamente, de modo que puedas acceder a la app y explorar algunas de las transacciones y los saldos de muestra. No hay que realizar ninguna acción específica, excepto para confirmar que Cymbal Bank se ejecuta de forma correcta. Es posible que todos los objetos Service demoren uno o dos minutos en iniciarse de forma correcta y permitirte acceder. Espera hasta que todos los Pods estén en estado Running y puedas acceder de forma correcta al sitio de Cymbal Bank antes de pasar a la siguiente sección y simular una falla de zona.

Simula una falla de zona

En esta sección, debes simular una falla con una de las zonas. Existen tres formas diferentes de simular esta conmutación por error. Solo debes elegir un método. Simula una falla de zona y verifica la respuesta correcta de la aplicación a través del método que se requiera para tus propios fines de cumplimiento.

Nota: Si las aplicaciones contienen cargas de trabajo con estado, como las bases de datos, asegúrate de que los datos estén almacenados en un volumen de Persistent Disk desconectado y las réplicas de lectura se implementen en varias zonas. Verifica este almacenamiento de datos antes de borrar un grupo de nodos (simula una falla de zona) o considera usar Persistent Disk regional. Para obtener protección adicional, también puedes usar Copia de seguridad para GKE. La estrategia de mitigación, confiabilidad y coherencia de datos de StatefulSets no se incluye en este documento. Si no tienes en cuenta estos factores de almacenamiento, existe el riesgo de una posible pérdida de datos. Consulta la documentación de la base de datos específica o la aplicación con estado, como PostgreSQL, SQL Server, MongoDB, Redis o Cassandra para obtener información acerca de las estrategias recomendadas de alta disponibilidad y recuperación ante desastres.

Reduce las zonas del 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 los Pods pueden ejecutarse en nodos en cualquiera de estas zonas.

En esta sección, debes simular una falla de zona a través de la actualización del grupo de nodos para que solo se ejecute en dos de cada tres zonas. En este enfoque, se verifica que tu aplicación pueda responder a la pérdida de una zona a través de la distribución correcta de los Pods y el tráfico en otras zonas.

Para actualizar el grupo de nodos para que solo se ejecute en ciertas zonas y simule fallas, completa los siguientes pasos:

1. Verifica la disponibilidad del clúster regional y los objetos Service:

   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 resultado de 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 una falla, inhabilita una de las zonas, como asia-southeast1-c, en la que se implementa el servicio de frontend.

2. Simula una interrupción de zona. Actualiza el grupo de nodos existente (default-pool) para especificar solo dos zonas de las tres zonas:

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

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

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'
   

   El resultado debería verse como el siguiente ejemplo:

   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 resultado de ejemplo, asia-southeast1-c ya no está en uso. Aún se puede acceder al servicio de frontend al que accedes desde un navegador con la URL http://EXTERNAL_IP. Un usuario aún podría realizar acciones de depósito y pago, aunque una de las zonas ya no esté disponible.

Usa un grupo de nodos de zona única

En esta sección, debes simular una falla de zona a través de la eliminación de dos de los grupos de nodos. En este enfoque, se verifica que tu aplicación pueda responder a la pérdida de un grupo de nodos a través de la distribución correcta de los Pods y el tráfico en un grupo de nodos en otra zona. Para simular una interrupción zonal en un clúster regional, expande el clúster básico creado anteriormente con la ejecución de la aplicación de Cymbal Bank en varios grupos de nodos. Este método de simulación de la interrupción zonal refleja mejor una falla de zona real que el primer ejemplo de actualización de zonas activas en un grupo de nodos, ya que es más común que existan varios grupos de nodos en un clúster:

El clúster que compilas en esta sección para simular una falla del grupo de nodos de zona única incluye los siguientes componentes:

• Grupo de nodos predeterminado, por lo general, se crea cuando creas un clúster de GKE Standard regional, que es un grupo de nodos de varias zonas (default-pool).

  Este clúster con el default-pool único es el que creaste antes 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 de Cymbal Bank.

En las líneas de puntos del diagrama, se muestra cómo el tráfico solo entrega zonal-node-pool-2 después de simular una falla en default-pool y zonal-node-pool-1.

Para crear grupos de nodos adicionales y simular fallas, completa los siguientes pasos:

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

   El resultado es similar al siguiente resultado de 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 resultado de ejemplo, todos los Pods de Cymbal Bank se implementan en todas las zonas del mismo clúster y se ejecutan en el default-pool existente.

2. Crea dos grupos de nodos nuevos 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
   

   Reemplaza ZONE_A y ZONE_B por las dos zonas en las que deseas que se ejecuten los grupos de nodos nuevos de zona única.

3. Para simular una falla de zona, borra el grupo de nodos regional default-pool y uno de los grupos de nodos nuevos 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 el proceso de eliminación de node-pool, las cargas de trabajo se cierran y se vuelven a programar en otro grupo de nodos disponible. Cuando ocurre este proceso, los objetos Service y Deployment no están disponibles. Este comportamiento significa que los períodos de tiempo de inactividad deben especificarse para la documentación o los informes de DR.

   Verifica la disponibilidad continua de los microservicios:

   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 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 resultado de ejemplo, como default-pool y zonal-node-pool-1 ya no existen, todos los objetos Service se ejecutan en zonal-node-pool-2.

Acordona y desvía nodos en una zona

En esta sección, acordonarás y desviarás nodos específicos del clúster. Acordona y desvía todos los nodos en una sola zona, lo que simula la pérdida de los Pods que se ejecutan en esos nodos en toda la zona:

En este diagrama, acordonas y desvías los nodos de la primera zona. Los nodos de las otras dos zonas continúan ejecutándose. Este enfoque verifica que tu aplicación pueda responder a la pérdida de todos los nodos en una zona a través de la distribución correcta de los Pods y el tráfico en los nodos que se ejecutan en otras zonas.

Para acordonar y desviar los nodos en una de las zonas, simulando fallas, completa los siguientes pasos:

1. Comprueba la disponibilidad del clúster regional y los objetos Service. Observa los nombres de los nodos de la zona de falla de destino. Deseas especificar una zona en la que se ejecutan los Pods de frontend:

   kubectl get pods -o wide
   

   El resultado debería verse como el siguiente ejemplo:

   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 enumerados 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'
   

   El resultado debería verse como el siguiente ejemplo:

   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, rastrearás todos los nodos en la zona asia-southeast1-b, que en este resultado de ejemplo son regional-cluster-1-default-pool-node1 y regional-cluster-1-default-pool-node2.

3. Acordona y desvía los nodos de destino en una de las zonas. En este ejemplo, esos son los dos nodos en 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 fallas en los nodos. Kubernetes reprograma los Pods en otros nodos en zonas de funcionamiento.

4. Observa dónde se reprogramaron los nuevos Pods de frontend y otros Pods de Cymbal Bank que antes se ejecutaban en el nodo en la zona con fallas:

   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 debería verse como el siguiente ejemplo:

   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 resultado de ejemplo, no hay Pods de Cymbal Bank que se ejecuten en nodos acordonados y todos los Pods solo se ejecutan en las otras dos zonas.

   Los presupuestos de interrupción de Pods (PDB) en los nodos pueden bloquear el desvío de nodos. Evalúa las políticas de PDB antes de la acción de acordonar y desviar. Para obtener más información acerca de PDB y su relación con la administración de interrupciones, consulta cómo garantizar la confiabilidad y el tiempo de actividad de tu clúster de GKE.

   Nota: Después de simular la falla, puedes usar kubectl uncordon para permitir que se vuelvan a programar Pods en los nodos.

Limpia

Para evitar que se generen costos en tu cuenta de Google Cloud por los recursos que se usaron en este instructivo, sigue estos pasos.

Borra el proyecto

La manera más fácil de eliminar la facturación es borrar el proyecto que creaste para el instructivo.

Precaución: Borrar un proyecto tiene estas consecuencias:

• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

1. En la consola de Google Cloud, ve a la página Administrar recursos.

   Ir a Administrar recursos

2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?

• Obtén información acerca de cómo simular una interrupción de zona para un grupo de instancias administrado (MIG) regional.
• Obtén más información acerca de la recuperación ante desastres en Google Cloud.
• Configura PostgreSQL de alta disponibilidad en varias zonas.
• Consideraciones sobre el presupuesto de interrupción de Pods.
• Obtén información acerca de los discos persistentes zonales frente a regionales.
• Obtén información acerca de cómo ejecutar bases de datos de alta disponibilidad en GKE.
• Obtén más información acerca de las prácticas recomendadas de recuperación ante desastres en Google Cloud.
• Obtén más información acerca de la Copia de seguridad para GKE.