Enable Model Registry (server + UI) by default in example installation

[sameerdattav]

This PR enables the Model Registry by default in the example Kubeflow installation.

Closes #3047

Summary of changes

• Enable the Model Registry server using the upstream Postgres overlay.
• Enable the Model Registry UI using the Istio overlay.
• Add a Central Dashboard overlay to expose the Model Registry UI in the dashboard navigation, following the same pattern used for KServe.

The change is intentionally minimal and aligns with existing Kubeflow integration patterns (e.g. Spark Operator, KServe).

Validation

• kustomize build example succeeds.
• Deployed on a live cluster (Docker Desktop + kubeadm).
• Verified that:
  • Model Registry server, Postgres, and UI pods are running.
  • The Model Registry UI is visible and accessible from the Central Dashboard.

Screenshots

1. Central Dashboard showing Model Registry in the navigation

2. Model Registry UI loaded from the dashboard

3. Running Model Registry pods

4. Model Registry UI deployment running

Notes

• The UI is exposed via Istio routing rather than a standalone ClusterIP Service, consistent with other Kubeflow UIs.
• No upstream files are modified; dashboard integration is done via a new overlay.

[github-actions]

Welcome to the Kubeflow Manifests Repository

Thanks for opening your first PR. Your contribution means a lot to the Kubeflow community.

Before making more PRs:
Please ensure your PR follows our Contributing Guide.
Please also be aware that many components are synchronizes from upstream via the scripts in /scripts.
So in some cases you have to fix the problem in the upstream repositories first, but you can use a PR against kubeflow/manifests to test the platform integration.

Community Resources:

• CNCF Slack channels: https://www.kubeflow.org/docs/about/community/#kubeflow-slack-channels
• Community meetings: https://www.kubeflow.org/docs/about/community/

Thanks again for helping to improve Kubeflow.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign juliusvonkohout for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ederign]

@sameerdattav thanks for working on this. The model registry page was not loaded right? Or am I missing something?

[ederign]

It should look like[1]:

[1] I'm running our standalone distribution on those screenshots.

[ederign]

/assign

[sameerdattav]

Hi @ederign,

Thanks for sharing the screenshots from the standalone distribution — that clarifies the expected UI behavior

I’ve been trying to validate the same behavior from kubeflow/manifests locally, but I’m consistently blocked by a Docker Desktop Kubernetes sandbox/CNI issue for several hours now.

Even when applying only the relevant components (centraldashboard + model-registry-ui + dashboard overlay), the pods never get past sandbox creation. For example, describing the model-registry-ui pod shows:

Error:
FailedCreatePodSandBox: networkPlugin cni failed … plugin type="loopback" failed (add): missing network name

I’ve tried the following troubleshooting steps without success:

• Restarting Docker Desktop and Kubernetes.
• Recreating/Resetting the cluster.
• Performing a manual cleanup of the CNI configuration within the Docker VM (/etc/cni/net.d/).
• Selectively applying only the required manifests to reduce resource pressure.

Despite these efforts, the pods never reach the Running state, so I cannot capture fresh screenshots from this specific setup to validate the changes.

Please suggest a way to resolve this issue or let me know if there is a known workaround for this CNI loopback error on Docker Desktop (WSL2).

Alternatively, if there’s a recommended lightweight way to validate this change from manifests on Docker Desktop—perhaps a specific minimal overlay—I’d really appreciate the guidance.

[juliusvonkohout]

@sameerdattav you can just use kind as in our ci/cd and in our documentation. https://github.com/kubeflow/manifests/blob/master/.github/workflows/full_kubeflow_integration_test.yaml we are using Ubuntu 24.04 in our ci/cd and I also test it on fedora 43. Please check the readme https://github.com/kubeflow/manifests/tree/master#prerequisites-1

[sameerdattav]

Hi @juliusvonkohout @ederign 👋

I revamped the whole thing from docker desktop and created a kind cluster as u have mentioned
i want to ask for guidance on the namespace behavior I’m seeing.

Current state:
The Model Registry sidebar entry is visible in Central Dashboard.
All related pods are running (model-registry, model-registry-ui, DB, profiles, etc.).
However, the namespace selector in Central Dashboard is empty, and Model Registry fails to load due to a missing namespace.

Screenshots for reference:

Central Dashboard (sidebar visible)

Model Registry error (missing required query parameter: namespace)

All pods running successfully

I also tried directly navigating to:

http://localhost:8080/_/model-registry/?namespace=kubeflow-user-example-com

but this still results in an error.

At the moment:

I can’t see any namespaces in the namespace dropdown.
I do have a default Profile created with owner [email protected].
My questions:

Is kubeflow-user-example-com the correct namespace I should be using here, or should it be something else (e.g. default or another profile-derived namespace)?
Is there an additional manifests overlay / install step required to make namespaces from Profiles appear in Central Dashboard?
Is this a known limitation or expected behavior when running via kind + local manifests?

Thanks a lot!