Kubernetes HPA Config Generator

A HorizontalPodAutoscaler automatically scales the number of Pod replicas in a Deployment, ReplicaSet, or StatefulSet based on observed metrics — most commonly CPU or memory utilization. When demand spikes, the HPA increases the replica count up to your maxReplicas limit; when traffic drops, it scales back down to minReplicas. The HPA controller runs in the Kubernetes control plane and queries metrics every 15 seconds by default.

autoscaling/v1 is the original API and only supports CPU utilization via targetCPUUtilizationPercentage. autoscaling/v2 (stable since Kubernetes 1.23) supports multiple metric types simultaneously: Resource metrics (CPU/memory by Utilization % or AverageValue), Pods metrics (per-pod custom metrics), Object metrics (metrics tied to Kubernetes objects like Ingress), and External metrics (from outside the cluster). v2 also adds the behavior block for fine-grained scale-up/scale-down control. Use v2 for any new workloads.

Use Utilization (%) when you want to target a percentage of the Pod's CPU request — e.g., targetAverageUtilization: 80 means the HPA will scale when average CPU across all pods exceeds 80% of their request. Use AverageValue when you want to target an absolute value like 500m (millicores) per pod. Utilization requires CPU requests to be set on the container spec; if requests are missing, the HPA cannot calculate utilization and will report unknown metrics.

The stabilization window prevents flapping — rapid scale-up followed immediately by scale-down (or vice versa). For scale-down, the default is 300 seconds: the HPA will look back over the last 5 minutes of metric history and only scale down to the highest recommendation it saw during that window. For scale-up, the default is 0 seconds (scale up immediately). Increasing the scale-up stabilization window is useful for workloads with spiky traffic where you want to avoid over-provisioning on transient bursts.

Scale policies (autoscaling/v2 behavior block) limit how fast the HPA can scale. A policy has three fields: type (Percent or Pods), value (how many or what percentage to change), and periodSeconds (over what time window). For example, type: Percent, value: 100, periodSeconds: 60 means at most double the current replicas per minute. You can define multiple policies; selectPolicy: Max picks the policy that allows the largest change, Min picks the most conservative. This prevents runaway scaling during sudden traffic spikes.

For Resource metrics (CPU/memory), you need the Kubernetes Metrics Server installed in your cluster — it is not included by default. Install it with: kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml. For custom metrics (Pods/Object types), you need a custom metrics adapter such as Prometheus Adapter configured to expose metrics via the custom.metrics.k8s.io API. Cloud-managed clusters (GKE, EKS, AKS) typically include the metrics server out of the box.