Kubernetes HorizontalPodAutoscaler (HPA v2) Generator

Kubernetes HorizontalPodAutoscaler (HPA v2) Generator

K8s 1.23+ GA

Build autoscaling HPA v2 YAML manifests with CPU and Memory utilization targets, custom metrics, and scale-up/scale-down stabilization policies.

Presets:
HPA Configuration
Replica BoundsScale: 2 → 10 pods
minReplicas
maxReplicas
Kubernetes Scheduling Note: When traffic diminishes, the HPA will never scale down below minReplicas (2), and will clamp burst expansion at maxReplicas (10).
Replicas: 2-10Metrics: 2
Target: api-service
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
Lines: 46Size: 1035 B
autoscaling/v2 syntax ready
API Version
autoscaling/v2 (K8s 1.23+)
Target Metrics
2 Rules Configured
Behavior Stabilization
300s Cooldown Window

Zero-Knowledge Local Execution

All data processing, parsing, and compilation execute strictly inside your local browser memory. Zero external server uploads.

Sub-Millisecond AST Engine

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Technical Reference & Architecture Guide

Kubernetes HorizontalPodAutoscaler (HPA v2) Generator — Reference Guide

Build autoscaling HPA v2 YAML manifests with CPU and Memory utilization targets, custom metrics, and scale-up/scale-down stabilization policies.

Key Parameters & Controls

scaleTargetRefobject (apiVersion, kind, name)

Specifies the target workload resource to autoscale, typically an apps/v1 Deployment, StatefulSet, or ReplicaSet.

Default: { apiVersion: "apps/v1", kind: "Deployment", name: "my-app" }
minReplicas / maxReplicasinteger (positive)

Defines the absolute lower and upper bounds of pod replicas. The controller will never scale below minReplicas or above maxReplicas under any load conditions.

Default: minReplicas: 2, maxReplicas: 10
metricsarray (Resource | ContainerResource | Pods | Object | External)

List of metric rules evaluated by the controller. Supports Resource metrics (averageUtilization or averageValue on cpu/memory), ContainerResource for specific pods, and custom/external metric queries.

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

Stabilization window and rate-limiting policies applied during scale-down to prevent flapping (thrashing) and ensure smooth pod termination.

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

Defines the rate of scale-up expansion to handle traffic spikes quickly, with customizable stabilization delays and replica growth burst policies.

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

Pro Tips & Best Practices

The HPA controller computes utilization

The HPA controller computes utilization percentage strictly against container 'resources.requests', not 'limits'. If requests are omitted from your Deployment container specs, HPA fails with an '<unknown>/target%' metric status and refuses to autoscale.

Configure

Configure 'behavior.scaleUp.stabilizationWindowSeconds: 0' to react instantly to sudden traffic surges, while keeping 'behavior.scaleDown.stabilizationWindowSeconds: 300' (5 minutes). This prevents rapid oscillations (thrashing) when traffic fluctuates around threshold boundaries.

If your service has

If your service has a strict PodDisruptionBudget (e.g. minAvailable: 80%), avoid overly aggressive scale-down step policies (e.g. 50% drop every 15s). Use 'type: Percent, value: 10' or 'type: Pods, value: 1-2' to avoid eviction rejections and rolling restarts.

Running Horizontal Pod Autoscaler

Running Horizontal Pod Autoscaler and Vertical Pod Autoscaler concurrently on CPU or memory causes mutual race conditions. If both are necessary, configure HPA on custom business metrics (e.g., HTTP request rate or queue depth) while allowing VPA to manage resource sizing.

Common Gotchas & Troubleshooting

HPA status shows 'TARGETS: <unknown>/70%' and does not trigger scaling.

Verify that all containers in the target Deployment define explicit 'resources.requests.cpu' (or memory). Next, ensure the Kubernetes Metrics Server is healthy and reachable by executing 'kubectl top pods' and 'kubectl get apiservice v1beta1.metrics.k8s.io'.

Workload experiences frequent thrashing (scale up followed immediately by scale down).

Increase 'behavior.scaleDown.stabilizationWindowSeconds' from 0 to 300 or 600 seconds. Add conservative scaleDown policies with 'selectPolicy: Min' so that pods terminate incrementally over several minutes.

Custom or External metrics fail with 'unable to fetch metrics: metric not found'.

Check that your custom metrics adapter (e.g., Prometheus Adapter, KEDA, Datadog Cluster Agent) is deployed and properly registered under 'kubectl get apiservices'. Verify that the metric name, namespace, and label selector match the metrics server catalog exactly.

Frequently Asked Questions

What is the primary difference between autoscaling/v1 and autoscaling/v2?▼

The legacy 'autoscaling/v1' API only supported target CPU utilization percentage on Deployments. 'autoscaling/v2' (standard since Kubernetes 1.23+) supports multiple metrics simultaneously (CPU, memory, custom metrics, and external services), container-level metrics, and fine-grained 'behavior' policies for scale-up and scale-down stabilization.

What mathematical formula does HPA use to determine the desired replica count?▼

HPA uses the algorithm: desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)]. For example, if you have 4 replicas running at 80% CPU and your target is 50%, the formula calculates ceil[4 * (80 / 50)] = ceil[6.4] = 7 replicas. If the ratio is within a 10% tolerance (0.9 to 1.1), no scaling action is taken.

Why is autoscaling on memory utilization generally considered risky?▼

Unlike CPU which immediately drops when idle, application runtimes (such as Java JVM, Go, Node.js, and Python) often retain allocated memory or rely on delayed garbage collection. Consequently, memory utilization remains high after traffic subsidies, preventing HPA from scaling down even when the workload is completely idle.

How do selectPolicy: Min and Max work in HPA behavior rules?▼

When multiple policies are defined under scaleUp or scaleDown, 'selectPolicy' determines which policy wins: 'Min' selects the policy that produces the smallest change in replicas (most conservative), whereas 'Max' selects the policy that produces the largest change (most aggressive). ScaleUp defaults to 'Max' for fast responsiveness, while scaleDown defaults to 'Max' unless customized.

Does HPA support scaling down to zero replicas?▼

Native Kubernetes HPA v2 allows setting 'minReplicas: 0' starting in Kubernetes 1.23 (requires the HPAScaleToZero feature gate, enabled by default in 1.28+), but only when evaluated against Custom or External metrics (not CPU/memory, since 0 pods report no metrics). For seamless scale-to-zero event-driven architectures, KEDA or Knative is widely recommended.

Related Tools & Utilities

All Tools →
Redis (redis.conf) Production Config Builder & TunerDeveloper

Generate tuned redis.conf configuration files with maxmemory policies, RDB/AOF persistence, network binding, and security authentication.

Open tool→
PostgreSQL (postgresql.conf) Hardware Tuner & BuilderDeveloper

Calculate and generate optimized postgresql.conf settings based on hardware specs (shared_buffers, work_mem, effective_cache_size, max_connections).

Open tool→
Linux Systemd (.timer & .service) Unit GeneratorDeveloper

Build systemd timer and companion service unit files with OnCalendar scheduling, OnBootSec intervals, Persistent execution, and random delays.

Open tool→
TypeScript (tsconfig.json) Configuration GeneratorDeveloper

Generate modern, robust tsconfig.json configurations for Next.js, Node.js, Vite, or Library setups with strict mode, paths, and module resolution.

Open tool→
JSON to ClickHouse CREATE TABLE DDL GeneratorDeveloper

Convert sample JSON documents into ClickHouse SQL DDL with MergeTree engine, UInt/Int/Float/String/DateTime types, and Array/Nested column mappings.

Open tool→
JSON to Google BigQuery Table Schema GeneratorDeveloper

Infer and convert JSON objects into Google Cloud BigQuery Table Schema JSON with RECORD mode, STRING, INTEGER, NUMERIC, and TIMESTAMP fields.

Open tool→