GitLab
It’s probably self-explanatory as to what GitLab is. It works and has all the features of just about every other Git hosting site (GitHub, Bitbucket, CodeCommit). You can either have a managed GitLab server where GitLab manages the server for you, or you can choose to set up GitLab on your own Linux server. You also have all the standard capabilities such as creating PRs, creating issues/user stories, having project wikis, code snippets, etc… However, GitLab also aims to be a full development management system. That means everything from committing your code to running security checks, to testing, packaging, and deploying your code via CI/CD pipeline.
This is where GitLab can help Kubernetes. One thing to note is that it is possible to run GitLab in a Kubernetes cluster, but that is not what we will be focusing on. We will instead be looking at how GitLab’s inbuilt CI/CD solution can help you continuously deploy and test apps with your Kubernetes clusters. GitLab also includes its own metrics and logging, which allow you to see the health of your CI/CD pipelines and the clusters it deploys to, as well as providing insights, and a simple way to manage any incidents that occur. There is also a dedicated analytics page that can give you easily visualizable graphs and charts that show things such as deployment frequency, lead times, change failure rates, and overviews that show everything at a brief glance. This analytics page also allows you to maintain analytics of other things such as code reviews and how long it takes to perform them, issues and how long it takes to resolve them (as well as how many of them pop up), and just general analytics regarding your actual repository.
These are all features that most other Git hosting services don’t offer, largely since they are out of the scope of a Git hosting service, and since GitLab hopes to be much more than a Git server. GitLab also offers a complete security suite, which monitors vulnerabilities in your project, generates reports, handles policies, license compliances, audit events, and much more. Yet another feature GitLab offers is its own container registry. Similar to Azure Container registry or GCR, this provides a private container registry that you can be called by registry.gitlab.com. It also contains in-built package registries and infrastructure registries. At this point, you can maintain almost all of your infrastructure as well as code within GitLab itself. Code can be committed to the GitLab repo, where automated GitLab pipelines could run. The images that are created from this pipeline can be hosted in the container repository, and then deployed to your Kubernetes cluster via another pipeline. You can even get analytics and metrics about how each part of this process is performing.
So now that we are clear on the benefits of using GitLab, let’s consider how we can connect Kubernetes clusters to GitLab so that we can use as many of these features as possible.