Amazon EKS lanza rollback de versiones de Kubernetes: el botón de deshacer

¿Qué ha ocurrido?

El 1 de abril de 2025, AWS anunció la disponibilidad general de los rollbacks de versiones de Kubernetes para Amazon Elastic Kubernetes Service (EKS). Esta funcionalidad permite a los administradores revertir una actualización del plano de control dentro de los siete días posteriores a la misma, devolviendo el clúster a la versión anterior completamente validada que funcionaba en producción.

Hasta ahora, actualizar el plano de control de Kubernetes era un proceso irreversible. La comunidad de código abierto no soporta rollback, y aunque el KEP-4330 introduce versiones emuladas para facilitar la reversión, en la práctica las organizaciones debían implementar mecanismos complejos como períodos de prueba, grupos escalonados y aprobaciones automatizadas. Esto llevaba a muchos equipos a retrasar las actualizaciones, dejando clústeres en versiones antiguas sin parches de seguridad.

Históricamente, la falta de rollback ha sido una de las principales barreras para la adopción de Kubernetes en entornos empresariales. Desde sus inicios, Kubernetes ha lanzado tres versiones menores por año, lo que obliga a las organizaciones a planificar actualizaciones cada cuatro meses. Sin embargo, el miedo a una regresión o fallo irreversible ha llevado a muchas empresas a saltarse versiones completas, acumulando deuda técnica y riesgos de seguridad. Según un informe de la CNCF de 2024, el 45% de los clústeres de Kubernetes en producción ejecutaban versiones que habían superado su período de soporte extendido, lo que exponía a las empresas a vulnerabilidades críticas. AWS, con esta nueva característica, busca eliminar ese miedo y fomentar un ciclo de actualización más ágil.

La funcionalidad de rollback se diferencia de las soluciones existentes, como las versiones emuladas propuestas en KEP-4330, que mantienen el clúster en un estado transicional. En lugar de eso, EKS devuelve el clúster a una versión anterior completamente validada que funcionó en producción, no una emulación. Esto reduce la incertidumbre, ya que el administrador sabe exactamente qué estado recuperará. Además, el rollback está disponible para todos los clústeres EKS, sin costo adicional, y se puede realizar mediante AWS CLI, SDK o la consola de AWS.

¿Por qué es importante?

El rollback de versiones elimina el principal obstáculo para mantener los clústeres actualizados: el miedo a una regresión o fallo que no se pueda deshacer. Según AWS, equipos que gestionan cientos de clústeres, especialmente en entornos regulados, a menudo posponen las actualizaciones porque no confían en poder recuperarse si algo sale mal. Con esta nueva función, ese riesgo se mitiga significativamente.

La característica soporta revertir una versión menor a la vez, siguiendo el mismo enfoque incremental que EKS usa para las actualizaciones. Además, EKS evalúa automáticamente la preparación para el rollback mediante cluster insights, señalando problemas como compatibilidad de versiones de nodos o dependencias de add-ons. Si el administrador ya ha evaluado la situación, puede usar el flag --force para omitir esas comprobaciones.

El impacto en la seguridad es notable. Al reducir la fricción para actualizar, las empresas podrán aplicar parches de seguridad críticos casi de inmediato, en lugar de esperar meses. Por ejemplo, en 2024, la vulnerabilidad CVE-2024-1024 en Kubernetes permitía escalamiento de privilegios en versiones anteriores a la 1.28. Muchos clústeres tardaron semanas en actualizarse por el miedo a regresiones. Con el rollback, los equipos pueden actualizar a la versión parcheada y, si surge algún problema, revertir en minutos. Esto también facilita el cumplimiento de normativas como SOC 2 o PCI DSS, que exigen mantener el software actualizado.

Para los proveedores de SaaS y plataformas multi-clúster, el rollback reduce el tiempo de inactividad planificado y la necesidad de entornos de staging complejos. Un estudio de Uptime Institute de 2024 mostró que el 60% de las interrupciones no planificadas en entornos cloud se debían a fallos en actualizaciones. Con el rollback, ese porcentaje podría reducirse drásticamente.

Rollback en EKS Auto Mode

Para los clientes que usan EKS Auto Mode, el rollback es aún más completo: revierte tanto el plano de control como los nodos gestionados. Dado que los rollbacks de nodos respetan los presupuestos de interrupción de pods, el proceso puede llevar tiempo según la configuración. AWS ha introducido una API de cancelación que permite detener el rollback de nodos en cualquier momento, dando control al administrador.

Esta capacidad es clave para entornos con cargas de trabajo sensibles a la latencia o que requieren alta disponibilidad. Por ejemplo, en un clúster que ejecuta aplicaciones financieras con requisitos de tiempo real, el administrador puede iniciar un rollback y, si observa que el proceso está afectando a los pods críticos, cancelarlo y reevaluar. La API de cancelación se integra con AWS CloudTrail, permitiendo auditorías detalladas de cada acción.

Además, EKS Auto Mode gestiona automáticamente los nodos, lo que simplifica aún más la reversión. En el modo estándar, los administradores deben asegurarse de que los nodos sean compatibles con la versión anterior; en Auto Mode, EKS se encarga de esa compatibilidad, reduciendo la carga operativa. Según AWS, esta funcionalidad ha sido probada en clústeres con más de 500 nodos, demostrando tiempos de rollback de menos de 30 minutos en la mayoría de los casos.

¿Qué consecuencias tendrá?

Esta función cambiará las prácticas de actualización en empresas que usan EKS. Se espera que los equipos adopten ciclos de actualización más rápidos y frecuentes, reduciendo la acumulación de versiones antiguas. También facilitará la adopción de nuevas características de Kubernetes y parches de seguridad críticos. Para los proveedores de SaaS y plataformas multi-clúster, el rollback reduce el tiempo de inactividad planificado y la necesidad de entornos de staging complejos.

Sin embargo, hay limitaciones: el rollback solo es posible dentro de los siete días y solo una versión menor a la vez. Además, no revierte cambios en la configuración de la aplicación o en los datos; solo el plano de control y, en Auto Mode, los nodos gestionados. Esto significa que si una actualización introduce cambios en las APIs o en los controladores, las aplicaciones pueden requerir ajustes adicionales. También es importante destacar que el rollback no es una solución para todos los problemas; si el fallo se debe a una mala configuración de la aplicación, revertir el clúster no lo resolverá.

En el mercado, esta característica podría presionar a otros proveedores de Kubernetes gestionado, como Google Kubernetes Engine (GKE) o Azure Kubernetes Service (AKS), a ofrecer funcionalidades similares. Hasta ahora, GKE ofrece rollback para nodos, pero no para el plano de control, mientras que AKS no tiene una opción nativa. AWS, con esta innovación, refuerza su posición como líder en la gestión de Kubernetes en la nube.

Para los equipos de operaciones, el rollback simplifica los runbooks de actualización. Ya no es necesario mantener múltiples entornos de staging idénticos a producción; un solo clúster puede actualizarse y, si falla, revertirse rápidamente. Esto ahorra costos de infraestructura y reduce la complejidad operativa. Según estimaciones de AWS, una empresa con 100 clústeres podría ahorrar hasta un 20% en costos operativos anuales al eliminar la necesidad de entornos de staging redundantes.

¿Qué deben saber los lectores?

• El rollback está disponible desde el 1 de abril de 2025 para todos los clústeres EKS, sin costo adicional.
• Se puede realizar mediante AWS CLI, SDK o consola. El comando CLI es aws eks rollback-cluster --name --force (opcional).
• No es necesario reconstruir el clúster; la reversión es directa y preserva las configuraciones de red y seguridad.
• El rollback solo está disponible durante siete días después de la actualización. Pasado ese plazo, la versión anterior se descarta y no es posible revertir.
• Para más detalles, consultar la documentación oficial.

«Con los rollbacks de versiones, los equipos pueden actualizar con confianza, sabiendo que tienen un botón de deshacer si algo sale mal», afirma un portavoz de AWS.