Installing GitLab by using Helm

Install GitLab on Kubernetes by using the cloud native GitLab Helm chart.

Assuming you already have the prerequisites installed and configured, you can deploy GitLab with the helm command.

For a production deployment, you should have strong working knowledge of Kubernetes. This method of deployment has different management, observability, and concepts than traditional deployments.

In a production deployment:

• PostgreSQL and Redis must run outside the cluster on PaaS or compute instances. This configuration is required to scale and reliably service the variety of workloads found in production GitLab environments.
• You should use Cloud PaaS for PostgreSQL, Redis, and object storage for all non-Git repository storage.

If Kubernetes is not required for your GitLab instance, see the reference architectures for simpler alternatives.

Container images

The GitLab Helm chart uses the Cloud Native GitLab (CNG) container images to deploy GitLab. Besides the CNG images for GitLab itself, the default configuration uses MinIO for object storage in non-production deployments.

External PostgreSQL, Redis, and object storage are required. Refer to the following documentation for instructions on how to configure the chart to use external services.

1. External Database
2. External Redis
3. External Object Storage

Configure the Helm chart to use external stateful data

Configure the chart to point to external object storage, Redis, PostgreSQL, and Gitaly services that match your selected reference architecture.

Use the reference architectures

The reference architecture for deploying GitLab instances to Kubernetes is called Cloud Native Hybrid specifically because not all GitLab services can run in the cluster for production-grade implementations. All stateful GitLab components must be deployed outside the Kubernetes cluster.

Available Cloud Native Hybrid reference architectures sizes are listed at Reference architectures page. For example, here is the Cloud Native Hybrid reference architecture for the 3,000 user count.

Use Infrastructure as Code (IaC) and builder resources

GitLab develops Infrastructure as Code that is capable of configuring the combination of Helm charts and supplemental cloud infrastructure:

• GitLab Environment Toolkit IaC.
• Implementation pattern: Provision GitLab cloud native hybrid on AWS EKS: This resource provides a Bill of Materials tested with the GitLab Performance Toolkit, and uses the AWS Cost Calculator for budgeting.

Zero downtime upgrades

Zero-downtime upgrades allow you to upgrade GitLab without service interruptions. To enable this capability, you must configure rolling update strategies during your initial installation. If you add these settings to an existing deployment later, it will trigger pod restarts and may cause brief downtime.

To configure your deployment for zero-downtime upgrades, be sure to include the rolling update settings from the Recommended deployment settings.

For complete upgrade procedures, see the Upgrade with zero downtime documentation.