Implementación y pruebas de cargas de trabajo críticas en Azure

La implementación y las pruebas de un entorno crítico es una parte fundamental de la arquitectura de referencia global. Los stamps de aplicación individuales se implementan usando una infraestructura como código de un repositorio de código fuente. Las actualizaciones de la infraestructura, y de la aplicación que alberga, deben implementarse sin tiempo de inactividad en la aplicación. Se recomienda una canalización de integración continua de DevOps para recuperar el código fuente del repositorio e implementar los stamps individuales en Azure.

La implementación y las actualizaciones son el proceso central de la arquitectura. Las actualizaciones relacionadas con la infraestructura y la aplicación deben implementarse en stamps totalmente independientes. Solo los componentes de infraestructura globales de la arquitectura se comparten entre stamps. Los stamps que ya había en la infraestructura no se tocan. Las actualizaciones de la infraestructura se implementan únicamente en estos nuevos stamps. Del mismo modo, la nueva versión de la aplicación solo se implementa en estos nuevos stamps.

Los nuevos stamps se agregan a Azure Front Door. El tráfico se mueve gradualmente a los nuevos stamps. Cuando se determina que el tráfico se atiende desde los nuevos stamps sin problema, se eliminan los stamps anteriores.

Se recomienda realizar pruebas de penetración, caos y esfuerzo del entorno implementado. Las pruebas proactivas de la infraestructura detectan puntos débiles y cómo se comportaría la aplicación implementada si se produjese un error.

Implementación

La implementación de la infraestructura en la arquitectura de referencia depende de los siguientes procesos y componentes:

• DevOps: código fuente de GitHub y canalizaciones de la infraestructura.

• Actualizaciones sin tiempo de inactividad: las actualizaciones se implementan en el entorno sin tiempo de inactividad en la aplicación implementada.

• Entornos: entornos de corta duración y permanentes usados para la arquitectura.

• Recursos compartidos y dedicados: recursos de Azure dedicados y compartidos con los stamps y la infraestructura global.

Para obtener más información, consulte Implementación y pruebas de cargas de trabajo críticas en Azure: Consideraciones de diseño.

Implementación: DevOps

Los componentes de DevOps proporcionan el repositorio de código fuente y las canalizaciones de CI/CD para la implementación de la infraestructura y las actualizaciones. GitHub y Azure Pipelines se han elegido como componentes.

• GitHub: contiene los repositorios de código fuente para la aplicación y la infraestructura.

• Azure Pipelines: canalizaciones que usa la arquitectura para todas las tareas de compilación, pruebas y versión.

Un componente adicional del diseño usado para la implementación es los agentes de compilación. Los agentes de compilación hospedados de Microsoft se usan como parte de Azure Pipelines para implementar la infraestructura y las actualizaciones. El uso de agentes de compilación hospedados de Microsoft libera a los desarrolladores de la carga de mantener y actualizar el agente de compilación.

Para obtener más información acerca de Azure Pipelines, consulte ¿Qué es Azure DevOps?.

Para obtener más información, consulte Implementación y pruebas de cargas de trabajo críticas en Azure: Implementaciones de infraestructura como código.

Implementación: actualizaciones sin tiempo de inactividad

La estrategia de actualización sin tiempo de inactividad de la arquitectura de referencia es fundamental para la aplicación crítica global. La metodología de reemplazar en lugar de actualizar los stamps garantiza una instalación nueva de la aplicación en un stamp de infraestructura. La arquitectura de referencia utiliza un enfoque azul/verde y permite entornos de desarrollo y pruebas separados.

La arquitectura de referencia tiene dos componentes principales:

• Infraestructura: servicios y recursos de Azure. Implementada con Terraform y la configuración asociada.

• Aplicación: servicio hospedado o aplicación que atiende a los usuarios. Se basa en contenedores de Docker y artefactos npm en HTML y JavaScript para la interfaz de usuario de la aplicación de página única (SPA).

En muchos sistemas, se supone que las actualizaciones de la aplicación serán más frecuentes que las actualizaciones de la infraestructura. Por eso, se desarrollan diferentes procedimientos de actualización para cada uno. Con una infraestructura de nube pública, los cambios pueden producirse a un ritmo más rápido. Se ha elegido un proceso de implementación para las actualizaciones de la aplicación y de la infraestructura. Un método garantiza que las actualizaciones de la infraestructura y de la aplicación estén siempre sincronizadas. Este método permite:

• Un proceso coherente: menos posibilidades de error si las actualizaciones de la infraestructura y de la aplicación se combinan en una versión, intencionadamente o no.

• Una implementación azul/verde: cada actualización se implementa usando una migración gradual del tráfico a la nueva versión.

• Mayor facilidad de implementación y depuración de la aplicación: el stamp entero nunca hospeda varias versiones de la aplicación en paralelo.

• Reversión sencilla: el tráfico se puede volver a enviar a los stamps que ejecutan la versión anterior si se encuentran errores o problemas.

• Eliminación de cambios manuales y del desfase de configuración: cada entorno es una implementación nueva.

Para obtener más información, consulte Implementación y pruebas de cargas de trabajo críticas en Azure: Implementaciones efímeras azules/verdes.

Estrategia de creación de ramas

La base de la estrategia de actualización es el uso de ramas en el repositorio de Git. La arquitectura de referencia usa tres tipos de ramas:

Rama	Description
feature/* y fix/*	Puntos de entrada para cualquier cambio. Estas ramas las crean los desarrolladores y se les debe asignar un nombre descriptivo, como feature/catalog-update o fix/worker-timeout-bug. Cuando los cambios están listos para fusionarlos mediante combinación, se crea una solicitud de incorporación de cambios (PR) en la rama main. Cada solicitud de incorporación de cambios debe ser aprobada por al menos un revisor. Salvo algunas excepciones, todos los cambios propuestos en una solicitud de incorporación de cambios deben ejecutarse a través de la canalización de validación de un extremo a otro (E2E). Los desarrolladores deben usar la canalización E2E para probar y depurar los cambios en un entorno completo.
main	Rama estable que avanza continuamente. Se usa principalmente para las pruebas de integración. Los cambios en main solo se realizan a través de solicitudes de incorporación de cambios. Una directiva de rama prohíbe las operaciones de escritura directa. Las versiones nocturnas en el entorno permanente integration (int) se ejecutan automáticamente desde la rama main. La rama main se considera estable. Debe suponerse con seguridad que, en un momento dado, se puede crear una versión a partir de ella.
release/*	Las ramas de versión solo se crean a partir de la rama main. Las ramas siguen el formato release/2021.7.X. Se usan directivas de rama para que solo los administradores del repositorio puedan crear ramas release/*. Solo se usan estas ramas para las implementaciones en el entorno prod.

Para obtener más información, consulte Implementación y pruebas de cargas de trabajo críticas en Azure: Estrategia de bifurcación.

Revisiones

Cuando se requiere una revisión urgente debido a un error u otro problema y no se puede seguir el proceso de versión normal, hay disponible una ruta de revisión. Las actualizaciones y correcciones de seguridad críticas para la experiencia del usuario que no se detectaron durante las pruebas iniciales se consideran ejemplos válidos de revisiones.

La revisión debe crearse en una rama fix nueva y, después, fusionarse mediante combinación en main usando una solicitud de incorporación de cambios normal. En lugar de crear una nueva rama de versión, la revisión se "selecciona de forma exclusiva" en una rama de versión que ya existía. Esta rama ya está implementada en el entorno prod. La canalización de CI/CD que implementó originalmente la rama de versión con todas las pruebas se ejecuta de nuevo y ahora implementa la revisión como parte de la canalización.

Para evitar problemas mayores, es importante que la revisión contenga algunas confirmaciones aisladas que se puedan seleccionar de forma exclusiva e integrar fácilmente en la rama de versión. Si no se pueden seleccionar exclusivamente confirmaciones aisladas para integrarlas en la rama de versión, es una indicación de que el cambio no es una revisión, sino que debe implementarse como una nueva versión completa y, posiblemente, combinarse con la reversión a una versión estable anterior hasta que se pueda implementar la nueva versión.

Implementación: entornos

La arquitectura de referencia usa dos tipos de entornos para la infraestructura:

• De corta duración: se usa la canalización de validación E2E para implementar entornos de corta duración. Los entornos de corta duración se usan para entornos de validación o depuración puros para desarrolladores. Los entornos de validación se pueden crear desde la rama feature/*, sujetos a pruebas y, después, destruirse si todas las pruebas son satisfactorias. Los entornos de depuración se implementan de la misma manera que los de validación, pero no se destruyen inmediatamente. Estos entornos no deben existir durante más de unos días y deben eliminarse cuando se fusiona mediante combinación la solicitud de incorporación de cambios correspondiente de la rama de características.

• Permanente: en los entornos permanentes, hay versiones integration (int) y production (prod). Estos entornos permanecen, no se destruyen. Los entornos usan nombres de dominio fijos como int.mission-critical.app. En una implementación real de la arquitectura de referencia, debe agregarse un entorno staging (preproducción). El entorno staging se usa para implementar y validar ramas release con el mismo proceso de actualización que prod (implementación azul/verde).

  • Integración (int): la versión int se implementa por la noche desde la rama main con el mismo proceso que prod. El cambio del tráfico es más rápido que en la unidad de versión anterior. En lugar de cambiar el tráfico gradualmente durante varios días, como en prod, el proceso de int se completa en unos minutos o unas horas. Este cambio más rápido garantiza que el entorno actualizado esté listo a la mañana siguiente. Los stamps antiguos se eliminan automáticamente si todas las pruebas de la canalización son satisfactorias.

  • Producción (prod): la versión prod solo se implementa desde ramas release/*. El cambio del tráfico sigue pasos más detallados. Entre paso y paso, hay una puerta de aprobación manual. Cada versión crea nuevos stamps regionales e implementa la nueva versión de la aplicación en esos stamps. Los stamps que había no se tocan durante el proceso. El aspecto más importante que debe tenerse en cuenta para prod es que debe estar "siempre activo". No se debe producir ningún tiempo de inactividad planeado ni no planeado. La única excepción es los cambios fundamentales de la capa de base de datos. Puede que sea necesaria una ventana de mantenimiento planeado.

Implementación: recursos compartidos y dedicados

Los entornos permanentes (int y prod) de la arquitectura de referencia tienen diferentes tipos de recursos en función de si se comparten con toda la infraestructura o si están dedicados a un stamp concreto. Los recursos pueden dedicarse a una versión determinada y existir únicamente hasta que llega la siguiente unidad de versión.

Unidades de versión

Una unidad de versión está formada por varios stamps regionales para una versión específica. Los stamps contienen todos los recursos que no se comparten con los demás stamps. Estos recursos son redes virtuales, un clúster de Azure Kubernetes Service, Event Hubs y Azure Key Vault. Azure Cosmos DB y ACR se configuran con orígenes de datos de Terraform.

Recursos compartidos globalmente

Todos los recursos compartidos entre unidades de versión se definen en una plantilla de Terraform aparte. Estos recursos son Front Door, Azure Cosmos DB, Container Registry (ACR), las áreas de trabajo de Log Analytics y otros recursos relacionados con la supervisión. Estos recursos se implementan antes de implementar el primer stamp regional de una unidad de versión. En las plantillas de Terraform para los stamps, se hace referencia a los recursos.

Front Door

Aunque Front Door es un recurso compartido globalmente entre stamps, su configuración es ligeramente diferente a la de los demás recursos globales. Front Door debe volver a configurarse después de implementar un nuevo stamp. También debe volver a configurarse para cambiar gradualmente el tráfico a los nuevos stamps.

La configuración de back-end de Front Door no se puede definir directamente en la plantilla de Terraform. La configuración se inserta con variables de Terraform. Los valores de las variables se construyen antes de iniciar la implementación de Terraform.

La configuración de los componentes individuales para la implementación de Front Door se define como:

• Front-end: la afinidad de sesión está configurada para asegurar que los usuarios no cambien entre diferentes versiones de la interfaz de usuario durante una sola sesión.

• Orígenes: Front Door está configurado con dos tipos de grupos de origen:

  1. Un grupo de origen para el almacenamiento estático que atiende a la interfaz de usuario. El grupo contiene las cuentas de almacenamiento del sitio web de todas las unidades de versión activas actualmente. Se pueden asignar diferentes pesos a los orígenes de diferentes unidades de versión para mover gradualmente el tráfico a una unidad más reciente. Cada origen de una unidad de versión debe tener asignado el mismo peso.

  2. Un grupo de origen para la API, que se hospeda en AKS. Si hay unidades de versión con diferentes versiones de API, hay un grupo de origen de API para cada unidad de versión. Si todas las unidades de versión ofrecen la misma API compatible, todos los orígenes se agregan al mismo grupo y se les asignan pesos diferentes.

• Reglas de enrutamiento: hay dos tipos de reglas de enrutamiento:

  1. Regla de enrutamiento para la interfaz de usuario que está vinculada al grupo de origen de almacenamiento de la interfaz de usuario.

  2. Una regla de enrutamiento para cada API admitida actualmente por los orígenes. Por ejemplo, /api/1.0/* y /api/2.0/*.

  Si una versión introduce una nueva versión de las API de back-end, los cambios se reflejan en la interfaz de usuario que se implementa como parte de la versión. Una versión específica de la interfaz de usuario siempre llama a una versión específica de la dirección URL de la API. Los usuarios a los que atiende una versión de la interfaz de usuario usan automáticamente la API de back-end correspondiente. Se necesitan reglas de enrutamiento específicas para diferentes instancias de la versión de la API. Estas reglas están vinculadas a los grupos de origen correspondientes. Si no se introduce una nueva API, todas las reglas de enrutamiento relacionadas con la API se vinculan al grupo de origen único. En este caso, no importa si a un usuario se le ofrece la interfaz de usuario de una versión diferente de la API.

Implementación: proceso de implementación

El objetivo del proceso de implementación es una implementación azul/verde. Una nueva versión a partir de una rama release/* se implementa en el entorno prod. El tráfico de usuario se desplaza gradualmente a los stamps de la nueva versión.

Como primer paso en el proceso de implementación de una nueva versión, se implementa la infraestructura de la nueva unidad de versión con Terraform. La ejecución de la canalización de implementación de la infraestructura implementa la nueva infraestructura desde una rama de versión seleccionada. En paralelo al aprovisionamiento de la infraestructura, se compilan las imágenes de contenedor o se importan e insertan en el registro de contenedor compartido globalmente (ACR). Cuando se completan los procesos anteriores, la aplicación se implementa en los stamps. Desde el punto de vista de la implementación, es una canalización con varias fases dependientes. La misma canalización se puede volver a ejecutar para la implementación de revisiones.

Una vez implementada y validada la nueva unidad de versión, se agrega a Front Door para recibir tráfico de usuario.

Se debe planear un modificador o parámetro que distinga entre las versiones que introducen y no introducen una nueva versión de API. En función de si la versión introduce o no una nueva versión de API, debe crearse un nuevo grupo de origen con los back-end de API. Como alternativa, se pueden agregar nuevos back-end de API a un grupo de origen que ya existía. Se agregan nuevas cuentas de almacenamiento de interfaz de usuario al grupo de origen correspondiente. Los pesos de los nuevos orígenes deben establecerse según la división deseada del tráfico. Debe crearse una nueva regla de enrutamiento como se ha descrito anteriormente que corresponda al grupo de origen adecuado.

Al agregar la nueva unidad de versión, los pesos de los nuevos orígenes deben establecerse en el tráfico de usuario mínimo deseado. Si no se detecta ningún problema, la cantidad de tráfico de usuario debe aumentarse para el nuevo grupo de origen durante un período de tiempo. Para ajustar los parámetros de peso, se deben volver a ejecutar los mismos pasos de implementación con los valores deseados.

Desmontaje de la unidad de versión

En la canalización de implementación de una unidad de versión, hay una fase de destrucción que quita todos los stamps una vez que ya no se necesita una unidad de versión. Todo el tráfico se mueve a una nueva versión de lanzamiento. Esta fase incluye la eliminación de referencias a unidades de versión en Front Door. Esta eliminación es fundamental para habilitar el lanzamiento de una nueva versión en una fecha posterior. Front Door debe apuntar a una sola unidad de versión para prepararse para la próxima versión en el futuro.

Checklists

Como parte de la cadencia de versión, debe usarse una lista de comprobación anterior y posterior a la versión. El ejemplo siguiente es de elementos que deben estar en cualquier lista de comprobación como mínimo.

• Lista de comprobación anterior a la versión: antes de iniciar el lanzamiento de una versión, compruebe lo siguiente:

  • Asegúrese de que el estado más reciente de la rama main se ha implementado y probado satisfactoriamente en el entorno int.

  • Actualice el archivo de registro de cambios con una solicitud de incorporación de cambios en la rama main.

  • Cree una rama release/ a partir de la rama main.

• Lista de comprobación posterior a la versión: antes de destruir los stamps antiguos y de quitar sus referencias de Front Door, compruebe lo siguiente:

  • Los clústeres ya no reciben tráfico entrante.

  • Event Hubs y otras colas de mensajes no contienen ningún mensaje sin procesar.

Implementación: limitaciones y riesgos de la estrategia de actualización

La estrategia de actualización descrita en esta arquitectura de referencia tiene algunas limitaciones y riesgos que se deben mencionar:

• Mayor costo: cuando se lanzan actualizaciones, muchos de los componentes de la infraestructura están activos dos veces durante el período de lanzamiento.

• Complejidad de Front Door: el proceso de actualización en Front Door es complejo de implementar y mantener. La capacidad de ejecutar implementaciones de tipo "azul/verde" eficaces sin tiempo de inactividad depende de que funcione correctamente.

• Pequeños cambios que consumen mucho tiempo: el proceso de actualización da como resultado un proceso de versión más largo para pequeños cambios. Esta limitación se puede mitigar parcialmente con el proceso de revisión descrito en la sección anterior.

Implementación: consideraciones de compatibilidad con datos de la aplicación de versiones posteriores

La estrategia de actualización puede admitir varias versiones de una API y componentes de trabajo que se ejecuten simultáneamente. Dado que Azure Cosmos DB se comparte entre dos o más versiones, existe la posibilidad de que los elementos de datos modificados por una versión no siempre coincidan con la versión de la API o los trabajos que los consumen. Las capas de API y los trabajos deben implementar un diseño de compatibilidad con versiones posteriores. Las versiones anteriores de la API o de los componentes de trabajo procesan los datos insertados por una versión posterior de la API o de los componentes de trabajo. Omite las partes que no entiende.

Pruebas

La arquitectura de referencia contiene diferentes pruebas que se usan en diferentes fases dentro de la implementación de pruebas.

Estas pruebas incluyen:

• Pruebas unitarias: estas pruebas validan que la lógica de negocios de la aplicación funciona según lo previsto. La arquitectura de referencia contiene un conjunto de pruebas unitarias de ejemplo que se ejecutan automáticamente antes de cada compilación de contenedor por parte de Azure Pipelines. Si alguna prueba da error, la canalización se detiene. La compilación y la implementación no continúan.

• Pruebas de carga: estas pruebas ayudan a evaluar la capacidad, la escalabilidad y los posibles cuellos de botella de una carga de trabajo o pila determinada. La implementación de referencia contiene un generador de carga de usuario para crear patrones de carga sintéticos que se pueden usar para simular el tráfico real. El generador de carga también se puede usar independientemente de la implementación de referencia.

• Pruebas de humo: estas pruebas detectan si la infraestructura y la carga de trabajo están disponibles y actúan según lo previsto. Las pruebas de humo se ejecutan como parte de cada implementación.

• Pruebas de interfaz de usuario: estas pruebas validan que la interfaz de usuario se ha implementado y funciona según lo previsto. La implementación actual solo realiza capturas de pantalla de varias páginas después de la implementación sin llevar a cabo pruebas reales.

• Pruebas de inserción de errores: estas pruebas se pueden automatizar o ejecutar manualmente. Las pruebas automatizadas en la arquitectura integran Azure Chaos Studio como parte de las canalizaciones de implementación.

Para obtener más información, consulte Implementación y pruebas de cargas de trabajo críticas en Azure: Validación y pruebas continuas.

Pruebas: marcos

La implementación de referencia en línea utiliza la funcionalidad y los marcos de pruebas que hay siempre que es posible.

marco	Prueba	Descripción
NUnit	Unidad	Este marco se usa para las pruebas unitarias de la parte de .NET Core de la implementación. Azure Pipelines ejecuta automáticamente las pruebas unitarias antes de las compilaciones de contenedor.
JMeter con Azure Load Testing	Cargar	Azure Load Testing es un servicio administrado que se usa para ejecutar definiciones de pruebas de carga de Apache JMeter.
Locust	Cargar	Locust es un marco de pruebas de carga de código abierto escrito en Python.
Playwright	Interfaz de usuario y humo	Playwright es una biblioteca de Node.js de código abierto para automatizar Chromium, Firefox y WebKit con una sola API. La definición de prueba de Playwright también se puede usar independientemente de la implementación de referencia.
Azure Chaos Studio	Inserción de errores	La implementación de referencia usa Azure Chaos Studio como paso opcional en la canalización de validación E2E para inyectar errores con el fin de validar la resistencia.

Pruebas: pruebas de inserción de errores e ingeniería de caos

Las aplicaciones distribuidas deben ser resistentes a interrupciones de componentes y servicios. Las pruebas de inserción de errores (también conocidas como ingeniería de caos) son la práctica de someter aplicaciones y servicios a esfuerzos y errores reales.

La resistencia es una propiedad de un sistema completo e insertar errores ayuda a encontrar problemas en la aplicación. Solucionar estos problemas ayuda a validar la resistencia de la aplicación a condiciones poco confiables, dependencias que faltan y otros errores.

Se pueden ejecutar pruebas manuales y automáticas en la infraestructura para encontrar errores y problemas en la implementación.

Automático

La arquitectura de referencia integra Azure Chaos Studio para implementar y ejecutar un conjunto de experimentos de Azure Chaos Studio con el fin de insertar varios errores en el nivel de stamp. Los experimentos de Caos se pueden ejecutar como una parte opcional de la canalización de implementación E2E. Cuando se ejecutan las pruebas, la prueba de carga opcional se ejecuta siempre en paralelo. La prueba de carga se usa para crear la carga en el clúster con el fin de validar el efecto de los errores insertados.

Manual

Las pruebas manuales de inserción de errores deben realizarse en un entorno de validación E2E. Este entorno garantiza pruebas completas representativas sin riesgo de interferencias de otros entornos. La mayoría de los errores generados con las pruebas se pueden observar directamente en la vista Métricas en directo de Application Insights. Los demás errores están disponibles en la vista Errores y en las tablas de registro correspondientes. Otros errores requieren una depuración más profunda, como el uso de kubectl para observar el comportamiento en AKS.

Los siguientes son dos ejemplos de pruebas de inserción de errores realizadas en la arquitectura de referencia:

• Inserción de errores basada en DNS: caso de prueba que puede simular varios problemas. Errores de resolución de DNS debidos a un error en un servidor DNS o Azure DNS. Las pruebas basadas en DNS pueden ayudar a simular problemas generales de conexión entre un cliente y un servicio, por ejemplo, cuando BackgroundProcessor no se puede conectar a Event Hubs.

  En escenarios de host único, puede modificar el archivo local hosts para sobrescribir la resolución de DNS. En un entorno más grande con varios servidores dinámicos, como AKS, no es viable el uso de un archivo hosts. Como alternativa para probar escenarios de error, se pueden usar zonas DNS privadas de Azure.

  Azure Event Hubs y Azure Cosmos DB son dos de los servicios de Azure que se usan en la implementación de referencia que se pueden usar para insertar errores basados en DNS. La resolución de DNS de Event Hubs se puede manipular con una zona DNS privada de Azure asociada a la red virtual de uno de los stamps. Azure Cosmos DB es un servicio replicado globalmente con puntos de conexión regionales específicos. La manipulación de los registros DNS para esos puntos de conexión puede simular un error para una región específica y probar la conmutación por error de los clientes.

• Bloqueo de firewall: la mayoría de los servicios de Azure admiten restricciones de acceso de firewall basadas en redes virtuales o direcciones IP. En la infraestructura de referencia, estas restricciones se usan para limitar el acceso a Azure Cosmos DB o Event Hubs. Un procedimiento sencillo consiste en quitar reglas Permitir o agregar nuevas reglas Bloquear. Este procedimiento puede simular errores de configuración del firewall o interrupciones del servicio.

  Los siguientes servicios de ejemplo de la implementación de referencia se pueden probar con una prueba de firewall:

  Servicio	Resultado
  Key Vault	Cuando se bloquea el acceso a Key Vault, el efecto más directo es el error de generación de los nuevos pods. El controlador CSI de Key Vault que captura secretos al iniciar el pod no puede realizar sus tareas e impide que el pod se inicie. Los mensajes de error correspondientes se pueden observar con kubectl describe po CatalogService-deploy-my-new-pod -n workload. Los pods que ya hay siguen funcionando, aunque se observa el mismo mensaje de error. El mensaje de error lo generan los resultados de la comprobación periódica de actualizaciones de secretos. Aunque no se ha probado, se supone que la ejecución de una implementación no funcionará mientras Key Vault no esté accesible. Las tareas de Terraform y la CLI de Azure en la ejecución de la canalización realizan solicitudes a Key Vault.
  Event Hubs	Cuando se bloquea el acceso a Event Hubs, los mensajes nuevos enviados por CatalogService y HealthService dan error. La recuperación de mensajes por BackgroundProcess deja de funcionar lentamente, hasta que deja de funcionar por completo en unos minutos.
  Azure Cosmos DB	La eliminación de la directiva de firewall actual para una red virtual da como resultado que el servicio de mantenimiento comience a dar error con un retraso mínimo. Este procedimiento simula únicamente un caso específico, la interrupción total de Azure Cosmos DB. La mayoría de los casos de error que se producen en el nivel regional deben mitigarse automáticamente mediante la conmutación por error transparente del cliente a otra región de Azure Cosmos DB. Las pruebas de inserción de errores basadas en DNS descritas aquí son una prueba más significativa para Azure Cosmos DB.
  Container Registry (ACR)	Cuando se bloquea el acceso a ACR, la creación de nuevos pods que se habían extraído y almacenado en caché antes en un nodo de AKS continúa funcionando. La creación sigue funcionando por la marca de implementación pullPolicy=IfNotPresent de K8s. Los nodos que no han extraído y almacenado en caché una imagen antes del bloqueo no pueden generar un nuevo pod y producen errores ErrImagePull de inmediato. kubectl describe pod muestra el mensaje 403 Forbidden correspondiente.
  Equilibrador de carga de entrada de AKS	La modificación de las reglas de entrada para HTTP(S)(puertos 80 y 443) en el grupo de seguridad de red (NSG) administrado de AKS para Denegar los resultados en el tráfico de sondeo de estado o de usuario no llega al clúster. En la prueba de este error, es difícil identificar la causa principal, que se simula como un bloqueo entre la ruta de acceso de red de Front Door y un stamp regional. Front Door detecta inmediatamente este error y excluye el stamp de la rotación.