Este conjunto de tutoriales está dirigido a administradores de TI y operadores que quieran desplegar, ejecutar y gestionar entornos de aplicaciones modernas que se ejecuten en Google Kubernetes Engine (GKE). A lo largo de esta serie de tutoriales, aprenderás a configurar la monitorización y las alertas, a escalar cargas de trabajo y a simular errores. Todo ello con la aplicación de microservicios de ejemplo Cymbal Bank:
- Crear un clúster y desplegar una aplicación de ejemplo
- Monitorizar con Google Cloud Managed Service para Prometheus
- Escalar cargas de trabajo
- Simular un fallo (este tutorial)
- Centralizar la gestión de cambios
Descripción general y objetivos
Las aplicaciones deben poder tolerar las interrupciones y los fallos. De esta forma, los usuarios pueden seguir accediendo a tus aplicaciones aunque haya algún problema. La aplicación de ejemplo Cymbal Bank se ha diseñado para gestionar los errores y seguir ejecutándose sin que tengas que solucionar los problemas. Para ofrecer esta resiliencia, los clústeres regionales de GKE distribuyen los nodos de computación en las zonas y el controlador de Kubernetes responde automáticamente a los problemas de servicio del clúster.
En este tutorial, aprenderás a simular un fallo en Google Cloud y ver cómo responden los servicios de la aplicación en tu clúster de GKE. Aprenderás a completar las siguientes tareas:
- Revisa la distribución de los nodos y los servicios.
- Simula un fallo de nodo o de zona.
- Verifica que los servicios sigan ejecutándose en los nodos restantes.
Costes
Si habilitas GKE y despliegas la aplicación de ejemplo Cymbal Bank para esta serie de tutoriales, se te aplicarán cargos por clúster de GKE en Google Cloud , tal como se indica en nuestra página de precios, hasta que inhabilites GKE o elimines el proyecto.
También eres responsable de otros Google Cloud costes que se generen al ejecutar la aplicación de ejemplo de Cymbal Bank, como los cargos de las máquinas virtuales de Compute Engine.
Antes de empezar
Para aprender a simular un fallo, debes completar el primer tutorial para crear un clúster de GKE que use Autopilot y desplegar la aplicación de ejemplo basada en microservicios Cymbal Bank.
Te recomendamos que completes este conjunto de tutoriales para aplicaciones escalables en orden. A medida que avances en el conjunto de tutoriales, adquirirás nuevas habilidades y usarás más Google Cloud productos y servicios.
Revisar la distribución de nodos y servicios
En Google Cloud, una región es una ubicación geográfica concreta en la que puedes alojar tus recursos. Las regiones tienen tres o más zonas. Por ejemplo, la región us-central1 hace referencia a una región del Medio Oeste de Estados Unidos que tiene varias zonas, como us-central1-a, us-central1-b y us-central1-c. Las zonas tienen conexiones de red de gran ancho de banda y baja latencia con otras zonas de la misma región.
Para desplegar aplicaciones tolerantes a fallos que tengan una alta disponibilidad, Google recomienda que despliegues las aplicaciones en varias zonas y regiones. Este enfoque ayuda a protegerse frente a fallos inesperados de componentes, incluidas zonas o regiones.
Cuando creaste tu clúster de GKE en el primer tutorial, 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. Con este enfoque, la aplicación de ejemplo Cymbal Bank ya se ha desplegado en varias zonas, lo que ayuda a protegerla frente a fallos inesperados.
Comprueba 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 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.4Comprueba la distribución de los servicios de la aplicación de ejemplo Cymbal Bank en los nodos de tu clúster de GKE:
kubectl get pods -o wideEn el siguiente ejemplo de salida se muestra que los servicios se distribuyen entre los nodos del clúster. En el paso anterior, hemos comprobado cómo se distribuyen los nodos. En este resultado se muestra que los servicios 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
Simular una interrupción del servicio
Google diseña las zonas para minimizar el riesgo de que se produzcan fallos correlacionados causados por interrupciones en la infraestructura física, como la electricidad, la refrigeración o la red. Sin embargo, pueden surgir problemas inesperados. Si un nodo o una zona deja de estar disponible, quieres que los servicios sigan ejecutándose en otros nodos o zonas de la misma región.
El controlador de Kubernetes monitoriza el estado de los nodos, los servicios y las implementaciones de tu clúster. Si se produce una interrupción inesperada, el controlador reinicia los recursos afectados y el tráfico se dirige a los nodos que funcionan.
Para simular una interrupción en este tutorial, acordonarás y drenarás los nodos de una de tus zonas. Este enfoque simula lo que ocurre cuando falla un nodo o cuando hay un problema en toda una zona. El controlador de Kubernetes debería reconocer que algunos servicios ya no están disponibles y deben reiniciarse en nodos de otras zonas:
Cordonar y drenar los nodos de una de las zonas. En el siguiente ejemplo se orienta a los dos nodos de
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 ellos. Kubernetes reprograma los pods en otros nodos de las zonas que funcionan.
Comprobar la respuesta de error simulada
En un tutorial anterior de esta serie, aprendiste a configurar la instancia de Prometheus gestionada de tu clúster de GKE para monitorizar algunos de los servicios y generar alertas si hay algún problema. Si los pods se estaban ejecutando en nodos de la zona en la que has simulado un corte, recibirás mensajes de notificación de Slack de las alertas generadas por Prometheus. Este comportamiento muestra cómo puedes crear un entorno de aplicación moderno que monitorice el estado de tus implementaciones, te avise si hay algún problema y se ajuste automáticamente a los cambios de carga o a los fallos.
Tu clúster de GKE responde automáticamente a la interrupción simulada. Los servicios de los nodos afectados se reinician en los nodos restantes.
Vuelve a comprobar 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 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 servicios entre los nodos disponibles. Todos los servicios deberían seguir funcionando.
Comprueba la distribución de los servicios de la aplicación de ejemplo Cymbal Bank en los nodos de tu clúster de GKE:
kubectl get pods -o wideEn el siguiente ejemplo de salida se muestra que los servicios se distribuyen entre los nodos restantes del clúster. En el paso anterior, hemos comprobado cómo se distribuyen los nodos. En este resultado se 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-node1Consulta los
AGEde los Servicios. En el resultado del ejemplo anterior, algunos de los servicios tienen una antigüedad menor que otros en la aplicación de ejemplo Cymbal Bank. Estos servicios más recientes se ejecutaban anteriormente en uno de los nodos en los que simulaste un fallo. El controlador de Kubernetes reinició estos servicios en los nodos disponibles.
En una situación real, solucionarías el problema o esperarías a que se resolviera el problema de mantenimiento subyacente. Si has configurado Prometheus para que envíe mensajes de Slack en función de las alertas, verás estas notificaciones. También puedes repetir opcionalmente los pasos del tutorial anterior para escalar los recursos y ver cómo responde tu clúster de GKE con una carga mayor cuando solo hay dos zonas disponibles en la región. El clúster debería aumentar la escala con las dos zonas restantes disponibles.
Limpieza
Para evitar que se apliquen cargos en tu cuenta de Google Cloud por los recursos utilizados en este tutorial, elimina el proyecto que has creado.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Siguientes pasos
En el siguiente tutorial, aprenderás a centralizar la gestión de cambios con Config Sync.