// Module included in the following assemblies:
//
// * nodes/nodes-vertical-autoscaler.adoc

:_mod-docs-content-type: CONCEPT
[id="nodes-pods-vertical-autoscaler-about_{context}"]
= About the Vertical Pod Autoscaler Operator

[role="_abstract"]
To help you maintain the optimal CPU and memory usage for your pods, you can use the {product-title} Vertical Pod Autoscaler Operator (VPA).

The VPA is implemented as an API resource and a custom resource (CR). The CR determines the actions for the VPA to take with the pods associated with a specific workload object, such as a daemon set, replication controller, and so forth, in a project.

The VPA consists of three components, each of which has its own pod in the VPA namespace:

Recommender::
The VPA recommender monitors the current and past resource consumption. Based on this data, the VPA recommender determines the optimal CPU and memory resources for the pods in the associated workload object.

Updater::
The VPA updater checks if the pods in the associated workload object have the correct resources. If the resources are correct, the updater takes no action. If the resources are not correct, the updater ensures that the pods have the updated requests. The way in which the VPA updates the resources depends on the update mode, as described in _About the Vertical Pod Autoscaler Operator modes_ later in this section.

Admission controller::
The VPA admission controller sets the correct resource requests on each new pod in the associated workload object. This applies whether the pod is new or the controller re-created the pod due to the VPA updater actions.

You can use the default recommender or use your own alternative recommender to autoscale based on your own algorithms.

The default recommender automatically computes historic and current CPU and memory usage for the containers in those pods. The default recommender uses this data to determine optimized resource limits and requests to ensure that these pods are operating efficiently at all times. For example, the default recommender suggests reduced resources for pods that are requesting more resources than they are using and increased resources for pods that are not requesting enough.

Depending upon the VPA mode, the VPA can automatically update any pods that are out of alignment with these recommendations one at a time, so that your applications can continue to serve requests with no downtime. The VPA updates the pods with optimized resource limits and requests before admitting the pods to a node. If you do not want the VPA to update pods, you can view the VPA resource limits and requests and manually update the pods as needed.

[NOTE]
====
By default, workload objects must specify a minimum of two replicas for the VPA to automatically delete their pods. Workload objects that specify fewer replicas than this minimum are not deleted. If you manually delete these pods, when the workload object redeploys the pods, the VPA updates the new pods with its recommendations. You can change this minimum by modifying the `VerticalPodAutoscalerController` object as shown in _Changing the VPA minimum value_.
====

For example, if you have a pod that uses 50% of the CPU but only requests 10%, the VPA determines that the pod is consuming more CPU than requested. Depending upon the VPA mode, the VPA updates the pod or you can manually update the pod at a convenient time.

For developers, you can use the VPA to help ensure that your pods active during periods of high demand by scheduling pods onto nodes that have appropriate resources for each pod.

Administrators can use the VPA to better use cluster resources, such as preventing pods from reserving more CPU resources than needed. The VPA monitors the resources that workloads are actually using and adjusts the resource requirements so capacity is available to other workloads. The VPA also maintains the ratios between limits and requests specified in the initial container configuration.

[NOTE]
====
If you stop running the VPA or delete a specific VPA CR in your cluster, the resource requests for the pods already modified by the VPA do not change. However, any new pods get the resources defined in the workload object, not the previous recommendations made by the VPA.
====

[id="nodes-pods-vertical-autoscaler-modes_{context}"]
== About the Vertical Pod Autoscaler Operator modes

You can set one of the following VPA modes by using a `VerticalPodAutoscaler` CR: 

* `InPlaceOrRecreate`. In this mode, the VPA automatically applies the recommended CPU and memory resources throughout the pod lifetime. When any pod in the project is out of alignment with the VPA recommendations, the VPA attempts to apply updates _in-place_, without restarting the pod. If the VPA is not able to update the containers in-place, the VPA deletes the pod. When redeployed by the workload object, the VPA uses a mutating admission webhook to update the new pod with its recommendations. For specific information about in-place updates, see "About the in-place-or-recreate mode". 
+
The container's resize policy dictates the way in which `InPlaceOrRecreate` mode updates are applied. If the policy is set to `NotRequired`, the VPA attempts to update the container without restarting. If the policy is `RestartContainer`, the VPA always restarts the container upon the update.

* `Recreate` and `Auto`. In either of these modes, the VPA automatically applies the recommended CPU and memory resources throughout the pod lifetime. When any pod in the project is out of alignment with the VPA recommendations, the VPA deletes the pod. When redeployed by the workload object, the VPA uses a mutating admission webhook to update the new pod with its recommendations. Use the `Recreate` mode rarely, only if you need to ensure that when the resource request changes the pods restart.
+
--
:FeatureName: The `Auto` VPA mode
include::snippets/deprecated-feature.adoc[leveloffset=+1]
--

* `Initial`. In this mode, the VPA applies the recommended CPU and memory resources mode only at pod creation.

* `Off`. In this mode, the VPA mode only provides the recommended resource limits and requests. You can then manually apply the recommendations. The `Off` mode does not update pods.
