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

Se aplica a: ✔️ AKS Automatic ✔️ AKS Standard

Para la mayoría de las cargas de trabajo de producción, AKS Automatic es la experiencia de clúster predeterminada recomendada. Proporciona valores predeterminados listos para producción para las operaciones de ciclo de vida de clúster y nodo, incluido el comportamiento de actualización administrada, las medidas de seguridad integradas y la sobrecarga operativa reducida.

AKS Standard sigue estando disponible para escenarios en los que necesita un mayor control manual sobre la mecánica de actualización, las opciones de red o el comportamiento del grupo de nodos.

En este artículo se proporciona una base técnica para las actualizaciones de AKS mediante la cobertura de opciones de actualización, escenarios comunes y recomendaciones para AKS Automatic y AKS Standard.

Lo que trata este artículo

Esta referencia técnica abarca:

• Por qué AKS Automatic es la opción predeterminada recomendada y lista para producción para la mayoría de las cargas de trabajo.
• El comportamiento de actualización difiere entre AKS Automatic y AKS Standard.
• Rutas de actualización manuales frente a automatizadas y cuándo usar cada una.
• Escenarios de actualización comunes con recomendaciones específicas.
• Técnicas de optimización para el rendimiento y una interrupción mínima.
• Procesos de validación y comprobaciones previas a la actualización.

Para obtener instrucciones relacionadas:

• Para obtener información general y valores predeterminados automáticos de AKS, consulte Introducción a Azure Kubernetes Service (AKS) Automático.
• Para obtener detalles de la estrategia de actualización de AKS orientada a producción, consulte Estrategias de actualización de producción de AKS.
• Para conocer los patrones de actualización de cargas de trabajo con estado, consulte Patrones de actualización de cargas de trabajo con estado.
• Para obtener orientación basada en escenarios, consulte Escenarios de actualización de AKS: Elija su ruta.
• Si no está familiarizado con las actualizaciones de AKS, comience con el centro de escenarios de actualización para obtener ayuda guiada.

Navegación rápida

Actualizar modelos operativos

AKS automático (opción predeterminada recomendada para producción)

AKS Automatic está diseñado para funcionar en entornos de producción de forma predeterminada. Para las actualizaciones, AKS Automatic proporciona:

• Grupos de nodos del sistema administrados.
• Comportamiento automático de actualización del clúster con valores predeterminados administrados por la plataforma.
• Comportamiento automático de actualización de imágenes del sistema operativo de nodo con cadencia centrada en la seguridad.
• Comprobaciones integradas para las API de Kubernetes obsoletas.
• Compatibilidad con la programación de mantenimiento planeado.

Use AKS Automatic cuando quiera minimizar la orquestación de actualizaciones manuales y mantener los clústeres de producción alineados con versiones compatibles con menos esfuerzo.

AKS Standard (modelo de control avanzado)

AKS Standard proporciona un control directo sobre la secuenciación de actualizaciones y el ajuste. Elija y administre:

• Configuración de actualización manual o automática.
• Selección del canal de actualización.
• Grupo de nodos y comportamiento ante picos de tráfico.
• Procedimientos operativos relativos a las ventanas de mantenimiento y los presupuestos de interrupción de cargas de trabajo.

Use AKS Standard cuando el entorno requiera personalización que supere los valores predeterminados automáticos de AKS.

Opciones de actualización

Realizar actualizaciones manuales

Se aplica principalmente a AKS Standard o a flujos de trabajo operativos especializados.

Las actualizaciones manuales le permiten controlar cuándo se actualiza el clúster a una nueva versión de Kubernetes. Estas actualizaciones son útiles para pruebas, implementaciones por fases y adopción selectiva de versiones.

• Actualización de un clúster de AKS
• Actualización de varios clústeres de AKS mediante Azure Kubernetes Fleet Manager
• Actualización de la imagen de nodo
• Personalización de la actualización de sobrecargas de nodo
• Procesar actualizaciones del sistema operativo del nodo

Configuración de actualizaciones automáticas

En el caso de AKS Standard, las actualizaciones automáticas ayudan a mantener los clústeres en versiones compatibles, a la vez que conservan el control sobre la directiva y la programación. En AKS Automatic, la automatización de las actualizaciones y los mecanismos de protección ya forman parte del modelo operativo predeterminado.

• Actualización automática de un clúster de AKS
• Actualización automática de varios clústeres de AKS mediante Azure Kubernetes Fleet Manager
• Uso del mantenimiento planeado para programar y controlar las actualizaciones
• Detener las actualizaciones del clúster de AKS automáticamente en los cambios importantes de la API (versión preliminar)
• Actualización automática de las imágenes del sistema operativo del nodo de clúster de AKS
• Aplicar actualizaciones de seguridad a los nodos de AKS automáticamente mediante acciones de GitHub

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

AKS utiliza el equilibrio de zonas best-effort en los grupos de nodos. Durante una oleada de actualizaciones, las zonas para los nodos de expansión en los conjuntos de escalado de máquinas virtuales son desconocidas previamente, lo que temporalmente puede causar una configuración de zonas 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. Las solicitudes de volúmenes persistentes que usan discos de almacenamiento con redundancia local de Azure están vinculadas a zonas y pueden provocar tiempo de inactividad si los nodos de ampliación están en una zona diferente. Use un Presupuesto de interrupciones de pod (PDB) para mantener la alta disponibilidad durante las purgas.

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

Combine la ventana de mantenimiento programada, la sobrecapacidad máxima, PDB, el tiempo de espera para el vaciado del nodo y el tiempo de estabilización del nodo para aumentar la probabilidad de realizar actualizaciones exitosas y con pocas interrupciones.

AKS Automatic

En AKS Automatic, el comportamiento de actualización de nivel de plataforma está preconfigurado. Céntrese en la optimización de la resistencia de la carga de trabajo y la preparación de la capacidad:

• Valida los presupuestos de interrupción de pods y el número de réplicas.
• Asegúrese de que haya suficiente cuota y capacidad de subred para el crecimiento previsto.
• Establezca las programaciones de mantenimiento planeado alineadas con períodos de bajo tráfico.
• Supervise los eventos de actualización y la preparación de la carga de trabajo crítica.

AKS Standard

En AKS Standard, ajuste los controles de actualización directamente:

• Ventana de mantenimiento planeado: programe la actualización automática durante períodos de bajo tráfico. Use al menos cuatro horas.
• Sobrecarga máxima: los valores más altos aceleran las actualizaciones, pero pueden interrumpir las cargas de trabajo. Utiliza el 33 % para producción.
• Número máximo no disponible: use cuando la capacidad esté limitada.
• Presupuesto de interrupciones de pods: se establece para limitar los pods durante las actualizaciones. Valide el servicio.
• Tiempo de espera de purga de nodo: aquí se configura la duración de espera de expulsión del pod. El valor predeterminado es 30 minutos.
• Tiempo de inmersión del nodo: Escalonar las actualizaciones para minimizar el tiempo de inactividad. El valor predeterminado es 0 minutos.

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.
• Comprobación de bloqueo de recursos administrados: Comprueba si hay bloqueos de recursos aplicados al grupo de recursos del clúster administrado.

Estas comprobaciones se aplican en AKS. En AKS Automatic, se integran en la ruta de actualización administrada; en AKS Standard, forman parte del flujo de trabajo operativo.

Escenarios y recomendaciones comunes de actualización

Escenario 1: Restricciones de capacidad

Si el clúster está limitado por el nivel de producto o la capacidad regional, es posible que se produzca un error en las actualizaciones cuando no se puedan aprovisionar nodos de sobrecarga. Esta situación es común con los niveles de producto especializados (como los 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.

Guía automática de AKS

• Mantenga las ventanas de mantenimiento programadas.
• Validar la cuota de la suscripción y la capacidad disponible de la subred antes de los períodos de actualización previstos.
• Mantenga los presupuestos de escalado de cargas de trabajo e interrupciones alineados con las ventanas de mantenimiento.

Guía estándar de AKS

• Use maxUnavailable para actualizar utilizando nodos existentes en vez de desplegar nuevos. Para obtener más información, consulte Personalización de nodos no disponibles durante la actualización.
• Reduzca maxSurge para disminuir las necesidades de capacidad adicionales. Para más información, consulte Personalización de la actualización de sobrecarga de nodos.
• En el caso de las actualizaciones de solo seguridad, use las imágenes de revisiones de seguridad que no requieren nodos de sobrecarga. Para más información, consulte Aplicación de actualizaciones de seguridad y kernel a los nodos de Linux en Azure Kubernetes Service.

Escenario 2: Errores de purga de nodos y PDB

Las actualizaciones requieren nodos de purga (expulsar pods). Las purgas pueden producir errores cuando los pods tardan en finalizarse o los presupuestos estrictos de Interrupciones de pods (PDB) bloquean las expulsiones de pods.

Error de ejemplo:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

Guía automática de AKS

• Trate la estrategia de réplica y PDB como los controles de confiabilidad principales.
• Valida los presupuestos de interrupción en el entorno de prueba antes del despliegue en producción.
• Mantener las cargas de trabajo críticas configuradas para garantizar el éxito del desalojo gradual.

Guía estándar de AKS

Opción 1: Forzar actualización, omitir restricciones PDB

Use la actualización forzada solo cuando los archivos PDB impidan actualizaciones críticas y no se puedan resolver. Esta acción invalida las protecciones de PDB y puede provocar una falta de disponibilidad completa del servicio durante la actualización.

Requisitos: CLI de Azure 2.79.0+ o la versión 2025-09-01 o posterior de la API de AKS

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

Opción 2: Gestionar nodos no drenables respetando los PDB

Use este enfoque conservador para respetar las PDB al tiempo que impide errores de actualización.

Configurar el comportamiento del nodo no drenable:

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

Opciones de comportamiento:

• Programación (valor predeterminado): elimina el nodo bloqueado y aumenta el reemplazo.
• Cordon (recomendado): Aísla el nodo y lo etiqueta como kubernetes.azure.com/upgrade-status=Quarantined.

Número máximo de nodos bloqueados (versión preliminar):

• Especifica cuántos nodos que fallan en drenar son tolerados.
• Es necesario establecer undrainable-node-behavior
• El valor predeterminado es maxSurge (normalmente 10%) si no se especifica
• Al igual que el aumento máximo, si el valor calculado es mayor que el número de nodos restantes que se van a actualizar en la operación actual, se usa el número de nodos restantes que se van a actualizar en su lugar.

Requisitos previos para el número máximo de nodos bloqueados

La extensión de la CLI aks-preview de Azure versión 18.0.0b9 o posterior es necesaria para usar la característica de nodos bloqueados máximos.

# Install or update the aks-preview extension
az extension add --name aks-preview
az extension update --name aks-preview

Configuración de ejemplo con nodos bloqueados máximos

az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5

Opción 3: Administración automática de PDB (versión preliminar)

Use la extensión de administración automática de PDB para resolver de forma proactiva las purgas bloqueadas por PDB sin omitir las protecciones de PDB ni requerir la limpieza manual de los nodos en cuarentena. La gestión automática de PDB detecta cuándo un PDB impide la expulsión en un nodo acordonado y aumenta temporalmente el número de réplicas de la implementación para que se respete el margen de interrupción. Una vez completado el vaciado, vuelve a ajustar el número de réplicas a su valor original.

La gestión automática de PDB también puede crear automáticamente PDB para las implementaciones que no dispongan de uno, lo que garantiza que sus cargas de trabajo estén protegidas durante las purgas de actualización. Para obtener información detallada sobre la instalación y la configuración, consulte Administrar automáticamente los presupuestos de interrupción de pods durante las actualizaciones de AKS.

Recomendaciones para prevenir fallos de drenaje

• Se establece maxUnavailable en PDB para permitir al menos una expulsión de pod
• Aumento de las réplicas de pod para cumplir los requisitos del presupuesto de interrupciones
• Extienda el tiempo de espera de drenaje si las tareas de trabajo necesitan más tiempo. (El valor predeterminado es 30 minutos).
• Use la administración automática de PDB para automatizar la creación y el escalado de réplicas de PDB durante las operaciones de purga.
• 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. Para más información, consulte Implementación azul-verde de clústeres de AKS.

Comprobación de nodos que no se pueden vaciar

• 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> kubernetes.azure.com/upgrade-status-
   

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 finalizar este paso, puede conciliar el estado del clúster realizando cualquier operación de actualización sin los campos opcionales, como se describe en az aks. 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 siguiente, 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

La configuración conservadora o los problemas de nivel de nodo pueden retrasar las actualizaciones, lo que afecta a la capacidad de mantenerse al día con 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).

Guía automática de AKS

• Mantenga las programaciones de mantenimiento actualizadas.
• Supervisa el estado de los eventos de actualización y el estado de preparación de la carga de trabajo.
• Resuelva con rapidez los problemas de bloqueo de PDB o de capacidad para evitar retrasos prolongados.

Guía estándar de AKS

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

Escenario 4: Agotamiento de IP

Los nodos de sobrecarga requieren más direcciones IP. Si la subred está cerca de su capacidad, la configuración de nodos puede fallar (por ejemplo, Error: SubnetIsFull). Este escenario es común con los recuentos de nodos Azure Container Networking Interface, maxPods altos o números elevados de nodos.

Guía automática de AKS

• Valide los planes de subred y capacidad antes de la expansión de producción.
• Supervise el uso de la red como parte de las operaciones rutinarias.

Guía estándar de AKS

• Asegúrese de que la subred tenga suficientes direcciones IP para todos los nodos, los nodos de sobrecarga y los pods. La fórmula es Total IPs = (Number of nodes + maxSurge) * (1 + maxPods).

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

• Reduzca maxSurge si no es posible ampliar la subred.

  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.

Preguntas más frecuentes

¿Debo usar AKS Automatic o AKS Standard para las actualizaciones de producción?

Para la mayoría de las cargas de trabajo de producción, use AKS Automatic. Está diseñado para ser la opción predeterminada preparada para producción, con un comportamiento de actualización gestionado y mecanismos de protección integrados.

Use AKS Standard cuando necesite un control manual avanzado sobre la secuenciación de actualizaciones, las opciones de infraestructura o las operaciones del grupo de nodos.

¿Puedo usar herramientas de código abierto para la validación?

Sí. Muchas herramientas de código abierto se integran bien con los procesos de actualización de AKS:

• Trivy: análisis de seguridad para imágenes de contenedor y configuraciones de Kubernetes.
• Sonobuoy: pruebas de conformidad de Kubernetes y validación de clústeres.
• kube-bench: Pruebas comparativas de seguridad según los estándares del Center for Internet Security.
• Polaris: validación de los procedimientos recomendados de Kubernetes.
• kubectl-neat: limpie los manifiestos de Kubernetes para la validación.

¿Cómo se valida la compatibilidad de api antes de actualizar?

Ejecución de comprobaciones de desuso mediante herramientas como kubent:

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

¿Qué hace que las actualizaciones de AKS difieren de otras plataformas de Kubernetes?

AKS proporciona varias ventajas únicas:

• Rutas operativas administradas en AKS Automatic para reducir la sobrecarga de actualización.
• Integración nativa de Azure con Azure Traffic Manager, Azure Load Balancer y redes.
• Azure Kubernetes Fleet Manager para actualizaciones multicluster coordinadas.
• Aplicación automática de parches de imágenes del nodo sin administración manual de nodos.
• Validación integrada de cuotas, redes y credenciales.
• Soporte de Azure para problemas relacionados con la actualización.

Elección de la ruta de actualización

Este artículo le proporcionó una base técnica. Ahora seleccione su ruta basada en casos.

¿Listo para ejecutar?

¿Sigue decidiendo?

Use el centro de escenarios de actualización para un árbol de decisión guiado que tenga en cuenta lo siguiente:

• Tolerancia al tiempo de inactividad
• Complejidad del entorno
• Perfil de riesgo
• Restricciones de la línea de tiempo

Recomendaciones finales

• Use AKS Automatic para la mayoría de las cargas de trabajo de producción.
• 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 la carga 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.