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.

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.

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

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:

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 30 días a partir de la eliminación de la versión para actualizar a una versión menor que esté admitida y 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 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 30 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.

¿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. Además, cuanto más alejada esté la versión del clúster de la versión mínima compatible, mayor será la probabilidad de que surjan problemas durante la actualización. En ese caso, la creación de un nuevo clúster y la migración de cargas de trabajo sería un mejor enfoque.

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

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

Si un clúster no es compatible con más de tres versiones secundarias y conlleva riesgos de seguridad, Azure se pone en contacto de forma proactiva con usted. Te aconsejan que actualices el clúster. Si no hace nada, Azure se reserva el derecho de actualizar automáticamente el clúster en su nombre.

¿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)
• Actualización de varios clústeres de AKS mediante Azure Kubernetes Fleet Manager