Versiones de Kubernetes compatibles en Azure Kubernetes Service (AKS)

La comunidad de Kubernetes publica versiones secundarias aproximadamente cada cuatro meses.

Las versiones secundarias incluyen nuevas características y mejoras. Las versiones de revisión son más frecuentes (a veces semanales) y están previstas para correcciones de errores críticos en una versión secundaria. Las versiones de revisión incluyen correcciones para vulnerabilidades de seguridad o errores importantes.

Versiones de Kubernetes

Kubernetes usa el esquema de versiones estándar de SemVer en todas las versiones:

[major].[minor].[patch]

Examples:
  1.29.2
  1.29.1

Cada número en la versión indica compatibilidad general con la versión anterior:

• Las versiones principales cambian cuando las actualizaciones de la API no son compatibles o la compatibilidad con versiones anteriores deja de funcionar.
• Las versiones secundarias cambian cuando se realizan actualizaciones de la funcionalidad que son compatibles las versiones anteriores de las restantes versiones secundarias.
• Las versiones de revisión cambian cuando se hacen correcciones de errores compatibles con versiones anteriores.

El objetivo es ejecutar la versión de revisión más reciente de la versión secundaria que se ejecuta. Por ejemplo, si el clúster de producción está en 1.29.1 y 1.29.2 es la versión de revisión más reciente disponible para la versión secundaria de 1.29, debe actualizar a 1.29.2 tan pronto como sea posible para asegurarse de que el clúster esté totalmente revisado y compatible.

Calendario de publicación de AKS Kubernetes

Vea las próximas versiones en el calendario de versiones de Kubernetes de AKS. Para ver las actualizaciones en tiempo real del estado de la versión de la región y las notas de la versión, visite la página web de estado de la versión de AKS. Para más información sobre la página web de estado de la versión, consulte Seguimiento de versiones de AKS.

Para ver el historial de versiones anteriores, consulte Historial de Kubernetes.

Versiones LTS

Diagrama de Gantt del calendario de lanzamiento programado de AKS Kubernetes

Si prefiere ver esta información visualmente, aquí tiene un diagrama de Gantt con todas las versiones actuales:

Cambios importantes en los componentes de AKS por versión

Tenga en cuenta los siguientes cambios importantes antes de actualizar a cualquiera de las versiones secundarias disponibles:

Kubernetes 1.30

Kubernetes 1.29

Kubernetes 1.28

Kubernetes 1.27

Versión secundaria del alias

AKS permite crear un clúster sin especificar la versión exacta del parche. Al crear un clúster sin designar un parche, el clúster ejecuta el parche GA más reciente de la versión secundaria. Por ejemplo, si crea un clúster con 1.29 y 1.29.2 es la revisión de disponibilidad general más reciente disponible, el clúster se creará con 1.29.2. Si desea actualizar la versión de revisión en la misma versión secundaria, use actualización automática.

Para ver qué revisión tiene, ejecute el comando az aks show --resource-group myResourceGroup --name myAKSCluster. La propiedad currentKubernetesVersion muestra toda la versión de Kubernetes.

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.eastus.azmk8s.io",
  "currentKubernetesVersion": "1.29.2",
}

Directiva de soporte técnico de versión de Kubernetes

AKS define una versión de disponibilidad general (GA) como una versión disponible en todas las regiones y habilitada en todas las mediciones de SLO o SLA. AKS es compatible con tres versiones secundarias en disponibilidad general de Kubernetes:

• La versión secundaria más reciente en disponibilidad general publicada en AKS (a la que nos referiremos como N).
• Dos versiones secundarias anteriores.
  • Cada versión secundaria compatible puede admitir cualquier número de revisiones en un momento dado. AKS se reserva el derecho de desaprobar revisiones si se detecta una vulnerabilidad crítica de CVE o de seguridad. Para conocer la disponibilidad de las revisiones y cualquier desuso ad hoc, consulte las notas de la versión y visite la página web de estado de la versión de AKS.

AKS también puede admitir versiones preliminares que se etiquetan explícitamente y están sujetas a los términos y condiciones de la versión preliminar.

AKS proporciona compatibilidad con la plataforma solo para una versión secundaria de disponibilidad general de Kubernetes después de las versiones compatibles normales. La ventana de compatibilidad de la plataforma de las versiones de Kubernetes en AKS se conoce como "N-3". Para obtener más información, consulte la directiva de soporte técnico.

La ventana admitida de las versiones secundarias de Kubernetes en AKS se conoce como "N-2", donde N hace referencia a la versión más reciente, lo que significa que también se admiten dos versiones secundarias anteriores.

Por ejemplo, en el día en que AKS presenta la versión 1.29, se proporciona compatibilidad con las versiones siguientes:

Cuando se publica una nueva versión secundaria, la versión secundaria más antigua cae en desuso y se quita. Por ejemplo, supongamos que la lista de versiones secundarias admitidas actual es:

1.29
1.28
1.27

Cuando AKS publica la versión 1.30, todas las versiones 1.27 salen del soporte técnico 30 días después.

AKS puede admitir cualquier número de revisiones en función de la disponibilidad de versiones de la comunidad ascendente para una versión secundaria determinada. AKS se reserva el derecho de desaprobar cualquiera de estas revisiones en un momento dado debido a un CVE o a un posible problema. Siempre se recomienda usar la revisión más reciente para una versión secundaria.

Directiva de soporte técnico de la plataforma

La directiva de soporte técnico de la plataforma es un plan de soporte técnico reducido para determinadas versiones de Kubernetes no admitidas. Durante el soporte técnico de la plataforma, los clientes solo reciben soporte técnico de Microsoft para problemas relacionados con la plataforma AKS/Azure. No se admiten los problemas relacionados con la funcionalidad y los componentes de Kubernetes.

La directiva de compatibilidad con la plataforma se aplica a los clústeres de una versión n-3 (donde n es la versión secundaria de AKS de disponibilidad general compatible más reciente), antes de que el clúster pase a n-4. Por ejemplo, Kubernetes v1.26 se considera compatible con la plataforma cuando la versión 1.29 es la versión más reciente en disponibilidad general. Sin embargo, durante la versión de disponibilidad general v1.30, la versión 1.26 se actualizará automáticamente a v1.27. Si ejecuta una versión de n-2, el momento en que se convierte en n-3, también queda en desuso y entra en la directiva de soporte técnico de la plataforma.

AKS se basa en las versiones y revisiones de Kubernetes, que es un proyecto de código abierto que solo admite una ventana deslizante de tres versiones secundarias. AKS solo puede garantizar compatibilidad total mientras esas versiones tienen servicio ascendente. Puesto que no se producen más revisiones ascendentes, AKS puede dejar esas versiones sin revisión o bifurcación. Debido a esta limitación, el soporte técnico para plataformas no admitirá nada que dependa directamente de Kubernetes ascendente.

En esta tabla se describen las directrices de soporte técnico para el soporte técnico de la comunidad en comparación con el soporte de la plataforma.

Versiones de kubectl admitidas

Puede usar una versión secundaria de kubectl que sea inmediatamente anterior o posterior a la versión de kubectl y que sea coherente con la directiva de compatibilidad de Kubernetes para kubectl.

Por ejemplo, si la versión de kube-apiserver es 1.28, puede usar las versiones de kubectl comprendidas entre 1.27 y 1.29 con esa versión de kube-apiserver.

Para instalar o actualizar kubectl a la versión más reciente, ejecute:

az aks install-cli

Install-AzAksKubectl -Version latest

Soporte técnico a largo plazo (LTS)

AKS proporciona un año de soporte técnico de la comunidad y un año de soporte técnico a largo plazo (LTS) para realizar correcciones de seguridad de puertos desde el nivel superior de la comunidad en nuestro repositorio público. Nuestro grupo de trabajo de LTS de nivel superior contribuye a los esfuerzos de la comunidad para proporcionar a nuestros clientes una ventana de soporte técnico más larga.

Para obtener más información sobre LTS, consulte Compatibilidad a largo plazo con Azure Kubernetes Service (AKS).

Proceso de publicación y desuso

Puede consultar las próximas publicaciones de versiones y las que se quedarán obsoletas en el Calendario de publicación de AKS Kubernetes.

En el caso de las nuevas versiones secundarias de Kubernetes:

• AKS publica un anuncio con la fecha prevista del lanzamiento de una nueva versión y la respectiva eliminación de la versión antigua en las Notas de lanzamiento de AKS al menos 30 días antes de la eliminación.
• AKS usa Azure Advisor para avisarle si una nueva versión puede causar problemas en su clúster debido a API obsoletas. Azure Advisor también le avisa si ya no tiene soporte técnico.
• AKS publica una notificación de estado del servicio disponible para todos los usuarios con acceso al portal y AKS, y envía un correo electrónico a los administradores de suscripciones con las fechas de eliminación de versión planeadas.

  Nota

  Para averiguar quién es el administrador de la suscripción o cambiarlo, consulte Administración de suscripciones de Azure.

• Tiene 30 días desde la eliminación de la versión para actualizar a una versión menor admitida para seguir recibiendo asistencia.

En el caso de las nuevas versiones de revisión de Kubernetes:

• Dada la naturaleza urgente de las versiones de revisión, se pueden introducir en el servicio en cuanto estén disponibles. Una vez disponibles, los parches tienen un ciclo de vida mínimo de dos meses.
• En general, AKS no difunde profusamente el lanzamiento de las versiones de revisión. Sin embargo, AKS supervisa y valida constantemente las revisiones de CVE disponibles para admitirlas en AKS de manera puntual. Si se encuentra una revisión crítica o se requiere una acción por parte del usuario, AKS le notifica para que actualice a la nueva revisión disponible.
• A partir de la retirada de una versión de revisión de AKS, dispone de 30 días para actualizar a una revisión compatible y seguir recibiendo asistencia. Sin embargo, una vez que la versión esté en desuso o se haya quitado, no podrá volver a crear clústeres o grupos de nodos.

Excepciones de directiva de versiones admitidas

AKS se reserva el derecho de agregar o eliminar las versiones nuevas o existentes con uno o varios problemas de seguridad o errores críticos que afecten a la producción sin previo aviso.

Se pueden omitir versiones de revisión concretas o se puede acelerar su lanzamiento en función de la gravedad del error o del problema de seguridad.

Versiones de Azure Portal y CLI

Cuando se implementa un clúster de AKS con Azure Portal, la CLI de Azure o Azure PowerShell, los valores predeterminados del clúster son la versión secundaria N-1 y la revisión más reciente. Por ejemplo, si AKS admite 1.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11, y 1.27.10, la versión predeterminada seleccionada es 1.28.7.

az aks get-versions --location eastus --output table

Get-AzAksVersion -Location eastus

Preguntas más frecuentes

¿Cómo me notifica Microsoft las nuevas versiones de Kubernetes?

El equipo de AKS publica anuncios con las fechas previstas de las nuevas versiones de Kubernetes en nuestra documentación, GitHub y en correos electrónicos a los administradores de suscripciones que poseen clústeres que van a dejar de recibir asistencia. AKS también usa Azure Advisor para alertarle dentro de Azure Portal si está fuera de soporte e informarle de las API obsoletas que pueden afectar a su aplicación o proceso de desarrollo.

¿Con qué frecuencia debo planear actualizar las versiones de Kubernetes para mantenerme con soporte técnico?

A partir de Kubernetes 1.19, la comunidad de código abierto ha ampliado el soporte técnico a 1 año. AKS se compromete a habilitar unas revisiones y un soporte técnico que cumplan los compromisos ascendentes. Para clústeres AKS en 1.19 y superiores, puede actualizar como mínimo una vez al año para permanecer en una versión compatible.

¿Qué ocurre cuando se actualiza un clúster Kubernetes con una versión menor no admitida?

Si está en el versión n-3 o anterior, está fuera del soporte técnico y se le pedirá que la actualice. Si la actualización de la versión n-3 a n-2 se completa correctamente, estará dentro de nuestras directivas de soporte técnico. Por ejemplo:

• Si la versión secundaria de AKS compatible más antigua es 1.27 y está en 1.26 o versiones anteriores, está fuera del soporte técnico.
• Cuando actualice correctamente 1.26 a 1.27 o superior, volverá a estar dentro de nuestras directivas de soporte técnico.

No se admiten cambios a una versión anterior.

¿Qué significa "fuera de soporte técnico"?

"Fuera del soporte técnico" significa lo siguiente:

• La versión que utiliza está fuera de la lista de versiones admitidas.
• Se le pedirá que actualice el clúster a una versión compatible cuando solicite soporte técnico, a menos que estén en el período de gracia de 30 días después de que la versión haya quedado en desuso.

Además, AKS no ofrece ningún entorno de ejecución ni otras garantías para los clústeres que estén fuera de la lista de versiones admitidas.

¿Qué ocurre cuando se escala un clúster de Kubernetes con una versión secundaria que no se admite?

Tanto la reducción como el escalado horizontales deberían seguir funcionando en las versiones secundarias que no son compatibles con AKS. Dado que no hay garantías con la calidad de servicio, se recomienda realizar la actualización para que el clúster vuelva tener soporte técnico.

¿Puede permanecer en una versión de Kubernetes para siempre?

Si un clúster ha estado sin soporte técnico durante más de tres (3) versiones secundarias y se ha descubierto que presenta riesgos para la seguridad, Azure se pondrá en contacto con usted de forma proactiva para que lo actualice con antelación. Si no hace nada, Azure se reserva el derecho de actualizar automáticamente el clúster en su nombre.

¿Qué ocurre si escala un clúster de Kubernetes con una versión secundaria que no se admite?

Tanto la reducción como el escalado horizontales deberían seguir funcionando en las versiones secundarias que no son compatibles con AKS. Dado que no hay garantías con la calidad de servicio, se recomienda realizar la actualización para que el clúster vuelva tener soporte técnico.

¿Qué versión admite el plano de control si el grupo de nodos no está en una de las versiones de AKS compatibles?

El plano de control debe estar dentro de una ventana de versiones de todos los grupos de nodos. Para obtener más información sobre la actualización del plano de control o de los grupos de nodos, visite la documentación sobre cómo actualizar grupos de nodos.

¿Cuál es la diferencia permitida en las versiones entre el plano de control y el grupo de nodos?

La directiva de asimetría de versiones de ahora permite una diferencia de hasta 3 versiones entre el plano de control y los grupos de agentes. AKS sigue este cambio de directiva de versión de asimetría a partir de la versión 1.28 en adelante.

¿Puedo saltarme varias versiones de AKS durante la actualización del clúster?

Cuando se actualiza un clúster de AKS compatible, no pueden omitirse las versiones secundarias de Kubernetes. La directiva de sesgo de versiones de los planos de control de Kubernetes no admite la omisión de versiones secundarias. Por ejemplo, las actualizaciones entre las siguientes versiones:

• 1.28.x ->1.29.x: permitida.
• 1.27.x ->1.28.x: permitida.
• 1.27.x ->1.29.x: no permitida.

Tenga en cuenta que para las actualizaciones de versión del plano de control, puede avanzar hasta tres versiones secundarias de las admitidas por la comunidad de forma secuencial.

Para actualizar de 1.27.x ->1.29.x:

1. Actualice desde 1.27.x ->1.28.x.
2. Actualice desde 1.28.x ->1.29.x.

Tenga en cuenta que a partir de la versión 1.28, las versiones de grupo de agentes pueden ser hasta tres versiones anteriores a las versiones del plano de control por directiva de sesgo de versiones. Cuando la versión es muy anterior a la versión mínima admitida, puede que tenga que realizar más de una operación de actualización del plano de control para llegar a la versión mínima admitida. Por ejemplo, supongamos que la versión actual del plano de control es la 1.23.x y quiere actualizar a una versión mínima admitida de 1.27.x. Puede que tenga que actualizar secuencialmente cuatro veces desde la versión 1.23.x para llegar a la 1.27.x. Tenga en cuenta también que las versiones del grupo de agentes se pueden actualizar hasta la versión secundaria del plano de control. Esto significa que, en el ejemplo anterior, puede actualizar la versión del grupo de agentes dos veces, es decir, una vez de 1.23.x a 1.25.x, cuando la versión del plano de control es la 1.25.x, y posteriormente desde la 1.25.x a la 1.27.x, cuando la versión del plano de control es la 1.27.x. Al actualizar en orden, es decir, el plano de control y el grupo de agentes conjuntamente, se aplican las mismas reglas que a la actualización del plano de control recogida anteriormente.

Al realizar una actualización desde una versión no admitida, la actualización se realiza sin ninguna garantía de funcionalidad y se excluye de los contratos de nivel de servicio y la garantía limitada. Los clústeres que ejecutan versiones no admitidas tienen la flexibilidad de desacoplar las actualizaciones del plano de control con las actualizaciones del grupo de nodos. Sin embargo, si la versión no está actualizada, se recomienda volver a crear el clúster.

¿Puedo crear un nuevo clúster 1.xx.x durante el período de soporte de la plataforma?

No, la creación de nuevos clústeres no es posible durante el período de soporte técnico de la plataforma.

Utilizo una versión que acaba de entrar en desuso y no tiene soporte de plataforma, ¿puedo seguir agregando nuevos grupos de nodos? ¿O tendré que actualizar?

Sí, puede agregar grupos de agentes siempre que sean compatibles con la versión del plano de control.

Pasos siguientes

Para obtener información sobre cómo actualizar el clúster, consulte:

• Actualización de un clúster de Azure Kubernetes Service (AKS)
• Actualización de varios clústeres de AKS mediante Azure Kubernetes Fleet Manager