### Summary GitLab builds and maintains Helm charts to support deploying GitLab on Kubernetes. A new major version of Helm is in development and expected to reach GA in the latter half of 2019 (possibly as early as September). As Kubernetes continues to grow in popularity, the GitLab helm charts remain an important install method for us to support and improve upon. ### Problem to solve Helm 3 introduces some breaking changes. As GitLab users transition from Helm 2 to Helm 3, we need to ensure that GitLab charts support Helm 3 so that we are keeping pace with the tools that are community is adopting. Helm 3 includes new functionality, major architecture changes, a supported migration path, and a new security model. ### Solution We will likely maintain two forks of the GitLab Helm chart and sub charts until such time as Helm 2 is deprecated so that we can support users still on Helm 2 as well as users upgrading to Helm 3. ### LL Notes from KubeCon SD * Helm 3 passed a third-party security review. * Bumped the API version to V2. V2 corresponds to Helm V3. The numbering is a bit confusing. * Library charts have been introduced as first-class citizens * Dependencies used to be defined in Requirements. These have been moved into the yaml. * Helm Hub has been introduced. It is a central catalog for chart repos. There were a lot of repos and there was a need for a central one. Introduced a search function to search the hub for charts. We need to add our repos to the hub. * Helm 3 uses a 3-way merge strategy. * Made updates to the test framework. Tests can be jobs now instead of test pods. Removed the `test-failure` hook. * Support for an OCI registry. Charts can be pushed into anything that is OCI compliant such as a docker registry. * No more tiller. Replaces the client-server model of Helm 2. `helm-init` has been removed. * Release storage update. Releases used to be tied to the namespace of the tiller, but now tied to the namespace of the release. Helm "Release" object has changed. Release name prefixed with `sh.helm.release.v1`. * Most things are backwards compatible with Helm 2. * Removing the idea of a CRD install hook. They will be in a crds directory. Can leave the hooks in place for now as well as create the crds directory during the transition from 2 to 3. #### Migration * Helm 2 charts still work in Helm 3. You can still deploy and render them. BUT, Helm won't create namespaces on the fly. Need to create it beforehand . They made this change to be more consistent with the Kubernetes ecosystem. * Need to put the manifest file in the crds directory. Things will break if we don't do that. * 2 migration use cases are strangler pattern where we install 2 and 3 and they coincide, but need to rename the binaries. In this situation Hem 3 is used for new deployments. The Helm 2 releases can be phased out over time. The other option is in situ migration where we want Helm 3 and don't want to use Helm 2 anymore. There's a plugin that helps with this migration approach. Does a clean up that removes all of the Helm 2 artifacts and then removes tiller. #### New security model * Helm 2 had Kubernetes security model but also had cert management and RBAC management for tiller. The tiller security pieces have been removed and Helm 3 is more of a per-user based security that is based off the kube config. Delegates security to the K8s user cluster security.