Single click deploy of Runner to k8s cluster
We make it really easy to get autoscaling runners if you install GitLab in a Kubernetes cluster, but what if you're using GitLab.com or otherwise have your GitLab instance outside of Kubernetes? We already let you connect a product to a Kubernetes cluster, and ideally we'd let you do that at a group level. But once you've done that, you still need to configure Kubernetes services manually. We should make it easy to install an autoscaling GitLab runner into the k8s cluster for you, ideally with a single click, likely in the Kubernetes service settings.
- Add button in Kubernetes service configuration to add GitLab runner to the cluster.
- Bonus: provide some monitoring an introspection of the health of the runner
Alternatives: should this be in the runners section of project/group settings instead? That would be a better place when looking for health of the runner.
Links / references
- Related: Single click deploy of Prometheus to k8s cluster: #28916
(Write the start of the documentation of this feature here, include:
- Why should someone use it; what's the underlying problem.
- What is the solution.
- How does someone use this
During implementation, this can then be copied and used as a starter for the documentation.)
I agree that the runner section could be the best choice, if you're interested in deploying a runner you probably would go there, not in k8s configuration. If the k8s integration is working, in the runner section you could have the ability to install a runner at the same you have instructions to install a specific one manually.
@dimitrieh could you please try to design such integration in the way you think it is?
As a plus, we can consider to add also a one click deploy of runner via ssh, it's quite complex and you've to provide root credentials, but could be easy in many scenarios.
You just need some YML to describe the deployment and provide the proper settings, we already have the API integration with the cluster.
Helm charts require additional dependencies in both the cluster and locally, but also a possibility. We already have a runner chart that can be used.
The main benefit of the Helm Chart would be that it provides a layer of abstraction from the actual YML itself, as well as simple upgrade commands. This would reduce the need for changes within the code in the future, I think.
The simplest today would be to use single
deployment.yamlto deploy runner, and this would be easy to main. In longer term when we will hopefully start to integrate more tightly with Helm, we could switch to helm approach of tracking deployments.