Kubernetes Cluster Assignment

Summary

In Non-Licensed EE the scope field on kubernetes clusters is shown but not functional (breaks the function).

Steps to reproduce

Install GitLab EE, do not assign a license. Then create an instance-wide cluster and set a scope.

What is the current bug behavior?

The cluster will never be used for any deployments.

What is the expected correct behavior?

The cluster should be used for the environment set in "scope" or the scope field should not be settable.

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:         Debian 9.9
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   2.6.3p62
Gem Version:    2.7.9
Bundler Version:1.17.3
Rake Version:   12.3.2
Redis Version:  3.2.12
Git Version:    2.21.0
Sidekiq Version:5.2.7
Go Version:     unknown

GitLab information
Version:        12.1.4-ee
Revision:       4ea82400e72
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     10.7
URL:            https://git.firesplash.de
HTTP Clone URL: https://git.firesplash.de/some-group/some-project.git
SSH Clone URL:  git@git.firesplash.de:some-group/some-project.git
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers: saml


GitLab Shell
Version:        9.3.0
Repository storage paths:
  • default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 9.3.0 ? ... OK (9.3.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK


Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Reply by email is disabled in config/gitlab.yml


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab App ...


Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
17/2 ... yes
16/8 ... yes
18/9 ... yes
20/10 ... yes
6/11 ... yes
22/12 ... yes
22/13 ... yes
21/14 ... yes
21/15 ... yes
21/16 ... yes
17/17 ... yes
23/18 ... yes
24/21 ... yes
25/22 ... yes
25/24 ... yes
25/25 ... yes
25/26 ... yes
27/27 ... yes
27/28 ... yes
28/29 ... yes
30/30 ... yes
30/31 ... yes
29/32 ... yes
26/33 ... yes
31/34 ... yes
32/35 ... yes
31/36 ... yes
33/37 ... yes
34/38 ... yes
34/39 ... yes
6/40 ... yes
6/41 ... yes
6/42 ... yes
35/43 ... yes
35/45 ... yes
35/46 ... yes
22/47 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.5.3 ? ... yes (2.6.3)
Git version >= 2.21.0 ? ... yes (2.21.0)
Git user has default SSH configuration? ... yes
Active users: ... 9
Elasticsearch version 5.6 - 6.x? ... skipped (elasticsearch is disabled)


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Further comments

It's okay that you do not support that feature for non-licensed users But please give us any choice to at assign clusters to projects just like it's done for runners or at least en/disable the integration on a per project base. With scope "*" every single project the runs in CI creates a namespace on kubernetes. However that makes hundreds of namespaces where only 3 are used.

I know you can kind of do that when creating clusters per project but that menas setting up the same cluster multiple times and removes the possibility to manage ingress etc centrally with gitlab. What about a simple toggle in project features "Uses Kubernetes-Integration" on/off? You'd not have to change the integration itself, just enable/disable it.

The feature descriptions says "free" version does not support multiple kubernetes clusters for differenc environments. However it does not even support restricting the environments/projects at all.

Another reasonable way would be a global instance wide environment filter in gitlab.rb like "Kubernetes Environment Filter" which allows regex or at least wildcards so you could make it only use "k8s-*" for kubernetes. As this would be an instance-wide setting the EE-Feature would not be changed.

Edited by Alex from Firesplash Entertainment