The gap between ML dashboards and Kubernetes primitives
Kubeflow is one of the most popular ways to assemble a Kubernetes-based stack for AI and ML. Notebook servers, distributed training jobs, hyperparameter tuning, multi-step pipelines, all of it is exposed as Custom Resource Definitions, the Kubernetes-native way to extend the API. That is great for cluster operators, because the workloads can be observed and managed with the same primitives as everything else in the cluster.
The problem is what happens when something goes wrong. The ML dashboards that ship with Kubeflow are aimed at data scientists. When a notebook hangs or a training run fails, the operator ends up dropping back to kubectl to find out what actually happened at the Pod level. Two workflows, two tools, and a context switch every time a production ML workload wobbles.
A plugin that closes the gap
A new Headlamp plugin for Kubeflow closes that gap. Headlamp is a general-purpose Kubernetes web UI maintained under Kubernetes SIG UI and licensed under Apache 2.0. It runs as a desktop app or in-cluster, and its plugin system lets anyone add first-class views for custom resources.
The plugin reads directly from the Kubernetes API server. It does not depend on a Kubeflow-specific backend service, so it works even when that service is unavailable. Because Kubeflow is modular and teams often install only the components they need, the plugin discovers the Kubeflow API groups that are present on a cluster and shows only the corresponding sections.
What the Notebook view gives operators
The Notebook detail view surfaces the kind of information that would otherwise require several kubectl commands strung together. It shows the Pod conditions for the notebook, including their reason and message fields. It shows CPU, memory, and GPU requests and limits. It enumerates volume mounts and their backing types, including PersistentVolumeClaim, ConfigMap, Secret, and EmptyDir. It pulls out environment variables that reference Secrets or ConfigMaps, lists sidecar containers, and surfaces node tolerations.
For an SRE trying to figure out why a notebook is stuck, that is the difference between five minutes of investigation and a half hour of piecing things together.
Katib: tuning, trials, and the current best
For hyperparameter tuning jobs, the Katib views show the tuning algorithm, the search space, every Trial with its live status, and the current best Trial with its metric values and parameter assignments. The early-stopping configuration is visible, as is the count of Trials that stopped early, so an operator can follow the search without leaving the cluster UI.
Pipelines: read from the API, not the backend
The Pipelines views read Kubernetes API resources directly and do not query the Kubeflow Pipelines API service or backend database. That detail matters: it means an operator can inspect stored pipeline state even when that service is unavailable. The Pipeline detail view compares the latest and previous PipelineVersion specifications in a side-by-side YAML diff. Run views show state and duration. RecurringRun views show human-readable schedules. The artifacts view aggregates values from recent Run resources.
A graph that shows the relationships
The plugin registers a custom graph view that renders Notebook, Profile, PodDefault, Experiment, Pipeline, SparkApplication, and TrainJob resources as graph nodes. It draws edges between supported resources based on their ownership and reference relationships. Hovering over a node shows an inline summary, so the graph becomes a quick way to navigate a complex ML workload without losing the underlying structure.
The pattern is bigger than Kubeflow
The most interesting thing about this plugin is that it is not really about Kubeflow. It is a worked example of a general pattern. Any platform that models its domain with custom resources ends up with two audiences: the platform users, who want a purpose-built dashboard, and the operators, who need to see the state of the underlying API resources. A general-purpose Kubernetes UI with a CRD-driven plugin can serve both audiences without forcing operators to context-switch.
The plugin is open source under Apache 2.0 and developed under Kubernetes SIG UI. To try it locally, the project documentation walks through a CRD-only path for evaluation, which means you do not need a full Kubeflow install to see what the views look like. The same installation flow works with a production modular Kubeflow cluster.