Static replica counts are a poor fit for variable traffic patterns. A cricket scores API receives 10× normal traffic when a T20 match is in its final over and 0.1× normal traffic at 3am. Overprovisioning for peak load wastes money during off-peak hours. Underprovisioning for average load causes degraded performance during spikes. Kubernetes provides three autoscaling mechanisms that together handle variable load efficiently. The Horizontal Pod Autoscaler (HPA) scales the number of Pod replicas based on CPU utilisation, memory utilisation, or custom metrics. The Vertical Pod Autoscaler (VPA) adjusts the CPU and memory requests/limits of individual Pods based on observed usage. The Cluster Autoscaler adds or removes nodes from the cluster when there are pending Pods that can't be scheduled (scale up) or underutilised nodes (scale down). Together they form a multi-level autoscaling stack that adapts both the application tier and the infrastructure tier to workload.
35 minintermediate
Autoscaling — HPA and Cluster Scaling
Analogy🏏Cricket
🏏 Think of it like cricket: A well-run cricket board has distinct departments with clear responsibilities: the selection committee chooses players, the grounds department prepares venues, the scheduling department assigns matches to grounds, the operations department manages logistics, and the referees enforce the rules. No department does another's job, and all communication flows through the central secretariat. Just as the ICC's effectiveness comes from each department having a clear mandate and working through a central coordination system, Kubernetes' reliability comes from each component (API server, scheduler, controller manager, etcd, kubelet, kube-proxy) having a single responsibility and communicating only through the API server as the central hub. The insight is that this architecture makes the system resilient: a failure in the scheduling department doesn't stop ongoing matches, just as a failing scheduler doesn't kill running Pods.
Lesson 17 of 24
0% complete