Frequently asked questions

I’m using SSL between Helm and Tiller. How can I configure the operator to use the certificate?

When installing Flux, you can supply the CA and client-side certificate using the helmOperator.tls options, more details here.

I’ve deleted a HelmRelease file from Git. Why is the Helm release still running on my cluster?

Flux doesn’t delete resources by default, you can enable Flux garbage collection feature by passing the command-line flag --sync-garbage-collection to fluxd.

With Flux garbage collection enabled, Helm operator will receive the delete event and will purge the Helm release.

I’ve manually deleted a Helm release. Why is Flux not able to restore it?

If you delete a Helm release with helm delete my-release, the release name can’t be reused. You need to use the helm delete --purge option only then Flux will be able reinstall a release.

It takes a long time before the operator processes an update to a HelmRelease resource. How can I speed up the processing of releases?

The operator watches for changes of Custom Resources of kind HelmRelease. It receives Kubernetes Events and queues these to be processed, all resources will also be re-queued every --charts-sync-interval (default 3m) for a dry-run to detect and revert manual changes made to a release.

Depending on how many resources the operator is watching and the complexity of the charts (umbrella charts for example generally take a longer time to process); the default amount of workers may not be sufficient to instantly process a release the moment it enters the queue as the queue works on a FIFO basis, and other releases may have to be processed first.

The solution is to increase the amount of workers processing the releases using the --workers flag (default 2), i.e. by steps of 2 until the releases are processed within a time frame that feels right to you.

If this does not give the desired effect, or if the amount of workers required is incredible high, there are two other tweaks possible:

  1. increasing the --charts-sync-interval; this causes the queue to be less heavy occupied at the cost of detecting mutations less rapidly

  2. using multiple Helm operator instances, i.e. by having one operator per namespace; namespace scoping is possible by configuring the --allow-namespace flag

I have a dedicated Kubernetes cluster per environment and I want to use the same Git repo for all. How can I do that?

Option 1 For each cluster create a directory in your config repo. When installing Flux Helm chart set the Git path using --set git.path=k8s/cluster-name and set a unique label for each cluster --set git.label=cluster-name.

You can have one or more shared dirs between clusters. Assuming your shared dir is located at k8s/common set the Git path as --set git.path="k8s/common\,k8s/cluster-name".

Option 2 For each cluster create a Git branch in your config repo. When installing Flux Helm chart set the Git branch using --set git.branch=cluster-name and set a unique label for each cluster --set git.label=cluster-name.

Are there prerelease builds I can run?

There are builds from CI for each merge to master branch. See fluxcd/helm-operator-prerelease.