Ruta de aprendizaje: Aplicaciones escalables - Simula una falla

Revisa la distribución de nodos y Services

En Google Cloud, una región es una ubicación geográfica específica en la que puedes alojar tus recursos. Las regiones tienen tres o más zonas. Por ejemplo, la región us-central1 corresponde a una región en la región medio oeste de Estados Unidos que tiene varias zonas, como us-central1-a,us-central1-b y us-central1-c. Las zonas se comunican con otras zonas de la misma región mediante conexiones de red con un amplio ancho de banda y latencia baja.

Para implementar aplicaciones tolerantes a errores que tengan alta disponibilidad, Google recomienda implementar las aplicaciones en varias zonas y regiones. Este enfoque ayuda a proteger las aplicaciones contra las fallas inesperadas de los componentes en una sola zona o región.

Cuando creaste el clúster de GKE en el primer instructivo, se usaron algunos valores de configuración predeterminados. De forma predeterminada, un clúster de GKE que usa Autopilot crea y ejecuta nodos que abarcan las zonas de la región que especifiques. Este enfoque significa que la aplicación de ejemplo de Cymbal Bank ya está implementada en varias zonas, lo que ayuda a proteger contra fallas inesperadas.

1. Verifica la distribución de nodos en tu clúster de GKE:

   kubectl get nodes -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, que muestra que los nodos están distribuidos en las tres zonas de la región:

   NAME                         ZONE            INT_IP
   scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
   scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
   scalable-apps-pool-2-node2   us-central1-a   10.148.0.8
   scalable-apps-pool-2-node1   us-central1-a   10.148.0.9
   scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
   scalable-apps-pool-2-node4   us-central1-b   10.148.0.4
   

2. Verifica la distribución de los Services de la aplicación de ejemplo de Cymbal Bank en los nodos del clúster de GKE:

   kubectl get pods -o wide
   

   En el siguiente resultado de ejemplo, se muestra que los Services se distribuyen entre los nodos del clúster. En el paso anterior, para verificar cómo se distribuyen los nodos, este resultado muestra que los Services se ejecutan en todas las zonas de la región:

   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          6m30s   10.28.1.5   scalable-apps-pool-2-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          6m30s   10.28.5.6   scalable-apps-pool-2-node1
   contacts-7ddc76d94-qv4x5              1/1     Running   0          6m29s   10.28.4.6   scalable-apps-pool-2-node2
   frontend-747b84bff4-xvjxq             1/1     Running   0          6m29s   10.28.3.6   scalable-apps-pool-2-node6
   ledger-db-0                           1/1     Running   0          6m29s   10.28.5.7   scalable-apps-pool-2-node1
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          6m29s   10.28.1.6   scalable-apps-pool-2-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          6m29s   10.28.4.7   scalable-apps-pool-2-node2
   transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          6m29s   10.28.3.7   scalable-apps-pool-2-node6
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          6m28s   10.28.5.8   scalable-apps-pool-2-node1
   

Simula una interrupción

Google diseña zonas para minimizar el riesgo de errores correlacionados causados por las interrupciones de la infraestructura física, como la energía, el enfriamiento o las herramientas de redes. Sin embargo, pueden ocurrir problemas inesperados. Si un nodo o una zona dejan de estar disponibles, querrás que los Services sigan ejecutándose en otros nodos o en zonas de la misma región.

El controlador de Kubernetes supervisa el estado de los nodos, los Services y los Deployments de tu clúster. Si hay una interrupción inesperada, el controlador reinicia los recursos afectados y el tráfico se enruta a los nodos trabajadores.

Para simular una interrupción en este instructivo, acordonarás y desviarás nodos en una de tus zonas. Este enfoque simula lo que sucede cuando falla un nodo o cuando una zona completa tiene un problema. El controlador de Kubernetes debe reconocer que algunos Services ya no están disponibles y deben reiniciarse en nodos de otras zonas:

• Acordona y desvía los nodos en una de las zonas. En el siguiente ejemplo, se segmentan los dos nodos en us-central1-a:

  kubectl drain scalable-apps-pool-2-node1 \
      --delete-emptydir-data --ignore-daemonsets
  
  kubectl drain scalable-apps-pool-2-node2 \
      --delete-emptydir-data --ignore-daemonsets
  

  Este comando marca los nodos como no programables para que los Pods ya no puedan ejecutarse en estos nodos. Kubernetes reprograma los Pods en otros nodos en zonas de funcionamiento.

Verifica la respuesta de falla simulada

En un instructivo anterior de esta serie, aprendiste a configurar la instancia administrada de Prometheus para tu clúster de GKE para supervisar algunos de los Services y generar alertas si hay algún problema. Si los Pods se ejecutaban en nodos en la zona en la que simulaste una interrupción, recibirás mensajes de notificación de Slack de las alertas que generó Prometheus. Este comportamiento muestra cómo puedes compilar un entorno de aplicación moderno que supervise el estado de tus implementaciones, te alerte si hay un problema y pueda ajustarse automáticamente a los cambios o fallas de carga.

Tu clúster de GKE responde automáticamente a la interrupción simulada. Todos los Services de los nodos afectados se reinician en los nodos restantes.

1. Vuelve a verificar la distribución de los nodos en tu clúster de GKE:

   kubectl get nodes -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, que muestra que los nodos ahora solo se distribuyen en dos de las zonas de la región:

   NAME                         ZONE            INT_IP
   scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
   scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
   scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
   scalable-apps-pool-2-node4   us-central1-b   10.148.0.4
   

2. El controlador de Kubernetes reconoce que dos de los nodos ya no están disponibles y redistribuye los Services entre los nodos disponibles. Todos los Services deberían seguir ejecutándose.

   Verifica la distribución de los Services de la aplicación de ejemplo de Cymbal Bank en los nodos del clúster de GKE:

   kubectl get pods -o wide
   

   En el siguiente resultado de ejemplo, se muestra que los Services se distribuyen entre los nodos restantes del clúster. Desde el paso anterior para verificar cómo se distribuyen los nodos, este resultado muestra que los servicios ahora solo se ejecutan en dos zonas de la región:

   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          28m     10.28.1.5   scalable-apps-pool-2-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          9m21s   10.28.5.6   scalable-apps-pool-2-node5
   contacts-7ddc76d94-qv4x5              1/1     Running   0          9m20s   10.28.4.6   scalable-apps-pool-2-node4
   frontend-747b84bff4-xvjxq             1/1     Running   0          28m     10.28.3.6   scalable-apps-pool-2-node6
   ledger-db-0                           1/1     Running   0          9m24s   10.28.5.7   scalable-apps-pool-2-node3
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   scalable-apps-pool-2-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          9m21s   10.28.4.7   scalable-apps-pool-2-node5
   transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          28m     10.28.3.7   scalable-apps-pool-2-node6
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          9m20s   10.28.5.8   scalable-apps-pool-2-node1
   

3. Observa el AGE de los Services. En el resultado del ejemplo anterior, algunos de los Services tienen una edad menor que otros en la aplicación de ejemplo de Cymbal Bank. Estos Services más recientes se ejecutaron anteriormente en uno de los nodos en los que simulaste la falla. El controlador de Kubernetes reinició estos Services en los nodos disponibles.

En una situación real, deberías solucionar el problema o esperar a que se resuelva el problema de mantenimiento subyacente. Si configuraste Prometheus para que envíe mensajes de Slack basados en alertas, verás que estas notificaciones llegan. De manera opcional, puedes repetir los pasos del instructivo anterior para escalar recursos para ver cómo responde tu clúster de GKE con una carga mayor cuando solo hay dos zonas disponibles. con la región. El clúster debería escalarse con las dos zonas restantes disponibles.