The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
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. Given the central part Kubernetes plays in infrastructure, we consider it business critical to support all the workflows and processes our users have around their Kubernetes clusters.
Our mission is to support the Platform Engineers and SRE 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.
Kubernetes is emerging as the de facto standard for container orchestration. Kubernetes and containers became mainstream by 2022. The primary benefits users see from Kubernetes are improved scalability and shortened deployment times. The primary challenges companies face in this area are
We provide deeper market insights based on the 2021 CNCF survey under the following internal-only document.
After regularly reviewing GitLab sales opportunities we noticed that often prospects are interested in adopting GitLab together with a larger modernization initiative, often involving a move to Kubernetes. As a result we want to provide outstanding integrations with Kubernetes, instead of extending support for non-cloud-native, legacy approaches.
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.
Our vision is that both Self-Managed and SaaS GitLab customers can shrink their cluster operations and cluster-focused platform teams whether they are operating in highly regulated, air-gapped environments or public-cloud-based environments. GitLab offers out-of-the-box integrations for cluster provisioning, deployments, monitoring, security, and alerting functionalities. In our solutions, we acknowledge that cluster management is an inherently complex task and we want to make it easy for inexperienced users without restricting the flexibility for advanced users.
We invite you to share your feedback and join the discussion on the future of our Kubernetes integrations.
In collaboration with monitoring and security we provide the core layer, for the GitLab Agent for Kubernetes, that other teams can build upon. Besides this platform-like work, we work directly on improving the deployments.
The agent is aimed at Platform and SRE teams. As a result, we assume that there are other teams our users serve. For this reason, our pricing leans heavily towards the Premium tier. Around every use case, we plan to launch as a Premium product, and want to move parts of the feature to Core as we better understand our users. The dividing line between Core and Premium features until now is around permissions management.
Example: We moved the CI/CD tunnel to GitLab Core, but only when the agent uses the service account of the cluster side component. At the same time, we are building out a set of "impersonating" featues, where a GitLab user or a CI/CD job can be targeted with Kubernetes RBAC rules. The latter feature set will remain in Premium.
The recommended approach to connect a cluster with GitLab is via the GitLab Agent for Kubernetes. The legacy, certificate based connection is currently being deprecated. Beside these, one can manually configure a
$KUBECONFIG or use 3rd party tooling around GitLab CI or webhooks. You can read more about the deprecated features in the related epic.
Using the agent, we want to offer a security-oriented, Kubernetes-friendly integration option to Platform Engineers. Besides 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.
As the agent itself does not have any features and is responsible for the cluster connection only, every team is welcome to build on this connection. The agent provides a bi-directional communication channel between the cluster and GitLab, as a result, either GitLab can reach out into the cluster, or the cluster side component can message GitLab. The agent is available from GitLab CI/CD as well using the CI/CD tunnel.
Today, the agent supports the following use cases:
As we deprecate the certificate based integrations, we want to make sure that we can offer alternatives for the most valuable parts of that integration. These are
Beside the feature development, we are actively rewriting and extending the related documentation to be focused around the GitLab Agent for Kubernetes, and we are working on more cross-stage initiatives that can integrate GitOps workflows with other parts of GitLab.
We want to make our integrations easy to use. This might mean more automation, conventions and UX improvements. We consider this especially important when we target Software Developers with our features, who might not be familiar with Kubernetes or GitLab at all.
We want to improve the observability aspects of our integrations.
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.
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.
When there is a problem with a just released version, I want an easy way to roll forward or backward.
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.
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.
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:
We offer various 3rd party application integrations as part of the Cluster Management Project and Infrastructure as Code cluster creation. More 3rd party integrations are welcome as long as the following criteria are met:
Kubernetes Management is currently
Argo CD is often considered to be the leading GitOps tool for Kubernetes with an outstanding UI.
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.io 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.
This category doesn't quite fit the "configuration management" area as it relates only to Kubernetes. No analyst area currently defined.