We are deprecating the certificate-based integration with Kubernetes in GitLab 14.5

Nov 15, 2021 · 5 min read · Leave a comment
Viktor Nagy GitLab profile

We are deprecating the certificate-based Kubernetes integration with GitLab and all the features that rely on it. This is the legacy integration, introduced early in 2018, in GitLab 10.4.

In September 2020, we started to build a more robust, secure, forthcoming, and reliable integration with Kubernetes and released the GitLab Kubernetes Agent, which is the recommended methodology to connect clusters with GitLab.

In this post, we explain the reasons for the change of path, what to expect, and how this affects the features that rely on the certificate-based integration with Kubernetes.

What to expect

The deprecation of the certificate-based Kubernetes integration affects all the features that require a cluster connected to GitLab through cluster certificates. All those features are deprecated but will continue to work until we remove the certificate-based integration from the codebase. We don't have a removal date yet, but the removal will not happen before GitLab 15.0 (ETA, May 2022). We will communicate the date as soon as we have it.

In regards to the existing features that rely on the certificate-based integration:

See the updated list of the affected features on the docs.

What this deprecation means

The deprecation means that we will not build more features on top of the existing features that depend on cluster certificates. It doesn't mean that the features will stop working right now.

New features for Kubernetes clusters will be built on top of the connection between GitLab and your cluster through the Agent rather than on top of the certificate-based connection.

What should you do for clusters not connected to GitLab yet

To connect new clusters with GitLab, use the Agent so that you don't have to take extra steps to use the Agent later on.

Why we deprecated the certificate-based integration with Kubernetes

There were several reasons why we decided to rethink our approach to Kubernetes:

We decided to address all these shortcomings with the GitLab Kubernetes Agent.

The advantages of the GitLab Kubernetes Agent

The integration with Kubernetes through the Agent provides many benefits compared to the certificate-based integration, such as:

Compared to the certificate-based integration, the Agent offers the following functionalities:

What is next on the roadmap of the GitLab Kubernetes Agent

We identified a few high-value features on the list of deprecated features. Moreover, we know that having some level of observability around the resources managed by the Agent is its biggest shortcoming. As a result, we are going to focus on the following three items first:

We are listening

Please help us to help you. We need your feedback to help us prioritize the migration of the current features to the Agent and to build new features based on the Agent. We are especially seeking feed back around real-world, high-scale usage of the features built for using Kubernetes clusters with GitLab.

If you would be open to sharing your feedback, please start a new thread in this epic. Feel free to mention @nagyv-gitlab in your comment to make sure that your comment is read and the information won't be missed.

“We are deprecating the certificate-based integration with Kubernetes in GitLab 14.5” – Viktor Nagy

Click to tweet

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license