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 la edición Enterprise de 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 un error (este instructivo)
Descripción general y objetivos
Las aplicaciones deben poder tolerar interrupciones y fallas. Esta capacidad permite que los usuarios sigan accediendo a tus aplicaciones incluso cuando haya 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 zonas, y el controlador de Kubernetes responde de forma automática 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 servicios de la aplicación en el clúster de Google Kubernetes Engine (GKE) Enterprise. Aprenderás a completar las siguientes tareas:
- Revisa la distribución de nodos y objetos Service.
- Simula un error de nodo o zona.
- Verifica que los objetos Service continúen ejecutándose en los nodos restantes.
Costos
Habilitar GKE Enterprise e implementar la aplicación de ejemplo Cymbal Bank para esta serie de instructivos significa que se generan cargos por clúster para GKE Enterprise en Google Cloud, como se indica en nuestra página de precios hasta que inhabilites GKE Enterprise 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 e implementar la aplicación basada en microservicios de muestra de Cymbal Bank.
Te recomendamos que completes este conjunto de instructivos para Cymbal Bank 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 objetos Service
En Google Cloud, una región es una ubicación geográfica específica donde puedes alojar 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 que implementes las aplicaciones en varias zonas y regiones. Este enfoque ayuda a proteger las aplicaciones contra las fallas inesperadas de los componentes en una zona o región.
Cuando creaste el clúster de GKE Enterprise en el primer instructivo, se usaron algunos valores de configuración predeterminados. De forma predeterminada, un clúster de GKE Enterprise que usa Autopilot crea y ejecuta nodos que abarcan las zonas de la región que especificas. 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 los nodos en el clúster de GKE Enterprise:
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 se distribuyen 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 servicios de la aplicación de ejemplo de Cymbal Bank en los nodos del clúster de GKE Enterprise:
kubectl get pods -o wideEn el siguiente resultado de ejemplo, se muestra que los Service se distribuyen entre los nodos del clúster. En el paso anterior para verificar cómo se distribuyen los nodos, en este resultado se muestra que los Services se ejecutan en 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 deja de estar disponible, deseas que los servicios continúen ejecutándose en otros nodos o en zonas de la misma región.
El controlador de Kubernetes supervisa el estado de los nodos, los objetos Service y las implementaciones en tu clúster. Si se produce una interrupción inesperada, el controlador reinicia los recursos afectados y el tráfico se enruta a los nodos en funcionamiento.
Para simular una interrupción en este instructivo, debes acordonar y desviar los nodos en una de tus zonas. En este enfoque, se simula lo que sucede cuando falla un nodo o cuando una zona completa tiene un problema. El controlador de Kubernetes debe reconocer que algunos objetos Service ya no están disponibles y debe reiniciarse en nodos en otras zonas:
Acordona y desvía los nodos en una de las zonas. El siguiente ejemplo se orienta a 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 Enterprise para supervisar algunos de los Services y generar alertas si hay algún problema. Si los Pods se ejecutaban en nodos de 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 alerta si hay un problema y puede ajustarse de forma automática para cambios o fallas en la carga.
Tu clúster de GKE Enterprise responde de forma automática a la interrupción simulada. Cualquier servicio en los nodos afectados se reinicia en los nodos restantes.
Vuelve a verificar la distribución de nodos en el clúster de GKE Enterprise:
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 se distribuyen solo 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 Service entre los nodos disponibles. Todos los servicios deberían seguir ejecutándose.
Verifica la distribución de los servicios de la aplicación de ejemplo de Cymbal Bank en los nodos del clúster de GKE Enterprise:
kubectl get pods -o wideEn el siguiente resultado de ejemplo, se muestra que los objetos Service se distribuyen en los nodos restantes del clúster. En el paso anterior para verificar cómo se distribuyen los nodos, en este resultado se muestra que los Services 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 Service más recientes antes se ejecutaban en uno de los nodos en los que simulaste una falla. El controlador de Kubernetes reinició estos servicios 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 estas notificaciones. De manera opcional, puedes repetir los pasos del instructivo anterior para escalar recursos para ver cómo responde tu clúster de GKE Enterprise con una carga mayor cuando solo hay dos zonas disponibles. con la región. El clúster debe escalar verticalmente con las dos zonas restantes disponibles.
Limpia
Para evitar que se generen cargos en 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 Enterprise similar al que aprendiste en este conjunto de instructivos, revisa algunas de las consideraciones de producción.