Tutorial: Prueba de la resistencia de la zona de AKS con un escenario

En este tutorial sobre escenarios de Azure Chaos Studio, use espacios de trabajo de Chaos Studio para probar la capacidad de recuperación de una aplicación de ejemplo de Azure Kubernetes Service (AKS) ante un error de zona. Implemente la aplicación en un clúster de prueba con redundancia de zona y ejecute Compute Zone Down en su infraestructura de nodos. La primera ejecución expone un frontend fijado a una zona. Corrija la ubicación del pod, vuelva a ejecutar el Scenario y compare la disponibilidad de la aplicación y los informes del Scenario.

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 se ha registrado en su suscripción. Para obtener instrucciones para registrarse, consulte Requisitos previos de inicio rápido de Espacios de trabajo.

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 el paso az account set si la suscripción ya es la que tiene 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. Se trata de una vista secundaria del estado de la aplicación durante la prueba; el monitor que se inicia más tarde 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.

Fija el front-end a una única zona para una demostración determinista.

Sin una fijación deliberada, el programador puede ubicar la única réplica del front-end en cualquier zona, y puede producirse una reprogramación simple con tanta rapidez que es 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. Mantén abierta esta sesión de shell: reutilizarás este valor para el monitor y, más adelante, para la configuración del escenario (que solo solicita el número, la parte que viene 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. Confirma que la asignación se mantiene: la réplica debería volver a estar 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, repite el paso anterior: la ejecución 1 no será determinista hasta que lo hagan.

Descarga e inicio del monitor de demostración

Una supervisión de kubectl solo desde el terminal es demasiado lenta y fácil de pasar por alto durante una demostración en directo. La señal propia de la tienda virtual 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. Descarga el monitor y el script de verificación de la corrección:

   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 se fusione la solicitud de incorporación de cambios correspondiente, las revisiones posteriores de este tutorial podrán pasar a una versión etiquetada.

2. Inicia el monitor, dirigiéndolo a la IP externa de la tienda y a la zona que fijaste 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 del monitor es ahora tu vista principal para ambas ejecuciones. Muestra cuatro señales:

   • Estado HTTP de Storefront: una solicitud a Storefront con la caché desactivada, para que veas en tiempo real si es accesible o no, en lugar de un resultado de éxito almacenado en caché.
   • Estado del nodo de zona de destino: si el nodo de la zona de destino es Ready o NotReady.
   • Ubicación de los pods de front-end: qué store-front pods se están ejecutando 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 falla una consulta contra kubectl o la API de Kubernetes —por ejemplo, si el servidor de la API queda inaccesible momentáneamente o si el archivo kubeconfig queda obsoleto—, el monitor muestra un banner rojo visible en el que se indica el error, en lugar de dejar la señal afectada estancada en un marcador de posición que indique comprobando. El resto del panel de control sigue mostrando su último estado válido conocido y el historial mientras el banner permanece visible. Considera el banner como una señal en sí misma: significa que el monitor ha perdido visibilidad, no que el elemento que está supervisando esté en buen estado.

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.

En la siguiente sección, asignas a la identidad los roles que necesita el propio escenario; allí, la validación te indicará exactamente qué 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. Para la Availability Zone, introduce el número de $PIN_ZONE (la parte que viene después del último guion; por ejemplo, 1 en eastus2-1). Establece la duración en 5 minutos: el tiempo suficiente para que las señales de la tienda, el nodo y el pod se estabilicen, sin una espera excesivamente larga. 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. Para este escenario, se trata de Virtual Machine Contributor en el conjunto de escalado de Virtual Machines 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 sigue faltando un rol requerido en tiempo de ejecución, la ejecución se inicia de todos modos, pero las acciones de apagado fallan con un error de permisos en el informe del 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 a nivel de aplicación es la que experimentan realmente los usuarios, y es la que debe considerarse prioritaria; las señales del nodo y del pod son datos internos del clúster que se actualizan posteriormente. Es de esperar que la interfaz de usuario muestre inaccesible notablemente antes de que el nodo muestre NotReady; esa diferencia es una propagación asíncrona normal de la señal, no un problema de la demostración.
• El estado del nodo de destino cambia a NotReady.
• Dado que el front-end está fijado a esa zona, su única réplica no puede ejecutarse en ningún otro lugar. La tienda virtual permanece inaccesible hasta que Kubernetes pueda reprogramar el pod, lo cual, con la fijación activa, solo ocurre una vez que el nodo de destino vuelve a estar disponible o se modifica la restricción de ubicación. No te fíes de una cifra fija de tiempo de inactividad en este caso; consulta el historial de transiciones del monitor para ver qué 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 transiciones del monitor es el registro de cuándo exactamente se cayó la tienda virtual y, posteriormente, cuándo volvió a estar disponible.

Solución de problemas: el impacto no es visible

Si el monitor muestra que la tienda virtual permaneció accesible durante toda la ejecución 1, comprueba estos puntos antes de dar por hecho 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, sin la fijación, pases por alto el cambio.
• Confirme que el monitor está viendo la zona y la dirección URL correctas. Reinicia monitor.py con el valor exacto de --target-zone y la URL de la tienda virtual de tu clúster. Un valor obsoleto o mal escrito muestra un estado en buen estado engañoso.
• Comprueba el informe del escenario en busca de acciones Skipped. Si las acciones de apagado muestran Skipped en lugar de Succeeded, la ejecución no encontró objetivos 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í misma tarda un breve tiempo en surtir efecto tras el inicio de 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 sustituye la restricción deliberada de una sola zona por una solución real a escala de clúster: tres réplicas, con la restricción estricta de 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. Amplíe el front-end a tres réplicas y añada una restricción de distribución topológica que exija una réplica por zona en lugar de simplemente 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 pueda cumplirla permanece en Pending en lugar de asignarse a una zona que ya tenga una. Se trata de una compensación deliberada: garantiza la cobertura de zonas de la que depende esta prueba, a costa de que una réplica pueda quedar sin programar si una zona se queda temporalmente sin espacio. ScheduleAnyway permitiría al programador omitir la restricción en situaciones de presión, que es precisamente el modo de fallo que soluciona esta corrección.

3. Compruebe la corrección antes de confiar en ella. Ejecute el script de verificación. Espera a que finalice la implementación para que no se cuenten los pods obsoletos de la antigua revisión 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 kubectl, una solicitud de API o el JSON que devuelve pueden fallar de forma transitoria —un breve tiempo de espera agotado, una conexión interrumpida— sin que ello signifique que la corrección en sí haya fallado. El script reintenta estos fallos transitorios hasta que se agota su propio tiempo de espera, en lugar de salir al primer fallo. 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 pases a ejecutar el paso 2 hasta que haya superado la prueba. Un resultado satisfactorio es lo que convierte una réplica por zona en un hecho verificado, en lugar de una suposición heredada del 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 en estado NotReady y arrastra consigo su réplica store-front, pero la tienda online sigue respondiendo, atendida por las réplicas de las zonas que han sobrevivido. La afirmación que se somete a prueba es la disponibilidad sostenida durante la interrupción de la zona, demostrada por el historial continuo del monitor —no por la ausencia de solicitudes perdidas, ni por el hecho de que el monitor muestre un estado de funcionamiento ininterrumpido en todo momento—. Sigue siendo posible una breve interrupción mientras el Load Balancer de Azure converge hacia las réplicas sanas restantes; una ejecución satisfactoria muestra un breve pico de convergencia, no una interrupción que dure todo el tiempo que dura la perturbació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. Correcto significa que se ha producido la interrupción, no que la aplicación haya seguido 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. Al combinar ambos datos es como se convierte una ejecución en una prueba: el informe registra la hora en que se produjo el fallo y el monitor muestra la diferencia antes y después de 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.