The Fundamental Challenge
Think of Kubernetes like a hotel manager. Guests (Pods) arrive and need rooms (Nodes). When all rooms are full, new guests have to wait in the lobby — this is the Pending state. The hotel manager needs an automated system that can call a construction crew to add new rooms on demand, and tear them down when occupancy drops.
In Kubernetes terms: when your application scales up — say, traffic spikes and you go from 10 replicas to 50 — your existing Nodes may run out of CPU or RAM. The Kubernetes scheduler says: "I have nowhere to put these pods. They are now Pending." Pending pods are not serving traffic. Every second they wait is a second of degraded user experience or failed batch work.
The solution is a Node Autoscaler: a controller that watches for Pending pods and automatically provisions new EC2 instances (Nodes) to host them, then decommissions those nodes when load drops. For years, the standard tool was the Kubernetes Cluster Autoscaler (CAS). AWS then introduced a fundamentally different approach: Karpenter. Understanding why Karpenter exists requires understanding exactly where CAS falls short.