128 lines
5.2 KiB
Go Template
128 lines
5.2 KiB
Go Template
# 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" . }}
|