Compartir a través de

Modelado de estado para cargas de trabajo críticas

  • Artículo

La supervisión de aplicaciones e infraestructura es una parte importante de cualquier implementación de infraestructura. Para una carga de trabajo crítica, la supervisión es una parte fundamental de la implementación. La supervisión del estado de la aplicación y las métricas clave de los recursos de Azure le ayuda a comprender si el entorno funciona según lo previsto.

Para comprender completamente estas métricas y evaluar el estado general de una carga de trabajo, requiere una comprensión holística de todos los datos supervisados. Un modelo de mantenimiento puede ayudar con la evaluación del estado de mantenimiento general mostrando una indicación clara del estado de la carga de trabajo en lugar de las métricas sin procesar. El estado se presenta a menudo como indicadores de «semáforo», como rojo, verde o amarillo. La representación de un modelo de mantenimiento con indicadores claros hace que sea intuitivo que un operador comprenda el estado general de la carga de trabajo y responda rápidamente a los problemas que surgen.

El modelado de estado se puede expandir en las siguientes tareas operativas para la implementación crítica:

  • Servicio de mantenimiento de aplicaciones: componente de aplicación en el clúster de proceso que proporciona una API para determinar el estado de una marca.

  • Supervisión: colección de contadores de rendimiento y aplicaciones que evalúan el estado y el rendimiento de la aplicación y la infraestructura.

  • Alertas: alertas accionables de problemas o interrupciones en la infraestructura y la aplicación.

  • Análisis de errores: desglose y análisis de los errores, incluida la documentación de la causa principal.

Estas tareas constituyen un modelo de mantenimiento completo para la infraestructura crítica. El desarrollo de un modelo de mantenimiento puede y debe ser una parte exhaustiva e integral de cualquier implementación crítica.

Para más información, consulta Modelado de estado y observabilidad de cargas de trabajo críticas en Azure.

Servicio de mantenimiento de la aplicación

El Servicio de mantenimiento de la aplicación (HealthService) es un componente de aplicación que reside con el servicio de catálogo (CatalogService) y el procesador en segundo plano (BackgroundProcessor) dentro del clúster de proceso. HealthService proporciona una API REST para que Azure Front Door llame a para determinar el estado de un sello. HealthService es un componente complejo que refleja el estado de las dependencias, además de su propio.

Cuando el clúster de computación está inactivo, el servicio de salud no responde. Cuando los servicios están en funcionamiento, realiza comprobaciones periódicas en los siguientes componentes de la infraestructura:

  • Intenta realizar una consulta en Azure Cosmos DB.

  • Intenta enviar un mensaje a Event Hubs. El trabajador en segundo plano filtra el mensaje.

  • Busca un archivo de estado en la cuenta de almacenamiento. Este archivo se puede usar para desactivar una región, incluso mientras las demás comprobaciones siguen funcionando correctamente. Este archivo se puede usar para comunicarse con otros procesos. Por ejemplo, si la marca se va a cancelar con fines de mantenimiento, el archivo podría eliminarse para forzar un estado incorrecto y volver a enrutar el tráfico.

  • Consulta el modelo de mantenimiento para determinar si todas las métricas operativas están dentro de los umbrales predeterminados. Cuando el modelo de mantenimiento indica que la marca es incorrecta, el tráfico no se debe enrutar a la marca aunque las demás pruebas que healthService realiza devuelvan correctamente. El modelo de mantenimiento tiene en cuenta una vista más completa del estado de mantenimiento.

Todos los resultados de la comprobación de estado se almacenan en caché en memoria durante un número configurable de segundos, de forma predeterminada 10. Esta operación puede agregar una pequeña latencia en la detección de interrupciones, pero garantiza que no todas las consultas de HealthService requieran llamadas de back-end, lo que reduce la carga en el clúster y los servicios de bajada.

Este patrón de almacenamiento en caché es importante, ya que el número de consultas healthService crece significativamente cuando se usa un enrutador global como Azure Front Door: todos los nodos perimetrales de cada centro de datos de Azure que atiende las solicitudes llaman al servicio de mantenimiento para determinar si tiene una conexión de back-end funcional. El almacenamiento en caché de los resultados reduce la carga adicional del clúster generada por las comprobaciones de estado.

Configuración

HealthService y CatalogService tienen valores de configuración comunes entre los componentes, excepto para la siguiente configuración utilizada exclusivamente por HealthService:

Configuración Valor
HealthServiceCacheDurationSeconds Controla el tiempo de expiración de la memoria caché, en segundos.
HealthServiceStorageConnectionString Cadena de conexión para la cuenta de almacenamiento donde debe estar presente el archivo de estado.
HealthServiceBlobContainerName Contenedor de almacenamiento donde debe estar presente el archivo de estado.
HealthServiceBlobName Nombre del archivo de estado: la comprobación de estado busca este archivo.
HealthServiceOverallTimeoutSeconds Tiempo de espera para toda la comprobación: el valor predeterminado es de 3 segundos. Si la comprobación no finaliza en este intervalo, el servicio notifica un estado incorrecto.

Implementación

Todas las comprobaciones se realizan de forma asincrónica y en paralelo. Si se produce un error en alguna de ellas, el stamp completo se considerará no disponible.

Los resultados de comprobación se almacenan en caché en la memoria, con el ASP.NET Core estándar y no distribuido MemoryCache. SysConfig.HealthServiceCacheDurationSeconds controla la expiración de la memoria caché. La configuración predeterminada es de 10 segundos.

Nota

La configuración de SysConfig.HealthServiceCacheDurationSeconds reduce la carga adicional generada por las comprobaciones de estado, ya que no todas las solicitudes generan una llamada descendente a los servicios dependientes.

En la tabla siguiente se detallan las comprobaciones de estado de los componentes de la infraestructura:

Componente Comprobación de estado
Cuenta de Blob Storage La comprobación de blobs actualmente tiene dos propósitos:
1. Pruebe si es posible acceder a Blob Storage. Otros componentes del stamp usan esta cuenta de almacenamiento y se considera un recurso crítico.
2. Para desactivar manualmente una región, elimine el archivo de estado.
Se tomó una decisión de diseño de que la comprobación solo buscaría una presencia de un archivo de estado en el contenedor de blobs especificado. El contenido del archivo no se procesa. Existe la posibilidad de configurar un sistema más sofisticado que lea el contenido del archivo y devuelva un estado diferente en función del contenido del archivo.
Algunos ejemplos de contenido son HEALTHY, UNHEALTHY y MAINTENANCE.
Eliminación del archivo de estado deshabilita la marca. Asegúrese de que el archivo de mantenimiento está presente después de implementar la aplicación. La ausencia del archivo de mantenimiento hace que el servicio responda siempre con UNHEALTHY. Front Door no reconoce el backend como disponible.
Terraform crea el archivo y debe estar presente después de la implementación de la infraestructura.
Centro de eventos Los informes de estado de Event Hubs gestionan el EventHubProducerService. Este servicio de estado notifica un estado correcto si puede enviar un nuevo mensaje a Event Hubs. Para el filtrado, este mensaje tiene agregada una propiedad de identificación:
HEALTHCHECK=TRUE
Este mensaje se omite en el extremo receptor. La configuración AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() comprueba la propiedad HEALTHCHECK.
Azure Cosmos DB Los informes de mantenimiento de Azure Cosmos DB gestionan el CosmosDbService, que notifica un estado correcto si es:
1. Puede conectarse a la base de datos de Azure Cosmos DB y realizar una consulta.
2. Puede escribir un documento de prueba en la base de datos.
El documento de prueba tiene un breve período de vida establecido. Azure Cosmos DB lo quita automáticamente.
El HealthService realiza dos sondeos independientes. Si Azure Cosmos DB está en un estado en el que las lecturas funcionan y las escrituras no, los dos sondeos garantizan que se desencadene una alerta.

Consultas de Azure Cosmos DB

Para la consulta de solo lectura, se usa la siguiente consulta, que no captura ningún dato y no tiene un gran efecto en la carga general:

SELECT GetCurrentDateTime ()

La consulta de escritura crea un ItemRating ficticio con contenido mínimo:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Supervisión

Azure Log Analytics se utiliza como almacén central de registros y métricas para todos los componentes de la aplicación y la infraestructura. Aplicación de Azure Insights se usa para todos los datos de supervisión de aplicaciones. Cada stamp de la infraestructura tiene un área de trabajo dedicada de Log Analytics y una instancia de Application Insights. Se usa un área de trabajo de Log Analytics independiente para los recursos compartidos globalmente, como Front Door y Azure Cosmos DB.

Todos los sellos son de corta duración y se reemplazan continuamente por cada nueva versión. Las áreas de trabajo de Log Analytics por marca se implementan como un recurso global en un grupo de recursos de supervisión independiente como recursos de Log Analytics de marca. Estos recursos no comparten el ciclo de vida de un sello.

Para más información, consulta Receptor de datos unificados para el análisis correlacionado.

Supervisión: Orígenes de datos

  • Configuración de diagnóstico: todos los servicios de Azure usados para Azure Mission-Critical están configurados para enviar todos sus datos de diagnóstico, incluidos los registros y las métricas al área de trabajo de Log Analytics específica de la implementación (global o stamp). Este proceso se produce automáticamente como parte de la implementación de Terraform. Las nuevas opciones se identifican automáticamente y se agregan como parte de terraform apply.

  • Supervisión de Kubernetes: la configuración de diagnóstico se usa para enviar registros y métricas de Azure Kubernetes Service (AKS) a Log Analytics. AKS está configurado para usar Container Insights. Container Insights implementa OMSAgentForLinus a través de un DaemonSet de Kubernetes en cada nodo de los clústeres de AKS. OMSAgentForLinux es capaz de recopilar registros y métricas extra desde el clúster de Kubernetes y enviarlos a su área de trabajo de Log Analytics correspondiente. Estos registros y métricas adicionales contienen datos más granulares sobre pods, implementaciones, servicios y el estado general del clúster. Para obtener más información de los distintos componentes, como ingress-nginx, cert-manager y otros componentes implementados en Kubernetes junto a la carga de trabajo crítica, es posible usar la extracción de Prometheus. La extracción de Prometheus configura OMSAgentForLinux para extraer las métricas de Prometheus de varios puntos de conexión del clúster.

  • Supervisión de datos de Application Insights: Application Insights se usa para recopilar datos de supervisión de la aplicación. El código se instrumenta para recopilar datos sobre el rendimiento de la aplicación con el SDK de Application Insights. Se recopila información crítica, como el código de estado resultante y la duración de las llamadas y contadores de dependencia para excepciones no controladas. Esta información se usa en el modelo de mantenimiento y está disponible para alertas y solución de problemas.

Supervisión: Pruebas de disponibilidad de Application Insights

Para supervisar la disponibilidad de los sellos individuales y la solución general desde un punto de vista externo, las pruebas de disponibilidad de Application Insights se configuran en dos lugares:

  • Pruebas de disponibilidad regional: estas pruebas se configuran en las instancias regionales de Application Insights y se usan para supervisar la disponibilidad de los stamps. Estas pruebas tienen como destino los clústeres y las cuentas de almacenamiento estáticas de los stamps directamente. Para llamar directamente a los puntos de entrada de los clústeres, las solicitudes deben llevar el encabezado de identificador de Front Door correcto; de lo contrario, el controlador de entrada rechaza las llamadas.

  • Prueba de disponibilidad global: estas pruebas se configuran en la instancia global de Application Insights y se usan para supervisar la disponibilidad de la solución global haciendo ping a Front Door. Se usan dos pruebas: una para probar una llamada API en CatalogService y otra para probar la página principal del sitio web.

Supervisión: Consultas

Azure Mission-Critical usa diferentes consultas de Lenguaje de consulta Kusto (KQL) para implementar consultas personalizadas como funciones para recuperar datos de Log Analytics. Estas consultas se almacenan como archivos individuales en nuestro repositorio de código, separados para implementaciones globales y de stamp. Se importan y se aplican automáticamente a través de Terraform como parte de cada ejecución de canalización de infraestructura.

Este enfoque separa la lógica de consulta de la capa de visualización. Las consultas de Log Analytics se llaman directamente desde el código, por ejemplo, desde healthService API. Otro ejemplo es de una herramienta de visualización, como Paneles de Azure, Monitor Workbooks o Grafana.

Supervisión: Visualización

Usamos Grafana para visualizar los resultados de nuestras consultas de estado de Log Analytics en nuestra implementación de referencia. Grafana muestra los resultados de las consultas de Log Analytics y no contiene ninguna lógica propia. Lanzamos el paquete de Grafana independientemente del ciclo de vida de implementación de la solución.

Para más información, consulta Visualización.

Alertas

Las alertas son una parte importante de la estrategia general de operaciones. La supervisión proactiva, como el uso de paneles, debe usarse con alertas que generen atención inmediata a los problemas.

Estas alertas forman una extensión del modelo de mantenimiento, mediante la alerta al operador a un cambio en estado de mantenimiento, ya sea en estado degradado o amarillo o en estado incorrecto o rojo. Al establecer la alerta en el nodo raíz del modelo de mantenimiento, el operador conoce inmediatamente cualquier efecto de nivel empresarial en el estado de la solución: Después de todo, este nodo raíz se volverá amarillo o rojo si alguno de los flujos de usuario subyacentes o los recursos notifica métricas amarillas o rojas. El operador puede dirigir su atención a la visualización del modelo de mantenimiento para solucionar problemas.

Para más información, consulta Respuesta automatizada a los incidentes.

Análisis de errores

Redactar el análisis de errores es principalmente un ejercicio teórico de planificación. Este ejercicio teórico se debe usar como entrada para las inyecciones de errores automatizadas que forman parte del proceso de validación continua. Al simular los modos de error definidos aquí, podemos validar la resistencia de la solución frente a estos errores para minimizar las interrupciones.

En la tabla siguiente se enumeran los casos de error de ejemplo de los distintos componentes de la implementación de referencia de Azure Mission-Critical.

Servicio Riesgo Afectación/Mitigación/Comentario Interrupción
Microsoft Entra ID Microsoft Entra ID deja de estar disponible. Actualmente no existe ninguna mitigación posible. Un enfoque de varias regiones no mitiga las interrupciones, ya que es un servicio global. Este servicio es una dependencia difícil. Microsoft Entra ID se usa para las operaciones del plano de control, como la creación de nuevos nodos de AKS, la extracción de imágenes de contenedor de ACR o el acceso a Key Vault en el inicio del pod. Los componentes existentes y en ejecución deben poder seguir ejecutándose cuando el identificador de Entra de Microsoft experimenta problemas. Es probable que los nuevos pods o nodos de AKS no puedan generarse. En las operaciones de escalado se requieren durante este tiempo, podría provocar una disminución de la experiencia del usuario y potencialmente interrupciones. Parcial
DNS de Azure Azure DNS deja de estar disponible y se produce un error en la resolución dns. Si Azure DNS deja de estar disponible, se produce un error en la resolución DNS para las solicitudes de usuario y entre distintos componentes de la aplicación. Actualmente no existe ninguna mitigación posible para este escenario. Un enfoque de varias regiones no mitiga las interrupciones, ya que es un servicio global. Azure DNS es una dependencia difícil. Los servicios DNS externos como copia de seguridad no ayudan, ya que todos los componentes de PaaS usados se basan en Azure DNS. Pasar DNS cambiando a IP no es una opción. Los servicios de Azure no tienen direcciones IP estáticas y garantizadas. Full
Front Door Interrupción general de Front Door. Si Front Door deja de funcionar por completo, no hay una mitigación. Este servicio es una dependencia difícil. Sí
Front Door Errores de configuración de enrutamiento, front-end o back-end. Puede producirse debido a un error de coincidencia en la configuración al realizar la implementación. Debe detectarse en las fases de prueba. La configuración de front-end con DNS es específica de cada entorno. Mitigación: revertir a la configuración anterior debe corregir la mayoría de los problemas. Dado que los cambios tardan un par de minutos en desplegarse en Front Door, esto provoca una interrupción. Full
Front Door Se elimina el certificado TLS/SSL administrado. Puede producirse debido a un error de coincidencia en la configuración al realizar la implementación. Debe detectarse en las fases de prueba. Técnicamente, el sitio seguiría funcionando, pero los errores de certificado TLS/SSL impiden que los usuarios accedan a él. Mitigación: volver a emitir el certificado puede tardar unos 20 minutos, además de corregir y volver a ejecutar la canalización. Full
Azure Cosmos DB Se cambia el nombre de la base de datos o colección. Puede producirse debido a un error de coincidencia en la configuración al implementar: Terraform sobrescribiría toda la base de datos, lo que podría provocar la pérdida de datos. Se puede evitar la pérdida de datos mediante bloqueos de nivel de base de datos o colección. La aplicación no puede acceder a ningún dato. La configuración de la aplicación debe actualizarse y reiniciarse los pods. Sí
Azure Cosmos DB Interrupción regional Azure Mission-Critical tiene habilitadas las escrituras en varias regiones. Si se produce un error en una lectura o escritura, el cliente reintenta la operación actual. Todas las operaciones futuras se enrutarán permanentemente a la siguiente región en orden de preferencia. En caso de que la lista de preferencias tenga una entrada (o estaba vacía) pero la cuenta tenga otras regiones disponibles, se enrutará a la siguiente región de la lista de cuentas. No
Azure Cosmos DB Limitación extensa debido a la falta de RU. En función del número de RU y del equilibrio de carga empleado en el nivel de Front Door, algunos stamps podrían ejecutarse activa en el uso de Azure Cosmos DB, mientras que otros stamps pueden atender más solicitudes. Mitigación: mejor distribución de carga o más RU. No
Azure Cosmos DB Partición completa El límite de tamaño de partición lógica de Azure Cosmos DB es de 20 GB. Si los datos de una clave de partición dentro de un contenedor alcanzan este tamaño, se producirá un error en las solicitudes de escritura adicionales con el error "La clave de partición alcanzó el tamaño máximo". Parcial (escrituras de base de datos deshabilitadas)
Azure Container Registry Interrupción regional Container Registry usa Traffic Manager para conmutar por error entre regiones de réplica. Cualquier solicitud se debe volver a enrutar automáticamente a otra región. En el peor de los casos, los nodos de AKS no descargan imágenes de Docker durante unos minutos mientras ocurre el cambio de DNS por error. No
Azure Container Registry Imagen o imágenes eliminadas No se puede extraer ninguna imagen. Esta interrupción solo debe afectar a los nodos recién generados o reiniciados. Los nodos existentes deben tener las imágenes almacenadas en caché. **Mitigación: si se detecta que vuelve a ejecutar rápidamente las canalizaciones de compilación más recientes, debe devolver las imágenes al registro. No
Azure Container Registry Limitación de peticiones La limitación puede retrasar las operaciones de escalado horizontal, lo que puede provocar un rendimiento temporalmente degradado. Mitigación: Azure Mission-Critical usa la SKU Premium que proporciona 10 000 operaciones de lectura por minuto. Las imágenes de contenedor están optimizadas y solo tienen un pequeño número de capas. ImagePullPolicy se establece en IfNotPresent para usar primero las versiones almacenadas en caché localmente. Comentario: la extracción de una imagen de contenedor consta de varias operaciones de lectura, según el número de capas. El número de operaciones de lectura por minuto es limitado y depende del tamaño de la SKU de ACR. No
Azure Kubernetes Service Error en la actualización de clústeres Las actualizaciones del nodo de AKS deben producirse en momentos diferentes en las marcas. si se produce un error en una actualización, el otro clúster no debería verse afectado. Las actualizaciones de clúster deben implementarse de forma gradual entre los nodos para evitar que todos los nodos no estén disponibles. No
Azure Kubernetes Service El pod de aplicación se elimina al atender la solicitud. Este resultado podría dar lugar a errores del usuario final y a una experiencia de usuario deficiente. Mitigación: Kubernetes quita los pods de forma predeterminada de forma correcta. Los pods se quitan primero de los servicios y la carga de trabajo recibe un SIGTERM con un período de gracia para finalizar las solicitudes abiertas y escribir datos antes de finalizar. El código de la aplicación debe comprender SIGTERM y es posible que sea necesario ajustar el período de gracia si la carga de trabajo tarda más tiempo en apagarse. No
Azure Kubernetes Service Capacidad de proceso no disponible en la región para agregar más nodos. Se produce un error en las operaciones de escalado vertical y horizontal, pero no debería afectar a los nodos existentes y a su operación. Lo ideal es que el tráfico cambie automáticamente a otras regiones para el equilibrio de carga. No
Azure Kubernetes Service La suscripción alcanza la cuota de núcleos de CPU para agregar nuevos nodos. Las operaciones de escalamiento vertical u horizontal fallan, pero no deberían afectar a los nodos existentes y su funcionamiento. Lo ideal es que el tráfico cambie automáticamente a otras regiones para el equilibrio de carga. No
Azure Kubernetes Service No se pueden emitir o renovar certificados TLS/SSL. El clúster debe notificar un estado incorrecto hacia Front Door y el tráfico debe cambiar a otros sellos. Mitigación: investigue la causa principal del error de problema o renovación. No
Azure Kubernetes Service Cuando las solicitudes o límites de recursos se configuran incorrectamente, los pods pueden alcanzar el 100 % de uso de CPU y las solicitudes de error. El mecanismo de reintento de la aplicación debe ser capaz de recuperar solicitudes con error. Los reintentos podrían provocar una duración de solicitud más larga, sin exponer el error al cliente. La carga excesiva finalmente produce un error. No (si la carga no es excesiva)
Azure Kubernetes Service Imágenes de contenedor de terceros/ registro no disponible Algunos componentes, como cert-manager e ingress-nginx, requieren descargar imágenes de contenedor y gráficos de Helm de registros de contenedor externos (tráfico de salida). En caso de que uno o varios de estos repositorios o imágenes no estén disponibles, es posible que las nuevas instancias de los nodos nuevos (donde la imagen aún no esté almacenada en caché) no puedan iniciarse. Posible mitigación: en algunos escenarios, puede tener sentido importar imágenes de contenedor de terceros en el registro de contenedor por solución. Este escenario agrega complejidad adicional y debe planearse y operacionalizarse cuidadosamente. Parcialmente (durante las operaciones de escalado y actualización o actualización)
Centro de eventos Los mensajes no se pueden enviar a Event Hubs Stamp se vuelve inutilizable para las operaciones de escritura. El servicio de mantenimiento debe detectar esto automáticamente y quitar la rotación. No
Centro de eventos BackgroundProcessor no puede leer los mensajes Los mensajes se ponen en cola. Los mensajes no deben perderse, ya que se conservan. Actualmente, este error no está cubierto por el Servicio de mantenimiento. El trabajador debe contar con una supervisión/alerta para detectar errores en la lectura de los mensajes. Mitigación: la marca debe deshabilitarse manualmente hasta que se corrija el problema. No
Cuenta de almacenamiento La cuenta de almacenamiento deja de ser utilizable por el trabajador para la comprobación de Event Hubs Stamp no procesa mensajes de Event Hubs. HealthService también usa la cuenta de almacenamiento. El HealthService detecta problemas de almacenamiento y debe sacar el sello de la rotación. Se puede esperar que otros servicios del sello se vean afectados simultáneamente. No
Cuenta de almacenamiento El sitio web estático encuentra problemas. Si el sitio web estático encuentra problemas, Front Door detecta este error. El tráfico no se envía a esta cuenta de almacenamiento. El almacenamiento en caché en Front Door también puede aliviar este problema. No
Key Vault Key Vault no disponible para las operaciones GetSecret. Al principio de los nuevos pods, el controlador CSI de AKS captura todos los secretos de Key Vault y produce un error. Los pods no se pueden iniciar. Hay una actualización automática actualmente cada 5 minutos. Se produce un error en la actualización. Los errores deben aparecer en kubectl describe pod, pero el pod sigue funcionando. No
Key Vault Key Vault no disponible para las operaciones GetSecret o SetSecret. No se pueden ejecutar nuevas implementaciones. Actualmente, este error podría hacer que toda la canalización de implementación se detenga, incluso si solo se ve afectada una región. No
Key Vault Limitaciones de ancho de banda de Key Vault Key Vault tiene un límite de 1000 operaciones por 10 segundos. Debido a la actualización automática de secretos, podría alcanzar este límite en teoría si tenía muchos (miles) de pods en un sello. Posible mitigación: reduce aún más la frecuencia de actualización o desactiva completamente. No
Aplicación Error de configuración Cadenas de conexión o secretos incorrectos insertados en la aplicación. Se mitiga mediante la implementación automatizada (la canalización controla la configuración automáticamente) y la implementación azul-verde de las actualizaciones. No
Aplicación Credenciales expiradas (recurso stamp) Si, por ejemplo, el token saS del centro de eventos o la clave de la cuenta de almacenamiento se cambió sin actualizarlos correctamente en Key Vault para que los pods puedan usarlos, se produce un error en el componente de aplicación correspondiente. A continuación, este error debe afectar al Servicio de mantenimiento, y la marca debe quitarse de la rotación automáticamente. Mitigación: use la autenticación basada en Microsoft Entra ID para todos los servicios que lo admiten. AKS requiere pods para autenticarse mediante Microsoft Entra Workload ID (versión preliminar). El uso de la identidad de pod se consideró en la implementación de referencia. Se encontró que la identidad de pod no era lo suficientemente estable actualmente y se decidió usar para la arquitectura de referencia actual. La identidad del pod podría ser una solución en el futuro. No
Aplicación Credenciales expiradas (recurso compartido global) Si, por ejemplo, la clave de API de Azure Cosmos DB se cambió sin actualizarla correctamente en todos los almacenes de claves de stamp para que los pods puedan usarlos, se produce un error en los componentes de la aplicación correspondientes. Este error reduciría todas las marcas al mismo tiempo y provocaría una interrupción en toda la carga de trabajo. Para obtener una forma posible de evitar la necesidad de claves y secretos mediante la autenticación de Microsoft Entra, consulte el elemento anterior. Full
Red virtual Espacio de direcciones IP de subred agotado Si se agota el espacio de direcciones IP en una subred, no se pueden realizar operaciones de escalado horizontal, como la creación de nuevos nodos o pods de AKS. No se produce una interrupción, pero podría disminuir el rendimiento y afectar la experiencia del usuario. Mitigación: aumente el espacio de IP (si es posible). Si no es una opción, puede ayudar a aumentar los recursos por nodo (SKU de máquina virtual más grandes) o por pod (más CPU/memoria), de modo que cada pod pueda controlar más tráfico, lo que reduce la necesidad de escalar horizontalmente. No

Pasos siguientes

Implemente la implementación de referencia para comprender completamente los recursos utilizados en esta arquitectura y su configuración.

Implementación: Crítica en línea