My company has been working with Kuberenetes for more than a year, and GitLab for about 6 months. We recently upgraded to GitLab 9.x and you are having trouble finding a solution related to configuring your CI + application with Kube. This feature is amazing and would like it to work in our environment.
GitLab seems to expect that you will have only one cluster installation with all the environments within the same cluster, a broken namespace that will be equal to your service / application and the application that will be equal to your environment. This is similar to what GitLab wants my Kuberenetes environment to look like as a single cluster with your service split into namespaces:
namespace = hello-world
app = development
app = qa
app = production
where in the real world example we would prefer to have the opposite, which also works well with one cluster
DEVELOPMENT CLUSTER
namespace = development
app = hello-world
QA CLUSTER
namespace = qa
app = hello-world
PRODUCTION CLUSTER
namespace = production
app = hello-world
If the namespace is an application and the application is an environment, we will not be able to upgrade to the latest version of kube without updating everything. Maybe I missed something, but based on what I'm reading, and after testing it looks like it was the way it was designed.
For reference, this is what my CI looks like now to make the deployment plugin + terminal happy
development:
<<: *deploy_definition
stage: development
environment: hello-world
script:
deploy.sh -a "hello-world"
but it should look like this:
development:
<<: *deploy_definition
stage: development
environment: development
script:
deploy.sh -a "hello-world"
To add to this confusion, they give you only one Kubernetes wizard to connect to on the integration tab.
Is this right, or am I missing something?