Compatibilidad a largo plazo con versiones de Azure Kubernetes Service (AKS)

La comunidad de Kubernetes publica una nueva versión secundaria aproximadamente cada cuatro meses y cada versión tiene una ventana de soporte técnico de un año. En Azure Kubernetes Service (AKS), esta ventana de soporte técnico se denomina Soporte técnico de la comunidad.

En el caso de las versiones de Kubernetes en la compatibilidad con la comunidad, AKS proporciona correcciones de errores y actualizaciones de seguridad de las versiones de la comunidad. Puede ser difícil mantenerse al día con la cadencia de versión de Kubernetes cuando las aplicaciones tienen dependencias complejas.

La compatibilidad a largo plazo (LTS) amplía la ventana de soporte técnico para que tenga más tiempo para planear y probar las actualizaciones a versiones más recientes de Kubernetes.

Tipos de soporte técnico de AKS

Después de aproximadamente un año, una versión secundaria de Kubernetes determinada sale del soporte técnico de la comunidad y las correcciones de errores y las actualizaciones de seguridad no están disponibles para los clústeres de AKS.

AKS proporciona un año de soporte técnico de la comunidad, seguido de un año adicional de soporte técnico a largo plazo. Juntos, el soporte técnico de la comunidad y los períodos de LTS proporcionan aproximadamente 24 meses de soporte técnico total a partir de la disponibilidad general (GA) de la versión de Kubernetes. Durante el año LTS, AKS retroporta las correcciones de seguridad de la comunidad ascendente. El grupo de trabajo de LTS ascendente contribuye a la comunidad, ampliando la ventana de soporte técnico.

Apoyo comunitario Soporte a largo plazo
Cuándo se deben usar Cuando pueda mantenerse al día con las versiones ascendentes de Kubernetes Cuando necesite controlar cuándo migrar de una versión a otra
Versiones compatibles Tres versiones secundarias de disponibilidad general más recientes Todas las versiones de Kubernetes admitidas son aptas para LTS. Consulte el calendario de lanzamiento de AKS LTS.

Proceso de revisión de soporte técnico a largo plazo

LTS solo admite las dos versiones de revisión más recientes. El soporte técnico de la comunidad puede incluir cualquier número de revisiones que se ofrecen actualmente. Sin embargo, AKS se reserva el derecho de dejar de usar cualquier versión de revisión en respuesta a vulnerabilidades de seguridad críticas (CVE). Para más información sobre la directiva de soporte técnico de la comunidad, consulte Directiva de compatibilidad con versiones de Kubernetes.

Para identificar las versiones de revisión compatibles más recientes, consulte el seguimiento de versiones de AKS.

Habilitar el soporte técnico a largo plazo

La habilitación de LTS requiere mover el clúster al nivel Premium y seleccionar explícitamente el plan de soporte técnico de LTS. Puede elegir participar en cualquier momento, incluso mientras su clúster todavía está en soporte comunitario.

LTS está disponible en el nivel Premium. Para obtener las tarifas actuales, consulte Precios de AKS.

Nota:

Habilite el canal de actualización automática de revisiones para mantener el clúster en las revisiones admitidas más recientes. LTS solo admite las dos versiones de revisión más recientes para cada versión secundaria. Los clústeres que no ejecutan una de esas versiones de revisión podrían perder compatibilidad.

Habilitar LTS en un nuevo clúster

Cree un clúster con LTS habilitado mediante el comando az aks create. AKS usa la versión de Kubernetes compatible predeterminada y la revisión más reciente disponible en la región.

az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --tier premium \
    --k8s-support-plan AKSLongTermSupport \
    --auto-upgrade-channel patch \
    --generate-ssh-keys

El comando usa los siguientes valores de parámetro específicos de LTS:

  • --tier premium establece el nivel de administración del clúster en Premium, que es necesario para LTS.
  • --k8s-support-plan AKSLongTermSupport inscribe el clúster en LTS y proporciona un año adicional de correcciones de seguridad.
  • --auto-upgrade-channel patch actualiza automáticamente el clúster a las versiones de revisión admitidas mientras mantiene la misma versión secundaria.

Habilitar LTS en un clúster existente

Habilitar LTS en un clúster existente mediante el comando az aks update.

az aks update --resource-group <resource-group-name> --name <cluster-name> --tier premium --k8s-support-plan AKSLongTermSupport --auto-upgrade-channel patch

El comando usa los siguientes valores de parámetro específicos de LTS:

  • --tier premium mueve el clúster al nivel de administración del clúster Premium, que es necesario para LTS.
  • --k8s-support-plan AKSLongTermSupport inscribe el clúster en LTS y proporciona un año adicional de correcciones de seguridad.
  • --auto-upgrade-channel patch actualiza automáticamente el clúster a las versiones de revisión admitidas mientras mantiene la misma versión secundaria.

Sugerencia

Para ver a qué versiones de Kubernetes puede actualizar, use el seguimiento de versiones de AKS o ejecute az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>.

Migrar a la versión más reciente de LTS

Para realizar una actualización local a la versión más reciente de LTS, especifique una versión de LTS superior que ofrece AKS como destino de actualización. Un clúster LTS puede omitir las versiones secundarias cuando la actualización satisface los requisitos de asimetría de versiones y las comprobaciones de validación. Para más información, consulte Reglas de actualización de versiones de Kubernetes.

Durante una actualización local completa, AKS actualiza primero el plano de control y, a continuación, actualiza cada grupo de nodos secuencialmente. Pruebe las cargas de trabajo en las API en desuso y otros cambios importantes entre las versiones actuales y de destino antes de actualizar.

  1. Enumere las versiones que AKS ofrece como destinos de actualización para el clúster mediante el az aks get-upgrades comando .

    az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output table
    
  2. Actualice a una versión de LTS ofrecida mediante el az aks upgrade comando .

    az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version <lts-kubernetes-version>
    

    Nota:

    Todas las versiones admitidas de Kubernetes de AKS son compatibles con LTS. Para obtener el calendario LTS más reciente, consulte el calendario de versión de Kubernetes de AKS. Para ver las versiones de LTS disponibles y sus revisiones por región, consulte el seguimiento de versiones de AKS.

Deshabilitar el soporte a largo plazo en un clúster existente

Para deshabilitar LTS en un clúster existente, mueva el clúster al nivel Gratis o Estándar y seleccione explícitamente el plan de KubernetesOfficial soporte técnico.

Puede deshabilitar LTS mientras la versión de Kubernetes del clúster todavía está en soporte técnico de la comunidad. Después de que esa versión salga del soporte técnico de la comunidad, actualice el clúster a una versión compatible con la comunidad antes de deshabilitar LTS. Compruebe el calendario de la versión de Kubernetes de AKS para determinar el estado de soporte técnico de la versión.

  1. Si la versión actual está fuera del soporte técnico de la comunidad, enumere los destinos de actualización disponibles mediante el az aks get-upgrades comando .

    az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output table
    
  2. Si es necesario, actualice el clúster a una versión ofrecida que se encuentra en soporte técnico de la comunidad mediante el az aks upgrade comando .

    az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version <community-supported-kubernetes-version>
    
  3. Deshabilite LTS mediante el az aks update comando . En el ejemplo siguiente se mueve el clúster al nivel Gratis y se selecciona el plan de KubernetesOfficial soporte técnico.

    az aks update --resource-group <resource-group-name> --name <cluster-name> --tier free --k8s-support-plan KubernetesOfficial
    

    El --tier free valor mueve el clúster al nivel de administración de clústeres gratis y --k8s-support-plan KubernetesOfficial cambia el clúster de LTS al plan de soporte técnico de AKS Kubernetes estándar.

Consideraciones sobre el ciclo de vida de las características y el complemento

LTS amplía la compatibilidad con la versión de Kubernetes, pero los complementos y las características pueden tener ciclos de vida de soporte técnico independientes. Antes de mover un clúster a LTS, revise el ciclo de vida y la compatibilidad de la versión de Kubernetes de cada complemento y característica que usa el clúster.

En la tabla siguiente se resumen las consideraciones del ciclo de vida actuales:

Complemento o característica Consideración del ciclo de vida
Calicó Confirme que la versión de Calico admite la versión de Kubernetes de destino y revise los términos de soporte técnico de Tigera para su uso más allá del soporte técnico de la comunidad de Kubernetes.
Servicio de administración de claves (KMS) La experiencia de KMS existente ahora se designa como heredada. Para Kubernetes 1.33 y versiones posteriores, revise la nueva experiencia de cifrado de datos de KMS y las instrucciones de migración aplicables. Tanto la nueva experiencia como su flujo de trabajo de migración están en versión preliminar.
Dapr La extensión Dapr administrada usa una ventana de compatibilidad gradual que incluye las versiones actuales y anteriores de Dapr. Mantenga la extensión dentro de su ventana de versión compatible.
Controlador de entrada de Application Gateway (AGIC) AGIC permanece disponible. Comience a realizar la transición a Application Gateway para contenedores.
Open Service Mesh (OSM) La compatibilidad de AKS con el complemento de OSM administrado finaliza el 30 de septiembre de 2027. Migre al complemento istio antes de esa fecha.
Microsoft Entra identidad administrada por pods La compatibilidad con el complemento administrado finalizó en septiembre de 2025. Migre a Id. de carga de trabajo de Microsoft Entra.
Azure Confidential Compute SGX (ACC SGX) Confirme que ACC SGX admite la versión de Kubernetes de destino antes de mover el clúster más allá del soporte técnico de la comunidad.

Planear la siguiente actualización de LTS

AKS hace que las versiones consecutivas de Kubernetes sean aptas para LTS y publique una fecha de finalización de ciclo de vida de LTS independiente para cada versión. Use el calendario de lanzamiento de AKS LTS y el rastreador de versiones de AKS para elegir una versión de destino ofrecida y planear la migración antes de que la versión actual alcance su fecha de finalización de ciclo de vida de LTS.

Preguntas más frecuentes

¿Puedo crear un nuevo clúster de AKS con una versión LTS una vez finalizada la compatibilidad con la comunidad?

Sí, puede crear un nuevo clúster de AKS mediante una versión de LTS después de que finalice su período de soporte técnico de la comunidad si habilita LTS. La compatibilidad con LTS solo continúa hasta el final del ciclo de vida de esa versión. A continuación, debe actualizar a la siguiente versión de LTS compatible. Para más información, consulte el calendario de versión de Kubernetes de AKS.

¿Puedo habilitar y deshabilitar LTS en una versión compatible con AKS después de que finalice el soporte técnico de la comunidad?

Sí, puede habilitar el plan de soporte técnico de LTS en cualquier versión compatible con AKS incluso después de que haya finalizado su período de soporte técnico de la comunidad. Sin embargo, una vez finalizado el período de soporte técnico de la comunidad, no se puede deshabilitar LTS para esa versión.

¿Un clúster de AKS compatible con la comunidad se convierte automáticamente en apto para LTS después del final del ciclo de vida?

No. Debe habilitar explícitamente LTS y mover el clúster al nivel Premium.

¿Cada versión de AKS es apta para soporte técnico a largo plazo?

Yes. Todas las versiones de Kubernetes admitidas son aptas para LTS.

¿Cuál es el modelo de precios para LTS?

LTS se ofrece en el nivel Premium. Para obtener las tarifas actuales, consulte Precios del plan Premium.

¿La habilitación de las cargas de trabajo de LTS interrumpe?

No. Es un cambio de solo configuración; no cambia la imagen de los nodos ni interrumpe las cargas de trabajo, por lo que no se espera ningún tiempo de inactividad.