Context
Vertical Pod Autoscaler recommendations can inform resource sizing without immediately changing running workloads. Recommendation-only operation gives a team time to compare observed demand with performance objectives, deployment constraints, and cost. The recommendation is evidence to review, not proof that the application will remain healthy under every future peak.
Identify the installed VPA contract
Record VPA version, API version, recommender configuration, target reference, update policy, and resource policy. The upstream project evolves, so use its current documentation for the installed release rather than assuming every update mode behaves like an old example.
In the documented recommendation-only mode, setting the update policy's updateMode to Off leaves recommendations available without VPA automatically applying resource changes. Distinguish that setting from disabling recommendations for an individual container in its container policy; similarly named fields have different scopes.
Confirm that the target and history are meaningful
Verify the VPA targets the intended controller and observes the expected containers. Sidecars, renamed containers, recently created workloads, and missing metrics can make the visible recommendation incomplete or unrepresentative.
Record the observation period and workload coverage. A service seen only during a quiet weekend has not demonstrated its month-end processing needs. Include startup, deployments, peak traffic, background work, and known exceptional tasks in the review.
Inspect recommendation conditions and bounds, not only the target value. A lower bound, target, and upper bound communicate different aspects of the recommendation model. Avoid presenting the target as a guarantee against OOM kills or latency degradation.
Apply operational constraints deliberately
Compare recommendations with namespace LimitRange, quotas, node shapes, platform minimums, and the workload's scheduling constraints. A theoretically appropriate request can still make Pods unschedulable in the available node pool.
Review controlled resources and controlled-value behavior according to the installed VPA version. Determine whether an eventual automatic mode would change requests only or related limits as well. Memory limits, CPU limits, and application runtime settings must remain consistent.
Check interaction with HPA. If horizontal scaling uses utilization relative to requests, changing those requests changes the scaling signal. Avoid letting two controllers independently modify the same capacity relationship without a reviewed design.
An illustrative incomplete observation
A batch service is observed between its weekly processing windows. The recommendation suggests substantially less memory, and the team considers applying it immediately. The next full dataset has not appeared in the observation period.
The team keeps recommendation-only mode active through a representative cycle, runs a controlled full-data test, and documents the accepted request with headroom. It retains a different configuration for exceptional reprocessing rather than assuming a quiet-period recommendation covers every workload shape.
Quick diagnostic map
| Evidence | Question | Next check |
|---|---|---|
| No recommendation for a container | Is it targeted and observed? | Container policy and metrics |
| Very low target after short history | Was peak work included? | Observation period and workload calendar |
| Recommended Pod remains pending | Does the platform support it? | Node shape, quota, and constraints |
| HPA behavior changes after resizing | Did the denominator change? | CPU request and utilization target |
A focused operator exercise
Enable recommendation-only behavior for a representative test workload and confirm running resources remain unchanged. Capture the target, conditions, bounds, and observation period. Compare them with measured startup, steady-state, and peak demand.
Prepare a reviewed resource change and roll it out to a limited test population. Verify latency, memory high-water behavior, OOM events, scheduling, and horizontal scaling. Rehearse restoring the previous requests. Keep the accepted values in source configuration so a later deployment does not silently revert the decision.
Decide when automation is appropriate
Automatic resource changes can introduce replacement or update behavior depending on supported mode and platform capabilities. Review disruption budgets, replica count, stateful requirements, and maintenance expectations before enabling such a mode.
Assign ownership for reviewing stale recommendations after software changes. Recommendation history is useful only when teams can connect it with the workload version and data profile that produced it. Measure useful completed work and cost together after a sizing change.
Frequently asked questions
Does updateMode: Off stop recommendations?
In the documented recommendation-only behavior, recommendations continue while automatic updates are disabled. Verify the installed version and distinguish per-container policy settings.
Can I copy the target value directly into production?
Review history, constraints, peaks, and scaling interaction, then validate a controlled rollout. A target value alone is not an acceptance test.
Continue the investigation
- Kubernetes CPU Throttling: Investigate Latency Below Average CPU Limits
- GKE Autopilot Requests: Inspect Admission Changes Before Estimating Cost
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Containers & Kubernetes to discuss implementation, validation and operational handover.
Technical reference
autoscaler/vertical-pod-autoscaler/docs/features.md at master · kubernetes/autoscaler · GitHub
autoscaler/vertical-pod-autoscaler/docs/components.md at master · kubernetes/autoscaler · GitHub