GitLab Runner Helm Chart and GitLab Runner Operator Strategy Discussion
Overview
This issue is for discussing our development and maintenance strategy for the GitLab Runner Helm Chart and the GitLab Runner Operator (OpenShift, Kubernetes).
Technology scope
- Helm: package management for Kubernetes.
- Operators: a design pattern for operational knowledge. In other words, "Operators are design-pattern-driven pieces of code that encapsulate knowledge for running an application." Source: Is there a Helm and Operators showdown?
Comparing use cases and value proposition
.. | GitLab Runner Helm Chart | GitLab Runner Operator |
---|---|---|
Install GitLab Runner | .. | .. |
Configure GitLab Runner | .. | .. |
placeholder | .. | .. |
Feature Gap Analysis
Feature | GitLab Runner Helm Chart | GitLab Runner Operator | Notes |
---|---|---|---|
Register multiple runner managers at one time | Available | Not Available | Installing multiple runner managers at one time with the Helm chart is made available via the use of a 3rd party application. It can be done with hemlfile and by following the steps described in this comment
|
Strategy proposal (revised 2022-12-02)
Replace HELM with the GitLab Runner Operator
- Announce the deprecation on the Helm Chart in the 15.7 release post.
- Fully remove the GitLab Runner Helm Chart in the 17.0 release.
Pre-requisites for migrating from Helm to Operator
-
Allow the same level of configuration for GitLab Runner. This is fulfilled, we currently allow a custom config.toml in both places. -
Have Operator work with Kubernetes. This is something @ratchade and I are working on right now. -
Add the same level of configuration for the Chart / Operator / Resources they manage. For example in Helm we allow for metrics, auto scaling and security context among other things, many of which aren't supported in the Operator yet. -
Last (off the top of my head) but not least is compatibility. With the Operator, especially in a Kubernetes environment, we need some additional resources such as cert manager (which might or might not be needed in the future when we have a better understanding of Operator in k8s). We should keep in mind the compatibility of these extra resources since helm is mostly a few simple resources with templating on top.
Edited by Romuald Atchadé