Tutorial: Implementación de una aplicación de ejemplo y prueba de su resistencia de zona con Chaos Studio

En este tutorial, implementará una aplicación comercial de ejemplo en un clúster de Azure Kubernetes Service (AKS) con redundancia de zona y, a continuación, usará un área de trabajo de Azure Chaos Studio para simular un error de zona de disponibilidad dos veces. La primera ejecución pone de manifiesto una brecha real de resiliencia: el front end de la aplicación está fijado deliberadamente a una única zona, por lo que la tienda online queda fuera de servicio cuando esa zona falla. Después, corriges el despliegue, vuelves a ejecutar el mismo escenario y compruebas cómo la aplicación supera el fallo. Durante el proceso, inicias un monitor basado en navegador que muestra el fallo y la corrección a medida que ocurren, y aprendes por qué la disponibilidad de la tienda y el estado del nodo del clúster no cambian al mismo tiempo.

Este tutorial es una buena primera demostración y reutiliza la aplicación de ejemplo AKS store demo de las guías de inicio rápido de AKS, por lo que no se necesita ningún registro de contenedores ni ningún paso de compilación. Planear aproximadamente una hora: creación de clústeres más dos ejecuciones de escenarios de aproximadamente 5 minutos cada una.

En este tutorial, obtendrá información sobre cómo:

Este tutorial está orientado a una demostración funcional. Para conocer los conceptos que hay detrás de cada paso, las advertencias de interrumpir la infraestructura que AKS administra automáticamente y cómo interpretar los resultados en una carga de trabajo real, consulte Probar la resistencia de la carga de trabajo en AKS con Chaos Studio.

Prerequisites

• Una suscripción a Azure. Si no tiene una cuenta de Azure, cree una cuenta gratuita antes de comenzar.
• CLI de Azure, kubectl, kubeloginy Python 3 (solo biblioteca estándar: no hay paquetes que instalar). Azure Cloud Shell tiene los cuatro preinstalados. Si trabaja localmente, instale kubectl con az aks install-cli y kubelogin por separado.
• El proveedor de recursos Microsoft.Chaos está registrado en su suscripción. Para registrarlo por primera vez, consulte Registro del proveedor de recursos Chaos Studio.

Crear un clúster de AKS con redundancia de zona

Una prueba de fallo de zona solo tiene sentido en un clúster diseñado para soportar uno, así que cree un clúster con tres nodos repartidos en tres zonas de disponibilidad. En este ejemplo se usa East US 2; cualquier región con zonas de disponibilidad servirá.

1. Cree un grupo de recursos y el clúster:

   az group create --name chaos-demo-rg --location eastus2
   
   az aks create \
     --resource-group chaos-demo-rg \
     --name chaos-demo-aks \
     --node-count 3 \
     --zones 1 2 3 \
     --generate-ssh-keys
   

   La creación del clúster tarda unos minutos.

2. En una sesión de Cloud Shell nueva, kubectl todavía no está conectado a ningún clúster. Configure su suscripción, obtenga las credenciales y convierta el archivo kubeconfig para la autenticación de Microsoft Entra antes de ejecutar cualquier comando kubectl:

   az account set --subscription <SUBSCRIPTION_ID>
   az aks get-credentials --resource-group chaos-demo-rg --name chaos-demo-aks
   kubelogin convert-kubeconfig -l azurecli
   

   Sustituya el identificador de suscripción por <SUBSCRIPTION_ID>. Omita az account set si la suscripción ya es la activa. El kubelogin paso es necesario incluso en una sesión de Cloud Shell nueva, sin él, el primer kubectl comando en un clúster autenticado por Entra produce un error de autenticación.

3. Compruebe que los nodos abarcan tres zonas:

   kubectl get nodes -L topology.kubernetes.io/zone
   

   La ZONE columna muestra un nodo en cada zona, como eastus2-1, eastus2-2y eastus2-3. El número de zona que aparece después del nombre de la región es el que usarás más adelante en la configuración del escenario.

Implementación de la aplicación de ejemplo

La demo de tienda de AKS es una pequeña tienda minorista con una interfaz web, un servicio de productos, un servicio de pedidos y una cola de RabbitMQ. Sus imágenes de contenedor son públicas, por lo que puede implementarla con un solo comando.

1. Implemente la aplicación:

   kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/2.2.0/aks-store-quickstart.yaml
   

   El manifiesto despliega todos los componentes con una única réplica. El clúster tiene redundancia de zona, pero la aplicación no lo es. En este tutorial se expone y, a continuación, se corrige esta brecha de resistencia.

2. Espere a que el front-end obtenga una dirección IP pública:

   kubectl get service store-front --watch
   

   Cuando el EXTERNAL-IP valor cambie de <pending> a una dirección IP pública, presione Ctrl+C para detener el reloj.

3. Abra http://<EXTERNAL-IP> en un explorador y confirme que se carga la tienda. Mantenga esta pestaña abierta. Es una vista secundaria del estado de la aplicación durante la prueba; el monitor que se inicia después es el principal.

Para obtener información sobre cómo se compila e implementa la propia aplicación, consulte la serie de tutoriales de AKS.

Fijar el frontend a una sola zona para una demostración determinista

Sin una fijación deliberada, el planificador puede colocar la única réplica del front end en cualquier zona, y una simple reprogramación puede producirse con la suficiente rapidez como para que sea fácil pasar por alto el impacto. Anclar la réplica a una zona conocida hace que el destino sea predecible y que el fallo sea observable cada vez que ejecutes la demostración.

1. Busque el nodo en el que se está ejecutando el store-front pod y lea la etiqueta de zona del nodo:

   STORE_NODE="$(kubectl get pods -l app=store-front -o jsonpath='{.items[0].spec.nodeName}')"
   PIN_ZONE="$(kubectl get node "$STORE_NODE" -o jsonpath="{.metadata.labels['topology\.kubernetes\.io/zone']}")"
   echo "$PIN_ZONE"
   

   PIN_ZONE es la etiqueta de zona completa, como eastus2-1. Mantenga abierta esta sesión de shell: vuelva a usar este valor para el monitor y, más adelante, para la configuración del escenario (que solicita solo el número, la parte después del último guión, por ejemplo, 1 en eastus2-1).

2. Aplique un parche al despliegue store-front para requerir la planificación en esa zona y añada una anotación que marque el parche como un patrón solo para demostración:

   kubectl patch deployment store-front --patch "$(cat <<EOF
   {
     "metadata": {
       "annotations": {
         "chaos-demo.aks-zone-down-demo/deliberate-anti-pattern": "Pins the single front-end replica to zone ${PIN_ZONE} so run 1 is deterministic. Removed as part of the fix later in this tutorial - do not carry this pin into a real deployment."
       }
     },
     "spec": {
       "template": {
         "spec": {
           "affinity": {
             "nodeAffinity": {
               "requiredDuringSchedulingIgnoredDuringExecution": {
                 "nodeSelectorTerms": [
                   {
                     "matchExpressions": [
                       {"key": "topology.kubernetes.io/zone", "operator": "In", "values": ["${PIN_ZONE}"]}
                     ]
                   }
                 ]
               }
             }
           }
         }
       }
     }
   }
   EOF
   )"
   
   kubectl rollout restart deployment/store-front
   kubectl rollout status deployment/store-front --timeout=300s
   

3. Confirme que el pin se mantiene: la réplica debería estar de nuevo en un nodo de $PIN_ZONE:

   STORE_NODE="$(kubectl get pods -l app=store-front -o jsonpath='{.items[0].spec.nodeName}')"
   STORE_ZONE="$(kubectl get node "$STORE_NODE" -o jsonpath="{.metadata.labels['topology\.kubernetes\.io/zone']}")"
   echo "Pod is in zone: $STORE_ZONE (expected $PIN_ZONE)"
   

   Si los dos valores no coinciden, repita el paso anterior: la ejecución 1 no será determinista hasta que coincidan.

Descarga e inicio del monitor de demostración

Una monitorización solo en kubectl terminal es demasiado lenta y fácil de pasar por alto durante una demostración en directo. La señal de la propia tienda no se mueve al unísono con la del clúster. En este tutorial se usa un pequeño script de supervisión de Python desde el repositorio de ejemplos de Chaos Studio como la forma principal de ver la ejecución.

1. Descargue el monitor y el script fix-verification:

   curl -O https://raw.githubusercontent.com/microsoft/chaos-studio/f9573c943694e88cf3aacbca38debe84fa91a62c/samples/aks-zone-down-demo/monitor.py
   curl -O https://raw.githubusercontent.com/microsoft/chaos-studio/f9573c943694e88cf3aacbca38debe84fa91a62c/samples/aks-zone-down-demo/verify-fix.sh
   chmod +x verify-fix.sh
   

   Estos vínculos se anclan a una confirmación específica para que sigan funcionando independientemente de los cambios posteriores en el ejemplo. Una vez que la solicitud de incorporación de cambios se combina, las revisiones posteriores de este tutorial pueden pasar a una versión etiquetada en su lugar.

2. Inicie el monitor y configúrelo para que apunte a la IP externa de la tienda y a la zona que fijó en la sección anterior:

   python3 monitor.py --storefront-url http://<EXTERNAL-IP> --target-zone "$PIN_ZONE"
   

   El monitor usa solo la biblioteca estándar Python, por lo que no hay nada más que instalar. De forma predeterminada sondea cada 5 segundos: configurable con --interval o la variable de MONITOR_INTERVAL_SECONDS entorno. Ese valor predeterminado es lo bastante frecuente como para determinar el orden de las señales sin sondear la API de Kubernetes ni la tienda de forma demasiado agresiva.

3. En Cloud Shell, seleccione Vista previa web y establezca el puerto en 8787 para abrir el monitor en una pestaña del explorador. Si se ejecuta localmente, abra http://localhost:8787 en su lugar.

   La página de monitorización ahora es la vista principal para ambas ejecuciones. Muestra cuatro señales:

   • Estado HTTP de la tienda: una solicitud a la tienda que evita la caché, para que vea el estado real de si está accesible o no, en lugar de una respuesta satisfactoria almacenada en caché.
   • Estado del nodo de zona de destino: si el nodo de la zona de destino es Ready o NotReady.
   • Ubicación del pod front-end : qué store-front pods se ejecutan y en qué zona se encuentra cada uno.
   • Historial de transiciones - una cronología continua de todos los cambios de estado anteriores, con marcas de tiempo, para que puedas revisar la secuencia cuando termine la ejecución en lugar de depender de lo que hayas visto en tiempo real.

   Si una comprobación contra kubectl o contra la API de Kubernetes falla —por ejemplo, porque el servidor de la API no está accesible temporalmente o el archivo kubeconfig queda desactualizado—, el monitor muestra un banner rojo visible que indica el error, en lugar de dejar el indicador afectado bloqueado en un marcador de posición de «comprobando». El resto del panel sigue mostrando su último estado correcto conocido y su historial mientras se muestra el aviso. Trata el aviso como una señal con significado propio: indica que el monitor ha perdido visibilidad, no que aquello que supervisa funcione correctamente.

Crear un área de trabajo con ámbito en el grupo de recursos de infraestructura

AKS coloca los conjuntos de escalado de máquinas virtuales del nodo del clúster en un grupo de recursos de infraestructura independiente (denominado a partir de MC_ de forma predeterminada), no en el grupo de recursos que contiene el recurso del clúster. Configure el ámbito del área de trabajo para que abarque el grupo de recursos de infraestructura y así descubra los nodos. Para obtener más contexto, consulte Por qué un espacio de trabajo limitado a su clúster de AKS no encuentra destinos de proceso.

1. Busque el nombre del grupo de recursos de infraestructura:

   az aks show --resource-group chaos-demo-rg --name chaos-demo-aks --query nodeResourceGroup -o tsv
   

2. En el portal de Azure, busque Chaos Studio, seleccione Áreas de trabajo y, a continuación, seleccione Crear.

3. En la pestaña Aspectos básicos , seleccione el grupo de recursos, asigne el chaos-demo-rg nombre al área de trabajo chaos-demo-workspacey elija una región admitida. La región del área de trabajo no necesita coincidir con la región del clúster.

4. En la pestaña Ámbito , seleccione Grupo de recursos como tipo de ámbito y, a continuación, seleccione el grupo de recursos de infraestructura en el paso 1.

5. En la pestaña Identidad , elija Asignado por el sistema.

6. Seleccione Revisar y crear>crear y, a continuación, Vaya al recurso.

   Una vez completada la detección, el conjunto de escalado de máquinas virtuales del nodo del clúster (denominado como aks-nodepool1-12345678-vmss) aparece como un recurso detectado.

7. Si el portal muestra un banner que indica que la identidad no tiene permisos de lectura en el ámbito del área de trabajo, seleccione Asignar el rol Lector en el ámbito del área de trabajo. Para crear asignaciones de roles, necesita derechos de propietario o administrador de acceso de usuario en el grupo de recursos de infraestructura.

Asigna a la identidad los roles que el propio escenario necesita en la siguiente sección, donde la validación te indica exactamente lo que falta. Para ver un tutorial completo de cada paso de creación del área de trabajo, consulte el inicio rápido del área de trabajo.

Ejecución del escenario y visualización del error de la aplicación

El escenario Caída de la zona de proceso simula un fallo de una zona de disponibilidad apagando las instancias del conjunto de escalado de máquinas virtuales de una zona de destino durante el tiempo configurado. Las instancias se reinician cuando finaliza la duración de la acción.

1. En el área de trabajo, seleccione Escenarios y, a continuación, seleccione Zona de cómputo inactiva en la biblioteca de escenarios.

2. Configure el escenario. En la zona de disponibilidad, escriba el número de $PIN_ZONE (la parte después del último guión, por ejemplo 1 , en eastus2-1). Establezca la duración en 5 minutos, lo suficientemente larga como para ver que las señales de la tienda, el nodo y el pod se estabilicen, sin tener que esperar demasiado. Esta cifra de 5 minutos se ha fijado para esta demostración específica; otros tipos de escenarios tienen sus propias indicaciones sobre la duración en función de lo que se esté probando. Por ejemplo, un escenario basado en el comportamiento del almacenamiento en caché de DNS necesita una duración suficiente para superar el TTL de caché del registro, que puede ser mucho más de 5 minutos. Seleccione Guardar configuración.

3. La validación comprueba si la identidad administrada del área de trabajo puede realizar todas las acciones que el escenario necesita en los recursos de destino. Si la validación informa de que faltan permisos, seleccione Corregir los permisos en la página de configuración del escenario para conceder a la identidad los roles integrados recomendados. En este escenario, es colaborador de máquina virtual en el conjunto de escalado de máquinas virtuales del nodo. Para asignar usted mismo los roles, o para usar roles personalizados con privilegios mínimos en lugar de roles integrados, consulte Permisos e identidad en áreas de trabajo de Chaos Studio y Usar roles personalizados con privilegios mínimos con áreas de trabajo de Chaos Studio.

   Si todavía falta un rol necesario en tiempo de ejecución, la ejecución se inicia de todos modos, pero las acciones de apagado producen un error de permisos en el informe de escenario.

4. Seleccione Ejecutar y confirme.

Pueden pasar unos minutos desde que se inicia la ejecución hasta que el apagado se haga efectivo, así que no se preocupe si no cambia nada en la pantalla de inmediato. A continuación, consulte la página de monitorización:

• La señal HTTP de la tienda y el estado del nodo de destino no cambian en el mismo momento. La señal de nivel de aplicación es la experiencia de los usuarios y es la que se debe tratar como principal; las señales de nodo y pod son contabilidad interna del clúster que se actualizan después. Es de esperar que la interfaz muestre “inaccesible” bastante antes de que el nodo muestre NotReady; ese desfase es normal, se debe a la propagación asíncrona de la señal, no a un problema de la demostración.
• El estado del nodo de destino cambia a NotReady.
• Dado que el frontend está fijado a esa zona, su única réplica no tiene ningún otro lugar donde pueda ejecutarse. El escaparate permanece inaccesible hasta que Kubernetes pueda volver a programar el pod, que, con el pin en su lugar, solo se produce una vez que el nodo de destino devuelve o cambia la restricción de selección de ubicación. No confíes en una cifra fija de tiempo de inactividad aquí; consulta el historial de transiciones del monitor para comprobar lo que ocurrió realmente en tu ejecución.

Este resultado es el hallazgo. El clúster tenía redundancia entre zonas, pero la decisión de ubicación de la aplicación convirtió un fallo de zona en una caída del servicio sin una duración definida mientras la restricción siguiera vigente. El historial de cambios de estado del monitor es el registro de exactamente cuándo la tienda dejó de estar disponible y, más tarde, cuándo volvió a estar disponible.

Solución de problemas: el impacto no es visible

Si el monitor muestra que la tienda sigue siendo accesible durante toda la ejecución 1, revise estos puntos antes de suponer que el escenario no funcionó:

• Confirme que el pin surtió efecto. Ejecute kubectl get pods -l app=store-front -o wide y compruebe que el nodo del pod está en $PIN_ZONE. Si no se aplicó el parche, es posible que el planificador haya colocado la réplica en otro lugar. Una simple reprogramación durante la interrupción puede ser tan rápida que puede pasarte desapercibida sin el pin.
• Confirme que el monitor está viendo la zona y la dirección URL correctas. Reinicie monitor.py con el valor exacto --target-zone y la URL de la tienda de su clúster. Un valor obsoleto o introducido incorrectamente muestra un estado «correcto» engañoso.
• Compruebe el informe del escenario para ver Skipped las acciones. Si las acciones de apagado se muestran Skipped en lugar de Succeeded, la ejecución no encontró destinos coincidentes en la zona de destino. Consulte Interpretación de los resultados.
• Déle unos segundos más. La acción de apagado en sí tarda unos instantes en surtir efecto cuando se inicia la ejecución. El historial de transición del monitor muestra las marcas de tiempo exactas una vez que se producen.

Corregir la implementación y comprobarla

Ahora sustituya la fijación deliberada a una única zona por una solución real a escala de clúster: tres réplicas, estrictamente limitadas a una por zona.

1. Quite el pin de zona que agregó anteriormente:

   kubectl patch deployment store-front --type=merge --patch '{"spec":{"template":{"spec":{"affinity":null}}}}'
   

2. Escala el frontend a tres réplicas y añade una restricción de dispersión por topología que requiere una réplica por zona en lugar de limitarse a preferirla:

   kubectl patch deployment store-front --patch '{"spec":{"replicas":3,"template":{"spec":{"topologySpreadConstraints":[{"maxSkew":1,"topologyKey":"topology.kubernetes.io/zone","whenUnsatisfiable":"DoNotSchedule","labelSelector":{"matchLabels":{"app":"store-front"}}}]}}}}'
   

   whenUnsatisfiable: DoNotSchedule hace que la distribución de una réplica por zona sea un requisito estricto. Una réplica que no puede satisfacerla permanece Pending en lugar de aterrizar en una zona que ya tiene una. Es un compromiso deliberado: garantiza la cobertura por zonas de la que depende esta prueba, a costa de que una réplica pueda no llegar a asignarse si temporalmente no hay espacio en una zona. ScheduleAnyway permitiría que el planificador se saltara la restricción bajo presión, que es precisamente el modo de fallo que corrige esta solución.

3. Compruebe la corrección antes de confiar en ella. Ejecute el script de verificación. Espera a que termine el despliegue para que no se tengan en cuenta los pods obsoletos de la revisión antigua de una sola réplica y, a continuación, confirma que cada zona tiene al menos un pod Readystore-front:

   ./verify-fix.sh
   

   Una llamada de kubectl, una solicitud a la API o el JSON que devuelve pueden fallar de forma transitoria —por ejemplo, por un breve tiempo de espera agotado o por una conexión interrumpida— sin que eso signifique que la propia corrección haya fallado. El script reintenta tras estos fallos transitorios hasta que se agota su propio tiempo de espera, en lugar de finalizar tras el primero. Solo cuando expira ese tiempo de espera sale con un estado distinto de cero y un mensaje de diagnóstico que indica qué zona sigue sin tener una réplica lista. No proceda a ejecutar la 2 hasta que se apruebe. Un resultado satisfactorio es lo que convierte «una réplica por zona» en un hecho verificado, en lugar de una suposición arrastrada desde el comando `patch`.

Vuelva a ejecutar el escenario y compare

1. En el espacio de trabajo, vuelva a ejecutar el escenario Compute Zone Down con la misma zona de destino y la misma duración de 5 minutos.

2. Observe el monitor. El nodo de destino sigue fallando NotReady y arrastra consigo a su réplica store-front, pero la tienda sigue respondiendo, atendida por las réplicas de las zonas que siguen operativas. La afirmación que se está evaluando es la disponibilidad sostenida durante la caída de la zona, demostrada por el historial continuo del monitor, no que haya cero solicitudes perdidas, ni que el monitor muestre un estado saludable ininterrumpido en todo momento. Sigue siendo posible una breve interrupción mientras Azure Load Balancer se estabiliza sobre las réplicas restantes en buen estado; una ejecución satisfactoria muestra una breve fluctuación de convergencia, no una caída que dure todo el tiempo de la interrupción. El tiempo que tarda en producirse esa convergencia varía según el entorno, así que no confíe en un límite de tiempo fijo; use el historial de transiciones del monitor para distinguir un incidente momentáneo de una caída prolongada.

Los componentes de una sola réplica aun así pueden experimentar una breve interrupción. Si el nodo de la cola de RabbitMQ está en la zona de destino, el envío de pedidos se ralentiza mientras se recupera su pod. Encontrar el siguiente componente más débil y decidir si merece la pena solucionarlo es precisamente el ciclo que las pruebas de caos están diseñadas para impulsar.

Comparación de los informes de escenarios

1. En el espacio de trabajo, seleccione Historial de ejecuciones. Ahora tiene dos ejecuciones completas del mismo escenario.

2. Seleccione cada ejecución y, a continuación, seleccione Generar informe. Confirme que las acciones de apagado tienen el estado Completado correctamente en ambos casos, lo que significa que cada ejecución encontró e interrumpió las instancias de la zona de destino. Si las acciones muestran Skipped, la ejecución no encontró objetivos coincidentes. Las causas habituales son un ámbito que no incluye el grupo de recursos de infraestructura o una zona de destino sin nodos. Para más información, consulte Probar la resistencia de la carga de trabajo en AKS con Chaos Studio.

3. Observe que ambos informes tienen el mismo aspecto aunque los resultados de la aplicación fueran opuestos. Correcta significa que se aplicó la interrupción; no significa que la aplicación siguiera funcionando correctamente. El informe demuestra qué interrupción ha ocurrido y cuándo; el historial de transición del monitor es lo que demuestra el comportamiento de la aplicación en respuesta. Combinar ambos es la forma de convertir una ejecución en evidencia: el informe registra el momento del fallo, y el monitor muestra la diferencia entre el antes y el después que produjo la corrección.

Puede descargar ambos informes como evidencia del antes y el después para las revisiones de resiliencia. Para obtener más información, consulte Informes de escenarios.

Limpieza de recursos

Elimine el grupo de recursos para quitar el clúster, la aplicación de ejemplo y el área de trabajo. Al eliminar el clúster también se elimina su grupo de recursos de infraestructura.

az group delete --name chaos-demo-rg --yes --no-wait

Notificar problemas y características de solicitud

Azure Chaos Studio se desarrolla de forma abierta. Para notificar un error, solicitar una característica o formular una pregunta sobre áreas de trabajo, escenarios o la extensión CLI de Azure, abra un problema en el repositorio de Chaos Studio en GitHub. Al presentar un problema, puede realizar un seguimiento de su progreso y ver las solicitudes de otros clientes.

Pasos siguientes

• Pruebe la resistencia de la carga de trabajo en AKS con Chaos Studio cubre las advertencias e instrucciones de interpretación para ejecutar esta prueba en una carga de trabajo real.
• Para evaluar de forma objetiva el éxito o el fracaso de una carga de trabajo real, combine las ejecuciones de escenarios con las pruebas de disponibilidad de Application Insights y sus propios indicadores de nivel de servicio, en lugar de una pestaña del explorador.
• Tutorial: Ejecutar un escenario de conmutación por error de caída de zona en PostgreSQL añade una conmutación por error del nivel de datos al mismo patrón de interrupción.
• Los escenarios de Azure Chaos Studio describen la biblioteca de escenarios completa.
• El repositorio Chaos Studio GitHub tiene scripts de implementación para este ejemplo (incluidos los scripts de supervisión y comprobación usados en este tutorial), escenarios personalizados que se pueden compartir y un complemento de la CLI de Copilot para impulsar Chaos Studio desde GitHub Copilot.