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

Nov 15, 2021 · 5 min read
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 Agent for Kubernetes, 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. The certificate-based integrations will be switched off on gitlab.com starting with the GitLab 15.0 release. Self-managed users will be able to switch the features back until their final removal. The final removal will happen once all the collected, critical use-cases are supported with the agent and enough time was given for our users to migrate to the agent.

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.

We have dedicated documentation to support you migrating from the certificate-based connections to agent-based connections.

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 Agent.

The advantages of the GitLab 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 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

Edit this page View source