- Installing GitLab on Kubernetes
Note: These charts have been tested on Google Container Engine and Azure Container Service. Other Kubernetes installations may work as well, if not please open an issue.
The easiest method to deploy GitLab on Kubernetes is to take advantage of GitLab's Helm charts. Helm is a package management tool for Kubernetes, allowing apps to be easily managed via their Charts. A Chart is a detailed description of the application including how it should be deployed, upgraded, and configured.
- GitLab-Omnibus: The best way to run GitLab on Kubernetes today, suited for small to medium deployments. The chart is in beta and will be deprecated by the cloud native GitLab chart.
- Cloud Native GitLab Chart: The next generation GitLab chart, currently in development. Will support large deployments with horizontal scaling of individual GitLab components.
- Other Charts
- GitLab Runner Chart: For deploying just the GitLab Runner.
- Advanced GitLab Installation: Deprecated, being replaced by the cloud native GitLab chart. Provides additional deployment options, but provides less functionality out-of-the-box.
- Community Contributed Charts: Community contributed charts, deprecated by the official GitLab chart.
Note: This chart is in beta while additional features are being added.
This chart is the best available way to operate GitLab on Kubernetes. It deploys and configures nearly all features of GitLab, including: a Runner, Container Registry, Mattermost, automatic SSL, and a load balancer. It is based on our GitLab Omnibus Docker Images.
Once the cloud native GitLab chart is ready for production use, this chart will be deprecated. Due to the difficulty in supporting upgrades to the new architecture, migrating will require exporting data out of this instance and importing it into the new deployment.
Learn more about the gitlab-omnibus chart.
GitLab is working towards building a cloud native GitLab chart. A key part of this effort is to isolate each service into its own Docker container and Helm chart, rather than utilizing the all-in-one container image of the current chart.
By offering individual containers and charts, we will be able to provide a number of benefits:
- Easier horizontal scaling of each service,
- Smaller, more efficient images,
- Potential for rolling updates and canaries within a service,
- and plenty more.
This is a large project and will be worked on over the span of multiple releases. For the most up-to-date status and release information, please see our tracking issue. We are planning to launch this chart in beta by the end of 2017.
Learn more about the cloud native GitLab chart.
If you already have a GitLab instance running, inside or outside of Kubernetes, and you'd like to leverage the Runner's Kubernetes capabilities, it can be deployed with the GitLab Runner chart.
Learn more about gitlab-runner chart.
If advanced configuration of GitLab is required, the beta gitlab chart can be used which deploys the core GitLab service along with optional Postgres and Redis. It offers extensive configuration, but offers limited functionality out-of-the-box; it's lacking Pages support, the container registry, and Mattermost. It requires deep knowledge of Kubernetes and Helm to use.
This chart will be deprecated and replaced by the gitlab-omnibus chart, once it supports additional configuration options. It's beta quality, and since it is not actively under development, it will never be GA.
Learn more about the gitlab chart.