KServe platform resources should be installed in the kserve namespace

[danish9039]

Problem

KServe platform resources are installed into the kubeflow namespace, while the
KServe project itself installs its control plane into the kserve namespace.
The Kubeflow distribution therefore diverges from the upstream layout, which has
three consequences.

The generated upstream bundle assumes the kserve namespace. Re-pointing it at
kubeflow required local patches that rewrote the
cert-manager.io/inject-ca-from annotations on every webhook configuration and
custom resource definition, and rewrote the subject alternative names on three
Certificate resources. Each of these patches is a place where a future
synchronization can silently break admission.

The kubeflow namespace mixes the KServe control plane with unrelated Kubeflow
components, so a cluster administrator cannot tell which controllers belong to
which project, and namespace-scoped policy cannot be written per project.

Finally, resources that belong to KServe are owned by the shared
common/kubeflow-namespace base rather than by the KServe component, which
makes the ownership boundary unclear for both Kustomize and Helm installations.

Current behaviour

• The KServe controllers, webhooks, certificates, namespaced role-based access
  control, and inferenceservice-config are installed into kubeflow.
• The KServe Models Web Application is installed into kubeflow.
• The KServe NetworkPolicies are owned by
  common/kubeflow-namespace/base/kubeflow, not by the KServe component.

Proposed work

• Install the standard upstream KServe bundle into the kserve namespace,
  including controllers, webhooks, certificates, namespaced role-based
  access control, and inferenceservice-config.
• Move the KServe Models Web Application into kserve while preserving
  routing through kubeflow/kubeflow-gateway.
• Keep user InferenceService resources and serving workloads in Profile
  namespaces.
• Keep KServe custom resource definitions and public application programming
  interface schemas unchanged.
• Keep direct Kustomize installation self-contained by owning
  Namespace/kserve in the component Kustomization.
• Give the kubeflow-namespaces foundation chart ownership of
  Namespace/kserve and its restricted Pod Security labels for the Helm
  installation, and keep component charts free of Namespace resources.
• Transfer KServe NetworkPolicy ownership from
  common/kubeflow-namespace to the owning components.
• Preserve the Kubeflow aggregate KServe roles and existing user
  authorization.
• Document the upgrade, including that controllers in the old and new
  namespaces use different leader-election Lease resources and therefore
  must not run concurrently.

Out of scope

Generated KServe control-plane Helm charts and their synchronization pipeline
remain separate future work. This issue does not move user namespaces,
InferenceService resources, or model-serving workloads.

Related

• Pull request implementing the relocation:
  kserve: move platform resources to kserve namespace #3515
• The synchronization that raised the namespace question:
  Update kserve/kserve manifests to version v0.19.0 #3505
• Related namespace strategy discussion for the Kubeflow control plane:
  Proposal: Use kubeflow-system namespace for the Kubeflow Control Plane #2937

[github-actions]

Welcome to the Kubeflow Community Distribution Repository

Thanks for opening your first issue. We are trying to deal with your issue on a best-effort basis. without guarantees.
If you need commercial support instead please reach out to us.
Please make sure to follow our default issue template so maintainers can quickly understand and reproduce the problem instead of just closing the issue.
The template asks for:

• Environment details (Kubernetes version, OS, platform)
• Components involved
• Steps to reproduce
• Current versus expected behavior
• Properly formatted logs, screenshots or error messages

Community Resources:

• Join us on the CNCF Slack: https://www.kubeflow.org/docs/about/community/#kubeflow-slack-channels
• Attend our community meetings: https://www.kubeflow.org/docs/about/community/

Feel free to ask questions — we are here to help.