Actualización de la orquestación entre varios clústeres de miembros

Los administradores de plataformas que administran un gran número de clústeres suelen tener problemas con el almacenamiento provisional de las actualizaciones de varios clústeres (por ejemplo, la actualización de versiones de imágenes de SO de nodo, la actualización de versiones de Kubernetes) de forma segura y predecible. Para solucionar este punto problemático, Azure Kubernetes Fleet Manager (Fleet) le permite organizar las actualizaciones en varios clústeres mediante ejecuciones de actualizaciones, fases, grupos y estrategias.

• Ejecución 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, que está formada por el objetivo y la secuencia de la actualización. El objetivo de la actualización describe las actualizaciones deseadas (por ejemplo, actualizar a la versión 1.28.3 de Kubernetes). La secuencia de la actualización describe el orden exacto en el que se aplican las actualizaciones a varios clústeres de miembros, expresados mediante fases y grupos. Si no se especifica, todos los clústeres de miembros se actualizan uno a uno secuencialmente. Se puede detener e iniciar una ejecución de actualización.
• Fase de actualización: las ejecuciones de actualización se dividen en fases, que se aplican secuencialmente. Por ejemplo, una primera fase de actualización puede actualizar los clústeres de miembros del entorno de prueba, y una segunda fase de actualización puede actualizar más tarde los clústeres de miembros del entorno de producción. Se puede especificar un tiempo de espera de retraso entre la aplicación de las siguientes fases de actualización.
• Grupo de actualizaciones: cada fase de actualización contiene uno o varios grupos de actualizaciones, que se utilizan para seleccionar los clústeres de miembros que se van a actualizar. Los grupos de actualizaciones también se utilizan para ordenar la aplicación de actualizaciones a los clústeres miembro. Dentro de una fase de actualización, las actualizaciones se aplican a todos los distintos grupos de actualizaciones en paralelo; dentro de un grupo de actualizaciones, los clústeres miembro se actualizan secuencialmente. Cada clúster miembro de la flota solo puede formar parte de un grupo de actualización.
• Estrategia de actualización: una estrategia de actualización describe la secuencia de actualizaciones con fases y grupos. Puede reutilizar una estrategia en sus ejecuciones de actualización, en lugar de definir la secuencia repetidamente en cada ejecución.

Actualmente, las operaciones de actualización admitidas en el clúster son las actualizaciones. Hay dos tipos de actualizaciones que puede elegir:

• Actualizar las versiones de Kubernetes para el plano de control y los nodos de Kubernetes (lo que incluye actualizar las imágenes de nodo).
• Actualizar solo las imágenes de nodo.

Puede especificar la versión de Kubernetes de destino que se va a actualizar, pero no puede especificar las versiones de imágenes de nodo de destino exactas, ya que las versiones de imágenes de nodo disponibles más recientes pueden variar en función de la región del clúster (consulte el seguimiento de versiones para obtener más información). Las versiones de imágenes de nodo de destino se seleccionan automáticamente según sus preferencias:

• Latest: utilice las imágenes de nodo más recientes disponibles en la región de un clúster cuando se inicie la actualización del clúster. Como resultado, se podrían utilizar diferentes versiones de imágenes, en función de la región en la que se encuentra un clúster y de cuándo se inicia realmente su actualización.
• Consistent: cuando se inicia la ejecución de la actualización, elige las versiones de imágenes más recientes comunes en las regiones de los clústeres miembro de esta ejecución, para que se utilicen las mismas versiones de imágenes coherentes en todos los clústeres.

Debe elegir Latest para utilizar las versiones de imágenes más recientes y minimizar los riesgos de seguridad, y elegir Consistent para mejorar la confiabilidad mediante la utilización y la comprobación de esas imágenes en clústeres en fases anteriores antes de usarlas en clústeres posteriores.

Mantenimiento planeado

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

Dentro de una ejecución de actualización (para ambos uno por uno o Fasesde ejecuciones de actualización de tipo), la ejecución de la actualización da prioridad a la actualización de los clústeres en el orden siguiente:

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

Actualizar estados de ejecución

Una ejecución de actualización puede estar en uno de los siguientes estados:

• NotStarted: Estado de la ejecución de la actualización antes de iniciarse.

• En ejecución: La actualización está en curso para al menos uno de los clústeres de la ejecución de la actualización.

• Pendiente:

  • Clúster miembro: Un clúster miembro puede estar en estado pendiente por cualquiera de los siguientes motivos y se muestra 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 Kubernetes de destino aún no está disponible en la región del miembro. El mensaje vincula al rastreador de versiones para que pueda comprobar el estado de la versión entre regiones.
    • La versión de la imagen del nodo de destino aún no está disponible en la región del miembro. El mensaje vincula al rastreador de versiones para que pueda comprobar el estado de la versión entre regiones.
  • Grupo: Un grupo está en Pending estado si todos los miembros de los grupos están en Pending estado o no se inician. Cuando un miembro se mueve a Pending, la ejecución de la actualización intentará actualizar el siguiente miembro del grupo. Si todos los miembros están en Pending estado, el grupo se mueve al estado Pending. Todos los grupos deben estar en estado terminal antes de pasar a la siguiente fase. Es decir, si un grupo está en Pending estado, la ejecución de la actualización espera a que se complete antes de pasar a la siguiente fase de ejecución.
  • Fase: Una fase está en Pending si todos los grupos de esa fase están en Pending estado o no se inician.
  • Ejecutar: Una ejecución se encuentra en Pending estado si la fase actual que se debe ejecutar está en Pending estado.

• Omitido: Se pueden omitir todos los niveles de una ejecución de actualización y esto podría ser detectado por el sistema o iniciado por el usuario.

  • Miembro:
    • Ha omitido la actualización de un miembro o de uno de sus elementos primarios.
    • El clúster miembro ya está en la versión de Kubernetes de destino (si el modo de ejecución de actualizaciones es Full o ControlPlaneOnly).
    • El clúster miembro ya está en la versión de Kubernetes de destino y todos los grupos de nodos están en la versión de la imagen del nodo de destino.
    • Cuando se elige una imagen de nodo coherente para una ejecución de actualización, si no es posible encontrar la versión de la imagen de destino para uno de los grupos de nodos, se omite la actualización para ese clúster. Una situación de ejemplo para esto es cuando se agrega un nuevo grupo de nodos con una nueva SKU de máquina virtual después de iniciar una ejecución de actualización.
  • Grupo:
    • El sistema detectó todos los clústeres de miembros como Skipped.
    • Ha iniciado una omisión en el nivel de grupo.
  • Fase:
    • El sistema detectó todos los grupos de la fase como Skipped.
    • Ha iniciado una omisión en el nivel de fase.
  • Ejecutar:
    • El sistema detectó todas las fases como Skipped.

• Detenido: Se pueden detener todos los niveles de una ejecución de actualización. Hay dos posibilidades para entrar en un estado detenido:

  • Detiene la ejecución de la actualización, en cuyo momento la ejecución de la actualización detiene el seguimiento de todas las operaciones. Si una operación ya se inició mediante la ejecución de la actualización (por ejemplo, una actualización del clúster está en curso), esa operación no se anula para ese clúster individual.
  • Si se produce un error durante la ejecución de la actualización (por ejemplo, se produjo un error en una de las actualizaciones en uno de los clústeres), toda la ejecución de actualización entra en un estado de detención y no se intenta operar para ningún clúster posterior en la ejecución de la actualización.

• Error: Un error al actualizar un clúster dará lugar a las siguientes acciones:

  • Marca el MemberUpdateStatus como Failed en el clúster miembro.
  • Marca todos los elementos primarios (grupo -> fase -> ejecutar) como Failed con un mensaje de error de resumen.
  • Detiene la ejecución de la actualización para continuar.

Pasos siguientes

• Orquestación de actualizaciones entre varios clústeres de miembros.