Feature request: Support tiller-less releases
Request
There are valid reasons to not use tiller at all. If at all possible, please update the chart to support the following flow:
helm template --namespace namespace-name --output-dir storage-dir
kubectl apply -f storage-dir --recursive;
Rationale
If (and when) a cluster's backing store fails, or for some other reason the cluster gets lost, any Releases done to the cluster will be lost. To mitigate this issue, some people choose to store their configurations in a 3rd party state store like a git server, or an NFS-server.
Other reasons to use a second state store (next to the cluster state store itself) include, but are not limited to:
- auditability of running applications on the cluster, without having actual access to the cluster
of course, this only works provided the leading state store is kept in sync with the cluster specs- for allowing 3rd parties to write specs for use in the cluster, which can then be audited by the cluster operator and applied/rejected according to own insight
- for read-only access to what should run in the cluster
Found points of improvement
Features specific to Helm+Tiller releases:
-
helm.sh/*
annotations for chart hooks.
These can be executed on specific times in the lifecycle of the helm release - Correct
.Release.{Revision,IsInstall,IsUpgrade}
-access in the templates.
These will always be 0, false, false respectively when usinghelm template
. - Correct
.Capabilities
access in the templates.
This is defaulted to some.Capabilities.TillerVersion.git_commit: 20adb27c7c5868466912eebdf6664e7390ebe710
, which is the same as the helm version. - Correct namespace support
Tiller automatically applies spec-files in the specified namespace (e.g. namespacea
inhelm install --namespace a ...
, but this namespace is not auto-injected in rendered template files, which results in different behaviour betweenhelm install --namespace a ...
andhelm template --namespace a ... | kubectl apply -f
.
There is an open merge request (!443 (merged)) which fixes most, if not all, of the occurances of this issue.
At the moment of writing, the following templates include chart hooks:
charts/gitlab/charts/unicorn/templates/test/test-runner.yaml
charts/shared-secrets/templates/job.yaml
charts/shared-secrets/templates/rbac-config.yaml
charts/shared-secrets/templates/configmap.yaml
charts/shared-secrets/templates/self-signed-cert-job.yaml
The following templates are not template-proof due to their reliance on .Release.Version
:
minio.createBucketsJobName
migrations.jobname
shared-secrets.jobname
certmanager-issuer.jobname
The following templates make use of .Capabilities
:
minio.networkPolicy.apiVersion
charts/nginx/templates/controller-service.yaml
Non-specification of .metadata.namespace
happens in most, if not all, yaml files.
footnote
These are an analysis of files in this repo as of 2e26382c. I have not analyzed any of the dependencies found in requirements.yaml
.