b62d7a8ad7
(chore): adds commonAnnotations and commonLabels to kustomize if applied, this commit will pass the common labels and annotations specified in postRenderers kustomization and which gets propagated to all resources Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): generates updated api-docs Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): adds common metadata to spec HelmRelease postRenderer uses `CommonMetadata` struct from kustomize controller to have a common CRD specification usage across flux API types Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): update helm release post renderer HelmRelease kustomize post renderer uses the CommonMetadata type from kustomize controller to propagate common labels and annotations across all resources. Labels are not propagated to `selector.matchLabels` Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): generates updated CRD and api docs Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): adds common metadata types Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): removes common metadata removes the insertion of common metadata info in `Kustomize.Run()` Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): adds common-metadata types this commit adds CommonMetadata to HelmRelease spec as an optional field and when used will run a helm postRenderer to add specified labels and annotations resources contained in helm template. The digest of common metadata is stored as ObservedCommonMetadataDigest in the resource status Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): common post-renderer this commit combines common metadata rendering and origin labels rendering into common_renderer.go with re-usable methods for label transformer and annotation transformer. Precedence is given to origin labels rendering over common metadata rendering. Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): trigger upgrade on commonMetadata value changes this commit ensures that when commonMetadata value has changed after install triggers an upgrade action to re-render the new commonMetadata values to the helm release. The digest of commonMetadata values are stored in .status.ObservedCommonMetadataDigest for release state out-of-sync detection. Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (fix): adheres to import ordering Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (fix): revert go mod updates Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): updates copyright headers Co-authored-by: Stefan Prodan <stefan.prodan@gmail.com> Signed-off-by: Abhijith Ravindra <137736216+abhijith-darshan@users.noreply.github.com> (chore): adds copyright headers Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): updates copyright headers Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): keep go mod in sync with upstream/main Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): adds common metadata documentation Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> (chore): fix precedence of label application This commit will ensure that OriginLabels run last so that it has a higher precedence over CommonMetadata.Labels Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com> |
||
|---|---|---|
| .. | ||
| v2 | ||
| v2alpha1 | ||
| v2beta1 | ||
| v2beta2 | ||
| README.md | ||
README.md
Helm Controller
The Helm Controller is a Kubernetes operator, allowing one to declaratively manage Helm chart releases with Kubernetes manifests.
Motivation
The main goal is to provide an automated operator that can perform Helm actions (e.g. install, upgrade, uninstall, rollback, test) and continuously reconcile the state of Helm releases.
When provisioning a new cluster, one may wish to install Helm releases in a specific order, for
example because one relies on a service mesh admission controller managed by a HelmRelease and
the proxy injector must be functional before deploying applications into the mesh, or when
Custom Resource Definitions are managed in a separate chart
and this chart needs to be installed first.
When dealing with an incident, one may wish to suspend the reconciliation of some Helm releases, without having to stop the reconciler and affect the whole cluster.
When operating a cluster, different teams may wish to receive notifications about the status of their Helm releases. For example, the on-call team would receive alerts about all failures in the prod namespace, while the frontend team may wish to be alerted when a new version of the frontend chart was released, no matter the namespace.
Design
The reconciliation process can be defined with a Kubernetes custom resource called HelmRelease
that describes the Helm release, a HelmChart template, and the configuration for a set of Helm
actions that should be (conditionally) executed. Based on this the reconciler:
- reconciles a
HelmChartbased on the provided template - confirms the chart artifact is available
- checks if all depends-on conditions are meet
- fetches the available chart artifact
- performs a Helm install or upgrade action if needed
- performs a Helm test action if enabled
- performs a reconciliation strategy (rollback, uninstall) and retries as configured if any Helm action failed
- performs in cluster drift detection and correction if enabled
The controller that runs these Helm actions relies on source-controller for providing the Helm charts from Helm repositories or any other source that source-controller could support in the future.
Reconciliation of the HelmRelease runs on-a-schedule and can be triggered manually by a
cluster admin, or automatically by a source event such as a Helm chart revision change.
When a custom resource is deleted from the cluster, the controller's garbage collector removes
the associated HelmChart and uninstalls the Helm release. Deleting a suspended resource does not
trigger a Helm uninstall.
Alerting can be configured with a Kubernetes custom resource that specifies a webhook address, and a
group of HelmRelease resources to be monitored using the notification-controller.
The API design of the controller can be found at helm.toolkit.fluxcd.io/v2.
Backward compatibility
| Feature | Helm Controller | Helm Operator |
|---|---|---|
| Helm install, upgrade, test, rollback, uninstall | ✔️ | ✔️ |
| Extensive control over configuration of individual actions | ✔️ | ❌ |
| Helm charts from Helm repositories | ✔️ | ✔️ |
| Helm charts from Git repositories | ✔️ | ✔️ |
| Helm uninstall on resource removal | ✔️ | ✔️ |
| Conditional run of actions (i.e. rolling back after test failure) | ✔️ | ❌ |
| Helm plugins | ❌ | ✔️ |
| Container image updates | ❌ | ✔️ |
| Automated chart updates based on semver ranges | ✔️ | ❌ |