Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Importante
Actualizaciones iniciadas por la plataforma de AKS. A partir del 1 de junio de 2027, AKS actualiza automáticamente cualquier clúster que permanezca en una versión de Kubernetes no compatible después de que finalice su período de gracia de soporte técnico de la plataforma de 60 días. Una actualización iniciada por la plataforma no se ajusta a su ventana de mantenimiento, no se detiene por el uso de API obsoletas y puede anular un presupuesto de interrupción de pods que bloquee el vaciado de un nodo, por lo que las cargas de trabajo podrían verse interrumpidas. Antes del mes de actualización, sustituya las API eliminadas de la versión de Kubernetes de destino y actualice los complementos autoadministrados incompatibles. Mantenga los clústeres en una versión de Kubernetes compatible para evitar una actualización iniciada por la plataforma. Para obtener más información, consulte Prepararse para las actualizaciones iniciadas por la plataforma en 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.
Para las versiones de Kubernetes en soporte comunitario, AKS proporciona correcciones de errores y actualizaciones de seguridad a partir 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.
El soporte 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 de LTS, AKS incorpora retroactivamente las correcciones de seguridad de la comunidad de origen. 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 parches de soporte a largo plazo
LTS solo admite las dos versiones de revisión más recientes. El soporte de la comunidad puede incluir cualquier número de parches 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 la directiva de soporte de 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 el soporte.
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 premiumestablece el nivel de administración del clúster en Premium, que es necesario para LTS. -
--k8s-support-plan AKSLongTermSupportregistra el clúster en LTS y proporciona un año adicional de correcciones de seguridad. -
--auto-upgrade-channel patchactualiza 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 premiummueve el clúster al nivel de administración del clúster Premium, que es necesario para LTS. -
--k8s-support-plan AKSLongTermSupportinscribe el clúster en LTS y proporciona un año adicional de correcciones de seguridad. -
--auto-upgrade-channel patchactualiza 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 in situ a la última versión LTS, especifica una versión LTS superior ofrecida por AKS como destino de la actualización. Un clúster LTS puede omitir las versiones menores cuando la actualización satisface los requisitos de desfase 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. Comprueba tus cargas de trabajo con respecto a las API obsoletas y otros cambios incompatibles entre la versión actual y la de destino antes de actualizar.
Enumere las versiones que AKS ofrece como destinos de actualización para el clúster mediante el
az aks get-upgradescomando .az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output tableActualice a una versión de LTS ofrecida mediante el
az aks upgradecomando .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. Una vez que esa versión deje de contar con soporte de la comunidad, actualice el clúster a una versión con soporte de la comunidad antes de desactivar LTS. Compruebe el calendario de la versión de Kubernetes de AKS para determinar el estado de soporte técnico de su versión.
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-upgradescomando .az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output tableSi 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 upgradecomando .az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version <community-supported-kubernetes-version>Deshabilite LTS mediante el comando
az aks update. En el ejemplo siguiente se mueve el clúster al nivel Gratis y se selecciona el plan deKubernetesOfficialsoporte técnico.az aks update --resource-group <resource-group-name> --name <cluster-name> --tier free --k8s-support-plan KubernetesOfficialEl
--tier freevalor mueve el clúster al nivel de administración de clústeres gratis y--k8s-support-plan KubernetesOfficialcambia el clúster de LTS al plan de soporte técnico de AKS Kubernetes estándar.
Consideraciones sobre el ciclo de vida de las funcionalidades 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 función | 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 utiliza una ventana de soporte continua que incluye la versión actual y las versiones 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 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. |
Planifica la siguiente actualización de LTS
AKS hace que las versiones consecutivas de Kubernetes sean aptas para LTS y publica una fecha de finalización del ciclo de vida de LTS independiente para cada versión. Utilice el calendario de lanzamientos de AKS LTS y el rastreador de lanzamientos de AKS para elegir una versión de destino disponible y planificar su migración antes de que la versión actual alcance su fecha de fin de vida útil de LTS.
Si no se actualiza, AKS actualiza automáticamente el clúster después del período de gracia de 60 días que sigue a la fecha de finalización del ciclo de vida de LTS, a través de una actualización iniciada por la plataforma. El clúster permanece en el canal LTS y pasa a la siguiente versión LTS compatible. Las actualizaciones iniciadas por la plataforma no se ajustan a su ventana de mantenimiento, por lo que actualizar según su propio calendario es la única forma de mantener el control sobre los plazos.
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 con una versión LTS una vez finalizado el período de soporte de la comunidad, siempre que habilite 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 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.
¿Una actualización iniciada por la plataforma inscribe mi clúster en LTS?
No. AKS nunca inscribe un clúster en LTS en su nombre ni modifica nunca su nivel de facturación. Una actualización iniciada por la plataforma mantiene el clúster en su nivel de soporte técnico actual: un clúster de soporte técnico de la comunidad se mueve a la versión secundaria de la comunidad admitida más baja y un clúster LTS se mueve a la versión de LTS aplicable.
¿Qué ocurre si la versión LTS del clúster alcanza el final del ciclo de vida y no actualizo?
AKS actualiza el clúster a la siguiente versión de LTS compatible después del período de gracia de 60 días que sigue a la fecha de finalización del ciclo de vida de LTS. El clúster no pasa a una versión con soporte de la comunidad. Para buscar el mes de la versión, consulte el calendario de lanzamiento de AKS LTS. Para obtener más información, consulte Actualizaciones iniciadas por la plataforma.
¿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 LTS interrumpe las cargas de trabajo?
No. Es un cambio de solo configuración; no reinstala la imagen de los nodos ni interrumpe las cargas de trabajo, por lo que no se espera ningún tiempo de inactividad.