Revertir las versiones del grupo de nodos en Azure Kubernetes Service (AKS)

La característica de reversión de versiones del grupo de nodos en Azure Kubernetes Service (AKS) permite recuperarse de comportamientos inesperados después de las actualizaciones de Kubernetes. Si se producen problemas, puede revertir los grupos de nodos a la combinación anterior de la versión y la imagen de nodo de Kubernetes, lo que garantiza la continuidad empresarial y minimiza el tiempo de inactividad. En este artículo se explica cuándo y cómo usar la característica de reversión, sus funcionalidades y limitaciones, y los procedimientos recomendados para las acciones posteriores a la reversión.

Prerrequisitos

  • CLI de Azure versión 2.88.0 o posterior. Busque la versión mediante el az --version comando . Si necesita instalar o actualizar, consulte Install CLI de Azure. La aks-preview extensión no es necesaria.
  • Versión 2026-04-01 de la API o posterior.

Características admitidas para la reversión de la versión del grupo de nodos

La característica de reversión de versiones del grupo de nodos admite las siguientes funcionalidades:

Característica Description
Revertir versión Restaura tanto las versiones de imágenes de Kubernetes como de nodo a su estado anterior.
Desencadenador manual, ejecución automática La reversión requiere el inicio manual, pero una vez desencadenado, el sistema controla automáticamente todo el proceso de reversión sin intervención adicional.
Compatibilidad del grupo de nodos Funciona en todos los tipos de grupos de nodos, incluidos los grupos de máquinas virtuales (VM) y los grupos de nodos basados en Virtual Machine Scale Sets (VMSS).
Compatibilidad con sistema operativo Compatible con todas las referencias de almacén (SKU) del sistema operativo (SKU), incluidos Ubuntu, Azure Linux y grupos de Windows.
Proceso simplificado No se requiere gestión de instantáneas.

Limitaciones y consideraciones de la reversión del grupo de nodos

Tenga en cuenta las siguientes limitaciones al usar la función de retroceso del grupo de nodos:

  • Limitado solo a cambios de versión. No se revierten otros cambios del grupo de nodos.
  • No se permiten operaciones simultáneas durante la reversión.
  • Debe deshabilitar el canal de actualización automática de Kubernetes antes de la reversión. Si el canal de actualización del sistema operativo del nodo está habilitado, la reversión de la versión de Kubernetes puede continuar, pero es posible que la imagen del nodo anterior no se restaure. Deshabilite el canal de actualización del sistema operativo del nodo cuando necesite revertir tanto la versión de Kubernetes como la imagen de nodo.
  • Disponible solo durante siete días después de la finalización de la actualización.
  • No se pueden realizar reversiones consecutivas para volver a varias versiones.
  • Rollback no admite la reversión de los cambios de SKU del sistema operativo. Si ha cambiado la SKU del sistema operativo del grupo de nodos (por ejemplo, de Ubuntu a Azure Linux), la reversión intenta restaurar la versión de la imagen de nodo anterior, que pertenece a una SKU de sistema operativo diferente y se rechaza. Para revertir un cambio de SKU del sistema operativo, use el az aks nodepool update --os-sku comando en su lugar.

Tenga en cuenta las siguientes consideraciones al usar la reversión del grupo de nodos:

Implicaciones de seguridad Consideraciones operativas
* Exposición a vulnerabilidades: la reversión elimina los parches de seguridad y las actualizaciones de la versión más reciente. Por lo tanto, se recomienda usar el rollback solo temporalmente mientras se resuelven los problemas y, a continuación, se actualiza nuevamente lo antes posible. * Interrupción del servicio: el proceso de reversión puede provocar interrupciones temporales de la carga de trabajo.
* Disponibilidad de recursos: asegúrese de que haya suficiente capacidad para la operación de reversión.
* Requisitos de prueba: planee corregir los problemas subyacentes antes de volver a intentar las actualizaciones.

¿Por qué usar la reversión?

La reversión proporciona un mecanismo de recuperación crítico para entornos de producción:

  • Continuidad empresarial: minimizar el tiempo de inactividad cuando las actualizaciones provocan problemas inesperados
  • Mitigación de riesgos: restauración rápida de configuraciones conocidas sin procedimientos de recuperación complejos
  • Recuperación simplificada: evitar la intervención manual o volver a generar clústeres a partir de copias de seguridad

Cuándo usar la reversión del grupo de nodos

Considere la posibilidad de revertir como opción de recuperación en los escenarios siguientes:

  • Se producen errores de actualización: los problemas de infraestructura, las restricciones de recursos o los problemas de compatibilidad impiden actualizaciones correctas.
  • Interrupción de aplicaciones: las cargas de trabajo experimentan errores críticos o daños en los datos con versiones más recientes de Kubernetes.
  • Degradación del rendimiento: las nuevas versiones provocan una latencia inaceptable, problemas de rendimiento o consumo de recursos.
  • Surgen brechas de pruebas: surgen problemas en producción que no se detectaron durante las pruebas de preproducción.

Flujo de trabajo de reversión del grupo de nodos

En el diagrama siguiente se muestra el flujo de trabajo de reversión del grupo de nodos:

Diagrama que muestra el flujo de trabajo de reversión del pool de nodos.

El proceso de reversión restaura todos los nodos de un grupo de nodos a su estado de versión anterior. Entre los aspectos clave del flujo de trabajo se incluyen:

  • Enfoque de todo o nada: todos los nodos deben revertir correctamente a la versión anterior para que la reversión se complete correctamente. Si falla la reversión de cualquier nodo, toda la operación falla para comunicar claramente el estado del clúster, como en la operación de actualización.
  • Seguimiento de progresos: Supervise el estado de reversión mediante el Registro de actividad de Azure para el historial de operaciones y la API de estado de la operación para actualizaciones en tiempo real.

Reversión de una versión del grupo de nodos

Importante

Tenga en cuenta la siguiente información al revertir una versión del grupo de nodos:

  • Mantenerse en versiones anteriores aumenta los riesgos de seguridad a largo plazo y podría evitar las actualizaciones debido a limitaciones de asimetría de versiones. Trate la reversión como un mecanismo de recuperación temporal, no una solución permanente.
  • La reversión reemplaza los nodos del grupo de nodos y puede interrumpir temporalmente las cargas de trabajo. Antes de empezar, compruebe que las cargas de trabajo tienen capacidad suficiente y que los presupuestos de interrupciones del pod permiten las interrupciones del nodo necesarias.
  • Al usar la API REST, puede llamar primero a los grupos de agentes: obtener la API de perfil de actualización para recuperar las versiones usadas recientemente. Use esta información para especificar la versión de destino en la solicitud de reversión.

El comando CLI de Azure reversión selecciona automáticamente la versión grabada más recientemente, también conocida como N-1. No puede usar el comando para seleccionar una versión arbitraria de la imagen de Kubernetes o de nodo, y no puede realizar reversiones consecutivas para pasar por varias versiones anteriores.

  1. Revise la configuración de actualización automática del clúster.

    az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query autoUpgradeProfile

    Deshabilite el canal de actualización automática de Kubernetes antes de la reversión. Si necesita restaurar la imagen de nodo anterior, deshabilite también el canal de actualización del sistema operativo del nodo.

  2. Revise el destino de reversión disponible mediante el az aks nodepool get-rollback-versions comando .

    az aks nodepool get-rollback-versions \
    --name myNodePool \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster

    Si el comando no devuelve ninguna versión, el grupo de nodos no tiene un destino de reversión apto. El grupo de nodos debe haberse actualizado en los siete días anteriores y AKS debe seguir admitiendo la versión de Kubernetes registrada.

  3. Revierte el grupo de nodos mediante el az aks nodepool rollback comando .

    az aks nodepool rollback \
    --name myNodePool \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster

  4. Compruebe la versión de Kubernetes, la versión de la imagen de nodo y el estado de aprovisionamiento una vez finalizada la reversión.

    az aks nodepool show \
    --name myNodePool \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --query '{provisioningState:provisioningState,kubernetesVersion:currentOrchestratorVersion,nodeImageVersion:nodeImageVersion}'

    Una reversión correcta devuelve SucceededprovisioningState y muestra las versiones grabadas de la imagen de Kubernetes y del nodo.

Si ha cambiado la configuración de actualización automática del clúster antes de la reversión, restaure la configuración prevista después de investigar y resolver el problema de actualización.

Supervisión del estado de reversión del grupo de nodos

Puede usar los métodos siguientes para supervisar el estado de una operación de reversión del grupo de nodos y validar una reversión correcta:

Solución de problemas de reversión del grupo de nodos

En la tabla siguiente se describen los problemas comunes de reversión y cómo resolverlos:

Cuestión Causa y resolución
No se devuelve ninguna versión de reversión. Es posible que el grupo de nodos no tenga ninguna actualización registrada, es posible que la ventana de reversión de siete días haya expirado o que ya no se admita la versión anterior de Kubernetes. Compruebe el historial de actualizaciones del grupo de nodos y la directiva de soporte técnico de la versión de Kubernetes de AKS.
AKS informa de que hay otra operación en curso. Espere a que finalice la operación actual del clúster o del grupo de nodos antes de reintentar la reversión. Si necesita detener la operación, use el az aks nodepool operation-abort comando .
La versión de Kubernetes se revierte, pero la imagen del nodo no lo hace. Es posible que el canal de actualización del sistema operativo del nodo esté habilitado. Deshabilite el canal cuando necesite restaurar la imagen de nodo anterior.
AKS rechaza la versión anterior de la imagen de nodo. Es posible que la SKU del sistema operativo del grupo de nodos haya cambiado desde la versión registrada. Rollback no admite la reversión de los cambios de SKU del sistema operativo. Use az aks nodepool update --os-sku para revertir la SKU del sistema operativo en su lugar.
AKS rechaza la versión anterior de Kubernetes. Es posible que ya no se admita la versión grabada. Compruebe la directiva de compatibilidad con la versión de Kubernetes de AKS.

Mejores prácticas posteriores a la reversión

Después de revertir correctamente el grupo de nodos, use los siguientes procedimientos recomendados para garantizar la estabilidad y la seguridad:

  • Investigue la causa principal: identifique por qué se produjo un error en la actualización antes de intentar otra actualización. Revise los registros de aplicaciones, las métricas de recursos y los requisitos de compatibilidad.
  • Prueba en no producción: valide la versión más reciente en un entorno de desarrollo o ensayo para reproducir y resolver problemas antes de volver a actualizar la producción.
  • Planificar la nueva actualización: no permanezca en la versión revertida indefinidamente. Programe una nueva actualización para mantener las revisiones de seguridad y el soporte técnico:
    • Para problemas de seguridad críticos: vuelva a actualizar en cuestión de días después de validar las correcciones.
    • Para problemas de compatibilidad de aplicaciones: vuelva a actualizar en un plazo de semanas después de los ajustes de código.
    • Período máximo recomendado: 30 días para evitar la acumulación de vulnerabilidades de seguridad.

Preguntas más frecuentes (FAQ)

¿Puedo realizar otras operaciones durante la reversión de un pool de nodos?

No, la reversión debe completarse antes de iniciar otras operaciones. Para realizar diferentes operaciones, primero cancele el rollback.

¿Con la reversión del grupo de nodos se revierte tanto la versión de Kubernetes como la imagen de nodo?

Sí, con la reversión se revierte a la versión de Kubernetes utilizada más recientemente y a su imagen de nodo correspondiente. Si ambos componentes han cambiado, el sistema restaura la versión anterior de Kubernetes con la última imagen de nodo compatible para esa versión.

¿Puedo revertir solo la imagen de nodo sin cambiar la versión del grupo de nodos?

Sí, si ha realizado solo una actualización de imagen de nodo en los últimos siete días (sin actualizar la versión del grupo de nodos), la reversión restaura la imagen anterior del disco duro virtual (VHD) al tiempo que mantiene la misma versión de Kubernetes.

¿Puedo revertir a una versión que no sea compatible?

No, no se puede revertir a una versión de Kubernetes que ya no sea compatible con AKS. Por ejemplo, si el grupo de nodos estaba en la versión 1.27.9 (ahora no es compatible) y actualizó a la versión 1.28.5, no puede revertir a la versión 1.27.9 porque ya no está en la lista de versiones admitidas. Compruebe siempre la directiva de compatibilidad de la versión de Kubernetes de AKS para comprobar la disponibilidad de la versión.

¿Es necesario deshabilitar la actualización automática antes de realizar un rollback del grupo de nodos?

Sí, debe deshabilitar el canal de actualización automática de Kubernetes antes de realizar una reversión. Si habilita solo el canal de actualización del sistema operativo del nodo, la reversión de la versión de Kubernetes puede continuar, pero es posible que la imagen de nodo anterior no se restaure. Deshabilite el canal de actualización del sistema operativo del nodo cuando necesite revertir tanto la versión de Kubernetes como la imagen de nodo.

Si el clúster se incluye en un grupo de actualizaciones en un perfil de degradación automática de Kubernetes Fleet Manager de Azure, también debe quitar el clúster del grupo de actualizaciones antes de realizar la reversión. De lo contrario, el proceso de actualización automática podría volver a actualizar el grupo de nodos una vez completada la reversión.

¿Puedo revertir después de cambiar la SKU del sistema operativo (por ejemplo, de Ubuntu a Azure Linux)?

N.º La reversión del grupo de nodos se limita a los cambios de versión y no revierte los cambios de la SKU del sistema operativo. Después de migrar de una SKU de sistema operativo a otra (por ejemplo, Ubuntu a Azure Linux), la versión de imagen del nodo anterior pertenece a la SKU del sistema operativo anterior y no es compatible con la configuración actual. La operación de reversión rechaza la versión de imagen anterior con un error similar al siguiente:

NodeImageVersion 'AKSUbuntu-2204gen2containerd-202602.13.5' is not accepted. NodeImageVersion can only be current version 'AKSAzureLinux-V3gen2-202602.13.5' or 'latest'

Para revertir la SKU del sistema operativo, utilice el comando az aks nodepool update con el parámetro --os-sku. Para obtener más información, consulte Revertir la versión del sistema operativo.

Contenido relacionado

Para más información sobre las actualizaciones del grupo de nodos en AKS, consulte los artículos siguientes:

  • Last updated on