Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Una guía práctica para la optimización del Autoescalador Horizontal de Pods (HPA) de Kubernetes

Desbloquee el rendimiento óptimo de la aplicación y la eficiencia de costos con esta guía práctica sobre la optimización del Autoescalador Horizontal de Pods (HPA) de Kubernetes. Aprenda a configurar el HPA utilizando métricas de CPU, métricas personalizadas y métricas externas, y domine los comportamientos de escalado avanzados con `%s` y `%s`. Este artículo proporciona pasos prácticos, ejemplos de código y mejores prácticas para garantizar que sus implementaciones de Kubernetes se adapten dinámicamente a las cargas fluctuantes, eviten el aprovisionamiento excesivo de recursos y mantengan una alta disponibilidad.

33 vistas

Guía Práctica para la Optimización del Autoscalador Horizontal de Pods (HPA) de Kubernetes

Kubernetes ha revolucionado la forma en que se implementan, gestionan y escalan las aplicaciones. En el centro de sus capacidades de escalado se encuentra el Autoscalador Horizontal de Pods (HPA), un potente mecanismo que ajusta automáticamente el número de réplicas de pods en un deployment, replication controller, replicaset o statefulset basándose en la utilización de CPU observada u otras métricas seleccionadas. Si bien el HPA ofrece inmensos beneficios para manejar cargas fluctuantes, su verdadero potencial se desbloquea mediante una configuración y optimización cuidadosas.

Esta guía profundiza en los aspectos prácticos de la configuración y optimización del Autoscalador Horizontal de Pods de Kubernetes. Cubriremos conceptos fundamentales, parámetros centrales, estrategias avanzadas de ajuste y las mejores prácticas para garantizar que sus aplicaciones puedan adaptarse eficientemente a la demanda, mantener el rendimiento bajo cargas variables y optimizar los costos de infraestructura. Al final de este artículo, tendrá una comprensión sólida de cómo aprovechar el HPA al máximo.

Comprensión del Autoscalador Horizontal de Pods (HPA)

El HPA escala automáticamente el número de pods de su aplicación hacia arriba o hacia abajo para que coincida con la demanda actual. Monitorea continuamente las métricas especificadas y las compara con los valores objetivo. Si la métrica observada excede el objetivo, el HPA inicia un evento de escalado ascendente; si cae por debajo, activa un escalado descendente. Este ajuste dinámico asegura que su aplicación tenga suficientes recursos para funcionar de manera óptima sin aprovisionamiento excesivo.

HPA puede escalar basándose en:

  • Métricas de Recursos: Principalmente la utilización de CPU y memoria (disponibles a través de la API metrics.k8s.io, generalmente servida por el Metrics Server de Kubernetes).
  • Métricas Personalizadas (Custom Metrics): Métricas específicas de la aplicación expuestas a través de la API custom.metrics.k8s.io (por ejemplo, solicitudes por segundo, profundidad de cola, conexiones activas). Estas típicamente requieren un adaptador como prometheus-adapter.
  • Métricas Externas (External Metrics): Métricas que provienen de fuentes externas al clúster expuestas a través de la API external.metrics.k8s.io (por ejemplo, tamaño de la cola de Google Cloud Pub/Sub, longitud de la cola de AWS SQS). Estas también requieren un servidor de API de métricas personalizadas capaz de obtener métricas externas.

Prerrequisitos para una Optimización Efectiva del HPA

Antes de sumergirse en las configuraciones de HPA, asegúrese de que estos elementos fundamentales estén implementados:

1. Definir Solicitudes y Límites de Recursos Precisos

Este es quizás el prerrequisito más crucial. El HPA depende en gran medida de las solicitudes (requests) de CPU y memoria definidas correctamente para calcular los porcentajes de utilización. Si un pod no tiene solicitudes de CPU definidas, el HPA no puede calcular su utilización de CPU, lo que hace imposible el escalado basado en CPU.

  • Solicitudes (Requests): Definen los recursos mínimos garantizados para sus contenedores. El HPA utiliza estos valores para determinar la utilización objetivo por pod.
  • Límites (Limits): Definen los recursos máximos que un contenedor puede consumir. Los límites evitan que un solo pod consuma recursos excesivos e impacte a otros pods en el mismo nodo.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:latest
        resources:
          requests:
            cpu: "200m"  # 20% de un núcleo de CPU
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

2. Instalar Kubernetes Metrics Server

Para que el HPA utilice las métricas de utilización de CPU y memoria, el Kubernetes Metrics Server debe estar instalado en su clúster. Recopila métricas de recursos de los Kubelets y las expone a través de la API metrics.k8s.io.

3. Observabilidad de la Aplicación

Para métricas personalizadas o externas, su aplicación debe exponer las métricas relevantes (por ejemplo, a través de un endpoint Prometheus) y necesitará una forma de recopilar y exponer estas métricas a la API de Kubernetes, generalmente utilizando un adaptador Prometheus o un servidor de API de métricas personalizado.

Configuración del HPA: Parámetros Centrales

Echemos un vistazo a la estructura básica de un manifiesto HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Parámetros clave:

  • scaleTargetRef: Define el recurso objetivo (por ejemplo, Deployment) que el HPA escalará. Especifique su apiVersion, kind y name.
  • minReplicas: El número mínimo de pods al que escalará el HPA hacia abajo. Es una buena práctica establecerlo en al menos 1 o 2 para alta disponibilidad, incluso con carga cero.
  • maxReplicas: El número máximo de pods al que escalará el HPA hacia arriba. Esto actúa como una salvaguarda contra el escalado descontrolado y limita los costos.
  • metrics: Una matriz que define las métricas que el HPA debe monitorear.
    • type: Puede ser Resource, Pods, Object o External.
    • resource.name: Para el tipo Resource, especifica cpu o memory.
    • target.type: Para el tipo Resource, Utilization (porcentaje del recurso solicitado) o AverageValue (valor absoluto).
    • averageUtilization: Para el tipo Utilization, el porcentaje objetivo. El HPA calcula el número deseado de pods basado en current_utilization / target_utilization * current_pods_count.

Optimización del HPA para Respuesta y Estabilidad

Más allá de la configuración básica, el HPA ofrece opciones avanzadas de optimización, especialmente con autoscaling/v2 (o v2beta2 en versiones anteriores), para gestionar el comportamiento de escalado de forma más granular.

1. Objetivos de CPU y Memoria (averageUtilization / averageValue)

Establecer la utilización objetivo correcta es crucial. Un objetivo más bajo significa un escalado más temprano (más receptivo, potencialmente más costoso), mientras que un objetivo más alto significa un escalado más tardío (menos receptivo, potencialmente más barato pero arriesgando la degradación del rendimiento).

  • Cómo Determinar Objetivos Óptimos: Las pruebas de carga y la elaboración de perfiles son sus mejores aliados. Aumente gradualmente la carga en su aplicación mientras monitorea el uso de recursos y las métricas de rendimiento (latencia, tasas de error). Identifique la utilización de CPU/memoria en la que su aplicación comienza a degradar el rendimiento. Establezca su objetivo de HPA por debajo de este umbral, generalmente en el rango del 60-80% para la CPU.
  • Acto de Equilibrio: Apunte a un objetivo que deje suficiente margen para picos inesperados, pero que no sea tan bajo que esté constantemente sobre aprovisionado.

2. Comportamiento de Escalado (Campo behavior)

Introducido en HPA autoscaling/v2, el campo behavior proporciona un control detallado sobre los eventos de escalado ascendente y descendente, evitando el "thrashing" (ciclos rápidos de escalado y desescalado).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60 # Esperar 60s antes de volver a escalar hacia arriba
      policies:
      - type: Pods
        value: 4
        periodSeconds: 15 # Añadir un máximo de 4 pods cada 15 segundos
      - type: Percent
        value: 100
        periodSeconds: 15 # O duplicar los pods actuales cada 15 segundos (el que sea menos restrictivo)
    scaleDown:
      stabilizationWindowSeconds: 300 # Esperar 5 minutos antes de escalar hacia abajo
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60 # Eliminar máx. 50% de pods cada 60 segundos
      selectPolicy: Max # Elegir la política que permita el número 'más agresivo' (menor número) de pods

Configuración de scaleUp:

  • stabilizationWindowSeconds: Esto previene ciclos rápidos de escalado ascendente y descendente (oscilación o flapping). El HPA considera las métricas de esta ventana al escalar hacia arriba, asegurando que solo escale si la métrica más alta persiste. Un valor típico es de 30 a 60 segundos.
  • policies: Define cómo se añaden los pods durante un evento de escalado ascendente. Puede definir múltiples políticas, y el HPA utilizará la que permita el mayor número de pods (escalado ascendente más agresivo).
    • type: Pods: Escala hacia arriba por un número fijo de pods. value especifica el número de pods a añadir. periodSeconds define la ventana de tiempo sobre la que se aplica esta política.
    • type: Percent: Escala hacia arriba por un porcentaje del recuento actual de pods. value es el porcentaje.

Configuración de scaleDown:

  • stabilizationWindowSeconds: Más crítico para scaleDown, especifica cuánto tiempo el HPA debe observar métricas por debajo del objetivo antes de considerar el escalado hacia abajo. Una ventana más larga (por ejemplo, 300-600 segundos) previene el escalado descendente prematuro durante caídas temporales, evitando "arranques en frío" y caídas de rendimiento. Esta es una configuración crucial para entornos estables.
  • policies: Similar a scaleUp, define cómo se eliminan los pods. El HPA utiliza la política que da como resultado el menor número de pods (escalado descendente más agresivo) si selectPolicy es Min, o la política que da como resultado el mayor número de pods si selectPolicy es Max.
    • type: Pods: Elimina un número fijo de pods.
    • type: Percent: Elimina un porcentaje de los pods actuales.

  • selectPolicy: Determina qué política aplicar cuando se definen múltiples políticas de scaleDown. Min es el predeterminado y generalmente recomendado para un escalado descendente más conservador; Max seleccionaría la política que resulte en el mayor número de pods (escalado descendente menos agresivo).

  • Advertencia: Tenga cuidado con las políticas de scaleDown agresivas o con valores cortos de stabilizationWindowSeconds para scaleDown. Si su aplicación tiene largos tiempos de inicialización o maneja conexiones con estado, el escalado rápido puede provocar interrupciones del servicio o un aumento de la latencia para los usuarios.

Métricas Avanzadas y Estrategias del HPA

Aunque la CPU y la memoria son comunes, muchas aplicaciones escalan mejor basándose en métricas personalizadas o externas que reflejan su carga de trabajo real.

1. Métricas Personalizadas (Custom Metrics)

Utilice métricas personalizadas cuando la CPU/memoria no sea un indicador directo de la carga o el cuello de botella de rendimiento de su aplicación. Ejemplos: solicitudes HTTP por segundo (QPS), conexiones activas, longitud de la cola de mensajes, backlog de trabajos por lotes.

Para usar métricas personalizadas:
1. Su aplicación debe exponer estas métricas (por ejemplo, a través de un exportador de Prometheus).
2. Implemente un adaptador de métricas personalizadas (por ejemplo, prometheus-adapter) que pueda extraer estas métricas y exponerlas a través de la API custom.metrics.k8s.io.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa-qps
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 15
  metrics:
  - type: Pods # O Object si la métrica es para el deployment en su conjunto
    pods:
      metric:
        name: http_requests_per_second # El nombre de la métrica expuesta por su aplicación/adaptador
      target:
        type: AverageValue
        averageValue: "10k" # Objetivo de 10,000 solicitudes por segundo por pod

2. Métricas Externas (External Metrics)

Las métricas externas son útiles cuando la carga de trabajo de su aplicación está impulsada por un sistema externo que no se ejecuta directamente en Kubernetes. Ejemplos: profundidad de cola de AWS SQS, lag de un tópico de Kafka, backlog de suscripción de Pub/Sub.

Para usar métricas externas:
1. Necesita un servidor de API de métricas personalizadas que pueda obtener métricas de su sistema externo (por ejemplo, un adaptador específico para AWS CloudWatch o GCP Monitoring).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-worker-hpa-sqs
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-worker
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: aws_sqs_queue_messages_visible # Nombre de la métrica de su fuente externa
        selector:
          matchLabels:
            queue: my-queue-name
      target:
        type: AverageValue
        averageValue: "100" # Objetivo de 100 mensajes visibles en la cola por pod

3. Múltiples Métricas

El HPA se puede configurar para monitorear múltiples métricas simultáneamente. Cuando se especifican varias métricas, el HPA calcula el número de réplicas deseado para cada métrica de forma independiente y luego selecciona el más alto de estos recuentos de réplicas deseados. Esto asegura que la aplicación escale lo suficiente para todas las dimensiones de carga observadas.

# ... (código base del HPA)
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "10k"

Monitoreo y Validación

La optimización efectiva del HPA es un proceso iterativo que requiere monitoreo y validación continuos:

  • Observar Eventos del HPA: Use kubectl describe hpa <nombre-hpa> para ver el estado del HPA, los eventos y las decisiones de escalado. Esto proporciona información valiosa sobre por qué el HPA escaló hacia arriba o hacia abajo.
  • Monitorear Métricas y Réplicas: Utilice su pila de observabilidad (por ejemplo, Prometheus, Grafana) para visualizar el uso de recursos de su aplicación (CPU, memoria), las métricas personalizadas/externas y el número real de réplicas de pods a lo largo del tiempo. Correlacione estos con los cambios en la carga entrante.
  • Pruebas de Carga: Simule las cargas esperadas y pico para validar la capacidad de respuesta del HPA y asegurar que su aplicación funcione como se espera bajo estrés. Ajuste los parámetros del HPA basándose en estas pruebas.

Mejores Prácticas para la Optimización del HPA

  • Comience con Solicitudes/Límites de Recursos Bien Definidos: Son la base de un HPA preciso basado en recursos. Sin ellos, el HPA no puede funcionar eficazmente para CPU/memoria.
  • Establezca minReplicas y maxReplicas Realistas: minReplicas proporciona una línea base para la disponibilidad, mientras que maxReplicas actúa como una red de seguridad contra el escalado descontrolado y el agotamiento de recursos.
  • Ajuste Gradualmente la Utilización Objetivo: Comience con un objetivo de CPU ligeramente conservador (por ejemplo, 60-70%) e itere. No apunte al 100% de utilización, ya que no deja margen para la latencia o los picos de procesamiento.
  • Aproveche stabilizationWindowSeconds: Esencial para prevenir oscilaciones rápidas de escalado. Use una ventana más larga para scaleDown (por ejemplo, 5-10 minutos) que para scaleUp (por ejemplo, 1-2 minutos) para garantizar la estabilidad.
  • Priorice las Métricas Específicas de la Aplicación: Si la CPU o la memoria no se correlacionan directamente con los cuellos de botella de rendimiento de su aplicación, utilice métricas personalizadas o externas para un escalado más preciso y eficiente.
  • Monitorear, Probar, Iterar: La optimización del HPA no es una configuración única. El comportamiento de la aplicación, los patrones de tráfico y la infraestructura subyacente pueden cambiar. Revise regularmente el rendimiento del HPA y ajuste la configuración según sea necesario.
  • Comprenda las Características de Escalado de su Aplicación: ¿Escala linealmente con las solicitudes? ¿Tiene largos tiempos de inicio? ¿Maneja estado? Estas características influyen en su estrategia de HPA.

Conclusión

El Autoscalador Horizontal de Pods de Kubernetes es un componente crítico para construir aplicaciones resilientes, rentables y de alto rendimiento en un entorno Kubernetes. Al comprender su mecánica central, definir solicitudes de recursos precisas y ajustar cuidadosamente sus parámetros de comportamiento de escalado, puede asegurar que sus aplicaciones se adapten automáticamente a las cargas variables con precisión.

La optimización efectiva del HPA es un viaje continuo de medición, observación y ajuste. Adopte el proceso iterativo, aproveche las métricas avanzadas cuando sea apropiado y monitoree continuamente el rendimiento de su aplicación para desbloquear todo el potencial del escalado dinámico dentro de Kubernetes.