Proposal: Use kubeflow-system namespace for the Kubeflow Control Plane

[andreyvelich]

Validation Checklist

• Is this a Kubeflow issue?
• Are you posting in the right repository ?
• Did you follow the Kubeflow installation guideline ?
• Is the issue report properly structured and detailed with version numbers?
• Is this for Kubeflow development ?
• Would you like to work on this issue?
• You can join the CNCF Slack and access our meetings at the Kubeflow Community website. Our channel on the CNCF Slack is here #kubeflow-platform.

Version

master

Describe your issue

I proposed during the previous Kubeflow Community meeting that we rename namespace from kubeflow to kubeflow-system. So we make the kubeflow-system - the default namespace for the Kubeflow control plane.

The motivation is to make it easier for cluster admins to understand that the Kubeflow control plane is deployed in this namespace, and make Kubeflow consistent with other CNCF projects. For example:

• Kubernetes: kube-system
• Istio: istio-system
• Kueue: kueue-system

FYI, @kubeflow/wg-training-leads are already using the kubeflow-system namespace for Kubeflow Training V2.

WDYT @kubeflow/wg-manifests-leads ?

Put here any screenshots or videos (optional)

No response

[terrytangyuan]

+1 but shouldn’t the namespace be configurable?

[thesuperzapper]

I like the idea of making it configurable, or even having separate ones like kubeflow-pipelines and kubeflow-notebooks as there is not really a reason to combine everything, and this just increases security risk (stuff like dashboard and profile controller could be in kubeflow-system).

However, this is going to be a crazy amount of work, because we hard code the kubeflow namespace everywhere, including places where it will be hard to template, like Istio configs.

[andreyvelich]

1 but shouldn’t the namespace be configurable?

@terrytangyuan I think, we should make this namespace configurable. I just meant that by default we can use the kubeflow-system namespace in the Kubeflow Manifests.

However, this is going to be a crazy amount of work, because we hard code the kubeflow namespace everywhere, including places where it will be hard to template, like Istio configs.

We don't hard code the Kubeflow namespace everywhere. For example, we allow to configure namespace for:

• Training Operator: https://github.com/kubeflow/training-operator/blob/master/manifests/base/deployment.yaml#L30C21-L30C37
• Katib: https://github.com/kubeflow/katib/blob/master/manifests/v1beta1/components/controller/controller.yaml#L50-L53

[juliusvonkohout]

I am in favour of renaming it and it sounds like something for Gsoc 2025.

[thesuperzapper]

Although, if we are only making this change for stylistic reasons, I am not sure it's worth it, because it's a breaking change which will reduce the amount of people who upgrade.

Doing a split up by app has other benefits so I am more open to it, but still hesitant to do anything that will make upgrades harder for users.