Actualizar Kubernetes y las imágenes de nodos de forma segura en varios clústeres

Se aplica a: ✔️ Administrador de flota ✔️ Administrador de flota con clúster de concentrador

Los administradores de plataformas que gestionan un gran número de clústeres suelen tener problemas para preparar actualizaciones para varios clústeres (por ejemplo, actualizar la imagen del sistema operativo de los nodos o las versiones de Kubernetes) de forma segura y predecible. Para abordar este desafío, Azure Kubernetes Fleet Manager permite organizar las actualizaciones en varios clústeres mediante ejecuciones de actualizaciones.

Las ejecuciones de actualizaciones constan de fases, grupos y estrategias. Puede aplicar ejecuciones de actualizaciones manualmente para las actualizaciones únicas o automáticamente para las actualizaciones periódicas en curso mediante perfiles de actualización automática. Todas las ejecuciones de actualización, tanto manuales como automatizadas, respetan las ventanas de mantenimiento del clúster.

Comprender las ejecuciones de actualización

Una ejecución de actualización representa una actualización que se aplica a una colección de clústeres de AKS. Consta del objetivo de actualización y la secuencia. El objetivo de actualización describe las actualizaciones deseadas. Por ejemplo, actualizar a una versión específica de Kubernetes o aplicar una imagen de nodo coherente en todos los clústeres.

Para lograr los mejores resultados al usar ejecuciones de actualización, es importante comprender los conceptos siguientes.

• Estrategia de actualización: describe una secuencia de actualización reutilizable que consta de fases y grupos de clústeres. Un clúster aparece en un grupo en una fase según las etiquetas de grupo de actualización o de miembro que tenga asignadas. Para obtener más información, consulte Descripción de las estrategias de actualización.

  • Fase de actualización: una estrategia de actualización se divide en fases de actualización, que se aplican secuencialmente. Por ejemplo, los clústeres de entorno de prueba se encuentran en la primera fase de actualización, mientras que los clústeres de entorno de producción van en una segunda fase de actualización. Una fase de actualización contiene uno o varios grupos de actualizaciones. Puede usar controles adicionales, como la simultaneidad máxima, los tiempos de espera y las puertas de aprobación para obtener más control sobre la ejecución de la fase de actualización.

  • Grupo de actualizaciones: cada fase de actualización contiene uno o varios grupos de actualizaciones, que seleccionan los clústeres que se van a actualizar. Asigne clústeres de miembros a Update Groups mediante la propiedad Update Group del clúster o la coincidencia basada en etiquetas en versión preliminar mediante etiquetas de miembro. Los grupos de actualización de una fase de actualización se actualizan en paralelo.

  Nota:

  El número máximo de grupos de actualizaciones en cada fase de actualización es 50.

  • Controles de flujo adicionales: hay más controles disponibles para proporcionar flexibilidad sobre la rapidez con la que se puede actualizar una flota de clústeres:

    • Simultaneidad máxima (versión preliminar): use la configuración de simultaneidad máxima para cambiar el número de clústeres que se actualizan en paralelo. Puede configurar este comportamiento tanto a nivel de fase como de grupo.

    • Errores máximos permitidos (versión preliminar): use la configuración Errores máximos permitidos para controlar cuántos errores de actualización del clúster miembro se toleran antes de que se detenga la ejecución de la actualización. Puede configurar este comportamiento tanto a nivel de fase como de grupo.

    • Condiciones de acceso: Pausa la ejecución de actualización hasta que se cumpla su condición.

      • Puertas de aprobación (versión preliminar): se puede configurar antes o después de cada fase o grupo. Las aprobaciones pausan la ejecución de la actualización, permitiendo que tanto usted como las automatizaciones que ha configurado comprueben que es adecuado continuar. Después de que usted o la automatización conceda la aprobación, la ejecución de la actualización continuará.

      • Puertas de inicio programadas (versión preliminar): se puede configurar antes de cada fase o grupo. Las puertas de inicio programadas pausan la ejecución de la actualización hasta un día y hora especificados. La condición de acceso se completa automáticamente cuando se alcanza la hora programada, o bien puedes completarla manualmente para continuar en cualquier momento.

• Perfil de actualización automática: crea e inicia automáticamente una ejecución de actualización cuando AKS pone a disposición nuevas versiones de Kubernetes o de la imagen de nodo. Para obtener más información, consulte Descripción de los perfiles de actualización automática.

Actualizar opciones de ejecución

Las ejecuciones de actualización pueden aplicar tres tipos de actualizaciones:

• Actualice las versiones de Kubernetes para el plano de control y los nodos. Esta actualización incluye la actualización de la imagen del nodo.
• Actualice las versiones de Kubernetes solo para el plano de control de los clústeres.
• Actualizar solo las imágenes de nodo.

Puede especificar la versión de Kubernetes de destino a la que actualizar, pero no puede seleccionar las versiones de la imagen del nodo de destino. El sistema selecciona automáticamente las versiones de la imagen del nodo de destino en función de sus preferencias:

• Más reciente: use las imágenes de nodo más recientes disponibles en la región de Azure de cada clúster cuando se inicie la actualización de ese clúster. Como resultado, se podrían usar diferentes versiones de imagen en toda la flota, en función de la región Azure en la que se encuentra un clúster y cuándo se inicia realmente su actualización.
• Coherente: cuando se inicia la ejecución de la actualización, elija las versiones de imagen que están disponibles actualmente en todas las regiones de Azure donde se encuentran los clústeres de esta ejecución. Por lo tanto, se usan versiones de imagen coherentes en todos los clústeres.

Elija Latest (Más reciente) para usar versiones de imagen más recientes y minimizar los riesgos de seguridad. Elija Constante para mejorar la fiabilidad usando y verificando estas imágenes en clústeres de fases anteriores antes de utilizarlas en clústeres posteriores.

Actualizar estados de ejecución

Para comprender el ciclo de vida de una ejecución de actualización, debe conocer cada estado, las acciones que puede realizar y cómo se calcula el estado.

Estado pendiente

• Actualizar ejecución: si la fase actual está en estado Pending.
• Actualizar fase: si todos los grupos de actualizaciones de la fase están en Pending o no se actualizan, o si tiene una puerta Pending.
• Actualizar grupo: si todos los clústeres del grupo están Pending o no se han iniciado, o si tiene una puerta Pending. Cuando un clúster se mueve a Pending, la ejecución de la actualización intenta actualizar el siguiente clúster del grupo. Si todos los miembros son Pending, el grupo se mueve a Pending. La ejecución de la actualización espera a que se completen todos los grupos de una fase antes de pasar a la siguiente.
• Clúster de miembros: por cualquiera de los siguientes motivos, que puede ver en el campo de mensaje.
  • La ventana de mantenimiento no está abierta. El mensaje indica la próxima hora de apertura.
  • La versión de destino de Kubernetes o de la imagen de nodo aún no está disponible en la región de Azure del clúster. El mensaje enlaza al seguimiento de versiones de AKS para comprobar el estado de la versión.

Estado omitido

• Ejecución de actualización: el sistema detectó que todas las etapas estaban Skipped.
• Fase de actualización: un usuario marcó la fase o todos los grupos de la fase como Skipped.
• Actualizar grupo: un usuario marcó el grupo o todos los clústeres del grupo como Skipped.
• Clúster de miembros: por cualquiera de los siguientes motivos, que puede ver en el campo de mensaje.
  • El usuario omitió explícitamente el clúster, el grupo o la fase.
  • El clúster ya está en la versión de Kubernetes de destino (si el modo de ejecución de actualizaciones es Full o ControlPlaneOnly) y todos los grupos de nodos están en la versión de la imagen del nodo de destino.
  • Cuando se selecciona una imagen de nodo coherente y no es posible encontrar la versión de la imagen de destino para uno de los grupos de nodos. Esta situación puede producirse cuando se agrega un nuevo grupo de nodos con una nueva SKU de máquina virtual (VM) después de iniciar una ejecución de actualización.

Estado de error

El estado de error se propaga desde los clústeres, tal como se muestra. Un mensaje de error resumido muestra la causa por la que falló la actualización del clúster.

• Ejecución de actualización: al menos un clúster del grupo actual ha fallado.
• Fase de actualización: falló al menos un clúster de un grupo de la fase.
• Grupo de actualizaciones: se produjo un error al menos un clúster en el grupo.
• Clúster miembro: error en la actualización y el estado del clúster se establece como Failed.

Al configurar errores máximos permitidos, el umbral de error afecta al estado del grupo de actualizaciones, la fase de actualización y la ejecución de la actualización. No afecta al estado de un clúster miembro individual. Si falla la actualización de un clúster miembro, su estado sigue configurado como Failed.

• Si el recuento de errores para el grupo o la fase supera el umbral configurado maxAllowedFailures , el grupo o la fase se marca como Failed con un mensaje de error de resumen y la ejecución de la actualización deja de avanzar. Si no maxAllowedFailures está configurado (o se establece en 0), un único error detiene toda la ejecución.
• Si el número de fallos está dentro del umbral de maxAllowedFailures, el proceso de actualización continúa actualizando los miembros siguientes. Para obtener más información, consulte Errores máximos permitidos.

Estado completado

Un Completed estado significa que la ejecución de la actualización alcanzó un estado de ciclo de vida del terminal. Cuando se usan errores máximos permitidos, Completed significa que no se superó el umbral de error configurado cuando Fleet Manager decidió si continuar con la programación del trabajo. No garantiza una tasa de éxito mínima ni resultados correctos. Inspeccione siempre FailureCount, los estados de los miembros y los mensajes de fallo.

Ventanas de mantenimiento planeado

Las ejecuciones de actualización respetan las ventanas de mantenimiento planeado que establezca en el nivel de clúster de AKS.

Los clústeres de AKS admiten dos ventanas de mantenimiento distintas: una para las actualizaciones de Kubernetes (plano de control) y otra para las actualizaciones de imágenes de nodo. Las ventanas de mantenimiento definen períodos cuando se pueden aplicar actualizaciones a un clúster, pero no son un desencadenador de actualización.

La actualización de Fleet Manager respeta las ventanas de mantenimiento de AKS de la siguiente manera:

La ejecución de la actualización prioriza la actualización de clústeres en función del mantenimiento planeado en el orden siguiente:

1. Clúster con una ventana de mantenimiento en curso abierta.
2. Clúster con ventana de mantenimiento abierta en las próximas cuatro horas.
3. Clúster sin ventana de mantenimiento.
4. Clúster con una ventana de mantenimiento cerrada.

Introducción a los perfiles de actualización automática

Use perfiles de actualización automática para iniciar automáticamente las ejecuciones de actualización cuando haya disponibles nuevas versiones de Kubernetes o de imágenes de nodo para AKS.

En un perfil de actualización automática, configure:

• un canal (Rapid, Stable, TargetKubernetesVersion, NodeImage, SecurityPatch (versión preliminar)) que determina el tipo de actualización que se aplica a los clústeres.
• UpdateStrategy que configura la secuencia en la que se actualizan los clústeres. Si no proporciona una estrategia, los clústeres se actualizan uno por uno secuencialmente.
• NodeImageSelectionType (Latest, Consistent) para especificar cómo se selecciona la imagen del nodo al actualizar la versión de Kubernetes.

Canal rápido

El canal Rápido siempre es la versión secundaria de Kubernetes compatible con AKS más reciente. Las versiones secundarias del clúster cambian automáticamente cuando AKS publica una nueva versión secundaria de Kubernetes.

Ejemplos:

• La versión secundaria compatible más reciente es 1.30. Cualquier versión de parche de la rama secundaria 1.30 se tiene en cuenta para las actualizaciones del canal rápido.
• Se publica una nueva versión secundaria de Kubernetes de 1.31. 1.30 cambia al canal estable. Cualquier clúster que haya recibido actualizaciones de la versión 1.30 se actualiza a la revisión más reciente de la versión 1.31 que ahora es el canal Rápido.

Canal estable

El canal estable siempre es la versión secundaria antes del canal Rápido . A veces, las personas hacen referencia a Estable como "N-1", donde "N" es la versión secundaria compatible con Kubernetes más reciente (canal rápido). Las versiones secundarias del clúster cambian automáticamente cuando AKS publica una nueva versión secundaria de Kubernetes.

Ejemplos:

• La versión secundaria de Kubernetes más reciente admitida es 1.30. Las versiones de revisión de la 1.29 intervalo secundario se considerarían para las actualizaciones de canales estables.
• Se publica una nueva versión secundaria de Kubernetes de 1.31. El canal Estable considera cualquier versión de parche en el intervalo de la versión secundaria 1.30 para las actualizaciones. Cualquier clúster que haya recibido actualizaciones de la versión 1.29 se actualiza a la revisión más reciente de la versión 1.30.

Canal de TargetKubernetesVersion

El canal TargetKubernetesVersion proporciona control sobre cuándo mover los clústeres a la siguiente versión secundaria de Kubernetes. Debe especificar la versión de Kubernetes de destino con el formato "{major}. {minor}" (por ejemplo, "1.33"). Fleet Manager actualiza automáticamente los clústeres a la versión de revisión más reciente de la versión de Kubernetes de destino especificada cuando la revisión está disponible. Fleet Manager no se actualiza a la siguiente versión menor hasta que se actualice la versión de destino de Kubernetes del perfil de actualización automática.

Ejemplos:

• Cree un perfil de actualización automática mediante el canal TargetKubernetesVersion y especifique una versión de Kubernetes de destino de "1.30". Se publica una nueva versión de revisión 1.30.5. Se crea automáticamente un proceso de actualización con la versión de destino 1.30.5.
• Cree un perfil de actualización automática mediante el canal TargetKubernetesVersion, especifique una versión de Kubernetes de destino de "1.29" y habilite LongTermSupport (LTS) en el perfil de actualización automática. La última versión menor compatible con la comunidad es "1.33". Se publica una nueva versión de revisión 1.29.5. Se crea automáticamente una ejecución de la actualización con la versión de destino 1.29.5. Si la ejecución de la actualización generada incluye clústeres sin LTS habilitado, se produce un error.

Comportamiento de omisión de versiones secundarias

La actualización automática no mueve clústeres entre versiones secundarias de Kubernetes cuando hay más de una diferencia de versión secundaria de Kubernetes (por ejemplo: 1.28 a 1.30). Cuando los administradores tienen un conjunto diverso de versiones de Kubernetes, use primero una o varias ejecuciones de actualizaciones para incorporar clústeres a un conjunto de versiones con versiones coherentes para que las actualizaciones configuradas Stable o Rapid del canal garanticen que la coherencia se mantenga en el futuro.

Canal NodeImage

Los nodos de clúster miembro se actualizan con un VHD recién revisado que contiene correcciones de seguridad y correcciones de errores en una cadencia semanal. La actualización al nuevo VHD supone una interrupción, según los periodos de mantenimiento y la configuración de sobrecarga. No se incurre en ningún coste adicional de VHD al elegir esta opción. Las actualizaciones de imágenes de nodo son compatibles con las versiones de revisión que están en desuso, siempre que todavía se admita la versión secundaria de Kubernetes. Las imágenes de nodo son probadas por AKS, totalmente administradas y aplicadas con prácticas de implementación seguras.

Los nodos de diferentes sistemas operativos se actualizan de acuerdo con las versiones de imagen de nodo alineadas con esos sistemas operativos.

Ejemplo:

• Un clúster tiene nodos con nodeImage de AKSWindows-2022-containerd de la versión 20348.2582.240716. Se publica una nueva versión de NodeImage 20348.2582.240916 y los nodos del clúster se actualizan automáticamente a la versión 20348.2582.240916.

Descripción de las actualizaciones e instantáneas de imágenes de nodo

Cuando un clúster tiene grupos de agentes que se crearon a partir de una instantánea de un grupo de nodos, el resultado de la actualización de la imagen del nodo depende de la selección de imagen del nodo en Update Run de Fleet Manager.

Canal SecurityPatch (versión preliminar)

Actualice los nodos de Linux del clúster miembro con solo correcciones de seguridad en una cadencia semanal. Ubuntu canónico y Azure Linux hacen que las revisiones de seguridad del sistema operativo estén disponibles una vez al día. Microsoft prueba estas revisiones y las agrupa en actualizaciones semanales de imágenes de nodo.

El canal de actualización automática SecurityPatch es menos disruptivo, ya que utiliza el parcheo en vivo del sistema operativo cuando es posible, minimizando las interrupciones de los nodos y manteniéndolos protegidos frente a vulnerabilidades conocidas. Cuando no es posible aplicar parches en tiempo real, se implementa en su lugar una imagen de nodo con los parches preinstalados.

Solo se actualizan los nodos basados en Linux cuando se usan SecurityPatchy se omiten automáticamente los nodos basados en Windows.

Si necesitas correcciones de errores incluidas en las nuevas imágenes de nodo (VHD), o una experiencia coherente con los nodos Windows, elige en su lugar el canal NodeImage.

Descripción de las estrategias de actualización

Los administradores pueden controlar el orden en el que se actualizan los clústeres mediante la creación de estrategias de actualización reutilizables mediante la serie de fases y grupos de actualizaciones. Pueden configurar cuándo deben producirse aprobaciones y pausas dentro de esas fases y grupos. Toda la configuración se puede guardar como una estrategia de actualización que se puede administrar independientemente de las ejecuciones de actualización o perfiles de actualización automática, lo que permite reutilizar las estrategias según sea necesario.

Agrupación de clústeres mediante etiquetas de miembro (versión preliminar)

Las etiquetas de miembro se pueden usar para agrupar clústeres y configurar la secuencia de actualizaciones con selectores de etiquetas de estilo de Kubernetes. De este modo, puede asignar varias etiquetas a los clústeres miembro y usarlas para diferentes estrategias en lugar de restringirse a un único grupo de actualizaciones por clúster. Puede agrupar clústeres en tu estrategia con sus etiquetas de miembro configurando memberSelector en tu estrategia a dos niveles:

• Nivel de fase: selecciona clústeres para toda la fase. Cuando no se definen grupos, todos los clústeres coincidentes forman un único grupo implícito. Cuando también se definen grupos, el selector de la fase actúa como filtro previo antes de aplicar la sincronización de grupos.
• Nivel de grupo: selecciona clústeres para un grupo específico dentro de una fase, lo que habilita subconjuntos paralelos con diferentes límites de simultaneidad.

memberSelector usa un selector de etiquetas basado en cadenas que se analiza mediante la sintaxis estándar del selector de etiquetas de Kubernetes. Los operadores admitidos son: =, ==, !=, in, notin, existsy !exists.

Para obtener instrucciones sobre cómo asignar etiquetas de miembro y usar memberSelector en una estrategia, consulte Creación de una estrategia de actualización mediante selectores de miembros.

Simultaneidad máxima (versión preliminar)

Maximum concurrency es una configuración opcional en la estrategia de actualización que controla el número de clústeres que se pueden actualizar simultáneamente. Puede establecer Maximum concurrency en dos niveles:

• Nivel de fase: define el número máximo de clústeres que se pueden actualizar al mismo tiempo en todos los grupos de una fase. Actúa como límite global para la etapa.
• Nivel de grupo: define el número máximo de clústeres que pueden actualizarse simultáneamente dentro de un grupo específico.

La concurrencia máxima acepta dos formatos de valor:

• Entero fijo: por ejemplo, "3" limita la simultaneidad a exactamente tres clústeres.
• Porcentaje: por ejemplo, "25%" limita la simultaneidad a un porcentaje de clústeres. Para la configuración a nivel de etapa, el porcentaje se calcula de todos los clústeres en la etapa. Para la configuración de nivel de grupo, el porcentaje se calcula a partir de los clústeres de ese grupo. Los porcentajes se calculan en tiempo de ejecución, se redondean hacia abajo y se aplican con un valor resuelto mínimo de 1.

Sugerencias para el control de concurrencia

Si desea actualizar con seguridad (menos velocidad, pero menos probable que termine con varios clústeres rotos): establezca la simultaneidad máxima en un valor más pequeño. Si desea actualizar con velocidad (más velocidad, pero es más probable que termine con varios clústeres rotos): establezca la simultaneidad máxima en un valor mayor.

Interacción de los límites de fase y grupo

La simultaneidad máxima de nivel de fase siempre actúa como límite máximo general. Incluso si los grupos individuales permiten una mayor simultaneidad, el límite de fases tiene prioridad. La simultaneidad de nivel de grupo puede ser inferior a la configurada debido al límite de nivel de fase, el tamaño del grupo o las condiciones específicas del miembro.

Ejemplo 1: Límites fijos

Resultado: hasta cuatro clústeres totales, con un máximo de dos por grupo.

Ejemplo 2: El límite de la etapa regula a los grupos

Resultado: Solo dos clústeres pueden actualizarse en total al mismo tiempo porque el límite de etapa tiene prioridad.

Ejemplo 3: lanzamiento basado en porcentajes

Una fase tiene 20 clústeres en dos grupos: Grupo A (ocho clústeres) y Grupo B (12 clústeres).

Resultado: hasta cinco actualizaciones simultáneas totales, distribuidas entre grupos según sus límites individuales.

Errores máximos permitidos (versión preliminar)

Maximum allowed failures es una configuración de estrategia de actualización opcional que controla cómo responde Fleet Manager a errores durante las actualizaciones de varios clústeres.

De forma predeterminada, las actualizaciones siguen un modelo rápido de error: un único error de clúster detiene más actualizaciones. Al configurar maximum allowed failures, la ejecución de la actualización se convierte en tolerante a errores y las actualizaciones continúan entre clústeres hasta que se alcanza el umbral de error especificado.

Esta configuración proporciona un equilibrio deliberado entre la detección temprana de errores y el mantenimiento del impulso de la implementación. Establezca maximum allowed failures en dos niveles:

• Nivel de fase: define el número máximo de errores de actualización de miembros tolerados en todos los grupos de una fase antes de que la fase se marque como errónea.
• Nivel de grupo: define el número máximo de errores de actualización de miembros tolerados dentro de un grupo específico antes de que el grupo se marque como erróneo.

Maximum allowed failures acepta dos formularios de valor:

• Entero fijo: Por ejemplo, "3" permite hasta tres fallos de clústeres miembros antes de que el grupo o la fase se marquen como fallidos.
• Porcentaje: por ejemplo, "25%" permite errores de hasta 25% de los clústeres miembro. Para la configuración a nivel de etapa, el porcentaje se calcula de todos los clústeres en la etapa. Para la configuración de nivel de grupo, el porcentaje se calcula a partir de los clústeres de ese grupo. Los porcentajes se resuelven cuando se crea la ejecución de la actualización mediante el redondeo al alza, por ejemplo, el 25 % de 5 clústeres se resuelve en 2.

Fleet Manager evalúa maxAllowedFailures únicamente en función del número de actualizaciones fallidas de miembros. No evalúa la tasa de éxito y no exige un número mínimo de miembros exitosos. Cuando esta configuración está presente, Completed significa que el umbral de error configurado no se superó en el momento en que Fleet Manager tomó sus decisiones de programación. Completed no significa que el despliegue se haya realizado sin problemas ni que haya tenido éxito.

Ejemplo: Completado con un 0 % de éxito

Supongamos que un grupo tiene cuatro miembros y group.maxAllowedFailures está establecido en "4". Si se produce un error en las cuatro actualizaciones de miembros, el grupo todavía se puede marcar como Completed. Este resultado es esperado e intencionado, no un error, porque cuatro errores son iguales a la tolerancia configurada y, por lo tanto, no supera el umbral. En otras palabras, un grupo puede ser Completed incluso cuando el 100 % de sus miembros fallaron.

Use solo este umbral cuando ese comportamiento coincida con las expectativas de lanzamiento.

Elección cuidadosa de los valores de umbral

• Los valores absolutos son fáciles de entender, pero pueden producir resultados contraintuitivos en grupos pequeños. Por ejemplo, permitir "2" fallos en un grupo de dos miembros significa que el grupo puede completarse Completed incluso si ningún miembro se completó correctamente.
• Los valores de porcentaje se escalan mejor entre diferentes tamaños de grupo, por lo que se recomiendan para la mayoría de los usuarios.
• Evite establecer maxAllowedFailures igual al número total de miembros, a menos que desee intencionadamente un comportamiento que, a todos los efectos, sea "no fallar nunca debido a errores de los miembros". Si ese comportamiento es intencionado, 100% normalmente se escala más claramente que un número fijo.
• Tenga especial cuidado con los grupos pequeños, donde un único fallo puede representar un gran porcentaje del despliegue.
• Vuelva a evaluar el umbral a medida que crece la flota. Un valor que se siente seguro para cinco clústeres puede ser demasiado estricto o demasiado permisivo para 500 clústeres.

Entender FailureCount

Los campos FailureCount son métricas de generación de informes. Cuentan las actualizaciones fallidas de miembros. No son ratios ni porcentajes, y no son iguales que el umbral de cumplimiento configurado.

• UpdateRun.FailureCount: total de actualizaciones de miembros fallidas en todas las fases y todos los grupos de la ejecución.
• Stage.FailureCount: Total de actualizaciones fallidas de miembros en todos los grupos de esa fase.
• Group.FailureCount: Total de actualizaciones fallidas de miembros en ese grupo.

Revise siempre estos recuentos junto con los estados de nivel de miembro, las condiciones y los mensajes de error antes de decidir si el resultado del lanzamiento es aceptable.

Por qué FailureCount puede superar maxAllowedFailures

maxAllowedFailures controla la toma de decisiones de Fleet Manager sobre si desea continuar programando el nuevo trabajo. No es un límite superior estricto del número final de fallos notificado.

Si permite las actualizaciones paralelas de miembros utilizando maxConcurrency, varios miembros pueden fallar casi al mismo tiempo antes de que Fleet Manager detecte que se ha superado el umbral y deje de programar más tareas. Como resultado, es posible y se espera FailureCount que sea mayor que el valor configurado maxAllowedFailures .

Cómo interactúan los límites de errores de fase y grupo

El nivel de grupo y el nivel maxAllowedFailures de fase se evalúan de forma independiente:

• Cada grupo realiza un seguimiento de su propio recuento de errores con su propio umbral.
• Esos mismos errores de grupo también se acumulan en la fase FailureCount.
• Si se supera cualquiera de los umbrales, Fleet Manager deja de programar un nuevo trabajo para ese segmento.
• Es posible que las actualizaciones de los miembros ya iniciadas puedan seguir completándose, lo que puede aumentar el valor final notificado FailureCount después de que se tome la decisión de detener.

El nivel maxAllowedFailures de fase actúa como límite general para la tolerancia a errores en una fase. Incluso si los grupos individuales permiten mayores recuentos de errores, el límite de fase tiene prioridad. Si el recuento de errores de un grupo supera su propio maxAllowedFailures, ese grupo se marca como erróneo independientemente de la configuración de nivel de fase.

Ejemplo 1: Límites de fallo fijos

Resultado: el grupo A tolera hasta dos errores y el grupo B tolera hasta tres. Si el total de errores en la fase supera los cinco, se produce un error en la fase.

Ejemplo 2: tolerancia basada en porcentajes

Una fase tiene 19 clústeres en dos grupos: Agrupación A con 7 clústeres y Grupo B con 12 clústeres.

Usos recomendados y no recomendados

Utilice umbrales más altos o basados en porcentajes cuando vaya a actualizar grandes flotas, se esperen algunos fallos transitorios o el progreso de implementación sea más importante que un comportamiento estricto de respuesta rápida a errores.

Use 0 o valores muy pequeños para implementaciones críticas para la seguridad, fases de producción estrictamente controladas o cualquier situación en la que deba detenerse e inspeccionarse tras el primer fallo.

Pasos siguientes

• Guía: Actualizar múltiples clústeres utilizando las ejecuciones de actualización de Azure Kubernetes Fleet Manager.
• Guía para actualizar automáticamente los clústeres múltiples mediante Azure Kubernetes Fleet Manager.
• Cómo supervisar las ejecuciones de actualizaciones para Azure Fleet Manager de Kubernetes.
• Preguntas más frecuentes sobre las actualizaciones de varios clústeres.