✦ For everyone, free.

Practical knowledge for real and everyday life

Home

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.