Delayed reaction Triggering a scaling action based on a metric value is a multistep process involv‐ ing multiple Kubernetes components. First, it is the cAdvisor (container advisor) agent that collects metrics at regular intervals for the Kubelet. Then the metrics server collects metrics from the Kubelet at regular intervals. The HPA controller loop also runs periodically and analyzes the collected metrics. The HPA scaling formula introduces some delayed reaction to prevent fluctuations/thrashing (as explained in the previous point). All this activity accumulates into a delay between the cause and the scaling reaction. Tuning these parameters by introduc‐ ing more delay makes the HPA less responsive, but reducing the delays increases the load on the platform and increases thrashing. Configuring Kubernetes to bal‐ ance resources and performance is an ongoing learning process. Knative serving (which we introduce in “Knative Build” on page 230) allows even more advanced horizontal scaling techniques. These advanced features include “scale- to-zero” where the set of Pods backing a Service can be scaled down to 0 and scaled up only when a specific trigger happens, like an incoming request. For this to work, Knative is built on top of the service mesh Istio, which in turn provides transparent internal proxying services for Pods. Knative serving provides the foundation for a serverless framework for an even more flexible and fast horizontal scaling behavior that goes beyond the Kubernetes standard mechanisms. A detailed discussion of Knative serving is beyond the scope of this book, as this is still a very young project and deserves its own book. We have added more links to Knative resources in “More Information” on page 219. Horizontal scaling is preferred over vertical scaling because it is less disruptive, espe‐ cially for stateless services. That is not the case for stateful services where vertical scal‐ ing may be preferred. Other scenarios where vertical scaling is useful is for tuning the actual resource needs of a service based on actual load patterns. We have discussed why identifying the correct number of replicas of a Pod might be difficult and even impossible when load changes over time. Vertical scaling also has these kinds of chal‐ lenges in identifying the correct  requests  and  limits  for a container. The Kuber‐ netes Vertical Pod Autoscaler (VPA) aims to address these challenges by automating the process of adjusting and allocating resources based on real-world usage feedback. As we saw in Chapter 2,  Predictable Demands , every container in a Pod can specify its CPU and memory  requests , which influences where the managing Pods will be scheduled. In a sense, the resource  requests  and  limits  of a Pod form a contract 210  |  Chapter 24: Elastic Scale Vertical Pod Autoscaling Knative Serving