Partekatu honen bidez:

Actualización de un clúster de Azure Kubernetes Service (AKS)

  • Artikulua

Parte del ciclo de vida del clúster de AKS implica efectuar actualizaciones periódicas a la versión más reciente de Kubernetes. Es importante que aplique las últimas versiones de seguridad y actualizaciones para obtener las características más recientes. En este artículo se muestra cómo comprobar y aplicar actualizaciones al clúster de AKS.

Actualizaciones de la versión de Kubernetes

Al actualizar un clúster de AKS compatible, no se pueden omitir las versiones secundarias de Kubernetes. Debe hacer las actualizaciones secuencialmente con arreglo al número de versión principal. Por ejemplo, se permiten actualizaciones entre 1.14.x :>1.15.x o 1.15.x :>1.16.x. 1.14.x : no se permite>1.16.x. Solo puede omitir varias versiones al actualizar desde una versión no admitida a una versión compatible. Por ejemplo, puede realizar una actualización desde un 1.10.x no compatible a un compatible de1.12.x si está disponible.

Cuando se realiza una actualización desde una versión no compatible que omite dos o más versiones secundarias, la actualización no tiene ninguna garantía de funcionalidad y se excluye de los contratos de nivel de servicio y la garantía limitada. Si la versión no está actualizada, se recomienda volver a crear el clúster en su lugar.

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. Ejecute az --version para encontrar 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. Ejecute Get-InstalledModule -Name Az para encontrar la versión. Si necesita instalarla o actualizarla, consulte el artículo sobre la instalación de Azure PowerShell.
  • La realización de operaciones de actualización requiere el rol RBAC Microsoft.ContainerService/managedClusters/agentPools/write. Para más información sobre los roles de RBAC de Azure, vea las operaciones del proveedor de recursos de Azure.
  • A partir de la versión 1.30 de Kubernetes y las versiones 1.27 LTS, las API beta se deshabilitarán de forma predeterminada al actualizar a estas versiones.

Advertencia

Una actualización del clúster de AKS desencadena un acordonamiento y purga de los nodos. Si tiene disponible una cuota de proceso baja, es posible que se produzca un error en la actualización. Para más información, vea Aumento de cuotas.

Compruebe las actualizaciones disponibles del clúster de AKS

Nota:

Para mantenerse al día con las correcciones, las versiones y las actualizaciones de AKS, vea el seguimiento de versiones de AKS.

  • Para comprobar qué versiones de Kubernetes están disponibles para su clúster, use el comando az aks get-upgrades.

    az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

    En la salida de ejemplo siguiente se muestra la versión actual como 1.26.6 y se enumeran las versiones disponibles en upgrades:

    {
  "agentPoolProfiles": null,
  "controlPlaneProfile": {
    "kubernetesVersion": "1.26.6",
    ...
    "upgrades": [
      {
        "isPreview": null,
        "kubernetesVersion": "1.27.1"
      },
      {
        "isPreview": null,
        "kubernetesVersion": "1.27.3"
      }
    ]
  },
  ...
}

Solución de problemas de mensajes de error de actualización del clúster de AKS

La salida de ejemplo siguiente significa que la extensión appservice-kube no es compatible con la versión de la CLI de Azure (se requiere al menos la versión 2.34.1):

The 'appservice-kube' extension is not compatible with this version of the CLI.
You have CLI core version 2.0.81 and this extension requires a min of 2.34.1.
Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.

Si recibe esta salida, debe actualizar la versión de la CLI de Azure. El comando az upgrade se agregó en la versión 2.11.0 y no funciona con versiones anteriores a la 2.11.0. Para actualizar las versiones anteriores, reinstale la CLI de Azure como se indica en Instalación de la CLI de Azure. Si la versión de la CLI de Azure es 2.11.0 o posterior, ejecute az upgrade para actualizar la CLI de Azure a la versión más reciente.

Si la CLI de Azure se actualiza y recibe la siguiente salida de ejemplo, significa que no hay actualizaciones disponibles:

ERROR: Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.

Si no hay ninguna actualización disponible, cree un clúster con una versión compatible de Kubernetes y migre las cargas de trabajo del clúster existente al nuevo clúster. AKS no admite la actualización de un clúster a una versión más reciente de Kubernetes cuando az aks get-upgrades no muestra ninguna actualización disponible.

Actualización de un clúster de AKS

Durante el proceso de actualización del clúster, AKS realiza las siguientes operaciones:

  • Agregar un nuevo nodo de búfer (o tantos nodos como se hayan configurado en sobrecarga máxima) al clúster que ejecuta la versión especificada de Kubernetes.
  • Acordonar y purgar uno de los nodos antiguos para minimizar la interrupción de las aplicaciones en ejecución. Si se utiliza la sobrecarga máxima, acordona y drena todos los nodos posibles al mismo tiempo que la cantidad de nodos del buffer especificado.
  • Para pods de larga duración, puede configurar el tiempo de espera de purga de nodos, lo que permite un tiempo de espera personalizado en la expulsión de pods y un periodo de gracia de finalización correcta por nodo. Si no se especifica, el valor predeterminado es de 30 minutos. El valor de tiempo de espera mínimo permitido es de 5 minutos.
  • Cuando el nodo anterior se ha purgado por completo, se restablece la imagen inicial para recibir la nueva versión y se convierte en el nodo de búfer para el siguiente nodo que se va a actualizar.
  • Opcionalmente, puede establecer una duración de tiempo para esperar entre purgar un nodo y continuar con la imagen inicial y pasar al siguiente nodo. Un intervalo corto le permite completar otras tareas, como comprobar el estado de la aplicación desde un panel de Grafana durante el proceso de actualización. Se recomienda un breve período de tiempo para el proceso de actualización, tan cerca de 0 minutos como sea razonablemente posible. De lo contrario, un tiempo de inmersión de nodo superior afecta al tiempo que transcurre antes de detectar un problema. El valor mínimo de tiempo de inmersión es de 0 minutos, con un máximo de 30 minutos. Si no se especifica, el valor predeterminado es 0 minutos.
  • Este proceso se repite hasta que se hayan actualizado todos los nodos del clúster.
  • Al final del proceso, se elimina el último nodo del búfer, y se mantiene el número de nodos de agente existentes, así como el equilibrio de zona.

Nota:

Si no se especifica ninguna revisión, el clúster se actualiza automáticamente a la revisión de disponibilidad general más reciente de la versión secundaria especificada. Por ejemplo, si --kubernetes-version se establece en 1.28, el clúster se actualiza a 1.28.9.

Para más información, veaActualizaciones de versión secundaria de Kubernetes admitidas en AKS.

  1. Actualice el clúster mediante el comando az aks upgrade.

    az aks upgrade \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --kubernetes-version <KUBERNETES_VERSION>

  2. Confirme que la actualización se completó correctamente con el comando az aks show.

    az aks show --resource-group myResourceGroup --name myAKSCluster --output table

    En la salida de ejemplo siguiente se muestra que el clúster ahora se ejecuta 1.27.3:

    Name          Location    ResourceGroup    KubernetesVersion    ProvisioningState    Fqdn
------------  ----------  ---------------  -------------------  -------------------  ----------------------------------------------
myAKSCluster  eastus      myResourceGroup  1.27.3               Succeeded            myakscluster-dns-379cbbb9.hcp.eastus.azmk8s.io

Establecimiento de un canal de actualización automática

Actualice manualmente o establezca un canal de actualización automática en el clúster. Para más información, consulte Actualización automática de un clúster de AKS.

Personalización de la actualización de sobrecargas de nodo

Importante

  • Los sobrecargas de nodo requieren la cuota de suscripción para el recuento máximo de sobrecargas solicitado para cada operación de actualización. Por ejemplo, un clúster que tiene cinco grupos de nodos, cada uno con un recuento de cuatro nodos, tiene un total de 20 nodos. Si cada grupo de nodos tiene un valor de sobrecarga máxima del 50 %, se requiere un proceso adicional y una cuota de IP de 10 nodos (2 nodos x 5 grupos) para completar la actualización.

  • El valor de sobrecarga máxima en un grupo de nodos es permanente. Las actualizaciones posteriores de Kubernetes o las actualizaciones de la versión de nodo usarán esta configuración. Puede cambiar el valor máximo de sobrecarga de los grupos de nodos en cualquier momento. En el caso de los grupos de nodos de producción, se recomienda un valor de sobrecarga máxima del 33 %.

  • Si usa Azure CNI, compruebe que haya direcciones IP disponibles en la subred, para cumplir los requisitos de direcciones IP de Azure CNI.

AKS configura las actualizaciones para sobrecargar con un nodo adicional de forma predeterminada. Un valor predeterminado de uno para la configuración de sobrecarga máxima permite a AKS minimizar la interrupción de las cargas de trabajo mediante la creación de otro nodo antes de acordonar o purgar las aplicaciones existentes para reemplazar un nodo de una versión anterior. Puede personalizar el valor máximo de sobrecarga por grupo de nodos. Al aumentar el valor máximo de sobrecarga, el proceso de actualización se completa más rápido y puede experimentar interrupciones durante el proceso de actualización.

Por ejemplo, un valor máximo de sobrecarga de 100 % proporciona el proceso de actualización más rápido posible, pero también hace que todos los nodos del grupo de nodos se desagüen simultáneamente. Es posible que quiera usar un valor más alto, como este, para los entornos de prueba. En el caso de los grupos de nodos de producción, se recomienda un valor de max_surge del 33 %.

AKS acepta valores enteros y un valor de porcentaje para la sobrecarga máxima. Un entero, como 5, indica cinco nodos adicionales para la sobrecarga. Un valor de 50 % indica un valor de sobrecarga de la mitad del número de nodos actual del grupo. Los valores de porcentaje de sobrecarga máxima pueden ser de 1 % como mínimo y 100 % como máximo. Un valor de porcentaje se redondea al número de nodos más próximo. Si el valor máximo de sobrecarga es mayor que el número necesario de nodos que se van a actualizar, el número de nodos que se actualicen se usa como valor máximo de sobrecarga. Durante una actualización, el valor de sobrecarga máxima puede ser 1 como mínimo y un valor igual al número de nodos del grupo de nodos como máximo. Puede establecer valores más grandes, pero no puede establecer el número máximo de nodos usados para el aumento máximo superior al número de nodos del grupo en el momento de la actualización.

Establecer el valor máximo de sobrecarga

  • Establezca valores máximos de sobrecarga para grupos de nodos nuevos o existentes mediante el comando az aks nodepool add o az aks nodepool update.

    # Set max surge for a new node pool
az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33%

# Update max surge for an existing node pool 
az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 5

Establecimiento del valor de tiempo de espera de la purga de nodos

En ocasiones, puede tener una carga de trabajo de larga duración en un determinado pod y no se puede volver a programar a otro nodo durante el tiempo de ejecución, por ejemplo, una carga de trabajo con estado intensivo de memoria que debe terminar de ejecutarse. En estos casos, puede configurar un tiempo de espera de purga de nodos que AKS respetará en el flujo de trabajo de actualización. Si no se especifica ningún valor de tiempo de espera de purga de nodos, el valor predeterminado es de 30 minutos. El valor mínimo permitido del tiempo de espera de purga es de 5 minutos.

Si el valor de tiempo de espera de purga transcurre y los pods siguen ejecutándose, se detiene la operación de actualización. Cualquier operación PUT posterior reanudará la actualización detenida. También se recomienda que los pods de larga duración configuren [terminationGracePeriodSeconds][https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/].

  • Establezca el tiempo de espera de purga de nodos para grupos de nodos nuevos o existentes mediante el comando az aks nodepool add o az aks nodepool update.

    # Set drain timeout for a new node pool
az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster  --drain-timeout 100

# Update drain timeout for an existing node pool
az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --drain-timeout 45

Establecer el valor de tiempo de inmersión de nodo

Para permitir una duración de tiempo entre purgar un nodo y continuar con la imagen inicial y pasar al siguiente nodo, puede establecer el tiempo de inmersión en un valor entre 0 y 30 minutos. Si no se especifica ningún valor de tiempo de inmersión de nodo, el valor predeterminado es 0 minutos.

  • Establezca el tiempo de inmersión de nodos para grupos de nodos nuevos o existentes mediante el comando az aks nodepool add, az aks nodepool updateo az aks nodepool upgrade.

    # Set node soak time for a new node pool
az aks nodepool add --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --node-soak-duration 10

# Update node soak time for an existing node pool
az aks nodepool update --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 5

# Set node soak time when upgrading an existing node pool
az aks nodepool upgrade --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 20

Visualización de eventos de actualización

  • Vea los eventos de actualización mediante el comando kubectl get events.

    kubectl get events

    En la salida de ejemplo siguiente se muestran algunos de los eventos anteriores enumerados durante una actualización:

    ...
default 2m1s Normal Drain node/aks-nodepool1-96663640-vmss000001 Draining node: [aks-nodepool1-96663640-vmss000001]
...
default 1m45s Normal Upgrade node/aks-nodepool1-96663640-vmss000001   Soak duration 5m0s after draining node: aks-nodepool1-96663640-vmss000001
...
default 9m22s Normal Surge node/aks-nodepool1-96663640-vmss000002 Created a surge node [aks-nodepool1-96663640-vmss000002 nodepool1] for agentpool nodepool1
...

Pasos siguientes

Para obtener información sobre cómo configurar las actualizaciones automáticas, vea Configuración de actualizaciones automáticas para un clúster de AKS.

Para obtener una explicación detallada de los procedimientos recomendados de actualización y otras consideraciones, consulte Guía de actualización y revisión de AKS.