Cambie el tamaño de los grupos de nodos del sistema en Azure Kubernetes Service (AKS)

Es posible que desee cambiar el tamaño de las máquinas virtuales (VM) para dar cabida a un número cada vez mayor de implementaciones o para ejecutar una carga de trabajo mayor. No se admite el cambio de tamaño de las instancias de AKS directamente al usar virtual Machine Scale Sets en AKS, como se describe en las directivas de soporte técnico para AKS:

Los nodos de agente de AKS aparecen en Azure Portal como recursos de Azure IaaS normales. No obstante, estas máquinas virtuales se implementan en un grupo de recursos de Azure personalizado (normalmente, con el prefijo MC_*). No puede realizar personalizaciones directas en estos nodos mediante las API o recursos de IaaS. Los cambios personalizados que no se realicen a través de la API de AKS no se conservarán durante una mejora, escalado, actualización o reinicio.

En este artículo, aprenderá el método recomendado para cambiar el tamaño de un grupo de nodos mediante la creación de un nuevo grupo de nodos con el tamaño de SKU deseado, acordonar y purgar los nodos existentes y, a continuación, quitar el grupo de nodos existente.

Importante

Este método es específico de los clústeres de AKS basados en Conjuntos de Escalado de Máquinas Virtuales. Al usar grupos de nodos basados en máquinas virtuales, puede actualizar fácilmente los tamaños de máquina virtual en un grupo de nodos existente mediante un único comando de la CLI de Azure y tener varios tamaños de máquina virtual en el mismo grupo de nodos. Para más información, consulte la documentación sobre grupos de nodos de Virtual Machines.

Cambiar el tamaño de un grupo de nodos de VMSS localmente (versión preliminar)

Importante

Las características en versión preliminar de AKS están disponibles en modalidad de autoservicio y previa suscripción. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y la garantía limitada. Las versiones preliminares de AKS cuentan con soporte parcial por parte del servicio al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

Ahora puede cambiar el tamaño de máquina virtual (SKU) de un grupo de nodos basado en VMSS existente en un único comando mediante az aks nodepool update --node-vm-size <new-size>. Al desencadenar esta actualización, el proveedor de recursos de AKS realiza una actualización gradual mediante:

  1. Aumentar los nodos nuevos con el tamaño de la máquina virtual de destino.
  2. Acordonar y purgar los nodos antiguos.
  3. Eliminación de los nodos antiguos.

Esto evita el flujo de trabajo manual de crear/aislar/drenar/eliminar descrito en el resto de este artículo.

Cómo funciona la implementación del redimensionado

El despliegue del cambio de tamaño utiliza el mismo motor de actualización escalonada que el de una actualización de imagen de nodo y una actualización de la versión de Kubernetes, por lo que tiene en cuenta los siguientes ajustes de actualización ya configurados para el grupo de nodos. En concreto, el cambio de tamaño respeta:

  • Sobrecarga máxima (--max-surge): controla cuántos nodos adicionales con el tamaño de la máquina virtual de destino se agregan durante el lanzamiento. Un valor mayor cambia el tamaño del grupo más rápido, pero consume más cuota de proceso e IP; un valor inferior es más lento, pero menos perjudicial. El valor predeterminado de AKS es 1y 33% se recomienda para los grupos de nodos de producción.
  • Tiempo de espera del vaciado del nodo (--drain-timeout): cuánto tiempo espera AKS a que se expulsen los pods de cada nodo antiguo antes de eliminarlo por la fuerza. El valor predeterminado es 30 minutos. Combine esto con PodDisruptionBudgets adecuados para que las cargas de trabajo se puedan purgar de forma segura.
  • Duración de estabilización del nodo (--node-soak-duration): Cuánto tiempo espera AKS después de que un nodo nuevo pase al estado Listo antes de pasar al siguiente lote. Resulta útil para permitir que las cargas de trabajo se estabilicen en el nuevo tamaño de máquina virtual antes de continuar con el lanzamiento.

Dado que el cambio de tamaño reutiliza la canalización de actualización, se aplican los mismos requisitos previos: asegúrese de que la suscripción tiene suficiente capacidad de reemplazo de tamaño de máquina virtual de destino y las direcciones IP de subred disponibles para los nodos de sobrecarga y que los PodDisruptionBudgets permiten expulsar al menos una réplica a la vez, de lo contrario, se puede bloquear el cambio de tamaño durante la purga. Para obtener recomendaciones de un extremo a otro, consulte Procedimientos recomendados para las actualizaciones del grupo de nodos de AKS.

Prerequisites

Cambio del tamaño del grupo de nodos

Use el az aks nodepool update comando con el --node-vm-size parámetro para cambiar el tamaño de la máquina virtual de un grupo de nodos basado en VMSS existente:

az aks nodepool update \
    --resource-group MyResourceGroup \
    --cluster-name MyManagedCluster \
    --name nodepool1 \
    --node-vm-size Standard_D4s_v3

Combinaciones no admitidas y validación

El proveedor de recursos de AKS valida la solicitud de cambio de tamaño y bloquea los cambios de tamaño de máquina virtual incompatibles. Los cambios siguientes no se admiten como parte de un cambio de tamaño de VMSS local:

  • Cambiar el tipo de controlador de disco (por ejemplo, SCSI a NVMe).
  • Cambio de la arquitectura de CPU (por ejemplo, x64 a ARM64).
  • Cambiar el soporte de computación confidencial (por ejemplo, habilitar o deshabilitar SNP).
  • Cambio de la generación del hipervisor (por ejemplo, V1 a V2).
  • Combinar el cambio de tamaño con una actualización de la versión de Kubernetes o un cambio de recuento de nodos en la misma operación.

Si el tamaño de la máquina virtual de destino requiere cualquiera de los cambios anteriores, use el flujo de trabajo manual de cordón y purga descrito en las secciones siguientes en su lugar.

Nota:

El cambio de tamaño in situ requiere capacidad adicional para aprovisionar nuevos nodos con el tamaño objetivo de la máquina virtual antes de vaciar los antiguos. Si el grupo de nodos está configurado con --max-surge 0 (es decir, --max-unavailable está en vigor), la solicitud de cambio de tamaño se rechaza con un 400 Bad Request. Para continuar, establezca --max-surge en al menos 1 al cambiar el tamaño mediante

az aks nodepool update \
    --resource-group MyResourceGroup \
    --cluster-name MyManagedCluster \
    --name nodepool1 \
    --node-vm-size Standard_D4s_v3 \
    --max-surge 33%

y, opcionalmente, restaure los valores originales --max-surge y --max-unavailable una vez completado el cambio de tamaño.

Creación de un grupo de nodos con el SKU deseado

Nota:

Cada clúster de AKS debe contener al menos un grupo de nodos del sistema con al menos un nodo. En este ejemplo, usamos un --mode de System para agregar un grupo de nodos del sistema y reemplazar el grupo de nodos del sistema que queremos redimensionar. Puede actualizar el modo de un grupo de nodos en cualquier momento. También puede agregar un grupo de nodos de usuario estableciendo --mode en User.

Al cambiar el tamaño, asegúrese de tener en cuenta todos los requisitos de carga de trabajo, como las zonas de disponibilidad, y configure el grupo de nodos de VMSS en consecuencia. Es posible que tenga que modificar el siguiente comando para adaptarse mejor a sus necesidades. Para obtener una lista completa de las opciones de configuración, consulte la az aks nodepool add página de referencia.

  1. Cree un nuevo grupo de nodos mediante el az aks nodepool add comando . En este ejemplo, creamos un nuevo grupo de nodos, , mynodepoolcon tres nodos y la SKU de máquina Standard_DS3_v2 virtual para reemplazar un grupo de nodos existente, nodepool1, que tiene la SKU de máquina Standard_DS2_v2 virtual.

    az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 3 \
    --node-vm-size Standard_DS3_v2 \
    --mode System \
    --no-wait

    El nuevo grupo de nodos tarda unos minutos en crearse.

  2. Obtenga el estado del nuevo grupo de nodos mediante el kubectl get nodes comando .

    kubectl get nodes

    La salida debe ser similar a la siguiente salida de ejemplo, que muestra el nuevo grupo mynodepool de nodos y el grupo de nodos nodepool1existente:

    NAME                                 STATUS   ROLES   AGE   VERSION
aks-mynodepool-98765432-vmss000000   Ready    agent   23m   v1.21.9
aks-mynodepool-98765432-vmss000001   Ready    agent   23m   v1.21.9
aks-mynodepool-98765432-vmss000002   Ready    agent   23m   v1.21.9
aks-nodepool1-12345678-vmss000000    Ready    agent   10d   v1.21.9
aks-nodepool1-12345678-vmss000001    Ready    agent   10d   v1.21.9
aks-nodepool1-12345678-vmss000002    Ready    agent   10d   v1.21.9

Acordonamiento de los nodos existentes

El acordonamiento marca los nodos especificados como no programables e impide que se agregan más pods a los nodos.

  1. Obtenga los nombres de los nodos a los que desea acordonar mediante el kubectl get nodes comando .

    kubectl get nodes

    La salida debe ser similar a la siguiente salida de ejemplo, en la que se muestran los nodos del grupo nodepool1 de nodos existente que desea acordonar:

    NAME                                STATUS   ROLES   AGE     VERSION
aks-nodepool1-12345678-vmss000000   Ready    agent   7d21h   v1.21.9
aks-nodepool1-12345678-vmss000001   Ready    agent   7d21h   v1.21.9
aks-nodepool1-12345678-vmss000002   Ready    agent   7d21h   v1.21.9

  2. Acordone los nodos existentes mediante el comando kubectl cordon, especificando los nodos deseados en una lista separada por espacios. Por ejemplo:

    kubectl cordon aks-nodepool1-12345678-vmss000000 aks-nodepool1-12345678-vmss000001 aks-nodepool1-12345678-vmss000002

    La salida debe ser similar a la siguiente salida de ejemplo, en la que se muestra que los nodos están acordonados:

    node/aks-nodepool1-12345678-vmss000000 cordoned
node/aks-nodepool1-12345678-vmss000001 cordoned
node/aks-nodepool1-12345678-vmss000002 cordoned

Purga de los nodos existentes

Importante

Para purgar correctamente los nodos y quitar los nodos en ejecución, asegúrese de que los PodDisruptionBudgets (PDB) permitan que se mueva al menos una réplica de pod simultáneamente. De lo contrario, se produce un error en la operación de purga o desalojado. Para comprobarlo, puede ejecutar kubectl get pdb -A y asegurarse de que ALLOWED DISRUPTIONS sea 1 o superior.

Al drenar nodos, los pods que se ejecutan en ellos se desalojan y se vuelven a crear en los otros nodos programables.

  1. Drenar los nodos existentes mediante el comando kubectl drain con las marcas --ignore-daemonsets y --delete-emptydir-data, especificando los nodos deseados en una lista separada por espacios. Por ejemplo:

    Importante

    Se requiere el uso de --delete-emptydir-data para quitar los pods coredns y metrics-server creados por AKS. Si no usa esta marca, obtendrá un error. Para obtener más información, consulte la documentación sobre emptydir.

    kubectl drain aks-nodepool1-12345678-vmss000000 aks-nodepool1-12345678-vmss000001 aks-nodepool1-12345678-vmss000002 --ignore-daemonsets --delete-emptydir-data

  2. Una vez finalizada la operación de drenaje, todos los pods (excepto los controlados por conjuntos de demonios) deben ejecutarse en el nuevo grupo de nodos. Puede comprobarlo mediante el comando kubectl get pods.

    kubectl get pods -o wide -A

Solución de problemas de expulsión de pods

Es posible que encuentre el siguiente error al purgar nodos:

Error when evicting pods/[podname] -n [namespace] (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

De manera predeterminada, el clúster tiene presupuestos de interrupción de pods administrados por AKS (como coredns-pdb o konnectivity-agent) con un MinAvailable de 1. Por ejemplo, si hay dos pods coredns en ejecución, solo se puede interrumpir uno a la vez. Mientras uno de ellos se está volviendo a crear y no está disponible, el otro pod coredns no se puede expulsar debido al presupuesto de interrupción del pod. Esto se resuelve solo, después de que el pod coredns inicial esté programado y en ejecución, lo que permite que el segundo pod se expulse y se vuelva a crear correctamente.

Sugerencia

Considere la posibilidad de drenar los nodos uno por uno para que la eliminación sea más fluida y evitar la limitación. Para más información, consulte:

Eliminación del grupo de nodos existente

Importante

Al eliminar un grupo de nodos, AKS no realiza acordonar ni purgar. Para minimizar la interrupción de los pods que se están ejecutando actualmente en el grupo de nodos que planea eliminar, realice un cable y desagüe en todos los nodos del grupo de nodos antes de eliminarlos.

  1. Elimine el grupo de nodos original mediante el az aks nodepool delete comando .

    az aks nodepool delete \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name nodepool1

  2. Compruebe que el clúster de AKS solo tiene el nuevo grupo de nodos con las aplicaciones y los pods que se ejecutan correctamente mediante el comando kubectl get nodes.

    kubectl get nodes

    La salida debe ser similar a la siguiente salida de ejemplo, que muestra solo el nuevo grupo de nodos mynodepool:

    NAME                                 STATUS   ROLES   AGE   VERSION
aks-mynodepool-98765432-vmss000000   Ready    agent   63m   v1.21.9
aks-mynodepool-98765432-vmss000001   Ready    agent   63m   v1.21.9
aks-mynodepool-98765432-vmss000002   Ready    agent   63m   v1.21.9

Pasos siguientes

Después de cambiar el tamaño de un grupo de nodos mediante acordonamiento y purga, obtenga más información sobre el uso de varios grupos de nodos.

  • Last updated on