Modelado de estado para cargas de trabajo críticas
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 proceso está inactivo, el servicio de mantenimiento no responderá. 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 trabajo 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 llamarán al Servicio de mantenimiento para determinar si tiene una conexión 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 buscará este archivo. |
HealthServiceOverallTimeoutSeconds |
Tiempo de espera de 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 la comprobación de estado se copian en caché en memoria mediante el elemento estándar y no distribuido de ASP.NET CoreMemoryCache. La expiración de la memoria caché se controla mediante SysConfig.HealthServiceCacheDurationSeconds y se establece en 10 segundos de manera predeterminada.
Nota
La SysConfig.HealthServiceCacheDurationSeconds configuración reduce la carga adicional generada por las comprobaciones de estado, ya que no todas las solicitudes darán lugar a 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, elimina el archivo de estado. Se tomó una decisión de diseño 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. La eliminación del archivo de estado deshabilitará 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 hará que el servicio responda siempre con UNHEALTHY. Front Door no reconocerá el back-end 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 se controlan mediante 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 se controlan mediante 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 establecido de período de vida breve, 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 identificarán automáticamente y se agregarán 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 extra contienen datos más detallados sobre los pods, las implementaciones, los 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.
Telemetría de Application Insights: Application Insights se usa para recopilar datos de telemetría de la aplicación. El código se ha instrumentado 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 los rechaza.
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
Para visualizar los resultados de nuestras consultas de estado de Log Analytics, hemos usado Grafana en nuestra implementación de referencia. Grafana se usa para mostrar los resultados de las consultas de Log Analytics y no contiene ninguna lógica. La pila de Grafana no forma parte del ciclo de vida de implementación de la solución, pero se publica por separado.
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 asegurarse de que no provocarán 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 | Impacto, mitigación o 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 mitigará 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. Se espera que los componentes existentes y en ejecución puedan seguir ejecutándose cuando Microsoft Entra ID 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, es probable que se produzca 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 mitigará 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. A medida que los cambios tardan un par de minutos en implementar Front Door, provocará 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á funcionando, pero los errores de certificado TLS/SSL impedirán 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 podrá 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 pueden extraer imágenes de Docker durante unos minutos mientras se produce la conmutación por error de DNS. | No |
| Azure Container Registry | Imagen(es) eliminada(s) | 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. | Esto 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 producirá 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. | Se producirá 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 | 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 provocará eventualmente 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). Si uno o más de esos repositorios o imágenes no están disponibles, es posible que las nuevas instancias de los nodos nuevos (en los que la imagen todavía no está almacenada en caché) no se puedan iniciar. Posible mitigación: en algunos escenarios puede tener sentido importar imágenes de contenedor de terceros en el registro de contenedor por solución. Esto agrega complejidad adicional y debería planearse y operarse 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 procesará los mensajes de Event Hubs. HealthService también usa la cuenta de almacenamiento. Se esperan problemas con el almacenamiento que debe detectar HealthService y la marca debe quitarse 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 servicio del sitio web estático encuentra problemas, Front Door debe detectar este error. El tráfico no se enviará 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 capturará todos los secretos de Key Vault y producirá un error. Los pods no se podrán iniciar. Hay una actualización automática actualmente cada 5 minutos. La actualización generará un error. 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. Debe mitigarse 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 de SAS del centro de eventos o la clave de cuenta de almacenamiento se cambió sin actualizarlos correctamente en Key Vault para que los pods puedan usarlos, se producirá 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 producirá 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 de una subred, no se pueden realizar operaciones de escalado horizontal, como la creación de nuevos nodos o pods de AKS. No provocará una interrupción, pero podría reducir el rendimiento y afectar a 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.