Generador de Kubernetes HorizontalPodAutoscaler (HPA v2)

Generador de Kubernetes HorizontalPodAutoscaler (HPA v2)

K8s 1.23+ GA

Genere manifiestos YAML de HPA v2 con objetivos de uso de CPU y memoria, métricas personalizadas y políticas de estabilización de escalado ascendente y descendente.

Presets:
Configuración de HPA
Límites de réplicasScale: 2 → 10 pods
minReplicas
maxReplicas
Nota de programación de Kubernetes: Cuando disminuye el tráfico, el HPA nunca bajará de minReplicas (2), y limitará la expansión rápida a maxReplicas (10).
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-service-hpa
  namespace: production
  labels:
    app.kubernetes.io/name: api-service
    app.kubernetes.io/managed-by: toolsaa-k8s-hpa-generator
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 75
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      selectPolicy: Max
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15
        - type: Pods
          value: 4
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300
      selectPolicy: Min
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60
Versión de API
autoscaling/v2 (K8s 1.23+)
Métricas de Destino
2 reglas configuradas
Estabilización de Comportamiento
300s s ventana de enfriamiento

Procesamiento en el Cliente

Procesamiento de alto rendimiento ejecutado completamente en la memoria del navegador.

Privacidad sin Envío al Servidor

Todas las configuraciones y métricas permanecen estrictamente locales sin comunicación externa.

Exportación Lista para Producción

Formatos de salida limpios y optimizados, listos para su despliegue inmediato con kubectl.

Referencia técnica y guía de arquitectura

Guía para Desarrolladores del Generador de Kubernetes HorizontalPodAutoscaler (HPA v2) — Guía de referencia

Genere manifiestos YAML de HPA v2 con objetivos de uso de CPU y memoria, métricas personalizadas y políticas de estabilización de escalado ascendente y descendente.

Parámetros clave y controles

scaleTargetRefobjeto (apiVersion, kind, name)

Especifica el recurso de carga de trabajo objetivo a autoescalar, comúnmente un Deployment, StatefulSet o ReplicaSet de apps/v1.

Por defecto: { apiVersion: "apps/v1", kind: "Deployment", name: "my-app" }
minReplicas / maxReplicasentero (positivo)

Define los límites inferior y superior absolutos para el número de réplicas de pods. El controlador nunca escalará fuera de este rango bajo ninguna condición de carga.

Por defecto: minReplicas: 2, maxReplicas: 10
metricsmatriz (Resource | ContainerResource | Pods | Object | External)

Lista de reglas de métricas evaluadas por el controlador. Admite métricas de recursos (averageUtilization o averageValue para CPU/memoria), ContainerResource y consultas personalizadas/externas.

Por defecto: [{ type: "Resource", resource: { name: "cpu", target: { type: "Utilization", averageUtilization: 70 } } }]
behavior.scaleDownobjeto (stabilizationWindowSeconds, policies, selectPolicy)

Ventana de estabilización y políticas de limitación de tasa aplicadas durante el escalado descendente para evitar oscilaciones (flapping/thrashing).

Por defecto: { stabilizationWindowSeconds: 300, selectPolicy: "Min", policies: [{ type: "Percent", value: 10, periodSeconds: 60 }] }
behavior.scaleUpobjeto (stabilizationWindowSeconds, policies, selectPolicy)

Define la agresividad de expansión del escalado ascendente para responder a picos de tráfico, con retardos de estabilización y políticas de crecimiento por ráfaga.

Por defecto: { stabilizationWindowSeconds: 0, selectPolicy: "Max", policies: [{ type: "Percent", value: 100, periodSeconds: 15 }, { type: "Pods", value: 4, periodSeconds: 15 }] }

Consejos profesionales y mejores prácticas

El controlador HPA calcula los

El controlador HPA calcula los porcentajes de uso estrictamente sobre 'resources.requests', nunca sobre 'limits'. Si omite requests en la especificación del Deployment, el HPA mostrará '<unknown>/target%' y no podrá realizar el autoescalado.

Configure

Configure 'behavior.scaleUp.stabilizationWindowSeconds: 0' para reaccionar inmediatamente a aumentos de carga, pero mantenga 'behavior.scaleDown.stabilizationWindowSeconds: 300' (5 minutos). Esto evita fluctuaciones bruscas cuando el tráfico varía alrededor del umbral.

Si su aplicación tiene un PDB estricto

Si su aplicación tiene un PDB estricto (por ejemplo, minAvailable: 80%), evite reducciones agresivas (como recortar el 50% de pods en 15 segundos). Emplee 'type: Percent, value: 10' o pasos fijos de 1-2 pods para evitar rechazos de desalojo.

Ejecutar HPA y VPA juntos sobre

Ejecutar HPA y VPA juntos sobre métricas de CPU o memoria produce condiciones de carrera en los bucles de control. Si necesita ambos, configure HPA con métricas de negocio (como peticiones HTTP o colas) y deje el dimensionamiento de recursos a VPA.

Errores comunes y solución de problemas

El estado de HPA muestra 'TARGETS: <unknown>/70%' y no escala.

Compruebe que todos los contenedores del Deployment definan explícitamente 'resources.requests.cpu' (o memoria). Asegúrese además de que el Metrics Server de Kubernetes funcione ejecutando 'kubectl top pods' y 'kubectl get apiservice v1beta1.metrics.k8s.io'.

La carga de trabajo experimenta oscilación frecuente (escalados y desescalados continuos).

Aumente 'behavior.scaleDown.stabilizationWindowSeconds' a un valor entre 300 y 600 segundos. Añada políticas de reducción con 'selectPolicy: Min' para que los pods se eliminen de manera gradual a lo largo de varios minutos.

Las métricas personalizadas o externas fallan con 'unable to fetch metrics: metric not found'.

Verifique que el adaptador de métricas (por ejemplo Prometheus Adapter, KEDA o Datadog Cluster Agent) esté desplegado y registrado con 'kubectl get apiservices'. Asegúrese de que el nombre de la métrica y los selectores de etiquetas coincidan con el catálogo del adaptador.

Preguntas frecuentes (FAQ)

¿Cuál es la principal diferencia entre autoscaling/v1 y autoscaling/v2?▼

La versión heredada 'autoscaling/v1' solo permitía escalar Deployments en función del porcentaje de uso de CPU. 'autoscaling/v2' (estándar desde Kubernetes 1.23+) soporta múltiples métricas concurrentes (CPU, memoria, métricas personalizadas y externas), métricas a nivel de contenedor individual y la sección 'behavior' para estabilización avanzada.

¿Qué fórmula matemática utiliza HPA para calcular las réplicas deseadas?▼

HPA aplica la fórmula: réplicasDeseadas = ceil[réplicasActuales * (valorMétricaActual / valorMétricaObjetivo)]. Por ejemplo, con 4 réplicas al 80% de CPU y objetivo del 50%, se obtiene ceil[4 * (80 / 50)] = ceil[6.4] = 7 réplicas. Si la proporción se sitúa dentro de una tolerancia del 10% (0.9 a 1.1), no se efectúa ninguna acción de escalado.

¿Por qué el escalado por uso de memoria suele considerarse riesgoso?▼

A diferencia de la CPU, que disminuye de forma instantánea al cesar la actividad, entornos de ejecución como Java (JVM), Go o Node.js retienen la memoria asignada o difieren la recolección de basura. Por ello, el consumo de memoria se mantiene elevado incluso sin tráfico, impidiendo que HPA reduzca las réplicas.

¿Cómo funcionan selectPolicy: Min y Max en las reglas de comportamiento de HPA?▼

Cuando se definen varias políticas dentro de scaleUp o scaleDown, 'selectPolicy' elige la política ganadora: 'Min' selecciona la que produzca el cambio más pequeño en el recuento de réplicas (más conservadora), mientras que 'Max' elige la de mayor cambio (más reactiva). ScaleUp usa por defecto 'Max' para garantizar rapidez ante picos de demanda.

¿Permite HPA escalar a cero réplicas?▼

El API nativo HPA v2 permite configurar 'minReplicas: 0' a partir de Kubernetes 1.23 (activo por defecto en 1.28+), pero únicamente cuando se evalúa contra métricas personalizadas o externas (los pods en cero no pueden emitir métricas de CPU/memoria). Para una arquitectura controlada por eventos con escala a cero, se recomienda ampliamente el uso de KEDA o Knative.

Herramientas y utilidades relacionadas

Todas las herramientas →
Generador y Optimizador de Configuración de Producción Redis (redis.conf)Desarrollo

Genere archivos de configuración redis.conf ajustados para producción con políticas maxmemory, persistencia RDB/AOF, enlaces de red seguros y autenticación ACL.

Abrir herramienta→
Guía de Desarrollo: Optimizador y Generador de Hardware para PostgreSQL (postgresql.conf)Desarrollo

Calcule y genere configuraciones optimizadas de postgresql.conf basadas en las especificaciones del hardware (shared_buffers, work_mem, effective_cache_size, max_connections).

Abrir herramienta→
Guía de Desarrollo del Generador de Unidades Systemd (.timer y .service) de LinuxDesarrollo

Diseñe y genere unidades de temporizador (.timer) y servicios complementarios de systemd listos para producción con programación OnCalendar, intervalos OnBootSec, ejecución Persistent y demoras aleatorias.

Abrir herramienta→
Guía para Desarrolladores del Generador de Configuración TypeScript (tsconfig.json)Desarrollo

Genera configuraciones tsconfig.json modernas y robustas para Next.js, Node.js, Vite o librerías con modo estricto, alias de rutas y resolución de módulos.

Abrir herramienta→
Guía de Desarrollo: Generador de DDL CREATE TABLE de JSON a ClickHouseDesarrollo

Convierta documentos JSON de muestra en DDL de SQL para ClickHouse con motor MergeTree, tipos UInt/Int/Float/String/DateTime y mapeo de columnas Array/Nested.

Abrir herramienta→
Guía de Desarrollo: Generador de Esquema de Tabla Google BigQuery desde JSONDesarrollo

Infiere y convierte objetos JSON en esquemas de tabla para Google Cloud BigQuery con campos RECORD, STRING, INTEGER, NUMERIC y TIMESTAMP.

Abrir herramienta→