Compartir a través de

Opciones y recomendaciones de actualización para clústeres de Azure Kubernetes Service (AKS)

En este artículo se describen las opciones de actualización de los clústeres de AKS y se proporcionan recomendaciones basadas en escenarios para los desafíos comunes de actualización.

Opciones de actualización

Realizar actualizaciones manuales

Las actualizaciones manuales le permiten controlar cuándo se actualiza el clúster a una nueva versión de Kubernetes. Resulta útil para probar o tener como destino una versión específica.

Configuración de actualizaciones automáticas

Las actualizaciones automáticas mantienen el clúster en una versión compatible y actualizada. Esto es cuando quiere establecer y olvidar.

Consideraciones especiales para los grupos de nodos que abarcan varias zonas de disponibilidad

AKS usa el equilibrio de zona de mejor esfuerzo en grupos de nodos. Durante un aumento de actualización, las zonas de los nodos de sobrecarga en Virtual Machine Scale Sets son desconocidas con antelación, lo que puede provocar temporalmente una configuración de zona desequilibrada. AKS elimina los nodos de sobrecarga después de la actualización y restaura el equilibrio de zona original. Para mantener las zonas equilibradas, establezca el aumento en un múltiplo de tres nodos. Los PVC que usan discos LRS de Azure están enlazados a zona y pueden provocar tiempo de inactividad si los nodos de sobrecarga están en una zona diferente. Use un Presupuesto de interrupción del pod para mantener alta disponibilidad durante los vaciados.

Optimización de las actualizaciones para mejorar el rendimiento y minimizar las interrupciones

Combine la ventana de mantenimiento planeado, aumento máximo, presupuesto de interrupción del pod, tiempo de espera de purga de nodos, y tiempo de inmersión de nodos para aumentar la probabilidad de actualizaciones correctas y de baja interrupción.

Configuración de actualización Uso de nodos adicionales Comportamiento esperado
maxSurge=5, maxUnavailable=0 5 nodos de sobrecarga 5 nodos sobrecargados para la actualización
maxSurge=5, maxUnavailable=0 Nodos de sobrecarga de 0 a 4 La actualización falla debido a nodos de sobretensión insuficientes.
maxSurge=0, maxUnavailable=5 No disponible 5 nodos existentes purgados para la actualización

Nota:

Antes de actualizar, compruebe si hay cambios importantes en la API y revise las notas de la versión de AKS para evitar interrupciones.

Validaciones usadas en el proceso de actualización

AKS realiza validaciones previas a la actualización para garantizar el estado del clúster:

  • Cambios importantes en la API: Detecta las API en desuso.
  • Versión de actualización de Kubernetes: Garantiza una ruta de actualización válida.
  • Configuración de PDB: Comprueba si hay archivos PDB mal configurados (por ejemplo, maxUnavailable=0).
  • Cuota: Confirma la cuota suficiente para los nodos de sobrecarga.
  • Subred: Comprueba suficientes direcciones IP.
  • Certificados o entidades de servicio: detecta credenciales expiradas.

Estas comprobaciones ayudan a minimizar los errores de actualización y proporcionan visibilidad temprana de los problemas.

Escenarios y recomendaciones comunes de actualización

Escenario 1: Restricciones de capacidad

Si el clúster está limitado por la SKU o la capacidad regional, es posible que se produzca un error en las actualizaciones cuando no se puedan aprovisionar nodos de sobrecarga. Esto es común con SKU especializadas (como nodos de GPU) o en regiones con recursos limitados. Se pueden producir errores como SKUNotAvailable, AllocationFailedo OverconstrainedAllocationRequest si maxSurge se establece demasiado alto para la capacidad disponible.

Recomendaciones para evitar o resolver

  • Usa maxUnavailable para actualizar mediante nodos existentes en lugar de crear nuevos. Más información.
  • Reduzca maxSurge para disminuir las necesidades de capacidad adicionales. Más información.
  • En el caso de las actualizaciones de solo seguridad, use las imágenes de revisiones de seguridad que no requieren nodos de sobrecarga. Más información.

Escenario 2: Errores de purga de nodos y PDB

Las actualizaciones requieren nodos de purga (expulsar pods). Los desagües pueden fallar si:

Ejemplo de mensaje de error:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... failed with Too Many Requests error. This is often caused by a restrictive Pod Disruption Budget (PDB) policy. See https://aka.ms/aks/debugdrainfailures. Original error: Cannot evict pod as it would violate the pod's disruption budget. PDB debug info: ... blocked by pdb ... with 0 unready pods.

Recomendaciones para evitar o resolver

  • Establezca maxUnavailable en PDB para permitir que se expulse al menos un pod.

  • Aumente las réplicas de pod para que el presupuesto de interrupciones pueda tolerar las expulsiones.

  • Use undrainableNodeBehavior para permitir que las actualizaciones continúen incluso si algunos nodos no se pueden purgar:

    • Programación (valor predeterminado): Se puede eliminar el reemplazo de nodos y sobrecargas, lo que reduce la capacidad.
    • Cordón (recomendado): El nodo está acordonado y etiquetado como kubernetes.azure.com/upgrade-status=Quarantined.

      • Comando de ejemplo:

        az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon

        En la salida de ejemplo siguiente se muestra el comportamiento de nodo no purgable actualizado:

        "upgradeSettings": {
"drainTimeoutInMinutes": null,
"maxSurge": "1",
"nodeSoakDurationInMinutes": null,
"undrainableNodeBehavior": "Cordon"
}

  • Amplíe el tiempo de espera de purga si las cargas de trabajo necesitan más tiempo (el valor predeterminado es de 30 minutos).

  • Pruebe los archivos PDB en el almacenamiento provisional, supervise los eventos de actualización y use implementaciones azul-verde para cargas de trabajo críticas. Más información.

Comprobación de nodos que no se pueden detectar

  • Los nodos bloqueados no están programados para los pods y se marcan con la etiqueta "kubernetes.azure.com/upgrade-status: Quarantined".

  • Compruebe la etiqueta en los nodos bloqueados cuando se produzca un error en el nodo de purga al actualizar:

    kubectl get nodes --show-labels=true

Resolución de nodos que no se pueden drenar

  1. Quite el PDB responsable:

    kubectl delete pdb <pdb-name>

  2. Quite la kubernetes.azure.com/upgrade-status: Quarantined etiqueta:

    kubectl label nodes <node-name> <label-name>

  3. Opcionalmente, elimine el nodo bloqueado:

    az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>

  4. Después de completar este paso, puede conciliar el estado del clúster realizando cualquier operación de actualización sin los campos opcionales como se describe aquí. Como alternativa, puede escalar el grupo de nodos al mismo número de nodos que el recuento de nodos actualizados. Esta acción garantiza que el grupo de nodos llegue a su tamaño original previsto. AKS prioriza la eliminación de los nodos bloqueados. Este comando también restaura el estado de aprovisionamiento del clúster en Succeeded. En el ejemplo especificado, 2 es el número total de nodos actualizados.

    # Update the cluster to restore the provisioning status
az aks update --resource-group <resource-group-name> --name <cluster-name>

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2

Escenario 3: Actualizaciones lentas

Las actualizaciones se pueden retrasar mediante la configuración conservadora o los problemas de nivel de nodo, lo que afecta a la capacidad de mantenerse al día con las revisiones y mejoras.

Entre las causas comunes de las actualizaciones lentas se incluyen las siguientes:

  • Valores bajos maxSurge o maxUnavailable (limita el paralelismo).
  • Tiempos de inmersión altos (esperas largas entre las actualizaciones de nodos).
  • Errores de purga (consulte Errores de purga de nodos]).

Recomendaciones para evitar o resolver

  • Para producción: maxSurge=33%, maxUnavailable=1.
  • Para desarrollo/pruebas: maxSurge=50%, maxUnavailable=2.
  • Utilice el parche de seguridad del sistema operativo para aplicar parches rápidos y específicos (evita la reconfiguración completa del nodo).
  • Habilite undrainableNodeBehavior para evitar los bloqueadores de actualizaciones.

Escenario 4: Agotamiento de IP

Los nodos de sobrecarga requieren direcciones IP adicionales. Si la subred está cerca de la capacidad, el aprovisionamiento de nodos puede producir un error (por ejemplo, Error: SubnetIsFull). Esto es común con Azure CNI, altos maxPods o recuentos de nodos grandes.

Recomendaciones para evitar o resolver

  • Asegúrese de que la subred tiene suficientes direcciones IP para todos los nodos, los nodos de sobrecarga y los pods:

    • Fórmula: Total IPs = (Number of nodes + maxSurge) * (1 + maxPods)

  • Reclamar direcciones IP sin usar o expandir la subred (por ejemplo, de /24 a /22).

  • Reducir maxSurge si la expansión de subred no es posible.

    az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --max-surge 10%

  • Supervise el uso de IP con Azure Monitor o alertas personalizadas.

  • Reduzca maxPods por nodo, limpie direcciones IP huérfanas del equilibrador de carga y planee el ajuste de tamaño de subred para clústeres a gran escala.

Pasos siguientes

  • Revise la guía de revisión y actualización de AKS para conocer los procedimientos recomendados y sugerencias de planeación antes de iniciar cualquier actualización.
  • Compruebe siempre si hay cambios importantes en la API y valide la compatibilidad de las cargas de trabajo con la versión de Kubernetes de destino.
  • Pruebe la configuración de actualización (como maxSurge, maxUnavailabley PDB) en un entorno de ensayo para minimizar el riesgo de producción.
  • Supervise los eventos de actualización y el estado del clúster durante todo el proceso.