VPA & Cluster Autoscaling Concepts (Karpenter)

VPA: scaling size, not count

A VerticalPodAutoscaler (VPA) watches a workload's actual CPU/memory usage over time and recommends — or, in its more aggressive modes, directly sets — better resources.requests values. Where HPA changes how many pods you have, VPA changes how big each one is.

They don't combine cleanly on the same metric: if VPA is busy resizing a pod's CPU request while HPA is simultaneously trying to read that same request to decide whether to add more pods, the two can fight each other. In practice, teams either use VPA in recommendation-only mode alongside HPA, or pick one axis per metric.

This cluster doesn't have a VPA controller installed — it's a separate controller plus its own CRDs, and installing a whole extra component for one lesson isn't worth it. The lab below has you write a correct VerticalPodAutoscaler object anyway; the object's shape is exactly what you'd ship for real, the only thing missing here is a controller to act on it.

Cluster autoscaling: a different axis entirely

HPA and VPA both assume there's room on existing nodes. Cluster autoscaling is what adds or removes nodes when there isn't.

• Cluster Autoscaler (the original, widely-deployed-for-years approach): watches for Pending pods that can't be scheduled, picks a matching node group, scales it up by a node. It plans in terms of node groups you predefined — it's bin-packing pods onto a shape you already decided on, and scaling back down means waiting for a node to become practically empty across all its pods.
• Karpenter (AWS's newer, actively-developed approach — the one you'll meet for real in Module 15): skips the node-group abstraction entirely. It looks directly at unschedulable pods' actual requirements and launches whatever instance type/size genuinely fits, bin-packing far more precisely. Scaling down is the same idea in reverse: consolidate pods onto fewer, better-fitting nodes and terminate the rest.

The traditional-infra analogy

HPA is a scaling policy on an Auto Scaling Group. Cluster autoscaling is the layer that resizes the ASG's capacity (or, with Karpenter, skips the ASG concept and launches exactly the instance shapes your pending workload needs) when the fleet itself is the bottleneck, not any one app's replica count.

The lab has you author both a VPA object and a Karpenter-shaped NodePool object by hand — reading and writing the YAML correctly is most of what you'll actually do with these day to day, even with a live controller.