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, 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 innovación proporcionada con este ritmo de lanzamientos ofrece grandes ventajas, le plantea el reto de mantenerse al día con las versiones de Kubernetes, algo que puede ser más complicado en función del número de clústeres de AKS que tiene que mantener.
Tipos de soporte técnico de AKS
Después de aproximadamente un año, la versión de Kubernetes sale del soporte técnico de la comunidad y los clústeres de AKS ahora están en riesgo a medida que las correcciones de errores y las actualizaciones de seguridad dejen de estar disponibles.
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.
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 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
Habilitar y deshabilitar el soporte técnico a largo plazo es una combinación de mover el clúster al nivel Premium y seleccionar explícitamente el plan de soporte técnico de LTS.
Nota:
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.
Creación de un clúster con LTS habilitado
az aks create --resource-group myResourceGroup --name myAKSCluster --tier premium --k8s-support-plan AKSLongTermSupport --kubernetes-version 1.27
Nota:
Habilitar y deshabilitar LTS consiste en mover el clúster al nivel Premium y habilitar el soporte técnico a largo plazo. Ambos deben estar activados o desactivados.
Habilitar LTS en un clúster existente
az aks update --resource-group myResourceGroup --name myAKSCluster --tier premium --k8s-support-plan AKSLongTermSupport
Deshabilitar LTS en un clúster existente
az aks update --resource-group myResourceGroup --name myAKSCluster --tier [free|standard] --k8s-support-plan KubernetesOfficial
Soporte técnico a largo plazo, complementos y características
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.
Consulte la tabla siguiente para obtener una lista de complementos y características que no se admiten y el motivo.
| 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 |
| Cillium | Requiere el contrato Enterprise de Cillium 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 las 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 quedará 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 usarlo más allá del soporte técnico 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 posterior 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 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.
Migración de LTS a soporte técnico de la comunidad
El uso de LTS es una manera de ampliar la ventana para planear una actualización de la versión de Kubernetes. Es conveniente que migre a una versión de Kubernetes que esté dentro de la ventana de soporte técnico estándar.
Para pasar de un clúster habilitado para LTS a una versión de Kubernetes que se encuentra en la ventana de soporte estándar, debe deshabilitar LTS en el clúster:
az aks update --resource-group myResourceGroup --name myAKSCluster --tier [free|standard] --k8s-support-plan KubernetesOfficial
Y, a continuación, actualice el clúster a una versión compatible posterior:
az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.28.3
Nota:
Kubernetes 1.28.3 se usa como ejemplo aquí; consulte el seguimiento de versiones de AKS para ver las versiones disponibles de Kubernetes.
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.
Migración de LTS a la siguiente versión 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.
Para los clientes que deseen 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.
az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.32.2
Nota:
Si usa cualquier lógica de programación o scripting para enumerar y seleccionar una versión secundaria de Kubernetes antes de crear clústeres con la API ListKubernetesVersions, tenga en cuenta que a partir de Kubernetes v1.27, la API devuelve SupportPlan como [KubernetesOfficial, AKSLongTermSupport]. Asegúrese de actualizar cualquier lógica para excluir versiones AKSLongTermSupport para evitar interrupciones y elegir las versiones KubernetesOfficial del plan de soporte técnico. De lo contrario, si LTS es realmente su ruta de acceso, primero opte por el nivel Premium y las versiones del plan de soporte técnico AKSLongTermSupport de la API ListKubernetesVersions antes de crear clústeres.
Nota:
La siguiente versión de soporte técnico a largo plazo después de la versión 1.27 debe determinarse. Sin embargo, los clientes obtendrán un mínimo de 6 meses de superposición entre la versión 1.27 LTS y la siguiente versión de LTS para planificar las actualizaciones.
Kubernetes 1.32.2 se usa como versión de ejemplo en este artículo. Compruebe el seguimiento de versiones de AKS para ver las versiones disponibles de Kubernetes.