Help us learn about your current experience with the documentation.
Take the survey.
Multiple clusters per project with cluster certificates (deprecated)Using multiple Kubernetes clusters for a single project with cluster certificates was deprecated in GitLab 14.5. To connect clusters to GitLab, use the GitLab agent for Kubernetes.
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 that differentiates the new cluster from the rest.
Setting the environment scopeWhen 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 CI/CD variables 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, a project might have the following Kubernetes clusters:
Cluster Environment scope Development* Production production
And the following environments are set in the .gitlab-ci.yml file:
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:
deploy to staging job.deploy to production job.test job because it doesn’t define any environment.RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4