Administración automática de Pod Disruption Budget en AKS (versión preliminar)

Durante las actualizaciones del clúster de AKS, el proceso de actualización vacía los nodos desalojando los pods para poder recrear la imagen de los nodos o reemplazarlos. Los presupuestos de interrupciones de pods (PDB) protegen la disponibilidad de las aplicaciones durante este proceso limitando el número de pods que pueden no estar disponibles a la vez. Sin embargo, los archivos PDB mal configurados también pueden bloquear la expulsión por completo o las implementaciones podrían no tener suficientes réplicas para satisfacer el presupuesto. Las implementaciones que no cuentan con ningún PDB presentan el problema contrario: nada protege a sus pods de ser expulsados simultáneamente, lo que conlleva el riesgo de que se produzcan interrupciones del servicio durante las actualizaciones.

La administración automática de PDB es una extensión de AKS, basada en el proyecto de código abierto, que automatiza la administración de PDB durante las actualizaciones. Este:

• Crea archivos PDB automáticamente para las implementaciones que no tienen una, por lo que las cargas de trabajo se protegen durante las interrupciones voluntarias.
• Aumenta temporalmente el número de réplicas cuando un PDB bloquea la expulsión de pods en un nodo marcado como no programable, de modo que se respete el presupuesto de interrupciones y pueda continuar el vaciado del nodo.
• Vuelve a reducir el número de réplicas una vez completados los desalojos, para que no pague por capacidad extra más allá de la que requiere la actualización.

El resultado es que las actualizaciones se completan de manera fiable sin necesidad de eludir por la fuerza las protecciones de PDB ni de resolver manualmente los nodos en cuarentena. Para obtener información sobre cómo las actualizaciones de AKS drenan los nodos y cómo los PDB afectan a ese proceso, consulte Cómo funcionan las actualizaciones del clúster de AKS.

Cuándo usar la administración automática de PDB

Considere la posibilidad de habilitar la administración automática de PDB cuando:

• Las implementaciones carecen de PDB. Los pods se expulsan sin garantías de disponibilidad durante las actualizaciones, lo que provoca un posible tiempo de inactividad.
• Los PDB bloquean el drenado de nodos. Una PDB con minAvailable igual al número de réplicas (o maxUnavailable: 0) impide expulsar cualquier pod, lo que provoca que la actualización falle con un error como Cannot evict pod as it would violate the pod's disruption budget.
• Las réplicas no son suficientes para el presupuesto de interrupciones. La PDB existe y está configurada correctamente, pero la implementación no tiene suficientes réplicas para absorber incluso una expulsión.
• Usted experimenta errores frecuentes de purga de actualización y quiere una resolución automatizada y proactiva en lugar de una limpieza manual.

Identificación de errores de purga relacionados con PDB

Antes de habilitar la administración automática de PDB, compruebe si el clúster está experimentando errores de purga relacionados con PDB:

• Registro de actividad de Azure En el portal de Azure, abra el recurso del clúster de AKS y seleccione Registro de actividad. Busque las operaciones de actualización fallidas con estado Failed y mensajes que hacen referencia a presupuestos de interrupción de pods o errores de expulsión.

• Eventos de Kubernetes. Ejecute el siguiente comando para buscar eventos de expulsión y purga recientes:

  kubectl get events --sort-by='.lastTimestamp' -A | grep -i "disruption\|evict\|drain"
  

  Para obtener una guía completa sobre cómo trabajar con eventos de Kubernetes, consulte Eventos de Kubernetes.

Comparación con otras opciones

Cómo funciona

La administración automática de PDB tiene dos comportamientos complementarios: creación automática de PDB (proactiva) y escalado de réplicas durante el drenaje (reactivo).

Creación automática de PDB

Al habilitar la creación automática de PDB (controllerConfig.pdb.create=true), la extensión supervisa continuamente las implementaciones que no tienen una PDB. La extensión determina si hay una coincidencia comparando el selector de etiquetas del PDB con las etiquetas de la plantilla de pods de la implementación. Esta comparación garantiza que cada implementación esté protegida solo una vez y evite archivos PDB duplicados. Cuando encuentra una implementación desprotegida en un espacio de nombres habilitado, crea una PDB. En el caso de las implementaciones sin HPA o KEDA, minAvailable se establece en el recuento de réplicas actual de la implementación. En el caso de las implementaciones con HPA o KEDA, minAvailable realiza un seguimiento del nivel mínimo de réplica del escalador automático, por lo que el comportamiento de PDB permanece alineado con las restricciones del escalador automático. La extensión reconcilia continuamente los PDB creados automáticamente, por lo que, si cambia el número de réplicas del despliegue (por ejemplo, mediante una actualización manual o un escalador externo), el valor de minAvailable del PDB se actualiza para ajustarse a él. Esta protección garantiza que los pods no sean expulsados simultáneamente durante las interrupciones voluntarias.

Los PDB creados automáticamente son gestionados por la extensión durante todo su ciclo de vida. Para más información sobre la propiedad, la limpieza y cómo tomar el control manual, consulte Propiedad y limpieza de PDB.

Escalado de réplicas durante el drenaje

La extensión supervisa su clúster para detectar situaciones en las que los pods protegidos por PDB no puedan ser desalojados durante las operaciones de vaciado de nodos. Esto es lo que sucede durante una actualización típica:

1. AKS acordona un nodo como parte del proceso de actualización, lo que lo marca como no programado.
2. La extensión detecta el cordón y comprueba si los pods protegidos por PDB en ese nodo tienen cero interrupciones permitidas.
3. Si el PDB bloquea la expulsión, la extensión aumenta temporalmente el número de réplicas de la implementación en el número de pods protegidos por el PDB en nodos acordonados (hasta el límite maxSurge configurado de la implementación), lo que garantiza que la sobrecarga tenga el tamaño adecuado y evita el aprovisionamiento excesivo. Las réplicas adicionales están programadas en otros nodos disponibles.
4. Las interrupciones permitidas del PDB aumentan por encima de cero, ya que el número total de pods en buen estado supera ahora el umbral de minAvailable del PDB.
5. El drenaje del nodo continúa normalmente. La API de expulsión ahora puede quitar pods del nodo acordonado sin infringir el PDB.
6. Cuando las señales de expulsión cesan y las interrupciones permitidas vuelven a ser superiores a cero, la extensión restablece la implementación a su número original de réplicas. La reducción vertical no se llevará a cabo si todavía hay más nodos acordonados o si el vaciado está en curso. Esta condición evita renovaciones innecesarias durante los vaciados de varios nodos. La reducción se produce automáticamente después de un periodo de espera (60 segundos de forma predeterminada), sin que se necesite intervención manual.

Coordinación con escaladores automáticos (HPA y KEDA)

Las implementaciones suelen administrarse mediante un escalador automático. Para evitar condiciones de carrera en las que el escalador automático vuelva a reducir la implementación antes de que finalicen las expulsiones, la extensión ajusta el mínimo del escalador automático (no solo el número de réplicas) y restaura el valor original cuando finaliza el drenaje.

Para comprobar la vista que ofrece la extensión de una implementación, incluido cualquier estado Degraded de una configuración del escalador automático no admitida:

kubectl get evictionautoscalers -A -o yaml

Requisitos previos

Antes de instalar la extensión de administración de PDB automática, asegúrese de que tiene lo siguiente:

• Un clúster de AKS que ejecuta una versión de Kubernetes compatible.
• Cargas de trabajo que utilizan Deployments. StatefulSets no se admite y no se recomienda usar la administración automática de PDB con StatefulSets.
• CLI de Azure versión 2.64.0 o posterior. Ejecute az --version para comprobarlo. Para la instalación o la actualización, consulte Instalación de la CLI de Azure.
• Proveedor Microsoft.KubernetesConfiguration registrado en la suscripción.
• El clúster de AKS debe usar una identidad administrada (no una entidad de servicio). Las extensiones de clúster no funcionan con clústeres basados en entidades de servicio. Para más información, consulte Extensiones de clúster de AKS.

Permisos de extensión

La extensión de administración automática de PDB requiere permisos para leer y escribir implementaciones, presupuestos de interrupciones de pods y eventos en los espacios de nombres que administra. La extensión instala su propia cuenta de servicio y roles de RBAC durante la instalación. Para obtener la lista completa de roles y permisos, consulte el repositorio de proyectos en GitHub.

Registro del proveedor de configuración

Si no ha usado Azure extensiones de Kubernetes antes, registre el proveedor necesario:

az feature register --namespace Microsoft.KubernetesConfiguration --name Extensions

# Verify registration status
az feature show --namespace Microsoft.KubernetesConfiguration --name Extensions

# After the feature shows "Registered", refresh the provider
az provider register -n Microsoft.KubernetesConfiguration

Instalación de la administración automática de PDB

La administración automática de PDB se instala como una extensión en el clúster de AKS. Elija una opción de instalación en función de sus necesidades.

Instalación básica

Instale la extensión con la configuración predeterminada. En este modo, la extensión supervisa las expulsiones bloqueadas por PDB en el espacio de nombres kube-system, pero no crea automáticamente PDB para las implementaciones desprotegidas. El espacio de nombres kube-system se incluye de forma predeterminada porque los componentes del sistema gestionados por AKS también usan PDB que pueden bloquear el drenaje de nodos durante las actualizaciones:

az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --auto-upgrade-minor-version true

Instalación con creación automática de PDB para espacios de nombres específicos

Habilite la creación automática de PDB y especifique qué espacios de nombres debe proteger la extensión. Esta es la configuración recomendada para la mayoría de los clústeres:

az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --configuration-settings controllerConfig.pdb.create=true controllerConfig.namespaces.actionedNamespaces="{kube-system,production}" \
    --auto-upgrade-minor-version true

Instalación con protección en todo el clúster

Habilite la creación automática de PDB en todos los espacios de nombres:

az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --configuration-settings controllerConfig.pdb.create=true controllerConfig.namespaces.enabledByDefault=true \
    --auto-upgrade-minor-version true

Opciones de configuración

La siguiente configuración controla cómo se comporta la administración automática de PDB:

Problemas de configuración comunes

Control de espacio de nombres

La extensión funciona en uno de dos modos según la configuración enabledByDefault.

Dos controles complementarios rigen en qué espacios de nombres actúa la extensión:

• controllerConfig.namespaces.actionedNamespaces establece la lista de líneas base en tiempo de instalación y es la manera más fácil de habilitar un conjunto conocido de espacios de nombres.
• La anotación de espacio de nombres eviction-autoscaler.azure.com/enable (o disable) permite a los operadores del clúster incluir o excluir espacios de nombres en tiempo de ejecución sin necesidad de reinstalar la extensión.

Modo de participación (valor predeterminado)

Cuando enabledByDefault es false, solo se habilitan los espacios de nombres enumerados en actionedNamespaces. Puede habilitar espacios de nombres adicionales individualmente agregando una anotación:

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  annotations:
    eviction-autoscaler.azure.com/enable: "true"

Modo de exclusión

Cuando enabledByDefault es true, todos los espacios de nombres están habilitados. Puede excluir espacios de nombres específicos agregando una anotación:

apiVersion: v1
kind: Namespace
metadata:
  name: my-excluded-namespace
  annotations:
    eviction-autoscaler.azure.com/enable: "false"

Excluir implementaciones específicas

Para evitar que la extensión cree una PDB para una implementación específica, agregue la siguiente anotación a la implementación:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  annotations:
    eviction-autoscaler.azure.com/pdb-create: "false"

Creación automática de PDB

Cuando controllerConfig.pdb.create se establece en true, la extensión crea archivos PDB para implementaciones que cumplen los siguientes criterios:

• La implementación aún no tiene una PDB coincidente.
• La implementación se encuentra en un espacio de nombres habilitado.
• El despliegue no se excluye mediante la anotación eviction-autoscaler.azure.com/pdb-create: "false".

Los PDB creados automáticamente establecen minAvailable en función del origen de escalado de la carga de trabajo. En el caso de implementaciones sin HPA o KEDA, minAvailable coincide con el recuento de réplicas actual de la implementación (excepto las réplicas de sobrecarga agregadas por la extensión). Para implementaciones con HPA o KEDA, minAvailable coincide con el suelo de réplicas mínimas del escalador automático. Esto significa que la expulsión quede bloqueado hasta que la extensión amplíe la implementación; en ese momento, las réplicas adicionales cumplirán con el presupuesto y permitirán que la purga continúe.

Titularidad y limpieza de PDB

Los archivos PDF creados por la extensión se marcan con una ownedBy: EvictionAutoScaler anotación. Estos archivos PDB propiedad del controlador se eliminan automáticamente cuando:

• Se elimina el despliegue principal.
• El espacio de nombres se elimina del ámbito de la extensión.
• La extensión se elimina del clúster. Los PDB con la anotación ownedBy: EvictionAutoScaler se eliminan mediante la recolección de basura de Kubernetes.

Las PDB que cree manualmente nunca se modificarán o eliminarán mediante la extensión.

Para tomar el control manual de una PDB creada por la extensión, quite la anotación de propiedad. Después de quitar esta anotación, la extensión ya no administra esa PDB y es responsable de actualizarla o eliminarla:

kubectl annotate pdb <pdb-name> -n <namespace> ownedBy-

Comprobación de la instalación

Después de instalar la extensión, compruebe que la administración automática de PDB funciona correctamente.

1. Compruebe que los archivos PDB se crearon para las implementaciones en espacios de nombres habilitados. Filtre los archivos PDB creados por la extensión:

   kubectl get pdb -A -o custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace,MIN-AVAILABLE:.spec.minAvailable,OWNER:.metadata.annotations.ownedBy | grep EvictionAutoScaler
   

2. Compruebe los recursos personalizados de administración automática de PDB:

   kubectl get evictionautoscalers --all-namespaces
   

3. Pruebe con un cable de nodo (opcional). En un entorno de prueba o preproducción, marca un nodo como no programable y comprueba que la extensión escala la implementación y que las interrupciones permitidas por el PDB aumentan por encima de cero:

   # Cordon a node
   NODE=$(kubectl get pods -n <namespace> -l app=<app-label> -o=jsonpath='{.items[0].spec.nodeName}')
   kubectl cordon $NODE
   
   # Watch for automatic PDB management events
   kubectl get events -n <namespace> --sort-by='.lastTimestamp'
   
   # Check that the deployment scaled up
   kubectl get pods -n <namespace>
   
   # Verify PDB allowed disruptions
   kubectl get poddisruptionbudget <pdb-name> -n <namespace> -o yaml
   
   # After verification, uncordon the node
   kubectl uncordon $NODE
   

Actualizar o quitar la extensión

Actualización de la configuración

Para cambiar las opciones de configuración, elimine y vuelva a crear la extensión con la nueva configuración:

# Delete the existing extension
az k8s-extension delete \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --name eviction-autoscaler \
    --yes

# Recreate with new configuration
az k8s-extension create \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --extension-type microsoft.evictionautoscaler \
    --name eviction-autoscaler \
    --resource-group <resource-group-name> \
    --release-train stable \
    --configuration-settings controllerConfig.pdb.create=true controllerConfig.namespaces.enabledByDefault=true \
    --auto-upgrade-minor-version true

Eliminación de la extensión

Para desinstalar la administración automática de PDB:

az k8s-extension delete \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --cluster-type managedClusters \
    --name eviction-autoscaler \
    --yes

Limitaciones y consideraciones

• Las actualizaciones de configuración requieren eliminar y volver a crear la extensión.
• La gestión automática de PDB solo funciona con Deployments. StatefulSets no se admite y no se recomienda usar esta extensión con StatefulSets.
• La administración automática de PDB no invalida ni modifica los ARCHIVOS PDB existentes. Funciona con ellas ajustando el número de réplicas.
• La administración automática de PDB se coordina con un único escalador automático por despliegue (HPA o KEDA). No se admite una implementación administrada por KEDA y por una HPA independiente; la extensión se marca a sí misma Degraded y omite la sobreasignación. Consulte Coordinación con escaladores automáticos (HPA y KEDA).
• La administración automática de PDB es independiente de la configuración de actualización del grupo de nodos. No es necesario cambiar la configuración como max-surge, tiempo de espera de purga de nodos, tiempo de inmersión de nodo y estrategia de actualización (gradual frente a azul-verde) para que esta extensión funcione y la extensión no cambia el comportamiento de esa configuración.
• La ampliación temporal de la réplica requiere que haya capacidad disponible en el clúster. Si ningún nodo tiene espacio para los pods adicionales, considere la posibilidad de habilitar el escalador automático del clúster o el aprovisionamiento automático de nodos (NAP) para que se puedan aprovisionar nuevos nodos.

Solución de problemas

Para ver los síntomas, las causas y las soluciones, consulte el centro de solución de problemas de AKS: Solución de problemas de Azure Kubernetes Service.

Para inspeccionar la actividad de extensión directamente en el clúster, ejecute:

kubectl get evictionautoscalers -A -o yaml
kubectl get events -A --sort-by='.lastTimestamp'

Contenido relacionado

• Opciones y recomendaciones de actualización : incluye escenario 2: errores de purga de nodos y PDB, con varias opciones de resolución.
• Funcionamiento de las actualizaciones de clústeres de AKS : explica el proceso de actualización gradual paso a paso y lo que sucede cuando un clúster PDB bloquea la purga de nodos.
• Procedimientos recomendados para los presupuestos de interrupción de pods (PDB): orientación sobre la configuración de los PDB para garantizar una alta disponibilidad.
• Documentación de Kubernetes: presupuestos de interrupción de pods: referencia oficial de PDB.
• Proyecto de administración automática de PDB en GitHub: código fuente y referencia técnica detallada.