• Setting the environment scope

Multiple clusters per project with cluster certificates (deprecated)

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 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 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, let’s say the following Kubernetes clusters exist in a project:

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:

• 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.