Kubernetes Autoscaling: HPA vs VPA vs KEDA

Autoscaling in Kubernetes is not one mechanism but a family, and picking the wrong one produces the classic complaints: pods that never scale because CPU is the wrong signal, pods that get evicted by a right-sizing pass, or a cluster that cannot place replicas because there is no node capacity. This article maps the options - HPA, VPA, KEDA and the cluster-level autoscalers - to the workloads they actually fit.

Horizontal: HPA

The HorizontalPodAutoscaler is a core API resource plus controller that periodically adjusts the replica count of a workload to match observed metrics. CPU and memory utilisation work out of the box (they require metrics-server); custom and external metrics let you scale on requests per second, queue depth or a cloud provider metric.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

Use HPA when the workload is stateless or partitionable and demand varies. Two prerequisites decide whether it works at all: every container in the targeted pods must have CPU requests set (a percentage of nothing is undefined), and the scaling signal must actually correlate with load. The behavior block matters in production - a short scale-down window produces replica thrash as traffic fluctuates.

Vertical: VPA

The VerticalPodAutoscaler is an add-on (CRD plus controller) that adjusts the CPU and memory requests of the pods it manages. It is the right tool when a workload cannot be parallelised - a single-threaded batch job, a stateful component that cannot be replicated freely - or when the goal is right-sizing instead of scaling out.

Update modes determine the disruption: recommendations only, apply at pod creation, or evict and recreate to apply new values. Note that VPA cannot resize pods in place in current versions, so automatic mode means restarts. Also avoid running HPA and VPA on the same CPU or memory metric for the same workload - the two controllers will fight each other. If you need both, keep VPA in recommendation mode or give HPA a distinct custom metric.

Event-driven: KEDA

KEDA is a CNCF-graduated project that scales workloads based on events - the number of messages waiting in a queue, an HTTP backlog, a database row count - and can scale to zero when there is nothing to do. It installs a ScaledObject (or ScaledJob) and drives the standard HPA underneath, so the mechanics stay familiar while the signal becomes business-meaningful. Choose KEDA when "how much work is pending" is a better proxy for load than CPU, or when idle capacity should be genuinely zero. The trade-off is cold-start: scaling from zero means the first request waits for a pod.

Cluster-level capacity

Pod autoscalers can only scale within available node capacity. When pods sit Pending because there is nowhere to place them, the answer is node-level autoscaling (a cluster autoscaler or a node autoprovisioning capability), or the Cluster Proportional Autoscaler family for system components that should scale with cluster size rather than with load. Without this layer, an HPA that reaches maxReplicas with pending pods looks like a scaling failure but is really a capacity failure.

Verification and diagnosis

kubectl get hpa
kubectl describe hpa api        # scaling events, current vs target metric
kubectl top pods
kubectl get scaledobject -A
kubectl get vpa

describe hpa is the fastest diagnosis: it shows the current metric value, the target, and events such as FailedGetResourceMetric (metrics unavailable) or FailedComputeMetricsReplicas (missing requests).

Choosing, in one line each

• Variable load, replicable service: HPA on a metric that tracks demand.
• Cannot parallelise, or requests are guesses: VPA for right-sizing.
• Queue- or event-driven, scale-to-zero desired: KEDA.
• Pods pending with the right replica count: node-level autoscaling, not pod autoscaling.
• System components that should track cluster size: Cluster Proportional Autoscaler.

Related: Gateway API vs Ingress migration, VictoriaMetrics single-node vs cluster, and Prometheus relabel configuration.

原文链接：https://kubernetes.io/docs/concepts/workloads/autoscaling