8.4 KiB
stage | group | info |
---|---|---|
Configure | Configure | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments |
Manage cluster applications (FREE)
- Introduced in GitLab 12.10 with Helmfile support via Helm v2.
- Helm v2 support was dropped in GitLab 14.0. Use Helm v3 instead.
- Migrated to the GitLab Agent in GitLab 14.5.
Use a repository to install, manage, and deploy clusters applications through code.
Cluster Management Project Template
The Cluster Management Project Template provides you a baseline to get started and flexibility to customize your project to your cluster's needs. For instance, you can:
- Extend the CI/CD configuration.
- Configure the built-in cluster applications.
- Remove the built-in cluster applications you don't need.
- Add other cluster applications using the same structure as the ones already available.
The template contains the following components:
- A pre-configured GitLab CI/CD file so that you can configure CI/CD pipelines using the CI/CD Tunnel.
- A pre-configured Helmfile so that you can manage cluster applications with Helm v3.
- An
applications
directory with ahelmfile.yaml
configured for each application available in the template.
Use the Agent with the Cluster Management Project Template
To use a new project created from the Cluster Management Project Template with a cluster connected to GitLab through the GitLab Agent, you have two options:
- Use one single project to configure the Agent and manage cluster applications.
- Use separate projects - one to configure the Agent and another to manage cluster applications.
Single project
This setup is particularly useful when you haven't connected your cluster to GitLab through the Agent yet and you want to use the Cluster Management Project Template to manage cluster applications.
To use one single project to configure the Agent and to manage cluster applications:
- Create a new project from the Cluster Management Project Template.
- Configure the new project as the Agent's configuration repository
(where the Agent is registered and its
config.yaml
is stored). - From your project's settings, add a new environment variable
$KUBE_CONTEXT
and set it topath/to/agent-configuration-project:your-agent-name
. - Configure the components inherited from the template.
Separate projects
This setup is particularly useful when you already have a cluster connected to GitLab through the Agent and want to use the Cluster Management Project Template to manage cluster applications.
To use one project to configure the Agent ("project A") and another project to manage cluster applications ("project B"), follow the steps below.
We assume that you already have a cluster connected through the Agent and configured through the Agent's configuration repository ("project A").
- Create a new project from the Cluster Management Project Template. This new project is "project B".
- In your "project A", grant the Agent access to the new project (B) through the CI/CD Tunnel.
- From the "project's B" settings, add a new environment variable
$KUBE_CONTEXT
and set it topath/to/agent-configuration-project:your-agent-name
. - In "project B", configure the components inherited from the template.
Create a new project based on the Cluster Management Template
To get started, create a new project based on the Cluster Management project template to use as a cluster management project.
You can either create the new project from the template or import the project from the URL. Importing the project is useful if you are using a GitLab self-managed instance that may not have the latest version of the template.
- From the template: select the GitLab Cluster Management project template.
- Importing from the URL: use
https://gitlab.com/gitlab-org/project-templates/cluster-management.git
.
Configure the available components
Use the available components to configure your cluster applications:
The .gitlab-ci.yml
file
The base image used in your pipeline is built by the cluster-applications project. This image consists of a set of Bash utility scripts to support Helm v3 releases:
gl-fail-if-helm2-releases-exist {namespace}
: It tries to detect whether you have apps deployed through Helm v2 releases for a given namespace. If so, it will fail the pipeline and ask you to manually migrate your Helm v2 releases to Helm v3.gl-ensure-namespace {namespace}
: It creates the given namespace if it does not exist and adds the necessary label for the Cilium app network policies to work.gl-adopt-resource-with-helm-v3 {arguments}
: Used only internally in the cert-manager's Helmfile to facilitate the GitLab Managed Apps adoption.gl-adopt-crds-with-helm-v3 {arguments}
: Used only internally in the cert-manager's Helmfile to facilitate the GitLab Managed Apps adoption.gl-helmfile {arguments}
: A thin wrapper that triggers the Helmfile command.
The main helmfile.yml
file
This file has a list of paths to other Helmfiles for each app. They're all commented out by default, so you must uncomment the paths for the apps that you would like to use in your cluster.
By default, each helmfile.yaml
in these sub-paths has the attribute installed: true
. This means that every time
the pipeline runs, Helmfile tries to either install or update your apps according to the current state of your
cluster and Helm releases. If you change this attribute to installed: false
, Helmfile tries try to uninstall this app
from your cluster. Read more about how Helmfile works.
Built-in applications
The built-in supported applications are:
- Apparmor
- Cert-manager
- Cilium
- Elastic Stack
- Falco
- Fluentd
- GitLab Runner
- Ingress
- Prometheus
- Sentry
- Vault
Customize your applications
Each app has an applications/{app}/values.yaml
file (applications/{app}/values.yaml.gotmpl
in case of GitLab Runner). This is the
place where you can define default values for your app's Helm chart. Some apps already have defaults
pre-defined by GitLab.