# VPA

A chart to install the [Kubernetes Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)

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

## Tests and Debugging

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](https://github.com/kubernetes-sigs/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.

## Components

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.

## *BREAKING* Upgrading from <= v2.5.1 to 3.0.0

### ClusterRole rules

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:

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

```

## *BREAKING* Upgrading from <= v1.7.x to 2.0.0

### Certificate generation

The certificate creation process was changed from using OpenSSL to [kube-webhook-certgen](https://github.com/kubernetes/ingress-nginx/tree/main/images/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:

```bash
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.

### MutatingWebhookconfiguration

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.

### Admission controller

The admission controller is enabled by default.

## *BREAKING* Upgrading from v0.x.x to v1.x.x

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.

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

```

## Installation

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

## Utilize Prometheus for History

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.

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

{{ template "chart.valuesSection" . }}
