Este conjunto de instructivos es para administradores y operadores de TI que deseen implementar, ejecutar y administrar entornos de aplicaciones modernos que se ejecutan en Google Kubernetes Engine (GKE). A medida que avanzas con este conjunto de instructivos, aprenderás a configurar la supervisión y las alertas, escalar cargas de trabajo y simular fallas, todo con la aplicación de microservicios de muestra de Cymbal Bank:
- Crea un clúster y, luego, implementa una app de ejemplo
- Supervisa con Google Cloud Managed Service para Prometheus
- Escala las cargas de trabajo
- Simula una falla (este instructivo)
Descripción general y objetivos
Las aplicaciones deben poder tolerar interrupciones y fallas. Esta función permite que los usuarios sigan accediendo a tus aplicaciones incluso cuando hay un problema. La aplicación de ejemplo Cymbal Bank está diseñada para manejar fallas y continuar ejecutándose, sin la necesidad de solucionar problemas. Para proporcionar esta resiliencia, los clústeres regionales de GKE distribuyen los nodos de procesamiento entre las zonas, y el controlador de Kubernetes responde automáticamente a los problemas del servicio dentro del clúster.
En este instructivo, aprenderás a simular una falla en Google Cloud y a ver cómo responden los Services de la aplicación en el clúster de GKE. Aprenderás a completar las siguientes tareas:
- Revisa la distribución de nodos y Services.
- Simula una falla de nodo o zona.
- Verifica que los Services sigan ejecutándose en los nodos restantes.
Costos
Habilitar GKE e implementar la aplicación de ejemplo Cymbal Bank para esta serie de instructivos significa que se generan cargos por clúster para GKE en Google Cloud, como se indica en nuestra página de precios hasta que inhabilites GKE o borres el proyecto.
También eres responsable de otros costos de Google Cloud generados mientras ejecutas la aplicación de ejemplo de Cymbal Bank, como los cargos por las VMs de Compute Engine.
Antes de comenzar
Si quieres aprender a simular una falla, debes completar el primer instructivo para crear un clúster de GKE que use Autopilot y, luego, implementar la aplicación basada en microservicios de muestra de Cymbal Bank.
Te recomendamos que completes este conjunto de instructivos para aplicaciones escalables en orden. A medida que avanzas en el conjunto de instructivos, adquieres habilidades nuevas y usas productos y servicios adicionales de Google Cloud.
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.
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.4Verifica 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 wideEn 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-daemonsetsEste 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.
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.4El 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 wideEn 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-node1Observa el
AGEde 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.
Realiza una limpieza
Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos que usaste en este instructivo, borra el proyecto que creaste.
- En la consola de Google Cloud, ve a la página Administrar recursos.
- En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
- En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.
¿Qué sigue?
Antes de comenzar a crear tu propio entorno de clúster de GKE similar al que aprendiste en este conjunto de instructivos, revisa algunas de las consideraciones de producción.