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

Artículo
10/20/2024

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 la imagen del SO de nodo, o las versiones de Kubernetes) de forma segura y predecible. Para abordar este problema, Azure Kubernetes Fleet Manager (Fleet) le permite organizar las actualizaciones en varios clústeres mediante ejecuciones de actualización.

Las ejecuciones de actualizaciones constan de fases, grupos y estrategias y se pueden aplicar manualmente, para actualizaciones únicas, o automáticamente, para actualizaciones periódicas en curso mediante perfiles de actualización automática. Todas las ejecuciones de actualización (manuales o automáticas) respetan las ventanas de mantenimiento del clúster miembro.

Descripción de las ejecuciones de actualizaciones

En la imagen siguiente se visualiza una ejecución de actualización que contiene dos fases de actualización, cada una que contiene dos grupos de actualizaciones con dos clústeres de miembros. Se configura un período de espera entre las primeras y las segundas fases.

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 actualización describe el orden exacto para aplicar la actualización 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 actualización con fases y grupos y permite reutilizar una configuración de ejecución de actualización en lugar de definir la secuencia repetidamente en cada ejecución. Una estrategia de actualización no incluye versiones deseadas de la imagen de Kubernetes ni del nodo.

Actualmente, las operaciones de actualización admitidas en el clúster miembro son actualizaciones. Hay tres tipos de actualizaciones entre los 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).
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 especificar la versión exacta de la imagen del nodo de destino. Esto se debe a que la última versión de la imagen de nodo disponible puede variar según la región de Azure del clúster (consulte el rastreador de versiones de AKS para obtener más información).

Las versiones de imágenes de nodo de destino se seleccionan automáticamente según sus preferencias:

Latest: use las imágenes de nodo más recientes disponibles en la región de Azure de un clúster cuando se inicie la actualización del clúster. Como resultado, se podrían usar diferentes versiones de imagen en función de la región de Azure en la que se encuentra un clúster y cuándo se inicia realmente su actualización.
Consistent: cuando comienza la ejecución de actualización, selecciona las últimas versiones de imágenes comunes en las regiones de Azure de los clústeres miembro en esta ejecución, de modo que se usen las mismas versiones de imágenes consistentes 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:

Miembro con una ventana de mantenimiento en curso abierta.
Miembro con ventana de mantenimiento abierta en las próximas cuatro horas.
Miembro sin ventana de mantenimiento.
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: no se ha iniciado la ejecución de la actualización.
En ejecución: la actualización está en curso para al menos uno de los clústeres miembro de la ejecución de la actualización.
Pending:
- Clúster miembro: un clúster miembro puede estar en estado pendiente por cualquiera de los siguientes motivos que se pueden 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 Kubernetes de destino aún no está disponible en la región de Azure 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 de Azure 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 estado Pending si todos los miembros de los grupos están en estado Pending 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 Pending, el grupo se mueve al estado Pending. Si un grupo está en estado Pending, la ejecución de la actualización espera a que se complete el grupo antes de pasar a la siguiente fase para su ejecución.
- Fase: Una fase está en estado Pending si todos los grupos de esa fase están en estado Pending 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. Omitir puede ser sistema o iniciado por el usuario.
- Miembro:
  - Ha omitido la actualización de un miembro, un grupo o una fase.
  - 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. Por ejemplo, esto puede producirse cuando se agrega una nueva SKU de máquina virtual (VM) a un nuevo grupo de nodos 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), la ejecución de la actualización completa entra en un estado detenido. Las operaciones no se intentan para ningún clúster posterior en la ejecución de la actualización.
Error: un error al actualizar un clúster da como resultado 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.

Nota:

Puede volver a ejecutar una ejecución de actualización en cualquier momento para volver a aplicar las actualizaciones que pueden haberse omitido o con errores.

Descripción de los perfiles de actualización automática (versión preliminar)

Los perfiles de actualización automática se usan para desencadenar automáticamente las ejecuciones de actualización cuando se pone a disposición de AKS nuevas versiones de imágenes de Kubernetes o de nodo.

Importante

Las características en vista previa de Azure Kubernetes Fleet Manager están disponibles en autoservicio y de manera opcional. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y la garantía limitada. Las versiones preliminares de Azure Kubernetes Fleet Manager reciben cobertura parcial del soporte al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción.

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

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

Canal estable

El canal estable siempre es la versión de revisión de Kubernetes compatible con AKS más reciente en la versión secundaria N-1, donde N es la versión secundaria compatible más reciente.

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. Cualquier versión de revisión de la 1.30 intervalo menor se consideraría para las actualizaciones de canales estables. Cualquier clúster que haya recibido actualizaciones de 1.29 se actualizaría a la revisión más reciente de 1.30.

Canal rápido

El canal Rápido siempre es la versión secundaria de Kubernetes compatible con AKS más reciente.

Ejemplos:

La versión secundaria compatible más reciente es 1.30. Cualquier versión de revisión de la 1.30 intervalo menor se consideraría para las actualizaciones rápidas del canal.
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 1.30 se actualizaría a la revisión más reciente de 1.31 que ahora es el canal rápido.

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.

Si usa este canal, las actualizaciones desatendidas de Linux se deshabilitarán de forma predeterminada. 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 actualizarán 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.

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, se recomienda usar primero una o varias ejecución de actualizaciones para incorporar clústeres miembros a un conjunto de versiones coherentes para que las actualizaciones de canal configuradas Stable o Rapid garantizan que la coherencia se mantenga en el futuro.