Why autoscaling/v2 and not v1 or v2beta2?

autoscaling/v2 is the current stable API version, generally available since Kubernetes 1.23, and supports multiple metrics (CPU and memory together) in one HPA object, which the older autoscaling/v1 API doesn't. v2beta1/v2beta2 were deprecated once v2 stabilized, so new HPAs should target v2 directly.

What does the CPU/memory target percentage actually mean?

It's averageUtilization: the target average CPU or memory usage across all Pods, as a percentage of each Pod's requested resource. For this to mean anything, the target Deployment's containers need CPU and/or memory requests set; without a request, the HPA has no baseline to compute utilization against.

What happens if I set both a CPU and a memory target?

The HPA evaluates both metrics independently and scales to satisfy whichever one currently demands the most replicas, the standard Kubernetes behavior when an HPA has multiple metrics.

Does this tool create the target Deployment for me?

No, it only references it by name under scaleTargetRef. Use the Deployment Generator first to create the Deployment this HPA will scale, then reference its exact name here.

Kubernetes HPA Generator - Build Autoscaler YAML

Overview

Introduction

Autoscaling metrics YAML has a deep, easy-to-mistype nesting (metrics, then resource, then target, then averageUtilization) for what's conceptually just "scale to keep CPU near X%".

This tool generates a complete HorizontalPodAutoscaler manifest from a short form: target Deployment, replica bounds, and CPU/memory targets, entirely client-side.

What Is Kubernetes HorizontalPodAutoscaler YAML Generator?

A Kubernetes HorizontalPodAutoscaler YAML generator targeting the stable autoscaling/v2 API, which automatically adjusts a Deployment's replica count based on observed resource utilization.

It supports CPU utilization, memory utilization, or both together as target metrics, plus a min/max replica bound the autoscaler will never go outside of.

How Kubernetes HorizontalPodAutoscaler YAML Generator Works

The target Deployment name and min/max replica values populate spec.scaleTargetRef and spec.minReplicas/maxReplicas directly.

Each enabled metric (CPU, memory) becomes its own entry in spec.metrics, using type: Resource with a target.type of Utilization and your chosen averageUtilization percentage.

At least one metric must be enabled; an HPA with an empty metrics list has nothing to scale on and Kubernetes will reject it.

When To Use Kubernetes HorizontalPodAutoscaler YAML Generator

Use it once a Deployment is running with resource requests set, and you want replica count to track load automatically instead of staying fixed.

It's a good fit for stateless, horizontally-scalable services where CPU or memory usage correlates with traffic, like web APIs or worker queues.

It's not the right tool for scaling based on custom or external metrics (queue depth, request latency); those need a metrics adapter and a different metrics.type in the HPA spec, which this generator's form doesn't expose.

Often used alongside Kubernetes Deployment YAML Generator, Kubernetes PodDisruptionBudget YAML Generator and Kubernetes ResourceQuota YAML Generator.

Features

Advantages

Produces the correct autoscaling/v2 nested metrics structure without you having to remember its exact shape.
Supports CPU and memory targets together in one HPA, matching real-world multi-metric autoscaling setups.
Validates that minReplicas doesn't exceed maxReplicas and that at least one metric target is set, catching two of the most common HPA authoring mistakes before you even apply the manifest.

Limitations

Only supports Resource metrics (CPU/memory); Pods, Object, and External metric types aren't covered by this form.
Doesn't check whether the target Deployment actually has resource requests configured, a prerequisite for utilization-based autoscaling to work at all.
Doesn't set scaling behavior policies (like stabilization windows or scale-down rate limits); add a spec.behavior block manually if you need finer control.

Examples

Scaling a Deployment between 2 and 10 replicas on 70% CPU

Input

name: web-hpa, targetDeploymentName: web, minReplicas: 2, maxReplicas: 10, cpuTargetPercent: 70

Output

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

The HPA adds replicas (up to 10) as average CPU utilization across Pods rises above 70% of their requested CPU, and removes them as it falls, down to a floor of 2.

Best Practices & Notes

Best Practices

Set accurate CPU/memory requests on the target Deployment's containers first; utilization percentages are meaningless without a request baseline to measure against.
Leave headroom between minReplicas and typical steady-state load, so a sudden traffic spike doesn't immediately max out before the autoscaler can react.
Combine this with a PodDisruptionBudget so cluster maintenance or node scaling doesn't evict too many replicas at once while the HPA is also adjusting replica count.

Developer Notes

The generator emits autoscaling/v2's spec.metrics as an array with up to two entries (cpu, memory), each following the Resource metric source type's exact shape (type: Resource, then a nested resource.name/resource.target.type/resource.target.averageUtilization). minReplicas/maxReplicas and both percentage fields are validated as whole numbers in sane ranges before the manifest is assembled, and at least one of the two metrics must be set since Kubernetes requires a non-empty metrics array.

Kubernetes HorizontalPodAutoscaler YAML Generator Use Cases

Autoscaling a stateless web service's replica count based on CPU load
Autoscaling a background worker Deployment based on memory usage as queue backlogs grow
Setting a safe floor and ceiling on replica count for a Deployment that previously had a fixed replica count

Common Mistakes

Adding an HPA to a Deployment whose containers have no CPU/memory requests set, leaving the autoscaler with nothing to compute utilization against.
Setting minReplicas equal to maxReplicas, which defeats the purpose of autoscaling entirely.
Forgetting that an HPA and manually running `kubectl scale` on the same Deployment will fight each other; once an HPA is attached, let it own the replica count.

Tips

Generate the target Deployment first with the Deployment Generator, make sure its resources.requests are set, then reference its exact name here.

Kubernetes HorizontalPodAutoscaler YAML Generator