# Operating AI/ML Workloads on Kubernetes: A Headlamp Plugin for Kubeflow

DevFeed: [Operating AI/ML Workloads on Kubernetes: A Headlamp Plugin for Kubeflow](<https://devfeed.tech/articles/operating-ai-ml-workloads-on-kubernetes-a-headlamp-plugin-for-kubeflow-4565.md>)

Original publisher: [Read original article](<https://kubernetes.io/blog/2026/07/13/introducing-headlamp-plugin-for-kubeflow/>)

Author: Alok Dangre

Published: 2026-07-13T20:00:00Z

Content type: article

Language: en

Sources: [Kubernetes Blog](<https://devfeed.tech/sources/kubernetes-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [dashboards](<https://devfeed.tech/topics/dashboards.md>), [AI Development](<https://devfeed.tech/topics/ai-development.md>), [API](<https://devfeed.tech/topics/api.md>), [Web](<https://devfeed.tech/topics/web.md>), [data](<https://devfeed.tech/topics/data.md>)

Tags: [ai-ml](<https://devfeed.tech/tags/ai-ml.md>), [apache](<https://devfeed.tech/tags/apache.md>), [api](<https://devfeed.tech/tags/api.md>), [dashboards](<https://devfeed.tech/tags/dashboards.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [site-reliability](<https://devfeed.tech/tags/site-reliability.md>)

## AI overview

This article introduces a Headlamp plugin for Kubeflow that surfaces Kubeflow custom resources and Kubernetes-level workload information in a general-purpose Kubernetes UI. It helps operators troubleshoot notebooks, training jobs, experiments, pipelines, Pods, and related resources through the Kubernetes API.

## Source excerpt

Kubernetes has quietly become the default platform for AI and machine learning. Whether you run notebook servers for data scientists, schedule distributed training jobs, tune hyperparameters, or orchestrate multi-step ML pipelines, those workloads increasingly land on a Kubernetes cluster. Kubeflow is one of the most popular ways to assemble that stack, and it does so the Kubernetes-native way: every capability is exposed as a Custom Resource Definition (CRD). That design is a gift to cluster operators, because it means ML workloads can be observed and managed with the same primitives as everything else in the cluster. But in practice the specialized ML dashboards that ship with these platforms hide the Kubernetes layer underneath. When a notebook is stuck or a training run fails, the operator is often left dropping back to kubectl to find out what actually happened at the Pod level. This post introduces the Headlamp Kubeflow plugin, which closes that gap by surfacing Kubeflow's custom resources directly inside a general-purpose Kubernetes UI. It is a worked example of a pattern any CRD-heavy platform can follow: meet operators where they already work, and show them the cluster-level truth. Headlamp itself is an extensible 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. Why operators need a different view Purpose-built ML dashboards help data scientists submit experiments, pipelines, and notebooks. Cluster operators and site reliability engineers (SREs) troubleshoot the Kubernetes resources underneath, and they ask different questions: Why is a notebook stuck? Is it ImagePullBackOff, OOMKilled, or a Pod waiting on a PersistentVolumeClaim? Which Run resources failed recently across namespaces? Which parameter set does a Katib Experiment report as optimal? Do TrainJob resources reference the expected TrainingRuntime