When the reconciliation begins, while fulfilling the prerequisites, Ready=False condition for various reasons are added on the object. On failure, this reason is persisted on the object. On a subsequent reconciliation, when the failure is recovered, the Ready=False condition is not updates until the atomic reconciliation reaches a conclusion. During this period if the atomic reconciliation enters a retry loop due to constant drift detection and correction, the stale Ready=False condition with incorrect reason persists on the object. The Ready=False message is also copied to Reconciling=True condition, resulting in an incorrect depiction of what's actually happening. For example, if previously the HelmRelease failed with dependency not ready error, on a subsequent reconciliation, even after going past the dependency check and returning from atomic reconciliation due to drift detection and correction loop scenario, the Ready=False condition continues to show the stale dependency not ready error. In order to show more accurate status, the Ready=False conditions added while fulfilling prerequisites can be removed once those checks have succeeded, updating Ready=False to Ready=Unknown with "reconciliation in progress" message. If the atomic reconciliation gets stuck in the drift detection and correction loop with this, the Ready and Reconciling conditons would show "reconciliation in progress". This should be a better indicator of what's going on. The events and logs can be checked to determine accurately what's causing the reconciliation to be progressing for ever. Signed-off-by: Sunny <github@darkowlzz.space> |
||
|---|---|---|
| .github | ||
| api | ||
| config | ||
| docs | ||
| hack | ||
| internal | ||
| tests/fuzz | ||
| .gitignore | ||
| .goreleaser.yaml | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| DCO | ||
| DEVELOPMENT.md | ||
| Dockerfile | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| PROJECT | ||
| README.md | ||
| go.mod | ||
| go.sum | ||
| main.go | ||
README.md
helm-controller
The helm-controller is a Kubernetes operator, allowing one to declaratively manage Helm chart releases. It is part of a composable GitOps toolkit and depends on source-controller to acquire the Helm charts from Helm repositories.
The desired state of a Helm release is described through a Kubernetes Custom
Resource named HelmRelease. Based on the creation, mutation or removal of a
HelmRelease resource in the cluster, Helm actions are performed by the
operator.
Features
- Watches for
HelmReleaseobjects and generatesHelmChartobjects - Supports
HelmChartartifacts produced fromHelmRepository,GitRepositoryandBucketsources - Fetches artifacts produced by source-controller from
HelmChartobjects - Watches
HelmChartobjects for revision changes (including semver ranges for charts fromHelmRepositorysources) - Performs automated Helm actions, including Helm tests, rollbacks and uninstalls
- Offers extensive configuration options for automated remediation (rollback, uninstall, retry) on failed Helm install, upgrade or test actions
- Runs Helm install/upgrade in a specific order, taking into account the
depends-on relationship defined in a set of
HelmReleaseobjects - Reports Helm release statuses (alerting provided by notification-controller)
- Built-in Kustomize compatible Helm post renderer, providing support for strategic merge, JSON 6902 and images patches
- Supports detecting and correcting in-cluster changes compared to the desired state of the Helm release
