Actualización del plano de control del clúster de Azure Kubernetes Service (AKS)

Los clústeres de Azure Kubernetes Service (AKS) constan de dos componentes principales: el plano de control administrado por Azure y los grupos de nodos en los que se ejecutan las cargas de trabajo. Este artículo se centra en actualizar el plano de control de forma independiente, lo que le permite adoptar nuevas versiones de Kubernetes para las características del servidor de API, al tiempo que administra por separado las actualizaciones del grupo de nodos.

Antes de empezar

• Si usa la CLI de Azure, en este artículo se requiere la versión 2.34.1 o posterior de la CLI de Azure. Use el az --version comando para buscar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.
• Si usa Azure PowerShell, en este artículo se requiere Azure PowerShell versión 5.9.0 o posterior. Use el Get-InstalledModule -Name Az cmdlet para buscar la versión. Si necesita instalarla o actualizarla, consulte el artículo sobre la instalación de Azure PowerShell.
• Para realizar operaciones de actualización, necesita el rol de colaborador de Azure Kubernetes Service o permisos equivalentes.
• Las API beta están deshabilitadas de forma predeterminada al actualizar a las versiones 1.30 y 1.27 LTS de Kubernetes.

Introducción a los tipos de actualización de AKS

En la tabla siguiente se describen tres tipos de actualizaciones de AKS, que resaltan su ámbito y casos de uso:

Reglas de actualización de versiones de Kubernetes

Al actualizar un clúster de AKS que no es de LTS compatible, no se pueden omitir las versiones secundarias de Kubernetes. Debe hacer las actualizaciones secuencialmente con arreglo al número de versión secundaria. Por ejemplo, se permiten actualizaciones entre 1.28.x ->1.29.x o 1.29.x ->1.30.x . No se permite 1.28.x ->1.30.x.

Un clúster de LTS puede omitir las versiones secundarias al pasar a una versión de LTS superior que ofrece AKS, siempre que la actualización cumpla los requisitos de asimetría de versiones y las comprobaciones de validación. Para obtener más información, consulte ¿Puedo omitir varias versiones de AKS durante una actualización del clúster?.

A partir de Kubernetes 1.28, el plano de control puede tener hasta tres versiones secundarias antes de los grupos de nodos. Por ejemplo, si el plano de control está en 1.35.x, los grupos de nodos pueden ser 1.32.x, 1.33.x, 1.34.x o 1.35.x. Para obtener restricciones actuales, consulte la directiva de asimetría de versiones de AKS.

Comprobación de las actualizaciones de AKS disponibles

az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output table

Name     ResourceGroup          MasterVersion    Upgrades
-------  ---------------        ---------------  --------------
default  <resource-group-name>  1.28.9           1.29.2, 1.29.4

Get-AzAksVersion -Location <your-region> | Where-Object { $_.OrchestratorVersion }

Solo actualizar el plano de control de AKS

Actualización del clúster de AKS completo

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

Set-AzAksCluster -ResourceGroupName <resource-group-name> -Name <cluster-name> -KubernetesVersion 1.29.4

Preguntas más frecuentes sobre la actualización del plano de control de AKS (P+F)

¿Una actualización solo del plano de control también actualiza los grupos de nodos?

No. Una actualización de solo plano de control no cambia los grupos de nodos. La actualización automática del clúster funciona de forma diferente: no admite actualizaciones de solo plano de control y actualiza el plano de control y todos los grupos de nodos juntos.

¿Puedo actualizar grupos de nodos antes del plano de control?

No. La versión del plano de control siempre debe ser igual o mayor que cualquier versión del grupo de nodos. Primero debe actualizar el plano de control.

¿Cuánto tiempo tarda una actualización del plano de control?

La duración de la actualización varía según el estado del clúster y las condiciones de Azure. Supervise provisioningState mediante az aks show o Get-AzAksCluster. La actualización se completa cuando el estado de aprovisionamiento es Succeeded.

Resolución de problemas de actualización del plano de control

No hay actualizaciones disponibles

Para un clúster no compatible, use az aks get-upgrades para comprobar si AKS ofrece un destino admitido apto. Si un destino está disponible, realice una actualización de clúster completo. Las actualizaciones de solo plano de control no se admiten para esta ruta de recuperación.

Si no hay ningún destino disponible, es posible que el clúster ya esté en la versión compatible más reciente. Si el clúster ejecuta una versión no admitida, cree un clúster con una versión compatible y migre las cargas de trabajo.

Error de actualización debido a las API en desuso

Antes de actualizar, compruebe si hay API en desuso mediante herramientas como kube-no-trouble (kubent)::

kubent

El comando examina los recursos accesibles a través del contexto kubeconfig actual para las versiones de API de Kubernetes en desuso. Los resultados agrupan los resultados de la versión de Kubernetes e identifican cada recurso afectado por KIND, NAMESPACE, NAMEy API_VERSION. Actualice el manifiesto de origen de todos los recursos enumerados para usar una versión de API compatible antes de actualizar.

Contenido relacionado

• Configuración de actualizaciones graduales para grupos de nodos
• Configuración de actualizaciones automáticas del clúster
• Configuración de actualizaciones automáticas de imágenes del sistema operativo del nodo