debian-mirror-gitlab/doc/user/project/clusters/multiple_kubernetes_clusters.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

78 lines
2.7 KiB
Markdown
Raw Normal View History

2021-09-30 23:02:18 +05:30
---
stage: Configure
group: Configure
info: 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
---
2021-12-11 22:18:48 +05:30
# Multiple clusters per project with cluster certificates (DEPRECATED) **(FREE)**
2021-09-30 23:02:18 +05:30
2022-04-04 11:22:00 +05:30
> - Introduced in GitLab 10.3
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35094) from GitLab Premium to GitLab Free in 13.2.
2021-12-11 22:18:48 +05:30
> - [Deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
WARNING:
Using multiple Kubernetes clusters for a single project **with cluster
certificates** was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
2022-05-07 20:08:51 +05:30
To connect clusters to GitLab, use the [GitLab agent](../../../user/clusters/agent/index.md).
2021-09-30 23:02:18 +05:30
You can associate more than one Kubernetes cluster to your
project. That way you can have different clusters for different environments,
like development, staging, production, and so on.
Add another cluster, like you did the first time, and make sure to
[set an environment scope](#setting-the-environment-scope) that
differentiates the new cluster from the rest.
## Setting the environment scope
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](../../../ci/environments/index.md) similar to how the
[environment-specific CI/CD variables](../../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable) work.
The default environment scope is `*`, which means all jobs, regardless of their
environment, use that cluster. Each scope can be used only by a single cluster
in a project, and a validation error occurs if otherwise. Also, jobs that don't
have an environment keyword set can't access any cluster.
For example, let's say the following Kubernetes clusters exist in a project:
| Cluster | Environment scope |
| ----------- | ----------------- |
| Development | `*` |
| Production | `production` |
And the following environments are set in
[`.gitlab-ci.yml`](../../../ci/yaml/index.md):
```yaml
stages:
- test
- deploy
test:
stage: test
script: sh test
deploy to staging:
stage: deploy
script: make deploy
environment:
name: staging
url: https://staging.example.com/
deploy to production:
stage: deploy
script: make deploy
environment:
name: production
url: https://example.com/
```
The results:
- The Development cluster details are available in the `deploy to staging`
job.
- The production cluster details are available in the `deploy to production`
job.
- No cluster details are available in the `test` job because it doesn't
define any environment.