updateMode: Auto In addition to the recommendation creation and its application for newly created Pods as described previously, in this mode the VPA also activates its updated component. This component evicts running Pods matching its label selector. After the eviction, the Pods get recreated by the VPA admission plugin compo‐ nent, which updates their resource requests. So this approach is the most disrup‐ tive as it restarts all Pods to forcefully apply the recommendations and can lead to unexpected scheduling issues as described earlier. Kubernetes is designed to manage immutable containers with immutable Pod  spec definitions as seen in Figure 24-2. While this simplifies horizontal scaling, it introdu‐ ces challenges for vertical scaling such as requiring Pod deletion and recreation, which can impact scheduling and cause service disruptions. This is true even when the Pod is scaling down and wants to release already allocated resources with no dis‐ ruption. Another concern is around the VPA and HPA coexistence because these autoscalers are not currently aware of each other, which can lead to unwanted behavior. For example, if an HPA is using resource metrics such as CPU and memory and the VPA is also influencing the same values, you may end up with horizontally scaled Pods that are also vertically scaled (hence double scaling). We don’t go into more detail here because the VPA is still in beta and may change after it’s in active use. But it is a feature that has the potential to improve resource consumption significantly. The patterns in this book primarily use Kubernetes primitives and resources targeted at developers using a Kubernetes cluster that’s already set up, which is usually an operational task. Since it is a topic related to elasticity and scaling of workloads, we will cover the Kubernetes Cluster Autoscaler (CA) here briefly. Cluster Autoscaling Figure 24-2. Vertical Pod autoscaling mechanism Solution  |  213