between the Pod and the scheduler, which causes a certain amount of resources to be guaranteed or prevents the Pod from being scheduled. Setting the memory  requests too low can cause nodes to be more tightly packed which in turn can lead to out-of- memory errors or workload eviction due to memory pressure. If the CPU  limits  are too low, CPU starvation and underperforming workloads can occur. On the other hand, specifying resource  requests  that are too high allocates unnecessary capacity leading to wasted resources. It is important to get resource  requests  as accurately as possible since they impact the cluster utilization and the effectiveness of horizontal scaling. Let’s see how VPA helps address this. On a cluster with VPA and the metrics server installed, we can use a VPA definition to demonstrate vertical autoscaling of Pods, as in Example 24-5. A VPA definition has the following main parts: Label selector Specifies what to scale by identifying the Pods it should handle. Update policy Controls how VPA applies changes. The  Initial  mode allows assigning resource requests only during Pod creation time but not later. The default  Auto  mode allows resource assignment to Pods at creation time, but additionally, it can update Pods during their lifetimes, by evicting and rescheduling the Pod. The value  Off  disables automatic changes to Pods, but allows suggesting resource val‐ ues. This is a kind of dry run for discovering the right size of a container, but without applying it directly. Solution  |  211 Label selector to identify the Pods to manage The update policy for how VPA will apply changes Example 24-5. VPA apiVersion : poc.autoscaling.k8s.io/v1alpha1 kind : VerticalPodAutoscaler metadata : name : random-generator-vpa spec : selector : matchLabels : app : random-generator updatePolicy : updateMode : "Off"