¿Cuándo debo usar el autoescalado horizontal de pods (HPA) en Kubernetes?

Respuesta corta: usa HPA cuando tu carga de trabajo puede ejecutarse en varias réplicas idénticas y la demanda fluctúa — escala en función de la CPU/memoria, de métricas de la aplicación (RPS/latencia) o de métricas externas de cola/acumulación de trabajo. No utilice HPA para servicios con estado de una sola réplica ni cuando el verdadero cuello de botella sea la capacidad del nodo o las limitaciones de sistemas dependientes (conexiones de base de datos, límites de tasa de terceros).

TL;DR:

• Utilice HPA para cargas de trabajo que puedan particionarse horizontalmente y en las que las métricas por pod o externas reflejen la carga.
• Use métricas de recursos/personalizadas/externas (CPU, RPS, profundidad de cola); combínelas con Cluster Autoscaler para la capacidad de los nodos.
• Utilice KEDA para el escalado a cero controlado por eventos o para escaladores externos; utilice VPA en modo de recomendación para dimensionar las solicitudes de recursos.

Lista de comprobación rápida de decisiones (Sí/No)::

• ¿La carga de trabajo es sin estado o puede particionarse entre muchas réplicas? (Sí → candidato de HPA)
• ¿Puede observarse la carga como métrica por pod o como métrica externa (CPU, solicitudes/s, profundidad de cola)? (Sí → HPA apropiado)
• ¿Puede el clúster asignar más pods (Cluster Autoscaler o capacidad disponible)? (Sí → continuar; si no, habilite el escalado automático de nodos)
• ¿Los servicios de bajada (grupos de bases de datos, API de terceros) limitan la simultaneidad? (Sí → agregar limitación o agrupación de conexiones o preferir el escalado vertical)

Matriz de decisión (carga de trabajo → mejor métrica → escalador recomendado):

Funcionamiento de HPA (bucle de control simple y campos importantes)

• Componentes: el controlador HPA (plano de control) + proveedores de métricas (metrics-server para métricas de recursos, API de métricas personalizadas o externas a través de adaptadores o KEDA).
• Bucle de control (a alto nivel): el controlador HPA consulta la API de métricas → calcula desiredReplicas para cada métrica configurada → toma el valor de desiredReplicas calculado más alto → aplica los valores mínimo y máximo y el comportamiento (políticas/estabilización) → actualiza spec.replicas en el recurso de destino → repite. Consulte los documentos de HPA de Kubernetes para más información.
• Fórmula (cómo se calculan las réplicas deseadas): desiredReplicas = ceil(current_total/target_per_pod). El controlador calcula un valor de desiredReplicas para cada métrica configurada y, a continuación, usa el valor más alto antes de aplicar los valores mínimo y máximo y el comportamiento (este comportamiento de precedencia de métricas se documenta en la documentación de HPA).
• Campos importantes de escalado automático v2: minReplicas, maxReplicas, metrics (Resource, Pods, Object, External), behavior (políticas de scaleUp/scaleDown y stabilizationWindowSeconds).
• Utilice el comportamiento para limitar la tasa de cambio y evitar oscilaciones; stabilizationWindowSeconds es un parámetro clave para suavizar scaleDown.

Fragmento de código de comportamiento de ejemplo (escalado automático/v2)

behavior:
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
      - type: Percent
        value: 100
        periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
      - type: Pods
        value: 1
        periodSeconds: 60

Cuándo usar HPA (por tipo de métrica o casos de uso comunes)

1. CPU/memoria (métricas de recursos)
   • Utilice HPA cuando la utilización de CPU o memoria por pod se correlacione con las necesidades de capacidad y los pods tengan definidas correctamente las solicitudes de recursos. Típico para las API web y los microservicios sin estado.
   • Punto de partida práctico: establezca una utilización media objetivo de la CPU en el intervalo del 60 al 80 % y ajústela mediante pruebas de carga. HPA calcula el uso de las solicitudes de pod, por lo que se deben establecer las solicitudes.
2. Métricas personalizadas en clúster (Prometheus/métricas personalizadas)
   • Use HPA cuando las señales de nivel de aplicación (solicitudes por segundo, latencia, consumidores de colas/pod) representen mejor la carga que la CPU.
   • Exponga métricas con Prometheus + prometheus-adapter (custom.metrics.k8s.io) u otro proveedor de métricas personalizado y dirija esas métricas a HPA.
3. Métricas externas (colas, trabajos pendientes en la nube)
   • Use HPA (a través de la API de métricas externas) o KEDA cuando el escalado debe reaccionar a señales externas como la longitud de la cola (RabbitMQ, Azure Service Bus), Event Hubs o las métricas de supervisión en la nube.
   • Si necesitas escalado a cero o un comportamiento basado en eventos muy preciso, opta por KEDA: integra de forma nativa escaladores externos y admite el escalado a cero (documentación de KEDA).

Cuándo NO usar HPA

• Servicios con estado de una sola réplica (bases de datos, estado único dentro del pod): HPA no es adecuado a menos que se puedan fragmentar o particionar de forma segura.
• Cuando el cuello de botella está a nivel de nodo (GPU, E/S de disco, CPU del nodo) en lugar de a nivel de pod: conviene priorizar el autoescalado del grupo de nodos o el escalado vertical.
• Cuando los sistemas posteriores (pools de conexiones a bases de datos, cachés, API de terceros) tienen límites estrictos de concurrencia: escalar los pods sin aumentar la capacidad de los sistemas posteriores puede agravar los fallos; consulte «Consideraciones sobre sistemas posteriores y operativas» más abajo.
• Si necesita escalado a cero, un HPA por sí solo no puede hacerlo; use KEDA o un controlador externo.

Varias métricas, precedencia y un ejemplo

• Si configura varias métricas, el controlador HPA calcula un valor desiredReplicas para cada métrica de forma independiente y, a continuación, selecciona las instancias desiredReplicas más grandes como base para el escalado. Después, se aplican las directivas minReplicas/maxReplicas y de comportamiento (origen: documentos de HPA de Kubernetes).
• Ejemplo: el objetivo de CPU calcula 5 réplicas, el objetivo de solicitudes por segundo calcula 12 réplicas → HPA elegirá 12 (luego, las políticas de comportamiento y de mínimo/máximo pueden modificar el cambio final que se aplique).
• Para evitar un sobreescalado repentino, combine una política de `scaleUp` basada en porcentaje y un valor razonable de `scaleDown` `stabilizationWindowSeconds` (consulte el fragmento de comportamiento anterior).

HPA frente a VPA frente a Cluster Autoscaler frente a KEDA (guía corta)

• HPA: escala horizontalmente las réplicas en función de las métricas. Ideal para cargas de trabajo que se pueden particionar.
• VPA: ajusta las solicitudes y los límites de recursos del pod (vertical). Ideal para cargas de trabajo no paralelizables o para establecer valores predeterminados razonables.
• Escalador automático de clústeres (o Karpenter): escala los nodos para satisfacer las solicitudes de programación (capacidad de nivel de nodo). Úselo cuando los pods sigan en estado Pending debido a la falta de nodos.
• KEDA: escalador automático impulsado por eventos que integra disparadores externos y permite el escalado a cero para cargas de trabajo basadas en eventos.

Patrón común: usar el VPA en modo de recomendación para establecer las solicitudes base, el HPA para escalar el número de réplicas y Cluster Autoscaler (o Karpenter) para proporcionar capacidad de nodos. Utilice KEDA cuando necesite escalado a cero o integración directa con fuentes de eventos externas.

Nota: Las ofertas administradas de Kubernetes (AKS/GKE/EKS) pueden preinstalar proveedores de métricas o proporcionar características integradas del escalador automático. Documentación de Cluster Autoscaler de AKS

Consideraciones operativas y para fases posteriores (problemas habituales)

• Grupos de conexiones de base de datos: el aumento de las réplicas aumenta las conexiones simultáneas. Mitigue esto mediante el uso de un pool de conexiones (p. ej., PgBouncer), limitando la concurrencia por pod o aumentando el tamaño del pool de conexiones a la base de datos antes de escalar los pods.
• Límites de velocidad de API y cuotas de terceros: asegúrese de que los sistemas de bajada puedan controlar el volumen de solicitudes que producen los pods escalados; considere la limitación del lado cliente.
• PodDisruptionBudgets (PDBs): los PDBs no impiden que el HPA escale hacia arriba, pero pueden afectar a las operaciones de mantenimiento y al comportamiento del drenado; asegúrese de que las políticas de escalado estén alineadas con los PDBs.
• Efectos de inicio y calentamiento: initContainers, calentamiento de la caché o arranques en frío prolongados pueden sesgar las métricas y provocar oscilaciones — utilice sondas de preparación y de arranque, así como ventanas de estabilización.
• Enfoque operativo recomendado: establezca tasas de escalado conservadoras, ajuste las solicitudes, los límites y las sondas, pruebe en entornos no productivos y añada una limitación de tasa en función de los SLO si los sistemas posteriores son un cuello de botella.

Lista de comprobación de configuración y pasos de implementación seguros

Garantice las métricas y RBAC:

• Implemente metrics-server para las métricas de recursos (o use el proveedor administrado).
• Implemente Prometheus + prometheus-adapter para métricas personalizadas (custom.metrics.k8s.io) si es necesario.
• Para el escalado externo o basado en eventos, considere usar KEDA.

Escriba HPA (escalado automático/v2) con:

• minReplicas y maxReplicas,
• métricas y comportamiento explícitos (políticas scaleUp/scaleDown),
• sondas de preparación y de arranque en pods,
• solicitudes de recursos razonables para que las métricas de recursos sean significativas.

Lista de comprobación de pruebas seguras (cómo probar HPA de forma segura):

1. Pruebe en un espacio de nombres o clúster que no sea de producción con tamaños de nodo similares y el escalado automático habilitados.
2. Empiece con valores mínimos y máximos conservadores de réplicas y políticas de ampliación gradual (p. ej., un crecimiento máximo del 100 % por minuto).
3. Realice pruebas de carga graduales, supervise desiredReplicas en comparación con currentReplicas y los pods en estado Pending.
4. Iteración de solicitudes o límites, sondeos de preparación y directivas de comportamiento antes de aumentar la agresividad.

Notas sobre el escalado automático de AKS y de nodos:

• AKS y otras ofertas en la nube pueden preinstalar el servidor de métricas o ofrecer la integración del escalador automático administrado. Ejemplo de la CLI de AKS para habilitar el escalado automático del clúster: az aks nodepool update --resource-group myRG --cluster-name myAKS --name node-pool1 --enable-cluster-autoscaler --min-count 1 --max-count 5

Nota de Karpenter: Karpenter es un enfoque alternativo de escalado automático de nodos centrado en el aprovisionamiento rápido; tenga en cuenta cuándo se requiere el aprovisionamiento rápido de nodos.

Ejemplos de YAML de trabajo

HPA basado en CPU (escalado automático/v2):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapi-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapi
  minReplicas: 3
  maxReplicas: 12
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 1
          periodSeconds: 60

HPA mediante una métrica personalizada expuesta por Prometheus (a través de prometheus-adapter):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-requests-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "100"

Consulte la documentación de prometheus-adapter para las consultas de asignación.

KEDA ScaledObject (Azure Service Bus): admite la escala a cero:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sb-queue-scaledobject
  namespace: workers
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: event-worker
  minReplicaCount: 0
  maxReplicaCount: 20
  pollingInterval: 30
  cooldownPeriod: 300
  triggers:
    - type: azure-servicebus
      metadata:
        queueName: orders-queue
        queueLength: "50"
      authenticationRef:
        name: keda-azure-credentials

Documentos de KEDA

Observabilidad, alertas y ejemplos de SRE

Alertas sugeridas (ejemplos de Prometheus copiables: ajuste los nombres de métricas a la configuración de exportación):

1. Alerta cuando el valor deseado de HPA sea > el actual durante > 5 min (problema de capacidad de planificación)

   alert: HPAUnschedulable
   expr: (kube_hpa_status_desired_replicas - kube_hpa_status_current_replicas) > 0
   for: 5m
   labels:
     severity: page
   annotations:
     summary: "HPA desired replicas exceed current replicas for >5m (possible scheduling issue)"
   

2. Alerta sobre pods pendientes en un espacio de nombres

   alert: PodsPendingHigh
   expr: sum(kube_pod_status_phase{phase="Pending", namespace="production"}) > 3
   for: 2m
   labels:
     severity: ticket
   annotations:
     summary: "High number of Pending pods in production"
   

3. Alerta sobre el escalado frecuente (oscilación)

   alert: HPAFlapping
   expr: increase(kube_hpa_status_replicas_last_transition_count[10m]) > 5
   for: 0m
   labels:
     severity: warning
   annotations:
     summary: "Frequent HPA scaling events detected"
   

Paneles de control de instrumentos que muestran:

• HPA: currentReplicas, desiredReplicas, lastScaleTime, valores de métrica usados por HPA
• Estado de salud de los pods: pods pendientes, eventos FailedScheduling, número de reinicios de los pods
• Servicios descendentes: uso de la conexión a la base de datos, tasas de error, tasas de error de API externas y de respuestas 429

Comandos operativos y de depuración (referencia rápida)

• Enumeración de HPA: kubectl get hpa -n
• Describa HPA (busque métricas actuales, desiredReplicas, lastScaleTime y eventos): kubectl describe hpa -n
• Campos que se van a inspeccionar en la salida: currentReplicas, desiredReplicas, metrics (valores actuales o de destino), lastScaleTime, eventos (errores del proveedor de métricas o errores de escalado)
• Visualización del uso de recursos (requiere metrics-server): kubectl top pods -n
• Compruebe los pods pendientes y los errores de programación: kubectl get pods -n | grep Pending, kubectl describe pod -n (busque FailedScheduling)
• Compruebe los registros del proveedor de métricas: kubectl logs -n kube-system deploy/metrics-server, kubectl logs -n deploy/prometheus-adapter
• Aplicar manifiesto de HPA: kubectl apply -f hpa.yaml

Sugerencias de solución de problemas rápidas:

• El HPA informa de que desiredReplicas > currentReplicas y los pods siguen en estado Pending → probablemente no hay suficiente capacidad en los nodos; habilite Cluster Autoscaler o aumente el grupo de nodos.
• HPA muestra errores de métricas en los eventos → compruebe la configuración RBAC y la configuración del adaptador, así como los registros del proveedor de métricas.
• El escalado de HPA es demasiado rápido o lento → ajustar las directivas de comportamiento (límites de porcentaje o pods) y las ventanas de estabilización.

Valores predeterminados y heurísticas de ajuste recomendadas

• Objetivo de CPU: comience con una utilización media de alrededor del 60 % (rango habitual del 60 al 80 %) y ajústelo según la carga de trabajo.
• minReplicas: al menos 1 para disponibilidad; use KEDA si necesita minReplicas: 0.
• maxReplicas: establecido en función del planeamiento de la capacidad y el costo; asegúrese de que los límites del escalador automático de clústeres permiten agregar nodos a la capacidad necesaria.
• stabilizationWindowSeconds: scaleDown ≈ 300s (5 min) es un punto de partida habitual para evitar reducciones rápidas; ajústelo según la carga de trabajo.
• políticas de escalado: limite los incrementos porcentuales por período (por ejemplo, permita un crecimiento máximo del 100 % por minuto) para evitar sobrecargar los sistemas posteriores.
• Sondas de disponibilidad/arranque: defínalas siempre para que los pods no reciban tráfico hasta que estén listos por completo.

Nota: Los valores predeterminados de tiempo de controlador específicos y el comportamiento exacto pueden variar en las versiones y distribuciones de Kubernetes: compruebe los documentos de HPA para la versión del clúster.

Problemas comunes y lista de comprobación antes de habilitar HPA

• Las solicitudes de recursos de los pods ausentes o incorrectas → los objetivos de HPA basados en recursos serán engañosos.
• Ningún proveedor de métricas (metrics-server/prometheus-adapter/KEDA) → HPA no puede leer las métricas.
• El clúster no tiene capacidad de nodo y Cluster Autoscaler no está habilitado → los pods permanecerán en estado Pending.
• Uso conjunto de HPA y VPA: evite que ambos controladores modifiquen activamente las solicitudes de recursos; ejecute VPA en modo de recomendación y deje que HPA escale las réplicas.
• Picos al arrancar (initContainers, cachés frías) sin sondas → ajustar las ventanas de estabilización o precalentar las instancias manualmente.
• Configuración incorrecta de RBAC: asegúrese de que los adaptadores de métricas y el controlador HPA tienen permisos necesarios para leer las métricas.

Preguntas frecuentes breves

P: ¿Cuáles son las ventajas de HPA? R: Adapte automáticamente el recuento de réplicas para cambiar la carga, mejorar el uso y el costo, y mantener los objetivos de latencia cuando se usan con las métricas correctas y el escalado automático de nodos.

P: ¿Cómo calcula HPA las réplicas deseadas? R: Lee las métricas configuradas, calcula desiredReplicas = ceil(current_total /target_per_pod) para cada métrica, toma el valor calculado más grande y, a continuación, aplica directivas de comportamiento mínimas y máximas (origen: documentos de HPA).

P: ¿Se puede escalar el HPA hasta cero? A: No — un HPA estándar no puede escalarse hasta cero. Use KEDA para el comportamiento de escala a cero (documentos de KEDA).

P: ¿Cómo escalar según la longitud de la cola o las RPS? R: Exponga la longitud de la cola o RPS como una métrica externa o personalizada (adaptador de Prometheus o API de métricas externas) o use KEDA para el escalado controlado por eventos.

References

• Concepto de HPA de Kubernetes
• Guía y tareas del HPA de Kubernetes
• Servidor de métricas
• Adaptador de Prometheus (métricas personalizadas)
• KEDA (escalado automático controlado por eventos)
• Documentación de Cluster Autoscaler de AKS