Horizontal and Vertical Pod Autoscaling — HPA, VPA and KEDA

Manual replica counts and static resource requests set at deployment time represent a perpetual compromise between two failure modes: over-provision to handle peak load and waste resources during off-peak hours, or under-provision to minimise cost and risk saturation during traffic spikes. Kubernetes autoscaling eliminates this compromise by continuously adjusting both the number of replicas and the per-Pod resource allocation in response to observed metrics. The Horizontal Pod Autoscaler (HPA) adjusts replica counts based on CPU and memory utilisation or on custom metrics from an external metrics server — adding replicas when utilisation exceeds the target, removing them when it falls below. The Vertical Pod Autoscaler (VPA) adjusts individual Pod resource requests and limits based on observed usage history, replacing the guesswork of initial resource sizing with data-driven recommendations that track actual behaviour as workload patterns evolve. KEDA (Kubernetes Event-Driven Autoscaling) extends the HPA model to arbitrary external event sources — SQS queue depth, Kafka consumer lag, Redis list length — enabling scale-to-zero behaviour that the built-in HPA cannot achieve with CPU or memory alone.

Analogy🏏Cricket

🏏 Think of it like cricket: The Pod-ReplicaSet-Deployment hierarchy maps precisely onto the three levels of IPL franchise team management. A Pod is a single player on the field at a given moment — the smallest unit of participation, carrying its own identity and fulfilling a specific role in the current game. A ReplicaSet is the franchise's match-day playing XI contract — it specifies that exactly eleven players matching a specific profile must always be on the field; if one is injured and leaves, the team management immediately sends a substitute of the same profile to restore the count. A Deployment is the franchise's season-long team strategy — it manages how the playing XI evolves between matches: when a new batting approach is adopted, the Deployment replaces the old XI with the new one in a controlled rolling substitution rather than swapping all eleven players simultaneously and disrupting team cohesion. Just as the franchise director does not manage individual players directly — the playing XI contract (ReplicaSet) handles the count and the season strategy (Deployment) handles the transitions — you never manage Pods directly in production; the Deployment manages the transition and the ReplicaSet maintains the count. This reveals why the three-level hierarchy exists rather than one omnibus 'workload' object: each level solves one specific problem, and composing three focused abstractions produces better separation of concerns than one object that conflates scheduling, scaling, and update management.