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
called [VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.io/v1beta1/types.go).
15
+
called [VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.io/v1beta2/types.go).
16
16
It allows to specify which pods should be under vertically autoscaled as well as if/how the
17
17
resource recommendations are applied.
18
18
19
19
To enable vertical pod autoscaling on your cluster please follow the installation
20
20
procedure described below.
21
21
22
-
23
22
# Installation
24
23
25
-
### Notice on switching from alpha to beta (<0.3.0 to >=0.3.0)
24
+
The current default version is Verical Pod Autoscaler 0.4.0
25
+
26
+
**NOTE:** version 0.4 requires at least Kubernetes 1.11 to work (needs certain
27
+
Custom Resource Definition capabilities). With older Kubernetes versions we
28
+
suggest using the [latest 0.3 version](https://github.com/kubernetes/autoscaler/blob/vpa-release-0.3/vertical-pod-autoscaler/README.md)
29
+
30
+
### Notice on switching to v1beta2 version (0.3.X to >=0.4.0)
26
31
27
-
Between versions 0.2.x and 0.3.x there is an alpha to beta switch which includes
28
-
a change of VPA apiVersion from `poc.autoscaling.k8s.io/v1alpha1` to `autoscaling.k8s.io/v1beta1`.
29
-
The safest way to switch is to use `vpa-down.sh` script to tear down
30
-
the old installation of VPA first. This will delete your old VPA objects that
31
-
have been defined with `poc.autoscaling.k8s.io/v1alpha1` apiVersion.
32
-
Then use `vpa-up.sh` to bring up the new version of VPA and create you VPA
33
-
objects from the scratch, passing apiVersion `autoscaling.k8s.io/v1beta1`
34
-
(See [example](./examples/hamster.yaml)).
32
+
In 0.4.0 we introduced a new version of the API - `autoscaling.k8s.io/v1beta2`.
33
+
Full API is accessible [here](https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.io/v1beta2/types.go).
35
34
36
-
If you want to migrate your objects between versions, you can use the [object conversion script](./hack/convert-alpha-objects.sh).
37
-
It will save your VPA objects into temporary yaml files with the new apiVersion.
38
-
After running the script:
39
-
1. disable alpha VPA via vpa-down.sh script
40
-
1. enable beta VPA via vpa-up.sh script
41
-
1. re-create VPA objects following the instructions from the script.
35
+
The change introduced is in the way you express what pods should be scaled by a
36
+
given Vertical Pod Autoscaler. In short we are moving from label selectors to
37
+
controller references. Let's start with an example to ilustrate the change:
42
38
43
-
**NOTE: ** The script is experimental. Please check that the yaml files it generates are correct.
44
-
When switching between alpha and beta, VPA recommendations will NOT be kept and there
45
-
will be a brief disruption period until the new VPA computes new recommendations.
39
+
**[DEPRECATED]** In `v1beta1` pods to scale by VPA are specified by a
**[RECOMMENDED]** In `v1beta2` pods to scale by VPA are specified by a
54
+
target reference. This target will usually be a Deployment, as configured in the
55
+
example below.
56
+
57
+
```yaml
58
+
apiVersion: "autoscaling.k8s.io/v1beta1"
59
+
kind: VerticalPodAutoscaler
60
+
metadata:
61
+
name: hamster-vpa
62
+
spec:
63
+
targetRef:
64
+
apiVersion: "extensions/v1beta1"
65
+
kind: Deployment
66
+
name: hamster
48
67
```
49
-
./hack/convert-alpha-objects.sh
68
+
69
+
The target object can be a well known controller (Deployment, ReplicaSet, DaemonSet, StatefulSet etc.)
70
+
or any object that implements the scale subresource. VPA uses ScaleStatus to
71
+
retrieve the pod set controlled by this objetc.
72
+
If VerticalPodAutoscaler cannot use specified target it will report
73
+
ConfigUnsupported condition.
74
+
75
+
Note that VerticalPodAutoscaler does not require full implementation
76
+
of scale subresource - it will not use it to modify the replica count.
77
+
The only thing retrieved is a label selector matching pods grouped by this controller.
78
+
79
+
See complete examples:
80
+
* [v1beta2](./examples/hamster.yaml)
81
+
* [v1beta1](./examples/hamster-deprecated.yaml)
82
+
83
+
You can perform a 0.3 to 0.4 upgrade without losing your VPA objects.
84
+
The recommended way is as follows:
85
+
86
+
1. Run `./hack/vpa-apply-upgrade.sh` - this will restart your VPA installation with
87
+
a new version, add the new API and keep all your VPA objects.
88
+
1. Your `v1beta1` objects will be marked as deprecated but still work
89
+
1. Switch your VPA definition to
90
+
`apiVersion: "autoscaling.k8s.io/v1beta2"`
91
+
1. Modify the VPA spec to:
92
+
```yaml
93
+
spec:
94
+
# Note the empty selector field - this is needed to remove previously defined selector
95
+
selector:
96
+
targetRef:
97
+
apiVersion: "extensions/v1beta1"
98
+
kind: "Deployment"
99
+
name: "<deployment_name>"# This matches the deployment name
50
100
```
101
+
5. Kubectl apply -f the above
102
+
103
+
You can also first try the new API in the `"Off"` mode.
104
+
105
+
### Notice on switching from alpha to beta (<0.3.0 to 0.4.0+)
106
+
107
+
**NOTE:** We highly recommend switching to the 0.4.X version. However,
108
+
for instructions on switching to 0.3.X see the [0.3 version README](https://github.com/kubernetes/autoscaler/blob/vpa-release-0.3/vertical-pod-autoscaler/README.md)
109
+
110
+
Between versions 0.2.x and 0.4.x there is an alpha to beta switch which includes
111
+
a change of VPA apiVersion. The safest way to switch is to use `vpa-down.sh`
112
+
script to tear down the old installation of VPA first. This will delete your old
113
+
VPA objects that have been defined with `poc.autoscaling.k8s.io/v1alpha1`
114
+
apiVersion. Then use `vpa-up.sh` to bring up the new version of VPA and create
115
+
your VPA objects from the scratch, passing apiVersion
116
+
`autoscaling.k8s.io/v1beta2`and switching from selector to targetRef, as
117
+
described in the prevous section.
51
118
52
119
### Prerequisites
53
120
54
-
* It is strongly recommended to use Kubernetes 1.9 or greater.
55
-
Your cluster must support MutatingAdmissionWebhooks, which are enabled by default
56
-
since 1.9 ([#58255](https://github.com/kubernetes/kubernetes/pull/58255)).
57
-
Read more about [VPA Admission Webhook](./pkg/admission-controller/README.md#running).
121
+
* VPA version 0.4+ requires Kubernetes 1.11. For older versions see [latest 0.3 version](https://github.com/kubernetes/autoscaler/blob/vpa-release-0.3/vertical-pod-autoscaler/README.md)
58
122
* `kubectl` should be connected to the cluster you want to install VPA in.
59
123
* The metrics server must be deployed in your cluster. Read more about [Metrics Server](https://github.com/kubernetes-incubator/metrics-server).
60
124
* If you are using a GKE Kubernetes cluster, you will need to grant your current Google
@@ -97,9 +161,8 @@ with the API server.
97
161
After [installation](#installation) the system is ready to recommend and set
98
162
resource requests for your pods.
99
163
In order to use it you need to insert a *Vertical Pod Autoscaler* resource for
100
-
each logical group of pods that have similar resource requirements.
101
-
We recommend to insert a *VPA* per each *Deployment* you want to control
102
-
automatically and use the same label selector as the *Deployment* uses.
164
+
each controller that you want to have automatically computed resource requirements.
165
+
This will be most commonly a **Deployment**.
103
166
There are three modes in which *VPAs* operate:
104
167
105
168
* `"Auto"`: VPA assigns resource requests on pod creation as well as updates
0 commit comments