Skip to content

VPA component architecture

VPA component architecture refers to the internal design of the Kubernetes Vertical Pod Autoscaler (VPA), which consists of three distinct components that interact to monitor resource utilization and adjust Pod resource requests^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md]. Unlike the Horizontal Pod Autoscaler (HPA), which is built into the Kubernetes API, VPA is implemented as a set of custom components installed via Custom Resource Definitions (CRDs)^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md].

Core Components

The VPA system is composed of three main elements: the Recommender, the Updater, and the Admission Controller^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md].

Recommender

The Recommender is responsible for the initial analysis and calculation of resource needs^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md]. It continuously monitors historical resource Metrics to determine optimal values^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md]. Based on this data and the specific requirements defined in the VPA configuration, it calculates recommended requests and limits for CPU and memory^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md].

Updater

The Updater acts on the recommendations provided by the Recommender^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md]. Its primary role is to drive the actual application of these values, which typically involves evicting (deleting) existing Pods that need to be updated^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md]. This component operates primarily when the VPA updateMode is set to Auto, meaning it will automatically trigger Pod restarts to apply the new resource settings^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md].

Admission Controller

The Admission Controller functions as the mechanism that applies the configuration changes during the Pod recreation process^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md]. After the Updater evicts an old Pod, the Deployment controller attempts to create a replacement. Before this new Pod is finalized, the Admission Controller intercepts the request via a Webhook to patch the Pod's specification, applying the updated requests and limits calculated by the Recommender^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md].

Architecture Workflow

The interaction between these components follows a cyclic workflow to ensure resource settings stay aligned with actual usage^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md].

  1. Monitoring: The Recommender observes the resource usage history of the pods controlled by the VPA.
  2. Calculation: It generates a recommendation (e.g., Target, Lower Bound, Upper Bound) based on observed OOM kills or usage patterns^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md].
  3. Eviction: In Auto mode, the Updater identifies Pods whose current resources deviate from the recommendation and evicts them^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md].
  4. Patching: As the Deployment recreates the Pod, the Admission Controller webhook injects the recommended values into the new Pod's spec^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md].

Implementation Considerations

The architecture of VPA relies on specific Kubernetes infrastructure to function. The Admission Controller utilizes a mutating webhook, which requires TLS certificates to be generated and uploaded to the cluster during installation^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md]. Furthermore, because the process relies on Pod eviction to apply changes in Auto mode, the architecture assumes the workload is managed by a controller (such as a Deployment) that can automatically replace terminated Pods^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md].

Sources

^[400-devops__06-Kubernetes__k8s-ithelp__Day27__README.md]