Revisión y actualización de los nodos de trabajo y versiones de Kubernetes del Azure Kubernetes Service

En esta sección de la guía de operaciones de Azure Kubernetes Service (AKS) día 2 se describen las estrategias de revisión y actualización de los nodos de trabajo de AKS y las versiones de Kubernetes. Como operador de clúster, debe mantener sus clústeres al día y supervisar los cambios y obsolescencias de la API de Kubernetes a lo largo del tiempo.

Segundo plano y tipos de actualizaciones

Hay tres tipos de actualizaciones para AKS y cada uno se basa en la actualización anterior.

Tipo de actualización	Frecuencia de actualización	Soporte técnico de mantenimiento planeado	Métodos de operación admitidos	Destino	Documentación
Parches de seguridad del sistema operativo de nodo	Por la noche	Sí	Automático (semanal), manual/no administrado (nocturno)	Nodo	Actualizar automáticamente imágenes de nodo
Actualizaciones de la versión de la imagen de nodo	Linux: semanal Windows: Monthly	Sí	Automático, manual	Grupo de nodos	Actualización de imágenes de nodo de AKS
Actualizaciones de la versión (clúster) de Kubernetes	Trimestral	Sí	Automático, manual	Grupo de clústeres y nodos	Opciones de actualización para clústeres de AKS

Actualización de los tipos

Parches de seguridad del sistema operativo Node (solo Linux): Para nodos de Linux, Canonical Ubuntu y Azure Linux hacen que los parches de seguridad del sistema operativo estén disponibles una vez al día. Microsoft prueba y agrupa estas revisiones en las actualizaciones semanales de las imágenes de nodo.
Actualizaciones semanales de imágenes de nodo: AKS proporciona actualizaciones semanales de las imágenes de nodo. Estas actualizaciones incluyen los últimos parches de seguridad del sistema operativo y AKS, correcciones de errores y mejoras. Las actualizaciones de nodo no cambian la versión de Kubernetes. Las versiones de Linux tienen formato por fecha, por ejemplo, 202601.07.0. Las versiones de Windows están formateadas por la compilación del sistema operativo Windows Server y la fecha, por ejemplo, 20348.2113.260115. Para obtener más detalles, consulte Estado de la versión de AKS.
Versiones trimestrales de Kubernetes: AKS proporciona actualizaciones trimestrales para las versiones de Kubernetes. Estas actualizaciones proporcionan a los usuarios de AKS acceso a las últimas características y mejoras de Kubernetes, como las revisiones de seguridad y las actualizaciones de imágenes de nodo. Para obtener más información, consulte Versiones de Kubernetes compatibles en AKS.

Consideraciones anteriores a la actualización

Antes de actualizar los nodos de trabajo de AKS y las versiones de Kubernetes, tenga en cuenta los siguientes efectos y procedimientos recomendados.

Impacto general del clúster

Las actualizaciones locales de los nodos y clústeres afectan al rendimiento del entorno de Kubernetes mientras están en curso. Minimice este efecto a través de la configuración adecuada de los presupuestos de interrupciones de pods (PDB), la configuración de sobrecarga de nodo y el planeamiento adecuado.
Las estrategias de actualización azul-verde no afectan al rendimiento del clúster, pero aumentan el costo y la complejidad. Para obtener patrones detallados de implementación azul-verde en los niveles de clúster y pool de nodos, incluidas las implementaciones que utilizan Azure DNS, Azure Traffic Manager y Azure Front Door, consulte Implementación azul-verde de clústeres de AKS.

Independientemente de la estrategia de actualización y aplicación de revisiones, use un proceso de prueba y validación sólidos para el clúster. En primer lugar, aplique revisiones y actualice entornos inferiores y, a continuación, realice una validación posterior al mantenimiento para comprobar el estado de los clústeres, los nodos, la implementación y la aplicación.

Procedimientos recomendados de cargas de trabajo de AKS

Siga estos procedimientos recomendados para asegurarse de que el clúster de AKS funciona sin problemas durante el mantenimiento:

Definir archivos PDB. Es esencial configurar PDBs para tus implementaciones. Los PDB aplican un número mínimo de réplicas de aplicación disponibles para garantizar la funcionalidad continua durante los eventos de interrupciones. Los PDB ayudan a mantener la estabilidad del clúster durante los errores de mantenimiento o de nodo.

Advertencia

Los PDBs mal configurados podrían bloquear el proceso de actualización porque la API de Kubernetes impide el cordon necesario y el drain que se produce con una actualización de imagen de nodo progresiva. Además, se puede producir una interrupción de la aplicación si se mueven simultáneamente demasiados contenedores. La configuración de PDB adecuada mitiga este riesgo.
Active las medidas de seguridad de implementación. Las medidas de seguridad de implementación aplican los procedimientos recomendados de Kubernetes, como la validación de PDB, los límites de recursos, los sondeos de estado y las reglas de antiaffinidad. Las medidas de seguridad de implementación usan controles Azure Policy en la implementación para ayudar a garantizar que las cargas de trabajo estén configuradas correctamente antes de que comience una actualización.
Compruebe los límites de proceso y red disponibles. Compruebe los límites de proceso y red disponibles en la suscripción de Azure a través de la página quota en el portal de Azure o mediante el comando az quota. Compruebe los recursos de proceso y red, especialmente las CPU virtuales de máquina virtual (vCPU) de los nodos y el número de máquinas virtuales y conjuntos de escalado de máquinas virtuales. Si está cerca de un límite, solicite un aumento de cuota antes de actualizar.
Compruebe el espacio de direcciones IP disponible en subredes de nodo. Durante las actualizaciones, se crean nodos de sobrecarga adicionales en el clúster y los pods se mueven a estos nodos. Supervise el espacio de direcciones IP de las subredes del nodo para asegurarse de que haya suficiente espacio de direcciones IP para que se produzcan estos cambios. Las distintas configuraciones de red de Kubernetes tienen requisitos de direcciones IP diferentes. Para empezar, revise las consideraciones siguientes:
- Durante una actualización, el número de IP de nodo aumenta según el valor de sobrecarga. El valor mínimo de sobrecarga es 1.
- Los clústeres basados en Azure Container Networking Interface (CNI) asignan direcciones IP a pods individuales. Asegúrese de que hay suficiente espacio de direcciones IP para el movimiento del pod.
- El clúster sigue funcionando durante las actualizaciones. Asegúrese de que hay suficiente espacio de direcciones IP para el escalado de nodos.
Configure varios entornos. Configure varios entornos de Kubernetes, como el desarrollo, el almacenamiento provisional y los entornos de producción. Use estos entornos para probar y validar los cambios antes de moverlos a producción. La validación es especialmente importante cuando se mueve entre varias versiones de AKS, por ejemplo, de 1.32 a 1.34.
Planee y programe ventanas de mantenimiento. Los procesos de actualización pueden afectar al rendimiento general del clúster de Kubernetes. Programe procesos de actualización en contexto fuera de las ventanas de uso máximo mediante ventanas de mantenimiento y supervise el rendimiento del clúster para garantizar un ajuste de tamaño adecuado, especialmente durante los procesos de actualización.
Optimice los clústeres para el comportamiento de nodos no drenables. De forma predeterminada, si un nodo no se puede vaciar correctamente, el parcheo del clúster también fallará. Configure el cordón de purga de nodos para solucionar este problema. Este proceso pone en cuarentena los nodos no detectables para que el clúster pueda actualizarse correctamente y, de este modo, puede corregir manualmente los nodos que no se pudieron actualizar mediante la aplicación de revisiones o la eliminación de ellos. Puede configurar el parámetro --max-blocked-nodes para especificar cuántos nodos pueden dejar de drenarse antes de que se produzca un error en la actualización. Por ejemplo: az aks nodepool update --undrainable-node-behavior Cordon --max-blocked-nodes 2 --drain-timeout 30.
Utiliza la actualización forzada en escenarios de emergencia. Para la aplicación de revisiones de seguridad de emergencia, los operadores pueden usar la --enable-force-upgrade marca con --upgrade-override-until para omitir las protecciones de PDB y las comprobaciones de validación. Cuando se activa la actualización forzada, tiene prioridad sobre todas las demás configuraciones de drenaje, incluido el ajuste de comportamiento de nodo no purgable.

Importante

Use esta opción solo para escenarios de respuesta de vulnerabilidades y exposición comunes urgentes (CVE). Para más información, consulte Forzar la actualización de un clúster de AKS.
Ajuste los valores de actualización de sobrecarga. De manera predeterminada, AKS tiene un valor de sobrecarga de 1, lo que significa que se crea un nodo adicional a la vez como parte del proceso de actualización. Aumente la velocidad de una actualización de AKS aumentando este valor. El valor máximo de sobrecarga recomendado para las cargas de trabajo que son sensibles a las interrupciones es 33%. Para obtener más información, consulte Personalizar la actualización por aumento de nodos.
Ajuste el tiempo de espera de vaciado de nodos.El tiempo de espera de vaciado de nodos especifica la cantidad máxima de tiempo que un clúster espera mientras una carga de trabajo intenta reprogramar pods en un nodo que se está actualizando. El valor predeterminado es de 30 minutos. Si su carga de trabajo tiene dificultades para volver a programar pods, considere aumentar este valor.
Ajuste el tiempo de espera de inmersión del nodo. De forma predeterminada, la configuración de remojo del nodo continúa volviendo a restablecer el siguiente nodo después de que un nodo complete su proceso de actualización. Para determinadas cargas de trabajo heredadas o confidenciales, puede ayudar a agregar un retraso antes de continuar con el siguiente nodo. Agregue un retraso mediante la configuración de un tiempo de espera de remojo de nodo.
Compruebe otras dependencias del clúster. Los operadores de Kubernetes suelen implementar otras herramientas en el clúster de Kubernetes como parte de las operaciones, como escaladores de escalado automático controlados por eventos de Kubernetes (KEDA), Distributed Application Runtime (DAPR) y mallas de servicio. Cuando planifique sus procesos de actualización, compruebe las notas de lanzamiento de los componentes que utiliza para garantizar la compatibilidad con la versión objetivo.
Ajuste para configuraciones zonales AKS. En el caso de los clústeres de AKS zonales, la actualización por aumento podría dar lugar a una distribución temporalmente desequilibrada de cargas de trabajo entre zonas. Establezca el valor de sobrecarga en un múltiplo de 3, como 33%, para evitar este desequilibrio.

Administración de actualizaciones semanales de las imágenes de nodo

Microsoft crea una nueva imagen de nodo para los nodos de AKS aproximadamente una vez a la semana. Una imagen de nodo contiene actualizaciones al día de seguridad del sistema operativo, actualizaciones del kernel del sistema operativo, actualizaciones de seguridad de Kubernetes, binarios actualizados como kubelet, y actualizaciones de las versiones de componentes.

Cuando se actualiza una imagen de nodo, se desencadena una acción de cordón y purga en los nodos del grupo de nodos de destino:

Se agrega un nodo con la imagen actualizada al grupo de nodos. El valor de sobrecarga rige el número de nodos que se agregan al mismo tiempo.
Dependiendo del valor de sobrecarga, se acordona y purga un lote de nodos existentes. El cordón garantiza que el nodo no programe pods. La purga quita sus pods y los programa en otros nodos.
Una vez que estos nodos se hayan vaciado por completo, se eliminarán del grupo de nodos. Los nodos drenados se reemplazan por los nodos actualizados agregados por el incremento.

AKS repite este proceso para cada lote restante de nodos que requiere una actualización en el grupo de nodos. Se produce un proceso similar durante una actualización del clúster.

Actualizaciones automáticas de las imágenes de nodo

La mayoría de los clústeres deben usar el canal de actualización NodeImage. Este canal proporciona un disco duro virtual (VHD) de imagen de nodo actualizado cada semana. La imagen del nodo se actualiza según la ventana de mantenimiento del clúster.

Los canales disponibles son:

None. Las actualizaciones no se aplican automáticamente.
Unmanaged. El sistema operativo aplica las actualizaciones de Ubuntu y Azure Linux por la noche. Los arranques deben administrarse por separado. AKS no puede probar ni controlar la cadencia de estas actualizaciones.
SecurityPatch. El sistema operativo implementa revisiones de seguridad totalmente administradas y probadas por AKS mediante prácticas de implementación seguras. Esta revisión no contiene ninguna corrección de errores del sistema operativo. La revisión solo contiene actualizaciones de seguridad. Normalmente, el SecurityPatch canal aplica correcciones CVE en aproximadamente cinco días y restablece imágenes de nodos con menos frecuencia a través de la aplicación de revisiones en directo que NodeImage.
NodeImage. AKS actualiza los nodos semanalmente con un VHD recién revisado que contiene correcciones de seguridad y correcciones de errores. Estas actualizaciones se prueban e implementan completamente mediante prácticas de implementación seguras. Para obtener información en tiempo real sobre las imágenes de nodo implementadas actualmente, consulte Actualizaciones de imágenes de nodo de AKS.

Para obtener más información sobre las cadencias predeterminadas sin una ventana de mantenimiento establecida, consulte Actualizar la propiedad y la programación.

Si elige el canal de actualización Unmanaged, debe administrar el proceso de arranque mediante una herramienta como kured. El Unmanaged canal no incluye procedimientos de implementación seguros proporcionados por AKS y no funciona con ventanas de mantenimiento.
Si elige el canal de SecurityPatch actualización, puede instalar actualizaciones tan a menudo como semanalmente. Este nivel de revisión requiere que los VHD se almacenen en el grupo de recursos, lo que incurre en un cargo nominal. Establezca una aksManagedNodeOSUpgradeSchedule cadencia que funcione mejor para su carga de trabajo a fin de controlar cuándo se aplica SecurityPatch. Si también necesita correcciones de errores que suelen incluir nuevas imágenes de nodo (VHD), debe elegir el canal NodeImage en lugar de SecurityPatch.

Como procedimiento recomendado, use el NodeImage canal de actualización y configure una aksManagedNodeOSUpgradeSchedule ventana de mantenimiento durante el uso mínimo del clúster. Para ver los atributos para configurar la ventana de mantenimiento del clúster, consulte Creación de una ventana de mantenimiento. Los atributos clave son:

name. Use aksManagedNodeOSUpgradeSchedule para las actualizaciones del sistema operativo del nodo.
utcOffset. Configure la zona horaria.
startTime. Establezca la hora de inicio de la ventana de mantenimiento.
dayofWeek. Establezca los días de la semana para la ventana, como Saturday.
schedule. Establezca la frecuencia de la ventana. Para las actualizacionesde NodeImage, se recomienda weekly.
durationHours. Establezca este atributo en al menos cuatro horas.

En el ejemplo siguiente se establece una ventana de mantenimiento semanal a las 8:00 p. m. hora del este los sábados.

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

Lo ideal es implementar esta configuración como parte de la implementación de infraestructura como código (IaC) del clúster.

Para obtener más ejemplos, consulte Adición de una configuración de ventana de mantenimiento.

Compruebe si hay ventanas de mantenimiento configuradas mediante el Azure CLI.

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

Compruebe los detalles de una ventana de mantenimiento específica mediante la CLI.

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

Si no se configura una ventana de mantenimiento del clúster, las actualizaciones de imágenes de nodo se producen cada dos semanas. El mantenimiento de AKS se produce en la ventana configurada tanto como sea posible, pero no se garantiza el tiempo de mantenimiento.

Importante

Si tiene un grupo de nodos con muchos nodos y no está configurado con incremento de nodos, es posible que el evento de actualización automática no se desencadene. Las imágenes de nodo de un grupo de nodos solo se actualizan si el tiempo de actualización total estimado está en un plazo de 24 horas.

En esta situación, considere una de las siguientes opciones:

Divida los nodos en grupos de nodos diferentes si la cuota de vCPU está casi llena y no puede aumentar la cuota de vCPU.
Configure el incremento de nodos para reducir la duración estimada de la actualización si la cuota de vCPU es adecuada.

Para supervisar el estado de las actualizaciones automáticamente, use el administrador de comunicaciones de AKS para proporcionar alertas automáticas para las actividades de mantenimiento planeado. Como alternativa, supervise el estado de las actualizaciones a través de registros de actividad Azure Monitor o revise los registros de resource en el clúster a través de kubectl get events.

Suscríbase a eventos de actualización de AKS mediante Azure Event Grid para obtener eventos de actualización de AKS. Estos eventos pueden avisarle cuando hay disponible una nueva versión de Kubernetes y le ayudarán a realizar un seguimiento de los cambios de estado del nodo durante los procesos de actualización.

También puede administrar el proceso de actualización semanal mediante GitHub Actions. Este método proporciona un control más granular del proceso de actualización.

Otras herramientas de supervisión y observabilidad para las operaciones de actualización incluyen:

Diagnósticos de AKS. Seleccione Diagnose y resuelva problemas en el portal de Azure para obtener diagnósticos específicos sobre los errores de creación, lectura, actualización y eliminación de operaciones, problemas de actualización y estado del nodo.
Container Insights. Configure alertas de búsqueda de registros personalizadas en la tabla KubeEvents para eventos de actualización del componente de origen upgrader.
Azure Advisor. Advisor recomienda de forma proactiva las actualizaciones a medida que los clústeres se aproximan al final del soporte técnico y proporcionan recomendaciones de actualización y retirada del servicio.
El rastreador de versiones de AKS. Utilice el AKS release tracker para supervisar los lanzamientos de versiones en las regiones de Azure y rastrear la disponibilidad de imágenes de nodo en tiempo real.

Proceso de actualización manual de nodos

Puede usar el comando kubectl describe nodes para determinar la versión del kernel del sistema operativo y la versión de la imagen del sistema operativo de los nodos del clúster.

kubectl describe nodes <NodeName>

En la salida siguiente se muestra la información del sistema del nodo.

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             6.6.87.1-1.azl3
  OS Image:                   Microsoft Azure Linux 3.0
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.27
  Kubelet Version:            v1.33.1
  Kube-Proxy Version:         v1.33.1

Use el comando Azure CLI az aks nodepool list para determinar las versiones de imagen de nodo de los nodos de un clúster.

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

La siguiente salida muestra las versiones de la imagen de nodo.

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202601.13.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202601.13.0

Use el comando az aks nodepool get-upgrades para determinar la versión más reciente de la imagen de nodo disponible para un grupo de nodos específico.

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

La siguiente salida muestra las versiones más recientes de la imagen de nodo disponibles para el conjunto de nodos.

Name    NodeImageVersion
------  -------------------------------------
system  AKSAzureLinux-V3gen2-202601.13.0
user    AKSAzureLinux-V3gen2arm64-202601.13.0

Actualizaciones de clústeres

La Comunidad de Kubernetes publica versiones secundarias de Kubernetes aproximadamente cada tres meses. La página de notas de la versión de AKS se actualiza periódicamente con información sobre las nuevas versiones y lanzamientos de AKS. También puede suscribirse a la fuente RSS de AKS GitHub, que proporciona actualizaciones en tiempo real sobre los cambios y mejoras.

AKS sigue una directiva de soporte técnico N - 2 , lo que significa que se proporciona compatibilidad completa para la versión más reciente (N) y las dos versiones secundarias anteriores. Para la tercera versión secundaria anterior se ofrece compatibilidad limitada con la plataforma. Para obtener más información, consulte Directivas de soporte técnico para AKS.

Establezca un proceso de actualización continua del clúster para asegurarse de que los clústeres de AKS sigan siendo compatibles. Este proceso implica probar nuevas versiones en entornos inferiores y planear la actualización a producción antes de que la nueva versión se convierta en la predeterminada. Este enfoque ayuda a mantener la previsibilidad en el proceso de actualización y minimiza las interrupciones en las aplicaciones. Para más información, consulte Opciones de actualización para clústeres de AKS.

Si el clúster requiere un ciclo de actualización más largo, use versiones de AKS que admitan la opción de soporte técnico a largo plazo (LTS). Cada versión de Kubernetes de AKS compatible desde la versión 1.27 en adelante es apta para LTS de 24 meses a través del nivel Premium. LTS proporciona un ciclo de actualización más prolongado y controlado. Admite actualizaciones de versiones principales cada 24 meses en lugar del ciclo estándar de 12 meses. Para activar LTS, use --tier premium --k8s-support-plan AKSLongTermSupport.

Nota:

Durante la ventana LTS, solo se admiten las dos últimas versiones de revisión y se pueden aplicar algunas restricciones de compatibilidad de extensiones. Si usa LTS, considere la posibilidad de emparejarlo con el canal de actualización automática del patch clúster.

Para obtener más información, consulte Versiones de Kubernetes compatibles en AKS.

Una actualización del clúster incluye una actualización de nodo y usa un proceso de acordonamiento y purga.

Antes de actualizar

Como procedimiento recomendado, actualice y pruebe en entornos inferiores para minimizar el riesgo de interrupción en producción. Las actualizaciones de clúster requieren pruebas adicionales porque implican cambios de API, lo que puede afectar a las implementaciones de Kubernetes. Los siguientes recursos pueden ayudarle en el proceso de actualización.

AKS libro para LAS API en desuso: En la página de información general del clúster en el portal de Azure, Seleccione Diagnose y resuelva problemas, vaya a la Crear, Actualizar, Eliminar y Escalar y, a continuación, seleccione Kubernetes API en desuso. Este procedimiento ejecuta un libro de trabajo que comprueba si hay versiones de API en desuso que el clúster sigue usando. Para obtener más información, consulte Eliminación del uso de las API en desuso.
AKS release notes page: Esta página proporciona información completa sobre las nuevas versiones y versiones de AKS. Revise estas notas para mantenerse informado sobre las últimas actualizaciones y cambios.
Página de notas de la versión de Kubernetes: En esta página se proporciona información detallada sobre las versiones más recientes de Kubernetes. Preste especial atención a las notas urgentes de actualización. Resaltan información crítica que podría afectar al clúster de AKS.
Cambios significativos en los componentes de AKS por versión: Esta tabla proporciona una visión general completa sobre los cambios significativos en los componentes de AKS por versión. Solucione proactivamente los posibles problemas de compatibilidad antes del proceso de actualización haciendo referencia a esta guía.

Además de estos recursos de Microsoft, considere la posibilidad de usar herramientas de código abierto para optimizar el proceso de actualización del clúster. Por ejemplo, Fairwinds Pluto examina tus implementaciones y los charts de Helm en busca de API de Kubernetes en desuso. Estas herramientas pueden ayudarle a garantizar que las aplicaciones sigan siendo compatibles con las versiones más recientes de Kubernetes.

Proceso de actualización

Para comprobar si hay actualizaciones de clúster, use el comando az aks get-upgrades para obtener una lista de las versiones de actualización disponibles para el clúster de AKS. A partir de los resultados, determine la versión de destino del clúster.

El siguiente comando muestra las versiones de actualización disponibles.

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

En la salida siguiente se muestran las versiones de actualización de Kubernetes disponibles para el clúster.

MasterVersion  Upgrades
-------------  ---------------------------------
1.32.4         1.33.1, 1.33.2, 1.33.3

Para encontrar pools de nodos que necesitan una actualización, compruebe las versiones de Kubernetes de los nodos en sus pools de nodos.

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

En la salida siguiente se muestran las versiones de Kubernetes para cada grupo de nodos.

Name          K8version
------------  ------------
systempool    1.32.4
usernodepool  1.32.4

Actualizaciones manuales

Para minimizar las interrupciones y ayudar a garantizar una actualización sin problemas para el clúster de AKS, tome este enfoque de actualización:

Actualice el plano de control de AKS. Actualice los componentes del plano de control responsables de administrar y orquestar el clúster. Actualice primero el plano de control para ayudar a garantizar la compatibilidad y la estabilidad antes de actualizar los grupos de nodos individuales.
Actualice el grupo de nodos del sistema. Después de actualizar el plano de control, actualice el grupo de nodos del sistema en el clúster de AKS. Los grupos de nodos constan de las instancias de máquina virtual que ejecutan las cargas de trabajo de la aplicación. Actualice los grupos de nodos por separado para mantener el control y aplicar los cambios a la infraestructura subyacente que admita las aplicaciones.
Actualice los grupos de nodos de usuario. Después de actualizar el grupo de nodos del sistema, actualice los grupos de nodos de usuario en el clúster de AKS.

Siga este enfoque para minimizar las interrupciones durante el proceso de actualización y mantener la disponibilidad de las aplicaciones. Siga estos pasos:

Ejecute el comando az aks upgrade con la --control-plane-only marca para actualizar solo el plano de control del clúster y no los grupos de nodos del clúster.
```
az aks upgrade \
   --resource-group <ResourceGroupName> --name <AKSClusterName> \
   --control-plane-only \
   --kubernetes-version <KubernetesVersion>
```
Ejecute el comando az aks nodepool upgrade para actualizar grupos de nodos a la versión de destino.
```
az aks nodepool upgrade \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
   --no-wait --kubernetes-version <KubernetesVersion>
```
Durante la actualización del grupo de nodos, AKS crea un nodo de sobrecarga, acordona y purga pods en el nodo que se está actualizando, restablece la imagen inicial del nodo y, a continuación, descordona los pods. Este proceso se repite para los demás nodos del grupo de nodos.

Compruebe el estado del proceso de actualización ejecutando kubectl get events. Para más información sobre cómo solucionar problemas de actualización del clúster, consulte la documentación de solución de problemas de AKS.

Inscripción de clústeres en canales de actualización automática de versiones

AKS también proporciona una solución de actualización automática de clústeres para mantener el clúster actualizado. Si usa esta solución, adíle una ventana de mantenimiento para controlar el tiempo de actualización. La ventana de actualización debe ser de cuatro horas o más.

Al inscribir un clúster en un canal de versión, Microsoft administra automáticamente la cadencia de versión y actualización para el clúster y sus grupos de nodos.

La actualización automática del clúster proporciona diferentes opciones de canal de lanzamiento. En la tabla siguiente se muestra un entorno recomendado y una configuración del canal de lanzamiento.

Entorno	Canal de actualización	Descripción
Producción	`stable`	En el caso de la estabilidad y la madurez de la versión, use el canal estable o normal para cargas de trabajo de producción.
Almacenamiento provisional, pruebas, desarrollo	Igual que la producción	Use el mismo canal de lanzamiento que producción para garantizar que sus pruebas sean indicativas de la versión a la que va a actualizar el entorno de producción.
Valor controlado	`rapid`	Use el `rapid` canal para probar las versiones más recientes de Kubernetes y las nuevas características o API de AKS. Mejore su tiempo de llegada al mercado cuando la versión en `rapid` se promueva al canal que utiliza para producción.

Puede aplicar configuraciones de canal de actualización automática y de actualización automática del sistema operativo de nodo a través de su carga de trabajo mediante definiciones integradas de Azure Policy para AKS. Estas directivas pueden requerir que los clústeres usen un canal de actualización automática específico, apliquen canales de actualización automática del sistema operativo del nodo como SecurityPatch o NodeImagey requieran ventanas de mantenimiento planeado.

AKS Automatic

AKS Automatic es una experiencia de AKS totalmente administrada en la que Azure controla la configuración del clúster, la administración de nodos, el escalado y las actualizaciones automáticamente. AKS Automatic aplica de forma predeterminada la actualización automática a través del canal del clúster y el canal del sistema operativo del nodo NodeImage, emplea el aprovisionamiento automático para nodos dinámicos, e incluye protecciones de despliegue. Si la carga de trabajo necesita un modelo operativo que controle automáticamente la mayoría de las instrucciones de actualización manual de este artículo, considere la posibilidad de usar AKS Automatic como alternativa.

Actualizaciones de varios clústeres con Azure Kubernetes Fleet Manager

En el caso de las cargas de trabajo que administran varios clústeres de AKS, Azure Kubernetes Fleet Manager proporciona administración de actualizaciones orquestada en toda la flota. Fleet Manager proporciona:

Ejecuciones de actualizaciones en etapas. Defina las fases de actualización, como desarrollo, ensayo y producción, con períodos de espera configurables entre fases.
Actualizar grupos y estrategias. Cree estrategias de actualización reutilizables que definan el orden y el tiempo de las actualizaciones entre grupos de clústeres.
Perfiles de actualización automática. Configure perfiles de actualización automática de nivel de flota que apliquen directivas de actualización coherentes en todos los clústeres miembros.

Puede usar Fleet Manager para coordinar las actualizaciones de la imagen de nodo y la versión de Kubernetes en varios clústeres de AKS. Para obtener más información, consulte Orquestación de actualizaciones en varios clústeres de AKS mediante Fleet Manager.

Consideraciones

En la tabla siguiente se describen las características de varios escenarios de actualización y aplicación de revisiones de AKS.

Escenario	Iniciado por el usuario	Actualización de Kubernetes	Actualización del kernel del SO	Actualización de la imagen de nodo
Aplicación de revisiones de seguridad	No	No	Sí, después del arranque.	Sí
Creación de clústeres	Sí	Es posible	Sí, si una imagen de nodo actualizada usa un kernel actualizado.	Sí, con respecto a un clúster existente si hay disponible una nueva versión.
Actualización de Kubernetes del plano de control	Sí	Sí	No	No
Actualización de Kubernetes del grupo de nodos	Sí	Sí	Sí, si una imagen de nodo actualizada usa un kernel actualizado.	Sí, si hay disponible una nueva versión.
Ampliación de grupos de nodos	Sí	No	No	No
Actualización de la imagen de nodo	Sí	No	Sí, si una imagen de nodo actualizada usa un kernel actualizado.	Sí
Actualización automática del clúster	No	Sí	Sí, si una imagen de nodo actualizada usa un kernel actualizado.	Sí, si hay disponible una nueva versión.

Un parche de seguridad del sistema operativo que se aplica como parte de una actualización de la imagen de nodo podría instalar una versión más reciente del kernel que la que se instalaría al crear un nuevo clúster.
El escalado vertical del grupo de nodos usa el modelo asociado actualmente al conjunto de escalado de máquinas virtuales. Los kernels del sistema operativo se actualizan cuando se aplican las revisiones de seguridad y los nodos se reinician.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autor principal:

Anthony Nevico | Arquitecto principal de soluciones en la nube

Otros colaboradores:

Sam Cogan | Arquitecto sénior de soluciones en la nube
Rishabh Saha | Arquitecto principal de soluciones
Paolo Salvatori | Ingeniero principal de clientes, FastTrack para Azure
Ali Yousefi | Arquitecto de soluciones en la nube

Para ver perfiles de LinkedIn no públicos, inicie sesión en LinkedIn.

Pasos siguientes

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-03-06