Foreword: What you gain by installing GitLab on Kubernetes (K8S) and what you don’t.
As GitLab representatives in Israel, we are regularly asked technical questions about GitLab and tools, which integrate with it.
One of the questions often asked lately is about GitLab’s integration with K8S. We have noticed that there is a popular assumption that GitLab installation on K8S provides full high availability. This is not fully correct, and therefore we have decided to write this paper and put the things in some order.
First, some background:
- GitLab is not only a Git-based version control system, but also a powerful CI/CD tool. In a comparison of popular CI/CD tools (Jenkins, etc), Forrester, a market research company, gave GitLab high marks for its CI/CD offering (see the link at the bottom of this page).
- GitLab integrates seamlessly with Docker and K8S. Actually, many think that it is the leading tool for CI/CD and version control in that area, because from the beginning GitLab was built for Cloud Computing/Docker/K8S. Moreover, it is an all-in-one tool, so that you don’t need to waste your effort on “glueing” different tools.
- As you know, currently K8S is a de-facto standard for container orchestration and management. Many organizations are already using it or running usage pilots or planning to start using it in the near future.
As a system becomes critical for an organization’s operations, there arises the need of its high availability and fast response times. Usually this happens when the system contains important or critical information, which must be always available, and/or when there are very many system’s users.
High availability for GitLab? Why?
It is important to remember that GitLab is not only a Git repository, but much more than that: it provides task management, code reviews, CI pipelines and a lot of metadata. If GitLab were just a Git server, the need for HA would be less acute, because Git is a distributed system and each workstation holds a copy of the repo with all its history.
Currently, there are three ways to achieve GitLab HA:
- To buy GitLab Premium or Ultimate licenses and get the manufacturer’s support.
- To use GitLab cloud (GitLab.com), where you have HA provided by GitLab company. However this option has its caveats: you have no control over the server, the data security is considered relatively weak, and so on.
- To set up and support a HA environment by yourselves or request assistance from a company having expertise in that field.
As GitLab representatives in Israel, our company ALM Toolbox, can provide any of the three above-mentioned solutions, including end-to-end building a HA environment, including customer support with an option of SLA.
And what about Kubernetes, does it provide GitLab HA?
It is important to understand that GitLab installation on K8S does not provide full HA, because it does not provide redundancy of the data, i.e. Git repo storage and the databases.
Here is the explanation:
If you install GitLab on a K8S cluster, you can achieve “self healing”. If a container goes down, K8S replaces it with a new one.
GitLab can be installed so that each component runs in a separate pod. If that pod fails, it will heal itself (that is, a new persistent volume will be created, the component will be reinstalled and the service will continue). However it is important to remember that the data is stored outside the K8S cluster. If there is no data storage redundancy and the storage fails, the whole system will be down until you build a new storage and restore the data from the backup.
Summing up, GitLab installation on K8S can help to recover fast from failure, therefore it is kind of a disaster recovery (DR) setup rather than an HA solution.
And what about GitLab Runner, is there an advantage in installing it on Kubernetes?
For those who do not know it, GitLab Runner is an open source software, which can be installed on a separate machine and used to run GitLab CI/CD jobs and send the results back to GitLab.
For those of you who are familiar with Jenkins, GitLab Runner machines are analogous to Jenkins Nodes (or Slaves, by their previous name).
In particular, Gitlab Runner can be installed on a K8S cluster. Here we see more advantages than in installing GitLab itself on K8S: usually, there is no HA requirement for a specific runner, runners are stopped and started according to the needs of the jobs, and K8S auto-scaling capabilities allow to run multiple jobs simultaneously.
In one of our following posts we will write more about Runner installation on K8S and the resulting capabilities.
Soon we will also present a case study (a customer story) about the GitLab environment, which we have built on K8S for one of our clients.
The writer is the CEO of the ALM Toolbox company, GitLab representative in Israel and several other countries.
