Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Kubernetes Management


The main motivating factor behind using a container orchestration platform is cost reduction. Kubernetes has become the most widely adopted container orchestration platform to run, deploy, and manage applications. Yet, to seamlessly connect application code with the clusters in various environments, has remained a complex task that needs various approaches of CI/CD and Infrastructure as Code.

Our mission is to support the Platform Engineers in enabling developer workflows, to make deployments to every environment frictionless for the developer and reliable for the operator, no matter the experience level. We do this by supporting an integrated experience within GitLab and leverage the existing tools and approaches in the Kubernetes community.

Market overview

Kubernetes is emerging as the de facto standard for container orchestration. Today, Kubernetes runs in half of container environments, and around 90% of containers are orchestrated. (Source).

How can you contribute

Interested in joining the conversation for this category? Please have a look at our global epic where we discuss this topic and can answer any questions you may have or direct your attention to one of the more targeted epics presented below where our focus is today. Your contributions are more than welcome.


By 2022, GitLab is an indispensable addition in the workflow of Kubernetes users by making deployments reliable, frictionless and conventional, and by surfacing in-cluster insights in the form of alerts, metrics and logs in GitLab. As we are primarily focusing on enterprise customers, we want to support highly regulated, air-gapped use cases along with generic, public-cloud based environments.

Target User

We are building GitLab's Kubernetes Management category for the enterprise operators, who are already operating production grade clusters and work hard to remove all the roadblocks that could slow down developers without putting operations at risk. Our secondary persona is the Application Operator, who is in charge of 2nd day operations of deployed applictions in production environments.


When I have a new version of my application, I want to deploy it into production following my preferred deployment strategy, so that I can reap the fruits of my work and can celebrate success.

Job statements Maturity Confidence Source

When I push a new version into production, I want to monitor core metrics related to the deployment, so that I can be assured about the quality of the new release and act when necessary.

Job statements Maturity Confidence Source

When there is a problem with a just released version, I want an easy way to roll forward or backward.

Job statements Maturity Confidence Source

When I set up a new cluster, I want to make sure that application operators can easily target their developments at it, so they can start using the cluster immediately.

Job statements Maturity Confidence Source

When the engineers need a new cluster, I want to make sure that they can self-serve and the cluster will be set up following company requirements.

Job statements Maturity Confidence Source

Current status

We support 2 approaches to connect a cluster with GitLab:

Beside these, one can manually configur a $KUBECONFIG or use 3rd party tooling around GitLab CI or webhooks.

The recommended approach to integrate a Kubernetes cluster with GitLab is using the GitLab Kubernetes Agent.

In the case of the certificate based integration, GitLab should be able to access the kubernetes cluster APIs. This requirement is not acceptable in many use cases, especially on SaaS as it's considered a big security risk to open up the Kube API towards the Internet. For this reason, we are focusing on building out various integrations using the GitLab Kubernetes Agent that is secure by design.

Using the GitLab Kubernetes Agent, we want to offer a security oriented, Kubernetes-friendly integration option to Platform Engineers. Beside providing more control for the cluster operator, the agent opens up many new possibilities to make GitLab - cluster integrations easier and deeper. We expect the agent to support various GitLab features with automatic setups and integrations.

Today, the Agent supports the following workflows:

What's next & why

We are working towards supporting the most important and valuable features of the certificate based Kubernetes integration with the GitLab Kubernetes Agent. At the same time, we do not aim for feature parity, as we believe that some features did not serve our users well. Morevoer, we don't plan the deprecatiion of the certificate based integration yet.

We invite you to share your feedback and join the discussion on the future of our Kubernetes integrations.

Simplifying getting started with the Agent

The GitLab Kubernetes Agent is the foundational building block of our future Kubernetes integrations, but in its own it comes without features and without user interfaces. This is clearly not what we want, so we are focusing on adding user interfaces to provide administrative, connection-related insights between GitLab and the cluster, and more importantly to provide insights about ongoing deployments and the resources managed by an Agent.

GitLab Integrated Applications

Many GitLab features rely on 3rd party applications being available in the user's clusters. We are changing our approach to GitLab Managed Apps to GitLab Integrated Apps where platform operators can bring their own applications and processes, and GitLab can integrate with them to provide its features. As a result, we are moving away from the one click, UI based installation, but we want to support our users to install the required applications if they don't have them installed already.

We are looking at providing apps as GitLab Integrated Apps if they satisfy the following criteria:

We believe that infrastructure, including applications, should be managed by code whenever possible. As a result, we provide the cluster management project to get started easily with the GitLab Integrated Apps.


A more detailed view into our roadmap is maintained within GitLab.


We see Kubernetes as a platform for delivering containerised software to users. Currently, every company builds their own workflows on top of it. The biggest challenges as we see them are the following:



Kubernetes Management is currently Viable. We want to make it Complete by June 2021.

Competitive landscape

IBM Cloud Native Toolkit

It provides an Open Source Software Development Life Cycle (SDLC) and complements IBM Cloud Pak solutions. The Cloud Native Toolkit enables application development teams to deliver business value quickly using Red Hat OpenShift and Kubernetes on IBM Cloud.


Spinnaker is an open-source, multi-cloud continuous delivery platform that helps you release software changes with high velocity and confidence. It provides two core sets of features 1) Application management, and 2) Application deployment.

Backstage with its service registry oriented approach and kubernetes integration provides an umbrella to integrate other DevOps tools and provides some insights required by developers of Kubernetes workloads.

Argo CD

Argo CD is often considered to be the leading GitOps tool for Kubernetes with an outstanding UI.

Analyst landscape

This category doesn't quite fit the "configuration management" area as it relates only to Kubernetes. No analyst area currently defined.

Top Customer Success/Sales issue(s)

Customize Kubernetes namespace per environment for managed clusters

Top user issue(s)

Top internal customer issue(s)

Top Vision Item(s)

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