Install the VerticalPodAutoscaler Add-on Using Helm

Install the VerticalPodAutoscaler Add-on Using Helm

The VerticalPodAutoscaler (VPA) is provided as a separate component; it is not included in the core Kubernetes release. This task shows how to install the VPA control plane using Helm, and how to choose how the admission controller's webhook and TLS certificates are managed.

For how VPA adjusts workload resource requests and limits, see Vertical Pod Autoscaling.

Before you begin

You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:

Your Kubernetes server must be at or later than version 1.28.

To check the version, enter kubectl version.

🛇 This item links to a third party project or product that is not part of Kubernetes itself. More information

Add the Autoscaler Helm repository

The Kubernetes project publishes charts, including VPA, at https://kubernetes.github.io/autoscaler.

helm repo add autoscalers https://kubernetes.github.io/autoscaler
helm repo update

Install the VPA chart

Install a release named vertical-pod-autoscaler. The following example deploys into the vpa namespace.

helm upgrade -i vertical-pod-autoscaler autoscalers/vertical-pod-autoscaler \
  --version 0.9.0 \
  --namespace vpa --create-namespace

To see the versions available in the repository, run helm search repo autoscalers/vertical-pod-autoscaler --versions, or browse the chart releases in the Autoscaler repository.

With the default values this installs the recommender, the updater, and the admission controller, and configures the admission webhook using the default Helm-managed mode. To use cert-manager or another mode instead, see Choose how the admission webhook is managed.

Note:

Helm does not upgrade the VPA CustomResourceDefinitions; they ship in the chart's crds/ directory and Helm applies them only on first install. When you move to a chart version that ships newer CRDs, apply them yourself:

kubectl apply --server-side -f "https://raw.githubusercontent.com/kubernetes/autoscaler/vertical-pod-autoscaler-<appVersion>/vertical-pod-autoscaler/charts/vertical-pod-autoscaler/crds/vpa-v1-crd-gen.yaml"

Choose how the admission webhook is managed

The VPA admission controller is a mutating admission webhook that applies recommended resource requests to Pods as they are created. It needs a MutatingWebhookConfiguration and a TLS certificate that the API server trusts. The chart can set these up in several mutually exclusive ways; pick one mode that fits how you manage certificates.

Note:

The chart always runs the admission controller with --reload-cert=true. The controller watches its mounted certificate and reloads it in place when the contents change, so a renewed or rotated certificate, whether issued by the certgen Job, by cert-manager, or updated by you in the TLS Secret, takes effect after the kubelet refreshes the mounted Secret, without restarting the Pod.

Helm-managed (default)

In this mode Helm creates the MutatingWebhookConfiguration, and a one-shot Job that runs the registry.k8s.io/ingress-nginx/kube-webhook-certgen image generates a self-signed certificate, stores it in a Secret, and patches the CA bundle into the webhook configuration.

Caution:

For now, this mode relies on a certificate-generation image from the ingress-nginx project, which has been retired and no longer receives updates or security fixes. For production clusters, use the cert-manager mode instead.

This is the default, so the command in Install the VPA chart already uses it. To set it explicitly, use these values:

# values.yaml
admissionController:
  registerWebhook: false
  certGen:
    enabled: true

cert-manager

In this mode cert-manager issues and automatically renews the webhook certificate, and its CA injector keeps the CA bundle on the MutatingWebhookConfiguration up to date. Helm still creates the webhook configuration.

Install cert-manager in the cluster before enabling this mode. You can either point the chart at an issuer you already manage, or have the chart create a self-signed issuer for you.

Point the chart at an Issuer or ClusterIssuer that you already manage:

# values.yaml
admissionController:
  registerWebhook: false
  certGen:
    enabled: false
  certManager:
    enabled: true
    issuerRef:
      name: my-issuer
      kind: ClusterIssuer       # or Issuer
      group: cert-manager.io

Have the chart create a self-signed issuer for you:

# values.yaml
admissionController:
  registerWebhook: false
  certGen:
    enabled: false
  certManager:
    enabled: true
    createSelfSignedIssuer:
      enabled: true

This creates a namespaced self-signed Issuer that signs an intermediate CA, which in turn signs the webhook certificate. It needs no external PKI, so it is a good choice when you want cert-manager-managed renewal without bringing your own issuer.

Certificate lifetime and renewal are configurable. The webhook certificate defaults to admissionController.certManager.duration: 168h with renewBefore: 24h. See the chart values for the full list.

Note:

In cert-manager mode the chart manages the admission controller's certificate volumes and enables cert reloading, so any values written to admissionController.volumes or admissionController.volumeMounts will be Ignored.

Application-managed

In this mode the admission controller registers the MutatingWebhookConfiguration itself, and you are responsible for the TLS certificate.

# values.yaml
admissionController:
  registerWebhook: true
  certGen:
    enabled: false

Create the TLS Secret (default name vpa-tls-certs) before or after installing the chart. The admission controller registers the webhook only once that Secret exists. If you create the Secret after installing, restart the admission controller so it picks the certificate up and registers the webhook:

kubectl -n vpa rollout restart deployment vertical-pod-autoscaler-admission-controller

Because registerWebhook is enabled, the controller also writes the current CA bundle into the MutatingWebhookConfiguration and keeps it patched itself, no certgen Job or cert-manager cainjector is involved. That self-management is convenient, but it is why this mode needs broader permissions, as noted below.

Caution:

This mode grants the admission controller permission to manage MutatingWebhookConfigurations, which also lets it delete webhook configurations in the cluster. Prefer the default certgen mode or cert-manager unless you specifically need application-managed registration.

Verify the installation

Check that the recommender, updater, and admission controller are running. The label value matches the Helm release name from the install command above.

kubectl -n vpa get pods -l app.kubernetes.io/instance=vertical-pod-autoscaler

The output is similar to:

NAME                                                           READY   STATUS    RESTARTS   AGE
vertical-pod-autoscaler-admission-controller-b7787b7f8-5x6rv   1/1     Running   0          5m51s
vertical-pod-autoscaler-recommender-75d9c95bd4-jhnvd           1/1     Running   0          5m51s
vertical-pod-autoscaler-updater-857b5dbd6c-jcnwp               1/1     Running   0          5m50s

What's next

Last modified June 03, 2026 at 6:19 AM PST: docs: add documentation for vpa installation using helm (cbb8cc28e6)

Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the CNCF website guidelines for more details.

You should read the content guide before proposing a change that adds an extra third-party link.