Compartir a través de

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

  • Artículo

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

AKS admite versiones de Kubernetes que se encuentran en esta ventana de soporte técnico de la comunidad para insertar correcciones de errores y actualizaciones de seguridad de las versiones de la comunidad. Aunque la cadencia de la versión de soporte técnico de la comunidad proporciona ventajas, requiere que se mantenga al día de las versiones de Kubernetes, lo que puede ser difícil en función de las dependencias de la aplicación y del ritmo de cambio del ecosistema de Kubernetes.

Para ayudarle a administrar las actualizaciones de la versión de Kubernetes, AKS proporciona una opción de soporte técnico a largo plazo (LTS), que amplía la ventana de soporte técnico de una versión de Kubernetes para proporcionarle 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, lo que hace que 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 y un año de soporte técnico a largo plazo para realizar correcciones de seguridad de puertos desde el nivel superior de la comunidad en el repositorio público de AKS. El grupo de trabajo de LTS de nivel superior contribuye a los esfuerzos de la comunidad para proporcionar a los clientes una ventana de soporte técnico más larga. LTS tiene previsto proporcionarle un período de tiempo más largo para planear y probar las actualizaciones durante un período de dos años a partir de la disponibilidad general (GA) de la versión designada de Kubernetes.

Soporte técnico de la comunidad Compatibilidad 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
Compatibilidad con versiones Tres versiones secundarias de disponibilidad general Una versión de Kubernetes (actualmente 1.27) durante dos años

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. Aunque es posible habilitar LTS cuando el clúster esté en *soporte técnico de la comunidad, se le cobrará una vez que habilite el nivel Premium.

Habilitar LTS en un nuevo clúster

  • Cree un clúster con LTS habilitado mediante el comando az aks create.

    El comando siguiente crea un nuevo clúster de AKS con LTS habilitado mediante Kubernetes versión 1.27 como ejemplo. Para revisar las versiones disponibles de Kubernetes, consulte el seguimiento de versiones de AKS.

    az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --tier premium \
    --k8s-support-plan AKSLongTermSupport \
    --kubernetes-version 1.27 \
    --generate-ssh-keys

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

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

La comunidad de Kubernetes de nivel superior admite una ruta de actualización de dos versiones secundarias. El proceso migra los objetos del clúster de Kubernetes como parte del proceso de actualización y proporciona una ruta de migración probada y acreditada.

Si quiere realizar una migración local, el servicio AKS migrará el plano de control de la versión anterior de LTS a la versión más reciente y, a continuación, migrará el plano de datos. Para realizar una actualización local a la versión más reciente de LTS, debe especificar una versión de Kubernetes habilitada para LTS como destino de la actualización.

  • Migrar a la versión más reciente de LTS mediante el comando az aks upgrade.

    El comando siguiente usa Kubernetes versión 1.32.2 como una versión de ejemplo. Para revisar las versiones disponibles de Kubernetes, consulte el seguimiento de versiones de AKS.

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

    Nota:

    1.30 es la siguiente versión de LTS después de la versión 1.27. Puede participar en LTS desde un clúster de versión 1.30 a través de los pasos indicados anteriormente. La versión 1.27 de LTS finalizará el ciclo de vida (EOL) en julio de 2025. Revisiones admitidas en LTS hoy: [1.27.100] [https://github.com/aks-lts/kubernetes/blob/release-1.27-lts/CHANGELOG/CHANGELOG-1.27.md#v127100-akslts]

Deshabilitar compatibilidad a largo plazo en un clúster existente

Deshabilitar LTS en un clúster existente requiere mover el clúster al nivel gratuito o estándar y seleccionar explícitamente el plan de soporte técnico de KubernetesOfficial.

Hay aproximadamente dos años entre una versión de LTS y la siguiente. En lugar del soporte técnico de nivel superior para migrar más de dos versiones secundarias, hay una alta probabilidad de que la aplicación dependa de las API de Kubernetes que han quedado en desuso. Se recomienda probar exhaustivamente la aplicación en la versión de Kubernetes LTS de destino y llevar a cabo una implementación azul/verde de una versión a otra.

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

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

  2. Actualice el clúster a una versión compatible posterior mediante el comando az aks upgrade.

    El comando siguiente usa Kubernetes versión 1.28.3 como una versión de ejemplo. Para revisar las versiones disponibles de Kubernetes, consulte el seguimiento de versiones de AKS.

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

Complementos y características no admitidos

Actualmente, el equipo de AKS realiza un seguimiento de las versiones de complementos en las que existe soporte técnico de la comunidad de Kubernetes. Cuando una versión deja el soporte técnico de la comunidad, nos basamos en proyectos de código abierto para complementos administrados para continuar con dicho soporte. Debido a varios factores externos, es posible que algunos complementos y características no admitan versiones de Kubernetes a parte de estas ventanas de soporte técnico de la comunidad de nivel superior.

En la tabla siguiente se proporciona una lista de complementos y características que no se admiten y las razones por las que no se admiten:

Complemento / Característica Motivo por el que no se admite
Istio El ciclo de soporte técnico de Istio es corto (seis meses) y no habrá versiones de mantenimiento para Kubernetes 1.27.
Keda No se puede garantizar la compatibilidad de versiones posteriores con Kubernetes 1.27.
Calico Requiere el contrato Enterprise de Calico más allá del soporte técnico de la comunidad.
Servicio de administración de claves (KMS) KMSv2 reemplaza a KMS durante este ciclo de LTS.
Dapr No se admiten extensiones de AKS.
Controlador de entrada de Application Gateway La migración a App Gateway para Containers se produce durante el período de LTS.
Apertura de Service Mesh OSM está en desuso.
Identidad de pods de AAD En desuso en lugar de la identidad de carga de trabajo.

Nota:

No podrá mover el clúster a soporte técnico a largo plazo si alguno de estos complementos o características están habilitados.

Aunque Microsoft no admite estos complementos administrados de AKS, puede instalar sus versiones de código abierto en el clúster si quiere usarlos más allá del soporte de la comunidad.

Cómo decidimos la siguiente versión de LTS

Las versiones de LTS de Kubernetes están disponibles durante dos años a partir de la disponibilidad general; marcamos una versión superior de Kubernetes como LTS en función de los criterios siguientes:

  • Ha transcurrido tiempo suficiente para que los clientes migren de la versión anterior de LTS a la versión de LTS actual.
  • La versión anterior ha tenido una ventana de soporte técnico de dos años.

Lea las notas de la versión de AKS para mantenerse informado de cuándo puede planear la migración.

Preguntas más frecuentes

La compatibilidad de la comunidad con AKS 1.27 finaliza en julio de 2024. ¿Puedo crear un nuevo clúster de AKS con la versión 1.27 después de esa fecha?

Sí, siempre que LTS esté habilitado en el clúster, puede crear un nuevo clúster de AKS con la versión 1.27 una vez finalizada la ventana de soporte técnico de la comunidad.

¿Puedo habilitar y deshabilitar LTS en AKS 1.27 después del final del soporte técnico de la comunidad?

Puede habilitar el plan de soporte técnico de LTS en AKS 1.27 después del final del soporte técnico de la comunidad. Sin embargo, no puede deshabilitar LTS en AKS 1.27 después del final del soporte técnico de la comunidad.

Tengo un clúster que se ejecuta en la versión 1.27. ¿Significa que se encuentra automáticamente en LTS?

No, debe habilitar explícitamente LTS en el clúster para recibir compatibilidad con LTS. La habilitación de LTS también requiere estar en el nivel Premium.

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

LTS está disponible en el nivel Premium, consulte los precios del plan Premium para obtener más información.

Después de habilitar LTS, autoUpgradeChannel del clúster ha cambiado al canal de revisión.

Se espera que esto sea así. Si no se ha definido autoUpgradeChannel para el clúster de AKS, el valor predeterminado es patch con LTS.