Examine deployment options without Helm's Tiller component
Summary
Our GitLab.com has some concerns with Helm, and its full lifecycle management features: gitlab-com/gl-infra/k8s-workloads/gitlab-com!2 (comment 175991101)
The concerns are three fold:
- The chart is quite complex for use cases where someone wants to slowly migrate parts of GitLab into Kubernetes
- Relying on Helm to deploy and update mission critical software (GitLab!)
- Helm Tiller's security (can be resolved by running it locally, but this is sort of a hack until Helm 3 ships)
The current path forward to use is to helm template > kubectl apply
. This has some potential issues:
- This is not an installation/upgrade path we currently test or officially support
- Hooks will not work, which are still in use with the shared-secrets job
- Lifecycle events, like cleaning up prior configuration/objects will not occur
Proposal
We should examine these needs, and ask ourselves a few questions:
- Whether this is a deployment pattern we want to support
- For users who have concerns with Helm, what is our answer?
- Should we move more aggressively to an operator focused installation/maintainance pattern, augmented by something like ksonnet?
Note, this is a good time to evaluate these options, as Helm 3 is coming soon and may take some effort to fully support.
Edited by Jason Plum