Why can a cluster only manage a single namespace?

We are using the Kubernetes integration on GitLab.com for our (self-managed) OpenShift cluster, and we typically use 3 stages for customer projects:

  • development
  • integration
  • production

We have 2 strategies to deploy those into our cluster:

  1. dedicated (3 separate namespaces, application labels identical across namespaces)
  2. shared (a single namespace, application labels different to group resources)

Only “shared” works out for true Kubernetes integration, which includes

  • Pod Logs
  • Terminal

because for a the Cluster configuration to be complete you have to specify the “Project namespace”, which with the “dedicated” strategy is obviously different for each environment, e.g.

  • ${project_slug}-development
  • ${project_slug}-integration
  • ${project_slug}-production

Example source code: https://gitlab.com/appuio/example-django


Add cluster:

Cluster details:

Is Our Concept So Non-Standard?

Assuming our approach is a straight-forward one why is the “Project namespace” not tied to the environment instead of the cluster? (In fact, this seems to be the case for a “GitLab-managed cluster” according to the docs on deployment variables).

Has this issue ever been discussed? Is there a solution for integrating properly with our “dedicated” strategy? (Not sure whether configuring 3 times the same clusters with a different project namespace will help.)

We ran into the same issue when we started with GitLab integration with OpenShift. We decided that we wanted dedicated namespaces per environment so we dropped the GitLab direct K8s integration and managed it ourselves in scripts.

Since OpenShift is a hardened version of K8s it doesn’t make sense to do the shared approach as you will have to enable cross namespace commutation.

We did raise this with GitLab and there are multiple users wanting to use GitLab in the same way as you and there is an issue somewhere…

There is an easy solution now to fix the situation: GitLab allows to configure several clusters.

Hence, what we do is to configure the same cluster, but specify a specific namespace, for every single of our target environments. GitLab’s Kubernetes integration also lets you specify the environment scope, so all is neatly integrated.


No scripting necessary. Nice!

Thank you, GitLab! – You gals and guys are awesome!