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 destinadas a corregir errores críticos en una versión menor. Las versiones de revisión incluyen correcciones para vulnerabilidades de seguridad o errores importantes.

Versiones de Kubernetes

Kubernetes usa el esquema de versionado estándar de Versionado Semántico para cada versión.

[major].[minor].[patch]

Cada número de la versión refleja la compatibilidad con versiones anteriores:

• Versiones principales: introduzca cambios de API incompatibles o interrumpa la compatibilidad con versiones anteriores.
• Versiones secundarias: agregue nuevas características. Las API estables suelen seguir siendo compatibles, pero las API y características en desuso se pueden quitar según la directiva de desuso de Kubernetes.
• Versiones de revisión: incluya correcciones de errores compatibles con versiones anteriores.

Siempre use la versión más reciente del parche para su versión menor actual. Cuando haya un parche posterior disponible para su versión secundaria, actualice a él lo antes posible para garantizar que su clúster esté completamente actualizado con todos los parches y tenga soporte.

Calendario de lanzamiento de Kubernetes de AKS y próximas versiones

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

La columna actualización iniciada por la plataforma muestra el mes de lanzamiento planeado para los clústeres que siguen ejecutando esa versión después del período de gracia de soporte técnico de la plataforma de 60 días. El mes enumerado es una estimación de planificación, no una fecha de actualización exacta para un clúster. Las actualizaciones pueden producirse durante o después del mes indicado, ya que AKS las limita por región, suscripción y versión. Las versiones incluidas en el lanzamiento inicial comparten un mes de lanzamiento de junio de 2027. Para obtener más información, consulte Actualizaciones iniciadas por la plataforma.

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

Versiones de LTS

Debe habilitar la compatibilidad a largo plazo (LTS) para obtener soporte extendido. Para obtener más información, consulte Activar compatibilidad a largo plazo.

En el caso de los clústeres LTS, el mes de actualización iniciado por la plataforma sigue el período de gracia de 60 días después de la fecha de finalización del ciclo de vida de LTS. AKS actualiza estos clústeres a la siguiente versión de LTS compatible. La inscripción en LTS nunca es automática. El mes enumerado es una estimación de planificación, no una fecha de actualización exacta para un clúster.

Diagrama de Gantt del calendario de lanzamiento programado de AKS Kubernetes

En el siguiente diagrama de Gantt se muestran 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.37

Kubernetes 1.36

Kubernetes 1.35

Kubernetes 1.34

Kubernetes 1.33

Kubernetes 1.32

Kubernetes 1.31

Kubernetes 1.30

Versión menor de alias en AKS

Puede crear un clúster de AKS sin especificar una versión de 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. Si desea actualizar la versión de revisión en la misma versión secundaria, use autoupgrade.

Para ver qué parche está instalado, ejecute el comando az aks show --resource-group myResourceGroup --name myAKSCluster. En la salida, la currentKubernetesVersion propiedad muestra toda la versión de Kubernetes. Por ejemplo:

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.eastus.azmk8s.io",
  "currentKubernetesVersion": "<major>.<minor>.<patch>",
}

Política de soporte de versiones 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 más reciente de GA (N).
• Las dos versiones secundarias anteriores (N-1 y N-2).
  • Cada versión secundaria compatible puede admitir cualquier número de parches simultáneamente. 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 política de soporte de la plataforma.

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 y 1.27. Cuando AKS lance la versión 1.30, todas las versiones 1.27 dejarán de recibir soporte técnico 30 días después y pasarán a soporte de plataforma.

AKS puede admitir cualquier número de revisiones en función de la disponibilidad de versiones de la comunidad upstream 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. Le recomendamos que use el parche más reciente para una versión menor.

Directiva de soporte técnico de la plataforma

La política de soporte de la plataforma es un plan de soporte reducido para ciertas versiones de Kubernetes que no son compatibles. 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. Supongamos que está ejecutando una versión N-2 . Cuando la versión se convierte en N-3, su soporte oficial también finaliza, y se aplica la política de soporte de la plataforma.

La compatibilidad con la plataforma proporciona un período de gracia de 60 días para actualizarse según sus propios términos. Cuando finaliza el período de gracia, AKS actualiza automáticamente el clúster a una versión compatible. Para obtener más información, consulte Actualizaciones iniciadas por 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 estén siendo atendidas por el proveedor original. 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 la tabla siguiente se describen las directrices de compatibilidad para el soporte técnico de la comunidad en comparación con la compatibilidad con la plataforma:

Actualizaciones iniciadas por la plataforma

AKS actualiza los clústeres que permanecen en una versión de Kubernetes no compatible después de que finalice el período de gracia de compatibilidad de la plataforma. Esta directiva garantiza que ningún clúster permanezca indefinidamente en una versión que ya no reciba revisiones de seguridad.

AKS actualiza el clúster a la versión más baja admitida dentro de su nivel de soporte técnico actual: los clústeres de soporte técnico de la comunidad se mueven a la versión secundaria de la comunidad compatible más baja y los clústeres LTS se mueven a la versión de LTS aplicable. AKS no inscribe los clústeres en LTS y no modifica tu nivel de facturación.

A diferencia de una actualización manual, una actualización automática del clúster o una ejecución de actualización de Fleet Manager, una actualización iniciada por la plataforma no sigue la ventana de mantenimiento y no ejecuta la comprobación de API en desuso. Mantener el clúster en una versión compatible es la única manera de evitar una actualización iniciada por la plataforma.

Para obtener la directiva completa, incluida la forma en que se le notifica y cómo prepararse, consulte Actualizaciones iniciadas por la plataforma.

Versiones de kubectl admitidas

Puede usar una versión kubectl que sea una versión secundaria anterior o posterior a la versión kube-apiserver. Para más información, consulte la directiva de compatibilidad de Kubernetes para kubectl.

Por ejemplo, si kube-apiserver está en la versión 1.28, puede usar las versiones 1.27 a 1.29 de kubectl.

Para instalar o actualizar kubectl a la versión más reciente, use el comando en función de la herramienta preferida:

az aks install-cli

Install-AzAksKubectl -Version latest

Soporte técnico a largo plazo (LTS)

AKS ofrece un año de soporte técnico de la comunidad y un año de soporte técnico a largo plazo (LTS), incluidas las correcciones de seguridad backported de la comunidad ascendente. 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 más información sobre LTS, consulte Compatibilidad a largo plazo con Azure Kubernetes Service (AKS).

Proceso de publicación y desuso

Para conocer las próximas versiones y las que quedarán obsoletas, consulta el calendario de lanzamientos de AKS Kubernetes.

En el caso de las nuevas versiones secundarias de Kubernetes:

• AKS anuncia las fechas de lanzamiento de la nueva versión y la desuso de la versión anterior en las notas de la versión 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 alerta si está fuera de soporte.

• 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.

  Note

  Para ver o cambiar los administradores de suscripciones, consulte Administración de suscripciones de Azure.

• Tiene un período de gracia de soporte técnico de 60 días después de la fecha de finalización del ciclo de vida publicada para actualizar a una versión secundaria compatible. La eliminación de la versión regional puede producirse en un momento diferente de la fecha de publicación. Si el clúster permanece en una versión no admitida después del período de gracia, AKS lo actualiza automáticamente. Para obtener más información, consulte Actualizaciones iniciadas por la plataforma.

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 comunica ampliamente el lanzamiento de las nuevas versiones de parches. 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 60 días para actualizar a una revisión compatible y seguir recibiendo asistencia. Sin embargo, ya no podrá crear clústeres o grupos de nodos una vez que la versión esté en desuso o se quite.

Excepciones de política de versiones compatibles

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

Si implementa un clúster de AKS mediante Azure portal, CLI de Azure o Azure PowerShell, el clúster tiene como valor predeterminado la versión secundaria N-1 y la revisión más reciente.

Para averiguar qué versiones están disponibles actualmente para su suscripción y región, use el comando en función de su herramienta preferida:

# The following example lists the available Kubernetes versions for the EastUS region:

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

# The following example lists the available Kubernetes versions for the EastUS region:

Get-AzAksVersion -Location eastus

Preguntas más frecuentes (FAQ)

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

El equipo de AKS anuncia nuevas fechas de lanzamiento de la versión de Kubernetes en nuestra documentación, en GitHub y por correo electrónico a los administradores de suscripciones con clústeres que están cerca del final del soporte técnico. 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.

Un clúster que ejecuta una versión no admitida también informa de un estado Degradado en Azure Resource Health y muestra un banner en el recurso de clúster en el portal de Azure, indicando cuándo AKS actualiza el clúster. Para obtener más información, consulte Actualizaciones iniciadas por la plataforma.

¿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 expandió el soporte técnico a un 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 la versión no es compatible según la lista de versiones de Kubernetes admitidas, debe actualizar. Puede actualizar desde versiones no admitidas a versiones admitidas. Por ejemplo:

• Si la versión secundaria de AKS más baja admitida es la 1.33 y está en la versión 1.32 o anterior, está fuera del soporte técnico.
• Si actualiza correctamente de la versión 1.32 a la 1.33 o posterior, vuelve a estar dentro de las directivas de soporte técnico.

No se admiten las degradaciones ni la reversión a una versión no compatible. Cuanto más se aleje la versión del clúster de la versión más baja admitida, más API eliminadas y complementos autoadministrados incompatibles podría tener que abordar antes de actualizar.

Si no actualizas, AKS actualizará el clúster por ti cuando finalice el periodo de gracia de soporte de plataforma. AKS actualiza el clúster una versión menor cada vez hasta que alcance una versión compatible. Para obtener más información, consulte Actualizaciones iniciadas por la plataforma.

¿Qué significa que sea "fuera del apoyo"?

"Fuera del soporte técnico" significa:

• La versión que utiliza está fuera de la lista de versiones admitidas.
• Se te pedirá que actualices el clúster a una versión compatible cuando solicites asistencia técnica, a menos que te encuentres dentro del periodo de gracia de 60 días de soporte de plataforma tras la obsolescencia de la versión.

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.

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

N. º Un clúster que permanezca en una versión sin soporte ya no recibirá parches de seguridad, por lo que AKS lo actualizará automáticamente cuando finalice el periodo de gracia de 60 días de soporte de la plataforma. Azure también le notifica a través de Azure Resource Health, Azure Advisor y correo electrónico antes de que se ejecute la actualización.

Para mantener el control, mantenga el clúster en una versión secundaria de la comunidad compatible o en una versión de soporte técnico a largo plazo (LTS) en la que se inscribe explícitamente. No hay opción de exclusión. Para obtener más información, consulte Actualizaciones iniciadas por la plataforma.

¿Qué ocurre si escalas un clúster de Kubernetes con una versión secundaria que no es compatible?

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 y todos los grupos de nodos deben mantenerse dentro del margen admitido de desfase entre versiones. A partir de Kubernetes 1.28, el plano de control puede tener hasta tres versiones secundarias antes de los grupos de nodos. Para más información, consulte las reglas de actualización de la versión de Kubernetes.

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

La directiva de asimetría de versiones ahora permite una diferencia de hasta tres 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 omitir varias versiones de AKS durante una actualización del clúster?

Sí, puede saltarse las versiones menores en algunos casos. Sin embargo, si actualiza el plano de control independientemente de los grupos de nodos, debe cumplir las políticas de desfase de versiones de Kubernetes. La directiva de diferencia de versiones de Kubernetes solo admite actualmente N-3, por lo que el plano de control y los grupos de agentes deben estar a una diferencia de N-3 entre sí.

• LTS: una versión con el plan de soporte técnico de AKS Long-Term habilitado. Consulte las versiones con soporte a largo plazo.
• LTS sin soporte: una versión con LTS habilitado que ha superado su fecha de fin de vida útil de LTS en la tabla versiones LTS.
• Versiones no LTS compatibles: una versión que no es LTS pero que sigue figurando como compatible en el calendario de lanzamientos de Kubernetes de AKS.
• Versión no LTS no compatible: una versión que no es LTS y que ya no figura como compatible en el calendario de versiones de Kubernetes para AKS.

Ejemplos:

• Si el clúster está en la versión 1.29 LTS y desea pasar a 1.32 LTS, puede omitir varias versiones secundarias siempre que AKS siga ofreciendo la versión 1.32 LTS y la actualización satisface las comprobaciones de asimetría de versiones y validación.
• Si el clúster está en 1.28 non-LTS, puede pasar a AKS LTS 1.30 LTS mediante la ruta de recuperación no admitida, siempre que la versión de destino esté incluida en la lista de AKS, cumpla las comprobaciones de validación y ejecute una actualización completa del clúster en lugar de control-plane-only.
• Si su clúster está en la versión no LTS compatible 1.33 y desea actualizar a la versión no LTS compatible 1.35, no puede pasar directamente de 1.33 a 1.35. Debe actualizar una versión secundaria a la vez, como 1.33 a 1.34 y, después, 1.34 a 1.35.

En la tabla anterior, indica que la ruta de actualización se ejecuta de manera que no se puede garantizar la seguridad y, por tanto, Unsupported recovery path se considera fuera del soporte técnico. AKS permite continuar con la actualización, pero esta no está admitida y podría conllevar riesgos.

Para elegir la ruta correcta, compruebe los destinos disponibles ejecutando az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>. Revise la tabla anterior y, a continuación, considere el riesgo de actualizar frente a volver a crear el clúster y migrar cargas de trabajo.

¿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.

Estoy en una versión recién en desuso que no es compatible con la plataforma. ¿Puedo agregar nuevos grupos de nodos o debo actualizar?

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

Contenido relacionado

Para obtener información sobre las actualizaciones del clúster de AKS, consulte:

• Actualización de un clúster de Azure Kubernetes Service (AKS)
• Actualizaciones iniciadas por la plataforma en AKS
• Actualización de varios clústeres de AKS mediante Azure Kubernetes Fleet Manager