--- title: "Operating AI/ML Workloads on Kubernetes: A Headlamp Plugin for Kubeflow" url: https://daily.dev/posts/operating-ai-ml-workloads-on-kubernetes-a-headlamp-plugin-for-kubeflow-9u7uh7oeh source_url: https://kubernetes.io/blog/2026/07/13/introducing-headlamp-plugin-for-kubeflow type: article source: "Kubernetes" published: 2026-07-14T00:50:18.162Z updated: 2026-07-14T00:51:20.034Z tags: ["machine-learning", "kubernetes"] reading_time: 5 upvotes: 18 comments: 1 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Operating AI/ML Workloads on Kubernetes: A Headlamp Plugin for Kubeflow **[Kubernetes](https://daily.dev/sources/k8s)** · 5 min read · 18 upvotes · 1 comments ## Summary The Headlamp Kubeflow plugin is a new Kubernetes UI extension that surfaces Kubeflow's custom resources (Notebooks, Pipelines, Katib, Training, Spark) directly inside Headlamp, a general-purpose Kubernetes web UI. It addresses a common pain point for cluster operators and SREs who must switch between ML-specific dashboards and kubectl to diagnose issues at the Pod level. The plugin reads directly from the Kubernetes API server, showing Pod conditions, failure reasons, resource states, and cross-namespace views without requiring the Kubeflow backend services to be running. It also provides a graph map of ML resources with owner-reference edges. The post frames this as a reusable pattern for any CRD-heavy platform. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community discussion Top comments from developers on daily.dev. **@kartiknvj** · 0 upvotes > Reading straight from the API server instead of the Kubeflow backend is the smart call, because the moment you most need to debug a pipeline is usually when a controller has already fallen over. The owner-reference graph view should cut a lot of the guesswork when a Katib trial fails and you cannot tell if it was the Pod, the resource quota, or the CRD reconcile loop. I would want this to expose the last training-job exit reason inline so I am not jumping to kubectl for every failure. ## Similar posts on daily.dev - [Introducing the Cluster API plugin for Headlamp](https://daily.dev/posts/introducing-the-cluster-api-plugin-for-headlamp-hcvpsyaur) · Kubernetes · 3 upvotes · 0 comments - [From Kubernetes Dashboard to Headlamp: Understanding the Transition](https://daily.dev/posts/from-kubernetes-dashboard-to-headlamp-understanding-the-transition-nusab1jrn) · Kubernetes · 16 upvotes · 0 comments - [Inspect Volcano workloads faster with Headlamp](https://daily.dev/posts/inspect-volcano-workloads-faster-with-headlamp-yutkvfhwm) · Kubernetes · 3 upvotes · 0 comments --- Tags: [#machine-learning](https://daily.dev/tags/machine-learning), [#kubernetes](https://daily.dev/tags/kubernetes) [View this post on daily.dev](https://daily.dev/posts/operating-ai-ml-workloads-on-kubernetes-a-headlamp-plugin-for-kubeflow-9u7uh7oeh)