Versiones de Kubernetes compatibles en Azure Kubernetes Service (AKS)

  • Artículo

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.

Nota

AKS mantiene 12 meses de soporte técnico para una versión de Kubernetes de disponibilidad general (GA). A fin de obtener más información sobre nuestra directiva de soporte técnico para el control de versiones de Kubernetes, lea nuestras Preguntas más frecuentes.

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

Versión de K8s Versión anterior Versión preliminar de AKS Disponibilidad general de AKS Final de la vida útil Compatibilidad con plataformas
1,26 Diciembre de 2022 Febrero de 2023 Abril de 2023 Marzo de 2024 Hasta la versión 1.30 de disponibilidad general
1.27* Abril de 2023 Junio de 2023 jul. de 2023 Julio de 2024, LTS hasta julio de 2025 Hasta la versión 1.31 de disponibilidad general
1.28 agosto de 2023 Set. de 2023 Nov. de 2023 Noviembre de 2024 Hasta la versión 1.32 de disponibilidad general
1.29 Dic. de 2023 Feb. de 2024 Marzo de 2024 Hasta la versión 1.33 de disponibilidad general
1.30 Abril de 2024 Mayo de 2024 Junio de 2024 Hasta la versión 1.34 de disponibilidad general

* Indica que la versión se designa para soporte técnico a largo plazo

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:

Diagrama de Gantt que muestra el ciclo de vida de todas las versiones de Kubernetes actualmente activas en AKS.

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:

Versión de Kubernetes Complementos administrados de AKS Componentes de AKS Componentes del sistema operativo Últimos cambios Notas
1,26 Directiva de Azure 1.3.0
Metrics-Server 0.6.3
KEDA 2.10.1
Open Service Mesh 1.2.3
Core DNS V1.9.4
Superponer VPA 0.11.0
Azure-Keyvault-SecretsProvider 1.4.1
Controlador de entrada de Application Gateway (AGIC) 1.5.3
Image Cleaner v1.2.3
Identidad de carga de trabajo de Azure v1.0.0
MDC Defender 1.0.56
Identidad de pod de Azure Active Directory 1.8.13.6
GitOps 1.7.0
KMS 0.5.0
azurefile-csi-driver 1.26.10
 Cilium 1.12.8
CNI 1.4.44
Escalador automático de clústeres 1.8.5.3
 Imagen del sistema operativo Ubuntu 22.04 Cgroups V2
ContainerD 1.7
Azure Linux 2.0
Cgroups V1
ContainerD 1.6
 azurefile-csi-driver 1.26.10 None
1.27 Directiva de Azure 1.3.0
azuredisk-csi driver v1.28.5
azurefile-csi driver v1.28.7
blob-csi v1.22.4
csi-attacher v4.3.0
csi-resizer v1.8.0
csi-snapshotter v6.2.2
snapshot-controller v6.2.2
Metrics-Server 0.6.3
Keda 2.11.2
Open Service Mesh 1.2.3
Core DNS V1.9.4
Superponer VPA 0.11.0
Azure-Keyvault-SecretsProvider 1.4.1
Controlador de entrada de Application Gateway (AGIC) 1.7.2
Image Cleaner v1.2.3
Identidad de carga de trabajo de Azure v1.0.0
MDC Defender 1.0.56
Identidad de pod de Azure Active Directory 1.8.13.6
GitOps 1.7.0
azurefile-csi-driver 1.28.7
KMS 0.5.0
Controlador de almacén de secretos CSI 1.3.4-1
 Cilium 1.13.10-1
CNI 1.4.44
Escalador automático de clústeres 1.8.5.3
 Imagen del sistema operativo Ubuntu 22.04 Cgroups V2
ContainerD 1.7 para Linux y 1.6 para Windows
Azure Linux 2.0
Cgroups V1
ContainerD 1.6
 Keda 2.11.2
Cilium 1.13.10-1
azurefile-csi-driver 1.28.7
azuredisk-csi driver v1.28.5
blob-csi v1.22.4
csi-attacher v4.3.0
csi-resizer v1.8.0
csi-snapshotter v6.2.2
snapshot-controller v6.2.2		 Debido al estado de certificación FIPS de Ubuntu 22.04, cambiaremos los nodos FIPS de AKS de 18.04 a 20.04 desde la versión 1.27 en adelante.
1.28 Directiva de Azure 1.3.0
azurefile-csi-driver 1.29.2
csi-node-driver-registrar v2.9.0
csi-livenessprobe 2.11.0
azuredisk-csi-linux v1.29.2
azuredisk-csi-windows v1.29.2
csi-provisioner v3.6.2
csi-attacher v4.5.0
csi-resizer v1.9.3
csi-snapshotter v6.2.2
snapshot-controller v6.2.2
Metrics-Server 0.6.3
KEDA 2.11.2
Open Service Mesh 1.2.7
Core DNS V1.9.4
Superponer VPA 0.13.0
Azure-Keyvault-SecretsProvider 1.4.1
Controlador de entrada de Application Gateway (AGIC) 1.7.2
Image Cleaner v1.2.3
Identidad de carga de trabajo de Azure v1.2.0
Publicador de seguridad de MDC Defender 1.0.68
Controlador de almacén de secretos CSI 1.3.4-1
Limpiador de archivos antiguos de MDC Defender 1.3.68
Recopilador de pods de MDC Defender 1.0.78
Recopilador de bajo nivel de MDC Defender 1.3.81
Identidad de pod de Azure Active Directory 1.8.13.6
GitOps 1.8.1		 Cilium 1.13.10-1
CNI v1.4.43.1 (valor predeterminado)/v1.5.11 (Superposición de Azure CNI)
Escalador automático de clústeres 1.27.3
Tigera-Operator 1.28.13		 Imagen del sistema operativo Ubuntu 22.04 Cgroups V2
ContainerD 1.7.5 para Linux y 1.7.1 para Windows
Azure Linux 2.0
Cgroups V1
ContainerD 1.6
 azurefile-csi-driver 1.29.2
csi-resizer v1.9.3
csi-attacher v4.4.2
csi-provisioner v4.4.2
blob-csi v1.23.2
controlador azurefile-csi v1.29.2
controlador azuredisk-csi v1.29.2
csi-livenessprobe v2.11.0
csi-node-driver-registrar v2.9.0		 None
1.29 Directiva de Azure 1.3.0
csi-provisioner v4.0.0
csi-attacher v4.5.0
csi-snapshotter v6.3.3
snapshot-controller v6.3.3
Metrics-Server 0.6.3
KEDA 2.11.2
Open Service Mesh 1.2.7
Core DNS V1.9.4
Superponer VPA 0.13.0
Azure-Keyvault-SecretsProvider 1.4.1
Controlador de entrada de Application Gateway (AGIC) 1.7.2
Image Cleaner v1.2.3
Identidad de carga de trabajo de Azure v1.2.0
Publicador de seguridad de MDC Defender 1.0.68
Limpiador de archivos antiguos de MDC Defender 1.3.68
Recopilador de pods de MDC Defender 1.0.78
Recopilador de bajo nivel de MDC Defender 1.3.81
Identidad de pod de Azure Active Directory 1.8.13.6
GitOps 1.8.1
Controlador de almacén de secretos CSI 1.3.4-1
azurefile-csi-driver 1.29.3
 Cilium 1.13.5
CNI v1.4.43.1 (valor predeterminado)/v1.5.11 (Superposición de Azure CNI)
Escalador automático de clústeres 1.27.3
Tigera-Operator 1.30.7
 Imagen del sistema operativo Ubuntu 22.04 Cgroups V2
ContainerD 1.7.5 para Linux y 1.7.1 para Windows
Azure Linux 2.0
Cgroups V1
ContainerD 1.6
 Tigera-Operator 1.30.7
csi-provisioner v4.0.0
csi-attacher v4.5.0
csi-snapshotter v6.3.3
snapshot-controller v6.3.3		 None

Versión secundaria del alias

Nota:

La versión secundaria del alias requiere la versión 2.37 o posterior de la CLI de Azure, así como la versión de API 20220401 o superior. Use az upgrade para instalar la versión más reciente de la CLI.

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 también admite un máximo de dos revisiones estables.

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.

Nota

AKS usa prácticas de implementación segura que implican la implementación gradual de regiones. Esto significa que pueden pasar hasta 10 días hábiles hasta que haya una nueva versión disponible en todas las regiones.

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:

Nueva versión secundaria Lista de versiones secundarias admitidas
1.29 1.29, 1.28, 1.27

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 también admite un máximo de dos versiones de revisión de una versión menor determinada. Por ejemplo, dadas las siguientes versiones admitidas:

Current Supported Version List
------------------------------
1.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11, 1.27.10

Si AKS publica 1.29.3 y 1.28.8, las versiones de revisión más antiguas quedan en desuso y se eliminan, y la lista de versiones admitidas pasa a ser:

New Supported Version List
----------------------
1.29.3, 1.29.2, 1.28.8, 1.28.7, 1.27.11, 1.27.10

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.

Categoría de soporte técnico Soporte técnico de la comunidad (N-2) Compatibilidad con la plataforma (N-3)
Actualizaciones de N-3 a una versión compatible Compatible Compatible
Disponibilidad de la plataforma (Azure) Compatible Compatible
Escalado de grupos de nodos Compatible Compatible
Disponibilidad de máquinas virtuales Compatible Compatible
Problemas relacionados con el almacenamiento y las redes Compatible Se admite excepto para correcciones de errores y componentes retirados.
Arranque/parada Compatible Compatible
Rotación de certificados Compatible Compatible
Acuerdo de Nivel de Servicio de infraestructura Compatible Compatible
Acuerdo de Nivel de Servicio del plano de control Compatible Compatible
Acuerdo de Nivel de Servicio de plataforma (AKS) Compatible No compatible
Componentes de Kubernetes (incluidos complementos) Compatible No compatible
Actualizaciones de componentes Compatible No compatible
Revisiones de componentes Compatible No compatible
Aplicación de correcciones de errores Compatible No compatible
Aplicación de actualizaciones de seguridad Compatible No compatible
Compatibilidad con la API de Kubernetes Compatible No compatible
Creación de clústeres o grupos de nodos Compatible No compatible
Instantánea de grupo de nodos Compatible No compatible
Actualización de la imagen de nodo Compatible No compatible

Nota

La tabla anterior está sujeta a cambios y describe escenarios de soporte técnico comunes. No se admiten los escenarios relacionados con la funcionalidad y los componentes de Kubernetes para N-3. Para obtener más soporte técnico, consulte Soporte técnico y solución de problemas para AKS.

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

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.

Para averiguar qué versiones están disponibles actualmente para su suscripción y región, utilice el comando az aks get-versions. En el ejemplo siguiente se enumeran las versiones de Kubernetes disponibles para la región EastUS:

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

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.

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.

La omisión de varias versiones solo se puede realizar al actualizar desde una versión no admitida a la versión mínima admitida. Por ejemplo, puede actualizar desde la versión 1.25.x no admitida a la versión 1.27.x compatible si 1.27 es la versión secundaria mínima admitida.

Al realizar una actualización desde un versión no compatible que omite dos o más versiones secundarias, 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 versión no admitida 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 su período de soporte técnico de 30 días?

No. Una vez que una versión está en desuso o se ha quitado, no puede crear un clúster con esa versión. A medida que el cambio se implementa, comenzará a ver que la versión anterior se quita de la lista de versiones. Este proceso puede tardar hasta dos semanas desde el anuncio, y será progresivo por región.

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

No. No se le permite agregar grupos de nodos de la versión en desuso al clúster. Se permite la creación o actualización de grupos de nodos hasta el versión no admitida versión del plano de control, independientemente de la diferencia de versión entre el grupo de nodos y el plano de control. Solo se permiten actualizaciones secundarias de alias.

¿Con qué frecuencia actualiza las revisiones?

Las revisiones tienen un ciclo de vida mínimo de dos meses. Para mantenerse al día cuando se lanzan nuevas revisiones, consulte las notas de la versión de AKS.

Pasos siguientes

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