- Installing applications
- RBAC compatibility
- Cluster precedence
- Multiple Kubernetes clusters
- GitLab-managed clusters
- Base domain
- Environment scopes
- Cluster environments
- Security of runners
- More information
Introduced in GitLab 11.6.
Similar to project-level and instance-level Kubernetes clusters, group-level Kubernetes clusters allow you to connect a Kubernetes cluster to your group, enabling you to use the same cluster across multiple projects.
To view your group level Kubernetes clusters, navigate to your project and select Kubernetes from the left-hand menu.
GitLab can install and manage some applications in your group-level cluster. For more information on installing, upgrading, uninstalling, and troubleshooting applications for your group cluster, see GitLab Managed Apps.
For each project under a group with a Kubernetes cluster, GitLab creates a restricted
service account with
in the project namespace.
If the project’s cluster is available and not disabled, GitLab uses the project’s cluster before using any cluster belonging to the group containing the project. In the case of sub-groups, GitLab uses the cluster of the closest ancestor group to the project, provided the cluster is not disabled.
- Introduced to GitLab Core in 13.2.
You can associate more than one Kubernetes cluster to your group, and maintain different clusters for different environments, such as development, staging, and production.
When adding another cluster, set an environment scope to help differentiate the new cluster from your other clusters.
You can choose to allow GitLab to manage your cluster for you. If GitLab manages your cluster, resources for your projects are automatically created. See the Access controls section for details on which resources GitLab creates for you.
For clusters not managed by GitLab, project-specific resources aren’t created automatically. If you’re using Auto DevOps for deployments with a cluster not managed by GitLab, you must ensure:
- The project’s deployment service account has permissions to deploy to
KUBECONFIGcorrectly reflects any changes to
KUBE_NAMESPACE(this is not automatic). Editing
KUBE_NAMESPACEdirectly is discouraged.
If you install applications on your cluster, GitLab creates the resources required to run them, even if you choose to manage your own cluster.
Introduced in GitLab 12.6.
If you choose to allow GitLab to manage your cluster for you, GitLab stores a cached version of the namespaces and service accounts it creates for your projects. If you modify these resources in your cluster manually, this cache can fall out of sync with your cluster, which can cause deployment jobs to fail.
To clear the cache:
- Navigate to your group’s Kubernetes page, and select your cluster.
- Expand the Advanced settings section.
- Click Clear cluster cache.
Introduced in GitLab 11.8.
Domains at the cluster level permit support for multiple domains
per multiple Kubernetes clusters When specifying a domain,
this is automatically set as an environment variable (
the Auto DevOps stages.
The domain should have a wildcard DNS configured to the Ingress IP address.
When adding more than one Kubernetes cluster to your project, you need to differentiate them with an environment scope. The environment scope associates clusters with environments similar to how the environment-specific variables work.
While evaluating which environment matches the environment scope of a cluster, cluster precedence takes effect. The cluster at the project level takes precedence, followed by the closest ancestor group, followed by that groups’ parent and so on.
For example, if your project has the following Kubernetes clusters:
And the following environments are set in
stages: - test - deploy test: stage: test script: sh test deploy to staging: stage: deploy script: make deploy environment: name: staging/$CI_COMMIT_REF_NAME url: https://staging.example.com/ deploy to production: stage: deploy script: make deploy environment: name: production/$CI_COMMIT_REF_NAME url: https://example.com/
The result is:
- The Project cluster is used for the
- The Staging cluster is used for the
deploy to stagingjob.
- The Production cluster is used for the
deploy to productionjob.
For important information about securely configuring runners, see Security of runners documentation for project-level clusters.
For information on integrating GitLab and Kubernetes, see Kubernetes clusters.