Customize k8s namespace per environment for managed clusters

Release notes

In order to help with various setups around Kubernetes namespaces, users of GitLab Managed Clusters can choose between two namespace handling policies around deployments. While users of non GitLab Managed Clusters had the possibility to use custom namespaces in deployments for a long time, a similar feature was missing for GitLab Managed Clusters. Considering the security aspects of custom namespaces, we are currently offering two approaches to namespace management with GitLab Managed Clusters.

The namespace management policy can be chosen at cluster creation time. The two options are to use a single namespace per project or a single namespace per environment.

https://docs.gitlab.com/ee/user/project/clusters/add_remove_clusters.html

Problem to solve

As a Software Developer, I want easily find the version I've just deployed as a review app, so that I can administer/debug/manage it.

As a Platform Operator, I want to easily identify the role and owner of various namespaces, so that I can administer/manage them appropriately.

Previously GitLab had 1 namespace per project, and review apps were deployed inside. Currently, we provide 1 namespace per environment. This results in the proliferation of namespaces. The namespace names are not descriptive for our users and are often left behind (in the case of review apps).

The generic request is to provide fully customizable namespace names. This is currently not possible with GitLab managed clusters. A more restrictive solution is to provide support to the two naming schemes that GitLab actually supports.

Proposed solution

In the k8s cluster creation/import page, we could choose with an radio button, between 2 modes of namespaces:

• naming as we have today, (1 namespace per environment)
• naming you had before (1 namespace per project)

Currently, we would not add support for "custom" namespaces via environment:kubernetes:namespace. We could implement this in a later step.

This setting can not be changed later. We should document the benefits and shortcomings of both settings to help making a decision. We should measure usage to drive future decisions.

Concerns

By allowing users to disable namespace_per_environment, we undermine Protected Environments, as the anything stored in the namespace would be available to all environments.

This should be clearly stated on the setting, if exposed.