Skip to content

Commit d13d78e

Browse files
committed
VPA: add document behavior for Requests & Limits
1 parent 0a9528b commit d13d78e

File tree

1 file changed

+13
-0
lines changed
  • vertical-pod-autoscaler/docs

1 file changed

+13
-0
lines changed

vertical-pod-autoscaler/docs/faq.md

+13
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,7 @@
1313
- [How can I configure VPA to manage only specific resources?](#how-can-i-configure-vpa-to-manage-only-specific-resources)
1414
- [How can I have Pods in the kube-system namespace under VPA control in AKS?](#how-can-i-have-pods-in-the-kube-system-namespace-under-vpa-control-in-aks)
1515
- [How can I configure VPA when running in EKS with Cilium?](#how-can-i-configure-vpa-when-running-in-eks-with-cilium)
16+
- [Why does VPA fail to create a Pod when resource limits are explicitly set to 0?](#why-does-vpa-fail-to-create-a-pod-when-resource-limits-are-explicitly-set-to-0)
1617

1718
### VPA restarts my pods but does not modify CPU or memory settings
1819

@@ -244,3 +245,15 @@ The `--webhook-labels` parameter for the VPA admission-controller can be used to
244245
When running in EKS with Cilium, the EKS API server cannot route traffic to the overlay network. The VPA admission-controller
245246
Pods either need to use host networking or be exposed through a service or ingress.
246247
See the [Cilium Helm installation page](https://docs.cilium.io/en/stable/installation/k8s-install-helm/) for more info.
248+
249+
### Why does VPA fail to create a Pod when resource limits are explicitly set to 0?
250+
VPA currently handles requests=0 and limits=0 inconsistently with Kubernetes, leading to invalid Pod configurations. Here’s the breakdown:
251+
252+
| Scenario | Kubernetes Behavior | VPA Behavior |
253+
|-------------------------|----------------------------------------------|----------------------------------------------|
254+
| `requests=0`+`limits=0`| Disables resource fields (BestEffort QoS) | Disables limits but recommends non-zero requests (**QoS conflict**) |
255+
| `requests=limits≠0` | Guaranteed QoS | Maintains Guaranteed QoS |
256+
| `requests≠limits` | Burstable QoS | Maintains Burstable QoS |
257+
258+
VPA avoids modifying QoS classes by design. When a Pod is created with requests=0 and limits=0, Kubernetes treats it as BestEffort, but VPA attempts to set non-zero requests (e.g., via recommendations), inadvertently changing the QoS class to Burstable or Guaranteed. This violates VPA’s principle of preserving QoS. See the [Pod Qos](https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/) for more info.
259+

0 commit comments

Comments
 (0)