A chart to install the Kubernetes Vertical Pod Autoscaler

This chart is mostly based on the manifests and various scripts in the deploy and hack directories of the VPA repository.

There are a few tests included with this chart that can help debug why your installation of VPA isn't working as expected. You can run helm test -n <Release Namespace> <Release Name> to run them.

• crds-available - Checks for both the verticalpodautoscalers and verticalpodautoscalercheckpoints CRDs
• metrics-api-available - Checks to make sure that the metrics API endpoint is available. If it's not, install metrics-server in your cluster.
• create-vpa - A simple check to make sure that VPA objects can be created in your cluster. Does not check for functionality of that VPA.

• webhook-configuration - Checks that both the service and the CA bundle in the MutatingWebhookconfiguration are configured correctly.

There are three primary components to the Vertical Pod Autoscaler that can be enabled individually here.

• recommender
• updater
• admissionController

The admissionController is the only one that poses a stability consideration because it will create a MutatingWebhookconfiguration in your cluster. This could cause the cluster to stop accepting pod creation requests, if it is not configured correctly. Because of this, the MutatingWebhookconfiguration has its failurePolicy set to Ignore by default.

For more details, please see the values below, and the vertical pod autosclaer documentation.

Ensure that you update the CRDs from the autoscaler repository or the crds/ folder.

Previously, ClusterRoles were created by default from templates and could not be extended with custom rules. Since 3.0.0 version it is possible.

You can define it as follows:

rbac:
  extraRules:
    vpaActor:
      - apiGroups:
          - batch
        resources:
          - '*'
        verbs:
          - get
    vpaCheckpointActor: []
    vpaEvictioner: []
    vpaMetricsReader: []
    vpaTargetReader: []
    vpaStatusReader: []

The certificate creation process was changed from using OpenSSL to kube-webhook-certgen to simplify the process. It still uses the same configuration keys (.Values.admissionController.certGen), which makes it impossible to reuse the values from a previous install.

You can mitigate this change by setting the correct image for the upgrade:

helm upgrade <release name> fairwinds-stable/vpa --version 2.0.0 --reuse-values \
  --set "admissionController.certGen.image.repository=registry.k8s.io/ingress-nginx/kube-webhook-certgen" \
  --set "admissionController.certGen.image.tag=v20230312-helm-chart-4.5.2-28-g66a760794"

The new process is incompatible with the old secrets layout. To mitigate this, the secret was renamed to (by default) <release name>-tls-certs and can now also be customized.

All other changes are implemented in a non breaking fashion.

Previously, the webhook creation was handled by the admission controller itself. This had the downside that Helm is not in control of the resource and therefore required the cleanupOnDelete job.

This version disables the selfRegistration by the admission controller and creates the MutatingWebhookconfiguration using Helm.

You can either:

• Migrate the MutatingWebhookconfiguration by:

  • adding the label app.kubernetes.io/managed-by: Helm
  • adding the annotation meta.helm.sh/release-name: <release name>
  • adding the annotation meta.helm.sh/release-namespace: <release namespace>

• delete the configuration and it will be recreated by Helm

• or keep the configuration as it is and Helm will ignore it. Execute the tests, to make sure everything works.

Also, the cleanupOnDelete configuration is obsolete.

The admission controller is enabled by default.

In the previous version, when the admissionController.cleanupOnDelete flag was set to true, MutatingWebhookconfiguration and the tls secret for the admission controller were removed. There was no chance to pass any image information to start remove process. Now, it could be passed custom image by version 1.0.0.

cleanupOnDelete:
    enabled: true
    image:
      repository: quay.io/reactiveops/ci-images
      tag: v11-alpine

helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install vpa fairwinds-stable/vpa --namespace vpa --create-namespace

In order to utilize prometheus for recommender history, you will need to pass some extra flags to the recommender. If you use prometheus operator installed in the prometheus-operator namespace, these values will do the trick.

recommender:
  extraArgs:
    prometheus-address: |
      http://prometheus-operator-prometheus.prometheus-operator.svc.cluster.local:9090
    storage: prometheus