Kubernetes VPA Resource Policy
Kubernetes VPA Resource Policy dynamically adjusts pod resources based on usage, ensuring optimal performance and efficient cluster utilization.
Kubernetes VPA Resource Policy is the resourcePolicy section of a VerticalPodAutoscaler object, which lets operators constrain, exclude, or otherwise shape how the Recommender and Updater treat individual containers within a pod, providing fine-grained control over vertical scaling behavior beyond the workload-wide updateMode setting.
containerPolicies Structure
Targeting Specific Containers
Each entry in resourcePolicy.containerPolicies applies to a container matched by name, or to all containers via the wildcard name *, allowing a policy to set a baseline for every container while overriding specific ones individually.
spec:
resourcePolicy:
containerPolicies:
- containerName: "*"
minAllowed:
cpu: 50m
memory: 64Mi
maxAllowed:
cpu: 2
memory: 4Gi
- containerName: sidecar-proxy
mode: "Off"
mode: Off to Exclude a Container Entirely
Setting mode: "Off" for a specific container excludes it from both recommendation and automatic update, which is the standard way to prevent VPA from resizing a sidecar (a service mesh proxy, a logging agent) whose resource needs are managed separately or intentionally fixed.
Bounding Recommendations
minAllowed and maxAllowed
These fields establish a floor and ceiling on whatever value the Recommender would otherwise suggest, ensuring a container's resources never fall below a minimum needed for basic function, nor rise above a maximum that could be justified by cost, node capacity, or organizational policy regardless of observed usage.
containerPolicies:
- containerName: app
minAllowed:
cpu: 100m
memory: 128Mi
maxAllowed:
cpu: 4
memory: 8Gi
Interaction With ResourceQuota
Because maxAllowed bounds only what VPA itself will apply, it does not automatically guarantee compliance with a namespace's ResourceQuota; a VPA recommendation within its own maxAllowed bound can still be rejected at admission time if applying it would exceed the namespace's aggregate quota, meaning the two mechanisms should be reviewed together rather than assumed to be mutually enforcing.
controlledResources and controlledValues
Selecting Which Resource Types VPA Manages
controlledResources restricts VPA's management to a subset of resource types (cpu, memory), useful when a container's memory should remain manually configured while CPU is managed automatically, or vice versa.
containerPolicies:
- containerName: app
controlledResources: ["memory"]
RequestsOnly Versus RequestsAndLimits
controlledValues determines whether VPA adjusts only the resource RequestsOnly or both RequestsAndLimits together; managing requests alone while leaving limits under manual control is a common pattern for workloads where the operator wants VPA to right-size scheduling-relevant requests but retain explicit control over the hard ceiling a container's limit represents.
containerPolicies:
- containerName: app
controlledValues: "RequestsOnly"
Designing Resource Policies for Common Scenarios
Protecting Sidecars From Unintended Resizing
A pod combining an application container with a sidecar should typically set mode: "Off" for the sidecar unless there is a specific reason to let VPA manage it, since sidecar resource needs (a proxy's connection-handling overhead, for instance) often do not follow the same usage pattern the Recommender's statistical model is designed to capture well.
Establishing Organization-Wide Floors and Ceilings
Setting a wildcard containerName: "*" policy with sensible minAllowed and maxAllowed values across all VPA objects in a cluster (via a shared manifest template or policy-as-code enforcement) ensures no individual VPA recommendation, however derived, can push a container's resources to an extreme that would be operationally or financially problematic.
Verifying Resource Policy Effect
Confirming Bounds Are Actually Applied
Comparing the status.recommendation values against the configured minAllowed/maxAllowed bounds confirms the policy is constraining the Recommender's output as intended, since a recommendation sitting exactly at a bound (rather than the Recommender's unconstrained preferred value) indicates the bound is actively limiting the suggestion.
kubectl get vpa batch-worker-vpa -o jsonpath='{.status.recommendation.containerRecommendations}'
Testing Policy Changes in Isolation
Adjusting a resource policy on a VPA already running in Off mode, and reviewing the resulting recommendation before switching to Auto or Initial, confirms the new bounds produce sensible values before they are allowed to actually affect running pods.