Skip to content

Commit

Permalink
Update old main README for VPA
Browse files Browse the repository at this point in the history 
Add compability for 0.9, 0.10 and 0.11 VPA version.
Fix grammar
  • Loading branch information
@aleksrosz
aleksrosz committed Aug 8, 2022
1 parent d53220f commit 0eb7499
Showing 1 changed file with 39 additions and 39 deletions.
78 changes: 39 additions & 39 deletions vertical-pod-autoscaler/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@

# Intro

Vertical Pod Autoscaler (VPA) frees the users from necessity of setting
Vertical Pod Autoscaler (VPA) frees users from the necessity of setting
up-to-date resource limits and requests for the containers in their pods. When
configured, it will set the requests automatically based on usage and thus
allow proper scheduling onto nodes so that appropriate resource amount is
Expand All @@ -34,7 +34,6 @@ It can both down-scale pods that are over-requesting resources, and also
up-scale pods that are under-requesting resources based on their usage over
time.


Autoscaling is configured with a
[Custom Resource Definition object](https://kubernetes.io/docs/concepts/api-extension/custom-resources/)
called [VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.io/v1/types.go).
Expand All @@ -50,13 +49,14 @@ The current default version is Vertical Pod Autoscaler 0.11.0

### Compatibility

| VPA version | Kubernetes version |
| --- | --- |
| 0.11 | 1.22+ |
| 0.9 to 0.10 | 1.16+ |
| 0.8 | 1.13+ |
| 0.4 to 0.7 | 1.11+ |
| 0.3.X and lower | 1.7+ |
| VPA version | Kubernetes version |
|-----------------|--------------------|
| 0.11 | 1.22+ |
| 0.10 | 1.22+ |
| 0.9 | 1.16+ |
| 0.8 | 1.13+ |
| 0.4 to 0.7 | 1.11+ |
| 0.3.X and lower | 1.7+ |

### Notice on removal of v1beta1 version (>=0.5.0)

Expand All @@ -70,10 +70,10 @@ This doc is for installing latest VPA. For instructions on migration from older

### Prerequisites

* `kubectl` should be connected to the cluster you want to install VPA in.
* `kubectl` should be connected to the cluster you want to install VPA.
* The metrics server must be deployed in your cluster. Read more about [Metrics Server](https://github.com/kubernetes-incubator/metrics-server).
* If you are using a GKE Kubernetes cluster, you will need to grant your current Google
identity `cluster-admin` role. Otherwise you won't be authorized to grant extra
identity `cluster-admin` role. Otherwise, you won't be authorized to grant extra
privileges to the VPA system components.
```console
$ gcloud info | grep Account # get current google identity
Expand Down Expand Up @@ -128,13 +128,13 @@ The output of that command won't include secret information generated by

After [installation](#installation) the system is ready to recommend and set
resource requests for your pods.
In order to use it you need to insert a *Vertical Pod Autoscaler* resource for
In order to use it, you need to insert a *Vertical Pod Autoscaler* resource for
each controller that you want to have automatically computed resource requirements.
This will be most commonly a **Deployment**.
There are four modes in which *VPAs* operate:

* `"Auto"`: VPA assigns resource requests on pod creation as well as updates
them on existing pods using the preferred update mechanism. Currently this is
them on existing pods using the preferred update mechanism. Currently, this is
equivalent to `"Recreate"` (see below). Once restart free ("in-place") update
of pod requests is available, it may be used as the preferred update mechanism by
the `"Auto"` mode. **NOTE:** This feature of VPA is experimental and may cause downtime
Expand All @@ -143,12 +143,12 @@ There are four modes in which *VPAs* operate:
them on existing pods by evicting them when the requested resources differ significantly
from the new recommendation (respecting the Pod Disruption Budget, if defined).
This mode should be used rarely, only if you need to ensure that the pods are restarted
whenever the resource request changes. Otherwise prefer the `"Auto"` mode which may take
advantage of restart free updates once they are available. **NOTE:** This feature of VPA
whenever the resource request changes. Otherwise, prefer the `"Auto"` mode which may take
advantage of restart-free updates once they are available. **NOTE:** This feature of VPA
is experimental and may cause downtime for your applications.
* `"Initial"`: VPA only assigns resource requests on pod creation and never changes them
later.
* `"Off"`: VPA does not automatically change resource requirements of the pods.
* `"Off"`: VPA does not automatically change the resource requirements of the pods.
The recommendations are calculated and can be inspected in the VPA object.

### Test your installation
Expand All @@ -159,10 +159,10 @@ cluster is to create a sample deployment and a corresponding VPA config:
kubectl create -f examples/hamster.yaml
```

The above command creates a deployment with 2 pods, each running a single container
The above command creates a deployment with two pods, each running a single container
that requests 100 millicores and tries to utilize slightly above 500 millicores.
The command also creates a VPA config pointing at the deployment.
VPA will observe the behavior of the pods and after about 5 minutes they should get
VPA will observe the behaviour of the pods, and after about 5 minutes, they should get
updated with a higher CPU request
(note that VPA does not modify the template in the deployment, but the actual requests
of the pods are updated). To see VPA config and current recommended resource requests run:
Expand Down Expand Up @@ -202,28 +202,28 @@ The above command should list 3 pods (recommender, updater and admission-control
all in state Running.

* Check if the system components log any errors.
For each of the pods returned by the previous command do:
For each of the pods returned by the previous command do:
```
kubectl --namespace=kube-system logs [pod name]| grep -e '^E[0-9]\{4\}'
kubectl --namespace=kube-system logs [pod name] | grep -e '^E[0-9]\{4\}'
```

* Check that the VPA Custom Resource Definition was created:
```
kubectl get customresourcedefinition|grep verticalpodautoscalers
kubectl get customresourcedefinition | grep verticalpodautoscalers
```

### Components of VPA

The project consists of 3 components:

* [Recommender](https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/pkg/recommender/README.md) - it monitors the current and past resource consumption and, based on it,
provides recommended values containers' cpu and memory requests.
provides recommended values for the containers' cpu and memory requests.

* [Updater](https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/pkg/updater/README.md) - it checks which of the managed pods have correct resources set and, if not,
kills them so that they can be recreated by their controllers with the updated requests.
kills them so that they can be recreated by their controllers with the updated requests.

* [Admission Plugin](https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/pkg/admission-controller/README.md) - it sets the correct resource requests on new pods (either just created
or recreated by their controller due to Updater's activity).
or recreated by their controller due to Updater's activity).

More on the architecture can be found [HERE](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/vertical-pod-autoscaler.md).

Expand Down Expand Up @@ -252,46 +252,46 @@ It will maintain limit to request ratio specified for all containers.

VPA will try to cap recommendations between min and max of
[limit ranges](https://kubernetes.io/docs/concepts/policy/limit-range/). If limit range conflicts
and VPA resource policy conflict then VPA will follow VPA policy (and set values outside limit
and VPA resource policy conflict, VPA will follow VPA policy (and set values outside the limit
range).

## Examples

### Keeping limit proportional to request

Container template specifies resource request for 500 milli CPU and 1 GB of RAM. The template also
The container template specifies resource request for 500 milli CPU and 1 GB of RAM. The template also
specifies resource limit of 2 GB RAM. VPA recommendation is 1000 milli CPU and 2 GB of RAM. When VPA
applies the recommendation it will also set memory limit to 4 GB.
applies the recommendation, it will also set the memory limit to 4 GB.

### Capping to Limit Range

Container template specifies resource request for 500 milli CPU and 1 GB of RAM. The template also
specifies resource limit of 2 GB RAM. A limit range sets maximum limit to 3 GB RAM per container.
VPA recommendation is 1000 milli CPU and 2 GB of RAM. When VPA applies the recommendation it will
set memory limit to 3 GB (to keep it within the allowed limit range) and memory request to 1.5 GB (
to maintain 2:1 limit/request ratio from the template).
The container template specifies resource request for 500 milli CPU and 1 GB of RAM. The template also
specifies resource limit of 2 GB RAM. A limit range sets a maximum limit to 3 GB RAM per container.
VPA recommendation is 1000 milli CPU and 2 GB of RAM. When VPA applies the recommendation, it will
set the memory limit to 3 GB (to keep it within the allowed limit range) and the memory request to 1.5 GB (
to maintain a 2:1 limit/request ratio from the template).

### Resource Policy Overriding Limit Range

Container template specifies resource request for 500 milli CPU and 1 GB of RAM. The template also
specifies resource limit of 2 GB RAM. A limit range sets maximum limit to 3 GB RAM per container.
The container template specifies resource request for 500 milli CPU and 1 GB of RAM. The template also
specifies a resource limit of 2 GB RAM. A limit range sets a maximum limit to 3 GB RAM per container.
VPAs Container Resource Policy requires VPA to set containers request to at least 750 milli CPU and
2 GB RAM. VPA recommendation is 1000 milli CPU and 2 GB of RAM. When applying the recommendation
2 GB RAM. VPA recommendation is 1000 milli CPU and 2 GB of RAM. When applying the recommendation,
VPA will set RAM request to 2 GB (following the resource policy) and RAM limit to 4 GB (to maintain
2:1 limit/request ratio from the template).
the 2:1 limit/request ratio from the template).

# Known limitations

* Updating running pods is an experimental feature of VPA. Whenever VPA updates
the pod resources the pod is recreated, which causes all running containers to
the pod resources, the pod is recreated, which causes all running containers to
be restarted. The pod may be recreated on a different node.
* VPA does not evict pods which are not run under a controller. For such pods
`Auto` mode is currently equivalent to `Initial`.
* Vertical Pod Autoscaler **should not be used with the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-resource-metrics) (HPA) on CPU or memory** at this moment.
However, you can use VPA with [HPA on custom and external metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#scaling-on-custom-metrics).
* The VPA admission controller is an admission webhook. If you add other admission webhooks
to you cluster, it is important to analyze how they interact and whether they may conflict
with each other. The order of admission controllers is defined by a flag on APIserver.
to your cluster, it is important to analyze how they interact and whether they may conflict
with each other. The order of admission controllers is defined by a flag on API server.
* VPA reacts to most out-of-memory events, but not in all situations.
* VPA performance has not been tested in large clusters.
* VPA recommendation might exceed available resources (e.g. Node size, available
Expand Down

0 comments on commit 0eb7499

Please sign in to comment.