La comunidad de Kubernetes publica una nueva versión secundaria aproximadamente cada cuatro meses. Container Service for Kubernetes (ACK) se alinea con este ciclo de publicación para gestionar el ciclo de vida de las versiones de Kubernetes, lo que incluye su creación, mantenimiento y fin de vida útil (EOL). Este documento describe la directiva de compatibilidad de ACK para las versiones de Kubernetes, y abarca sus publicaciones, ciclos de vida y soporte.
Historial de versiones
A continuación se enumeran las versiones de Kubernetes compatibles con los clústeres administrados de ACK managed cluster.
|
Versión |
Estado |
Fecha de publicación en ACK |
Fin de soporte en ACK |
|
Released |
Mayo de 2026 |
30 de mayo de 2027 |
|
|
Released |
Febrero de 2026 |
28 de febrero de 2027 |
|
|
Released |
Septiembre de 2025 |
30 de septiembre de 2026 |
Formato de versión
ACK utiliza el esquema de versiones x.y.z-aliyun.n, donde x.y.z corresponde a la versión comunitaria de Kubernetes (mayor.secundaria.parche) y n es la versión del parche de ACK.
Ciclo de vida de las versiones
Después de que la comunidad de Kubernetes publica una nueva versión secundaria, ACK realiza una evaluación de riesgos y ejecuta pruebas de consistencia. Por lo general, puede crear clústeres nuevos o actualizarlos a la nueva versión dentro de las dos semanas posteriores a la primera publicación de un parche comunitario.
Cuando la comunidad de Kubernetes publica una nueva versión de parche para una versión secundaria, ACK evalúa el nivel de riesgo de los problemas corregidos para determinar si debe publicar una actualización. En el caso de versiones de parche que corrigen vulnerabilidades de seguridad de alta gravedad, ACK suele completar su evaluación y publicar la nueva versión en un plazo de 24 horas.
Directiva de soporte
-
Cluster creation
ACK admite la creación de clústeres que ejecutan una de las tres versiones secundarias más recientes de Kubernetes. Por ejemplo, si las tres versiones secundarias más recientes son 1.35, 1.34 y 1.33, la creación de clústeres deja de estar disponible para la versión 1.32 una vez que ACK comienza a admitir la versión 1.35. La creación de clústeres tampoco está disponible para versiones de parche obsoletas.
Una vez que se publica una nueva versión de parche para una versión secundaria, la creación de clústeres deja de estar disponible para versiones de parche anteriores. Por ejemplo, después de publicar la versión 1.30.7, ya no puede crear clústeres que ejecuten la versión 1.30.1.
-
Cluster upgrade
Solo puede actualizar los clústeres de una versión secundaria a la siguiente. No se admiten las degradaciones ni omitir versiones secundarias.
En cuanto a las versiones de parche, solo puede actualizar a la versión de parche más reciente disponible. No se admiten actualizaciones a versiones de parche obsoletas.
-
Technical support
ACK proporciona soporte técnico, que incluye preguntas y respuestas, orientación en línea y resolución de problemas, para todas las versiones de Kubernetes en mantenimiento.
Riesgos de las versiones obsoletas
Ejecutar una versión obsoleta implica riesgos de seguridad y estabilidad. Cuando una versión deja de tener soporte, su clúster no recibe nuevas funciones, correcciones de bugs ni soporte técnico oportuno, y queda vulnerable a fallos de seguridad sin parches.
Debe actualizar su clúster a una versión segura y estable.
Manually upgrade a cluster: Actualice su clúster de una versión secundaria a la siguiente hasta llegar a la versión más reciente. Puede controlar el ritmo de la actualización si especifica los nodos por actualizar, establece el número máximo de nodos simultáneos por lote de actualización y configura los intervalos de actualización junto con las directivas de pausa.
Automatically upgrade a cluster: Habilite las actualizaciones automáticas del clúster y seleccione una frecuencia adecuada para mantener su clúster en un ciclo de actualización regular.
Actualizaciones forzadas para versiones obsoletas
Para las versiones de Kubernetes que superaron la ventana de soporte oficial, la comunidad de Kubernetes no divulga riesgos CVE ni proporciona parches. Es posible que los riesgos de seguridad potenciales en versiones obsoletas no se descubran o corrijan a tiempo. Dado que los clústeres de ACK utilizan una arquitectura administrada, estos riesgos de seguridad pueden afectar no solo a su clúster, sino también a la seguridad general de Alibaba Cloud. Por lo tanto, ACK no permite que los clústeres ejecuten versiones obsoletas durante períodos prolongados y realizará una actualización forzada a una versión segura y estable.
ACK no realiza una actualización forzada inmediatamente después de que la versión de un clúster quede obsoleta. Se recomienda actualizar manualmente su clúster a una versión compatible. Antes de ejecutar una actualización forzada, ACK enviará notificaciones por SMS, correo electrónico y mensajes internos con al menos un mes de anticipación.
Una actualización forzada incluye las siguientes acciones:
Actualizar cluster components. Solo se actualizan los componentes incompatibles con la nueva versión del clúster.
Actualizar el plano de control del clúster.
Actualizar los node pools y los nodos.
Las actualizaciones forzadas no se realizan en los siguientes casos. Debe realizar la actualización manualmente:
El clúster es un ACK dedicated cluster. Se recomienda migrar a un ACK Pro cluster. Para obtener más información, consulte Hot migrate an ACK dedicated cluster to an ACK Pro cluster.
El clúster ejecuta Kubernetes 1.22 y usa Docker como entorno de ejecución de contenedores. Debe migrar al entorno de ejecución containerd. Para obtener más información, consulte Migrate the node container runtime from Docker to containerd.
El controlador NGINX Ingress instalado es una versión anterior con problemas de compatibilidad respecto a la versión de destino de ACK. Para obtener detalles sobre los componentes, consulte el registro de cambios de NGINX Ingress controller.
Preguntas frecuentes
¿Puedo permanecer en una versión fija?
No. Los riesgos de seguridad potenciales en versiones obsoletas pueden afectar no solo a su clúster, sino también a la seguridad general de Alibaba Cloud. ACK no permite que los clústeres ejecuten versiones obsoletas durante períodos prolongados y realizará una actualización forzada a una versión segura y estable.
Actualice la versión de su clúster oportunamente (Manually upgrade a cluster) para aprovechar las funciones más recientes y el soporte técnico de ACK. Antes de actualizar, revise Release notes for Kubernetes versions supported by ACK para comprender los cambios en las funciones y las notas importantes de cada versión. Se recomienda habilitar automatic cluster upgrades para garantizar que su clúster se actualice periódicamente.
¿Cómo actualizar rápidamente un clúster antiguo?
Puede elegir una de las dos soluciones siguientes:
Solución 1: Actualizar de una versión a la siguiente. Después de cada actualización, supervise su clúster para asegurarse de que sus aplicaciones se ejecutan de forma estable antes de continuar con la siguiente actualización. Para obtener más información, consulte Manually upgrade a cluster.
Solución 2: Crear un nuevo clúster con la versión más reciente, migrar gradualmente sus aplicaciones al nuevo clúster y luego retirar el clúster antiguo. Para obtener información sobre cómo crear y configurar un clúster, consulte Create an ACK managed cluster.
¿Puedo omitir versiones secundarias al actualizar?
El plano de control no admite actualizaciones entre versiones secundarias no consecutivas. El node pool sí puede actualizarse a la versión del plano de control saltando versiones secundarias.
¿Cómo cambiar de Docker a containerd?
ACK ya no admite Docker como entorno de ejecución de contenedores integrado en Kubernetes v1.24 y versiones posteriores. Debe migrar el entorno de ejecución de contenedores de los nodos de Docker a containerd.
Puede realizar el cambio de entorno de ejecución en el node pool original mediante la función de actualización de node pools, o bien crear un nuevo node pool con containerd para llevar a cabo una migración progresiva. Para obtener más información, consulte Migrate the node container runtime from Docker to containerd.
¿Cómo garantiza ACK la estabilidad de las actualizaciones?
Un clúster de ACK consta de un plano de control y uno o más node pools.
Actualización del plano de control: ACK ofrece una comprobación previa a la actualización que inspecciona API obsoletas, compatibilidad de componentes, compatibilidad de configuraciones de funciones y problemas en los componentes del plano de control. Ejecutar esta comprobación no afecta el funcionamiento normal de sus aplicaciones. Si la comprobación reporta problemas, puede seguir las recomendaciones de corrección proporcionadas en la consola. Para obtener más información, consulte Manually upgrade a cluster.
-
Actualización del node pool: Una actualización de node pool incluye la actualización de kubelet y containerd. ACK ofrece una comprobación previa a la actualización que inspecciona el estado del nodo, los recursos del sistema, el estado del disco y el entorno de red. Ejecutar esta comprobación no afecta el funcionamiento normal de sus aplicaciones. Si la comprobación reporta problemas, puede seguir las recomendaciones de corrección proporcionadas en la consola.
También puede configurar una directiva de actualización personalizada. Por ejemplo, puede controlar el ritmo de la actualización si especifica qué nodos actualizar, establece el número máximo de nodos simultáneos por lote de actualización y configura una directiva de pausa. Si el disco del sistema de un nodo contiene datos importantes de aplicaciones, también puede crear una snapshot del disco del sistema antes de actualizar el node pool. Para obtener más información, consulte Upgrade a node pool.
Precauciones para la actualización
Las actualizaciones de clúster no se pueden revertir. Se recomienda actualizar primero un entorno de prueba y, tras una verificación exitosa, actualizar el entorno de producción. Durante el proceso de actualización, también puede upgrade some nodes first para fines de verificación.
Las versiones de componentes compatibles, las funciones y las API obsoletas varían según la versión de Kubernetes. Para obtener más información, consulte Release notes for Kubernetes versions supported by ACK correspondiente a cada versión.
Documentos relacionados
Para obtener información sobre las actualizaciones de clúster, incluidos impactos, procedimientos, precauciones y métodos de actualización, consulte Upgrade clusters.
Para obtener información sobre los tipos de SO y las versiones de imagen que admite ACK, consulte OS image release notes.
Para obtener información sobre las correcciones de CVE y las soluciones correspondientes proporcionadas por ACK, consulte Fix CVEs.
Para obtener información sobre las comprobaciones previas a la actualización y las API obsoletas, consulte Cluster check items and remediation solutions.
Los ACK Pro cluster mejoran los clústeres básicos con mayor confiabilidad y seguridad para entornos de producción empresarial a gran escala, y cuentan con un SLA compensable. Si necesita migrar, consulte Hot migrate ACK managed basic clusters to ACK Pro clusters.