Welcome back! In this lesson, we’ll prepare our environment for a hands-on demo of the Vertical Pod Autoscaler (VPA). Before applying any manifests, you need a solid understanding of Custom Resource Definitions (CRDs), which power the VPA’s custom behaviors in Kubernetes.Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.
Table of Contents
What Are Custom Resource Definitions (CRDs)?
Custom Resource Definitions extend Kubernetes’ API by letting you introduce new resource types. Built-in objects include Pods, Services, and Deployments, but CRDs allow you to teach the API “new words”—for example, VerticalPodAutoscaler. When you register a CRD:- The Kubernetes API server recognizes your custom resource kind.
- You can create, read, update, and delete custom objects just like native ones.
- Controllers and operators watch these new objects and implement the logic you define.
Ensure your cluster has the
apiextensions.k8s.io API enabled before applying any CRDs. For more details, see Kubernetes CRD Documentation.VPA-Specific CRDs
The Vertical Pod Autoscaler relies on two CRDs to function:-
VerticalPodAutoscaler
Continuously observes pod CPU and memory usage, then recalculates optimal resource requests. -
VerticalPodAutoscalerCheckpoint
Persists historical usage metrics so that the VPA controller can make data-driven recommendations, even after restarts or failures.
[!note] The diagram below shows how these two CRDs interact within the VPA architecture.

Summary of VPA CRDs
| CRD Name | Role | How It Helps |
|---|---|---|
| VerticalPodAutoscaler | Real-time resource tuning | Adjusts CPU/memory requests |
| VerticalPodAutoscalerCheckpoint | Historical usage checkpointing | Stores past metrics to guide scaling |