Autoscaling

Kubernetes Intermediate/Advanced

Chapter 6 · Autoscaling

Chapter 5 (Course 1) named manual scaling and pointed here for the automatic version. This chapter closes that loop, and revisits cloud1-3's own VM-level auto-scaling material at the Kubernetes/pod level.

Revisiting Manual Scaling

k8s1-5's approach: kubectl scale deployment --replicas=N, or editing the YAML directly — a fixed, manually-chosen number. Genuinely fine for predictable load; doesn't respond to real-time demand changes automatically.

Horizontal Pod Autoscaler (HPA) — Scaling Pod Count

HPA automatically adjusts a Deployment's (or StatefulSet's) replica count based on observed metrics — most commonly CPU/memory utilization. Critically, HPA's calculations are based on the percentage of requested resources actually being used (k8s1-10's own requests/limits material) — exactly why setting requests accurately matters even more once autoscaling is involved. This is another instance of Chapter 2 (Course 1)'s reconciliation loop: observe the current metric value, compare against target, adjust replica count to reconcile. HPA can also scale on custom metrics (e.g. requests-per-second) via metrics adapters, worth knowing exists without deep detail here.

A Concrete HPA YAML, Explained

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

Yet another distinct API group — autoscaling/v2. scaleTargetRef points at the Deployment being scaled, reusing Chapter 5's own structure. maxReplicas is a genuinely important safety bound — always cap it, tying directly to cloud1-9's cost-consciousness material, since unbounded autoscaling under a traffic spike or a misbehaving metric could scale to a genuinely expensive pod count.

Vertical Pod Autoscaler (VPA) — Scaling Pod Size

A genuinely different, complementary approach: rather than adding more pods (HPA), VPA adjusts the resource requests/limits (k8s1-10's material) of existing pods, recommending or automatically applying more appropriate CPU/memory values based on observed actual usage over time — directly solving Chapter 10's "requests set too low/too high" sizing problem automatically rather than requiring manual tuning.

VPA's default mode restarts pods to apply new values

Since k8s1-10 established that resource requests are only read at pod creation/scheduling time, VPA's default "Auto" update mode genuinely restarts pods to apply new resource values — a real operational trade-off worth knowing about directly, not a silent, cost-free adjustment.

HPA + VPA Together — A Genuine Conflict Worth Knowing About

Running HPA (based on CPU/memory utilization) and VPA (which changes the resource requests those percentages are calculated against) targeting the same workload simultaneously can create confusing, conflicting behavior — VPA changing requests changes what "70% utilization" even means for HPA's own calculation. Worth being deliberate about this combination rather than combining the two carelessly.

Cluster Autoscaler — Scaling the Nodes Themselves

A genuinely different layer from HPA/VPA — both of those scale within the existing set of nodes. Cluster Autoscaler instead adds or removes actual nodes (VMs, directly tying to cloud1-3's own VM-level auto-scaling groups material), based on whether currently-pending pods can't be scheduled due to insufficient capacity, or whether nodes sit significantly underutilized. HPA/VPA operate on pods within a fixed node set; Cluster Autoscaler operates on the nodes themselves — two different scaling problems that work together: HPA adds pods → if no node has room, those pods stay Pending (k8s1-3's pod phase material) → Cluster Autoscaler notices the pending pods and adds a new node → the pods get scheduled.

The Full Autoscaling Picture — All Three Layers Together

Traffic spikes
HPA adds more pod replicas in response to rising CPU
If existing nodes lack capacity for the new pods -> they become PENDING
Cluster Autoscaler notices the Pending pods, provisions a new node
The Pending pods get scheduled onto it
   (meanwhile, VPA, if configured, separately and gradually right-sizes
    each pod's own resource requests based on longer-term usage trends)

A genuinely satisfying "all three working together" picture, closing the loop on manual scaling, resource requests, and node-level provisioning all at once.

Accurate resource requests now matter even more

k8s1-10's "set requests accurately" point becomes doubly important with autoscaling in play — both HPA's percentage-based calculations and VPA's own recommendations directly depend on requests being meaningful in the first place.

Hands-On Exercises

Exercise 1

Explain what specific problem HPA solves that Chapter 5's manual kubectl scale doesn't, and explain why setting resource requests (Chapter 10) accurately matters more once HPA is in use, not less.

📄 View solution

Exercise 2

Explain the difference between what HPA scales and what VPA scales, and explain why running both against the same workload's CPU-based metrics simultaneously can cause confusing behavior.

📄 View solution

Exercise 3

A traffic spike causes HPA to want to scale a Deployment from 5 to 20 replicas, but only enough node capacity exists for 12 more pods. Explain what happens to the remaining pods HPA tried to create, and what would need to happen next for all 20 to actually become Running.

📄 View solution

Chapter 6 Quick Reference

HPA — scales pod COUNT, based on utilization percentage of requested resources; always set maxReplicas as a cost safeguard
VPA — scales pod SIZE (requests/limits); default mode restarts pods to apply changes
Running HPA and VPA on the same CPU-based metric simultaneously can conflict — VPA changes the very baseline HPA's percentage is calculated against
Cluster Autoscaler — scales NODES themselves, triggered by Pending pods lacking capacity or significantly underutilized nodes
Full picture: HPA adds pods → Pending if no room → Cluster Autoscaler adds a node → pods scheduled; VPA right-sizes independently over time
Accurate resource requests (Ch.10) matter even more once autoscaling depends on them
Next chapter: Observability in Kubernetes — built-in tooling limitations, Prometheus/Grafana integration