You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: vertical-pod-autoscaler/docs/examples.md
+14Lines changed: 14 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,6 +11,7 @@
11
11
-[Controlling eviction behavior based on scaling direction and resource](#controlling-eviction-behavior-based-on-scaling-direction-and-resource)
12
12
-[Limiting which namespaces are used](#limiting-which-namespaces-are-used)
13
13
-[Setting the webhook failurePolicy](#setting-the-webhook-failurepolicy)
14
+
-[Specifying global maximum allowed resources to prevent pods from being unschedulable](#specifying-global-maximum-allowed-resources-to-prevent-pods-from-being-unschedulable)
14
15
15
16
## Keeping limit proportional to request
16
17
@@ -108,3 +109,16 @@ These options cannot be used together and are mutually exclusive.
108
109
It is possible to set the failurePolicy of the webhook to `Fail` by passing `--webhook-failure-policy-fail=true` to the VPA admission controller.
109
110
Please use this option with caution as it may be possible to break Pod creation if there is a failure with the VPA.
110
111
Using it in conjunction with `--ignored-vpa-object-namespaces=kube-system` or `--vpa-object-namespace` to reduce risk.
112
+
113
+
### Specifying global maximum allowed resources to prevent pods from being unschedulable
114
+
115
+
The [Known limitations dcoument](./known-limitations.md) outlines that VPA (vpa-recommender in particular) is not aware of the cluster's maximum allocatable and can recommend resources which will not fit even the largest node in the cluster. This issue occurs even when the cluster uses the [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#basics). The vpa-recommender's resource recommendation can exceed the allocatable of the largest node in the cluster. Hence, pod's will be unschedulable (in `Pending` state) and the pod wouldn't fit the cluster even if a new node is added by the Cluster Autoscaler.
116
+
It is possible to mitigate this issue by specifying the `--container-recommendation-max-allowed-cpu` and `--container-recommendation-max-allowed-memory` flags of the vpa-recommender. These flags represent the global maximum amount of cpu/memory that will be recommended **for a container**. If the VerticalPodAutoscaler already defines a max allowed (`.spec.resourcePolicy.containerPolicies.maxAllowed`) then it takes precedence over the global max allowed. The global max allowed is merged to the VerticalPodAutoscaler's max allowed if VerticalPodAutoscaler's max allowed is specified only for cpu or memory. If the VerticalPodAutoscaler does not specify a max allowed and a global max allowed is specified, then the global max allowed is being used.
117
+
118
+
The recommendation for computing the `--container-recommendation-max-allowed-cpu` and `--container-recommendation-max-allowed-memory` values for your cluster is to use the largest node's allocatable (`.status.allocatable` field of a node) minus the DaemonSet pods resource requests minus a safety margin:
> Pay attention that `--container-recommendation-max-allowed-cpu` and `--container-recommendation-max-allowed-memory` are **container-level** flags. A pod enabling autoscaling for more than one container can theoretically still get unschedulable if the sum of the resource recommendations of the containers exceeds the largest Node's allocatable. In practice, it is not very likely to hit such case as usually a single container in a pod is the main one, the others are sidecars that either do not need autoscaling or do not consume high resource requests.
Copy file name to clipboardExpand all lines: vertical-pod-autoscaler/docs/faq.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -215,6 +215,8 @@ Name | Type | Description | Default
215
215
`container-pod-name-label`| String | Label name to look for container pod names | "pod_name"
216
216
`container-name-label`| String | Label name to look for container names | "name"
217
217
`vpa-object-namespace`| String | Namespace to search for VPA objects and pod stats. Empty means all namespaces will be used. | apiv1.NamespaceAll
218
+
`container-recommendation-max-allowed-cpu`| Quantity | Maximum amount of CPU that will be recommended for a container. VerticalPodAutoscaler-level maximum allowed takes precedence over the global maximum allowed. | Empty (no max allowed cpu by default)
219
+
`container-recommendation-max-allowed-memory`| Quantity | Maximum amount of memory that will be recommended for a container. VerticalPodAutoscaler-level maximum allowed takes precedence over the global maximum allowed. | Empty (no max allowed memory by default)
218
220
`memory-aggregation-interval`| Duration | The length of a single interval, for which the peak memory usage is computed. Memory usage peaks are aggregated in multiples of this interval. In other words there is one memory usage sample per interval (the maximum usage over that interval | model.DefaultMemoryAggregationInterval
219
221
`memory-aggregation-interval-count`| Int64 | The number of consecutive memory-aggregation-intervals which make up the MemoryAggregationWindowLength which in turn is the period for memory usage aggregation by VPA. In other words, MemoryAggregationWindowLength = memory-aggregation-interval * memory-aggregation-interval-count. | model.DefaultMemoryAggregationIntervalCount
220
222
`memory-histogram-decay-half-life`| Duration | The amount of time it takes a historical memory usage sample to lose half of its weight. In other words, a fresh usage sample is twice as 'important' as one with age equal to the half life period. | model.DefaultMemoryHistogramDecayHalfLife
Copy file name to clipboardExpand all lines: vertical-pod-autoscaler/docs/known-limitations.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,9 @@
21
21
- VPA performance has not been tested in large clusters.
22
22
- VPA recommendation might exceed available resources (e.g. Node size, available
23
23
size, available quota) and cause **pods to go pending**. This can be partly
24
-
addressed by using VPA together with [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#basics).
24
+
addressed by:
25
+
* using VPA together with [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#basics) - the drawback of this approach is that pods can still get unschedulable if the recommendation exceeds the largest Node's allocatable.
26
+
* specifying the `--container-recommendation-max-allowed-cpu` and `--container-recommendation-max-allowed-memory` flags - the drawback of this approach is that a pod can still get unschedulable if more than one container in the pod is scaled by VPA and the sum of the container recommendations exceeds the largest Node's allocatable.
25
27
- Multiple VPA resources matching the same pod have undefined behavior.
26
28
- Running the vpa-recommender with leader election enabled (`--leader-elect=true`) in a GKE cluster
27
29
causes contention with a lease called `vpa-recommender` held by the GKE system component of the
Copy file name to clipboardExpand all lines: vertical-pod-autoscaler/pkg/recommender/main.go
+22-1Lines changed: 22 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -25,6 +25,7 @@ import (
25
25
26
26
"github.com/spf13/pflag"
27
27
apiv1 "k8s.io/api/core/v1"
28
+
"k8s.io/apimachinery/pkg/api/resource"
28
29
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
29
30
"k8s.io/apimachinery/pkg/util/uuid"
30
31
"k8s.io/client-go/informers"
@@ -103,6 +104,8 @@ var (
103
104
var (
104
105
// CPU as integer to benefit for CPU management Static Policy ( https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy )
105
106
postProcessorCPUasInteger=flag.Bool("cpu-integer-post-processor-enabled", false, "Enable the cpu-integer recommendation post processor. The post processor will round up CPU recommendations to a whole CPU for pods which were opted in by setting an appropriate label on VPA object (experimental)")
107
+
maxAllowedCPU= resource.QuantityValue{}
108
+
maxAllowedMemory= resource.QuantityValue{}
106
109
)
107
110
108
111
const (
@@ -115,6 +118,11 @@ const (
115
118
defaultResyncPeriod time.Duration=10*time.Minute
116
119
)
117
120
121
+
funcinit() {
122
+
flag.Var(&maxAllowedCPU, "container-recommendation-max-allowed-cpu", "Maximum amount of CPU that will be recommended for a container. VerticalPodAutoscaler-level maximum allowed takes precedence over the global maximum allowed.")
123
+
flag.Var(&maxAllowedMemory, "container-recommendation-max-allowed-memory", "Maximum amount of memory that will be recommended for a container. VerticalPodAutoscaler-level maximum allowed takes precedence over the global maximum allowed.")
0 commit comments