Autoscaling (HPA, VPA, KEDA)

Three pod-level autoscalers plus two node-level autoscalers. They solve different problems.

HPA: more or fewer pods

Watches a metric, scales the Deployment's replica count up or down to keep the metric at target.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef: { kind: Deployment, name: api }
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }

CPU and memory are built in (via metrics-server). For custom metrics (requests/sec, queue depth) you need the Prometheus Adapter or similar.

VPA: bigger or smaller pods

Watches actual resource usage over time, recommends or applies new CPU/memory requests. Three modes:

• Off: just recommend.
• Initial: set requests on Pod creation.
• Auto: evict and recreate Pods with new requests when recommendation diverges.

VPA in Auto mode causes Pod restarts. Do not combine with HPA on CPU/memory - they will fight.

KEDA: scale on anything external

Kubernetes Event-Driven Autoscaling. Adds scalers for SQS queue depth, Kafka lag, Redis list length, Prometheus queries, cron schedules. Wraps an HPA under the hood. Critical feature: scale to zero, which HPA cannot do on its own.

Node autoscaling: Cluster Autoscaler vs Karpenter

• Cluster Autoscaler: scales pre-defined Auto Scaling Groups (node groups). Picks an ASG based on unschedulable pod requirements. Slow (1-2 min) and constrained to ASG instance types.
• Karpenter: AWS's newer scheduler-aware node provisioner. Looks at pending pods, picks the cheapest EC2 instance type that fits, launches it directly. Much faster (under 60s) and packs better.

On EKS, default to Karpenter for new clusters.

The interview answer

HPA scales replicas on CPU/memory or custom metrics. VPA right-sizes requests. KEDA covers external events and scale-to-zero. Karpenter handles node-level autoscaling on EKS, faster and cheaper than Cluster Autoscaler.