GitLab’s Kubernetes Operator with Support for Red Hat OpenShift is Now Generally Available 

Why build the GitLab Operator?

Gitlab believes user expectations are at an all-time high. They expect always-on applications, available from any device, anywhere in the world. In order to meet these needs software teams employ cloud native methodologies and architectures such as containers and microservices to run reliably at scale. Kubernetes has emerged as the de facto standard for container orchestration and has seen broad adoption by companies of all sizes across all industries.

Red Hat OpenShift is an enterprise-grade Kubernetes distribution that adds productivity and security features designed for the needs of production workloads and systems. Red Hat OpenShift has become a leading choice for security-and-compliance-conscious companies in markets such as the public sector as well as regulated industries.

Enterprise shared services groups often favor running IT applications inside of the Kubernetes or Red Hat OpenShift cluster in order to take advantage of the resilience and scale it offers. Each app they can’t run inside their cluster creates operational overhead as it forces them to manage legacy infrastructure in order to support the app.

GitLab was an early adopter of Kubernetes, adding capabilities such as a built-in container registry and native deployment from GitLab CI/CD to a Kubernetes Cluster as early as 2016 [1] [2], with official installation of GitLab instances via Helm chart in 2017 [3]. As Kubernetes quickly evolved, often with breaking changes, GitLab chose to focus on vanilla Kubernetes in order to establish a strong foundation to reach as broad a base as possible. However, this meant IT organizations running their applications in a Red Hat OpenShift cluster either couldn’t use GitLab or needed to deploy their instance into separate legacy infrastructure with all of the associated overhead.

Introducing the GitLab Operator

Earlier this year the GitLab 13.11 release went live accompanied by the beta release of the GitLab Operator. Over the past 6 months, GitLab has worked closely with Red Hat to discuss technical details and optimize compatibility. Using the Operator pattern developed by CoreOS, the GitLab Operator provides an enhanced way to deploy and operate GitLab.

What is an Operator?

Generally, the intention of an Operator is to take the operational knowledge of an administrator and automate it with software running inside the cluster. Day 1 tasks, such as installation and configurations, along with Day 2 tasks such as upgrades with minimized downtime, are now integrated into the cluster and actioned through an Operator.

Expanding Beyond the GitLab Helm Chart

The GitLab Operator and Cloud Native Helm Chart are offered in tandem as deployment solutions for cloud native environments. Behind the scenes, the Operator consumes the Helm chart to model operations. Both are officially supported patterns for deployment.

The Operator offers extended capabilities beyond the Cloud Native Helm Chart. The Operator functions to not only deploy GitLab initially, but it also actively secures the deployment against unwarranted changes and keeps GitLab continually up-to-date as components are versioned. Most importantly, the GA release of the GitLab Operator provides the ability to run production instances of GitLab on Red Hat Openshift (with official Red Hat OpenShift certification coming soon!). While the Helm Chart only supports vanilla Kubernetes, the Operator runs on both Red Hat OpenShift and vanilla Kubernetes.

Get Started

Visit the GitLab Operator documentation for more information on ​​known limitations and prerequisites along with a full installation guide.

Source: William Chia, GitLab