Dora NodaOn June 25, 2026, the Kubernetes blog published three announcements in a single day — graphical Headlamp plugins for Cluster API, Volcano, and Knative — and followed them on July 13 with a fourth for Kubeflow. Four specialized control planes that operators previously drove through kubectl, vcctl, kn, and raw CRD YAML now render as first-class views in one browser UI. For a team running a self-hosted platform on Cluster API, that sprint quietly answers a question most small ops teams stopped asking: do we still need the hand-rolled status dashboard, or has the community finally built the operator console for us?
The short answer is that the console now exists, it is further along than its version numbers suggest, and it still is not the control plane. This post scores each plugin on what it concretely ships today, names the gaps that keep kubectl and GitOps in the loop, and maps the whole thing onto the workload a self-hosted PaaS actually cares about next: AI-agent sandboxes, eval batches, and inference endpoints running on the same Cluster API fleet as ordinary tenant apps.
The scorecard, up front
| Plugin | Announced | Current release | What you get | Verdict |
|---|---|---|---|---|
| Cluster API | Jun 25, 2026 | 0.2.0-beta | Fleet dashboard with remediation guidance, Scale actions, map view, inline Prometheus metrics | Closest to daily-driver ready |
| Volcano | Jun 25, 2026 | 0.2.0-beta | Jobs, Queues, and PodGroups views, Suspend/Resume, in-page pod logs | Best batch-debugging UI short of the CLI |
| Knative | Jun 25, 2026 | 0.3.0-beta | KService edit mode, validated traffic splits, effective autoscaler config, per-revision metrics | Most action-capable of the four |
| Kubeflow | Jul 13, 2026 | 0.2.0-alpha | Notebooks, Pipelines, Katib, Training, and Spark views via API-group discovery | Promising, still alpha — evaluate, don't depend |
Nothing here has reached 1.0, and that is the honest headline: three betas and an alpha, all built through CNCF LFX mentorship sprints rather than by the upstream projects' core teams. But every one of them graduated at least one release since its announcement post — CAPI and Volcano both moved from alpha to beta — and all four ride on Headlamp itself, which shipped v0.45.0 in August and is now the Kubernetes project's effectively anointed Dashboard successor. The direction of travel matters more than the version numbers.
Why this sprint matters now
The Kubernetes Dashboard — the generic click-around UI a generation of engineers opened every morning — stopped being maintained in January 2026 and was moved to kubernetes-retired on GitHub. No patches, no fixes. The community's replacement is Headlamp, an extensible Kubernetes SIG UI project, and on the same July 13 that brought the Kubeflow plugin, kubernetes.io published an official Dashboard-to-Headlamp migration guide. The platform is telling you where to go.
That context reframes the plugin sprint. As one July analysis put it, Kubernetes is no longer one operational surface — it is a pile of specialized control planes sharing an API server, and the generic "here are the pods" dashboard cannot answer "why is this batch workload waiting for capacity, why did this serverless revision receive traffic, and which team may change the thing that fixes it?" Each plugin in this sprint is a domain-specific workbench for one of those control planes, installable from Headlamp's built-in Plugin Catalog, RBAC-gated, and consistent with Headlamp's native views, map graph, and multi-cluster mode. The question is no longer whether to adopt Headlamp — the old Dashboard made that decision for you — but whether these young plugins are good enough to displace the per-project CLIs and the bespoke status pages for day-to-day operations.
What each plugin actually gives you
Cluster API: the fleet view. The CAPI plugin adds a dedicated section with list and detail views for Clusters, MachineDeployments, MachineSets, Machines, and MachinePools, plus a centralized dashboard summarizing resource health, active condition issues, provider information, and — notably — remediation guidance with diagnostic commands when something is degraded. Two capabilities stand out for fleet operators: a built-in Scale action on MachineDeployments and MachineSets (with guidance to scale at the Cluster level for topology-managed clusters), and inline Prometheus metrics on resource detail pages when the Headlamp Prometheus plugin is installed, so live performance data sits next to status conditions instead of in a separate Grafana tab. It supports both v1beta1 and v1beta2 CAPI APIs and renders ownership hierarchies in Headlamp's map view. If you run Cluster API on owned hardware, this is the plugin to install first.
Volcano: the batch cockpit. The Volcano plugin brings the scheduler's three core resources — Jobs, Queues, PodGroups — into one sidebar section with the relationships drawn for you. The Job detail page is the center of the experience: task details, pod status, linked Queue and PodGroup, conditions, events, Suspend and Resume actions, and pod logs (single-pod or all-pods, with container selection and follow) without leaving the page. The Queue view surfaces capacity, allocated, deserved, and guaranteed resources plus child queues — the numbers that answer "why is my job not scheduling?" — and the PodGroup view exposes gang-scheduling progress and minimum-resource blockers directly. For anyone running gang-scheduled work, this replaces a loop of vcctl and kubectl describe across four resource types with one screen and a relationship map.
Knative: the serverless workbench. The Knative plugin is arguably the most action-capable of the four. KServices get a full detail view with an Edit Mode toggle for live changes to traffic splits and autoscaling annotations, plus header actions (view YAML, logs, redeploy, restart pods) gated by your RBAC permissions. The traffic-splitting view shows per-revision traffic, readiness, and tags with inline editing that validates splits sum to 100% and tags stay unique before saving — canary validation without touching YAML. Particularly thoughtful is the autoscaling view, which reads config-autoscaler and config-defaults to show each KService's effective configuration and whether a value is explicit or a cluster-default fallback. Paired with the Prometheus plugin, KService and Revision pages render request-rate, latency, and utilization graphs, including a per-revision request-rate breakdown for validating a split in progress.
Kubeflow: the ML layer, read from the API server. The Kubeflow plugin covers five component families — Notebooks, Pipelines, Katib, Training (TrainJob/TrainingRuntime), and Spark — and discovers which API groups are actually installed, showing only the matching sections. Its sharpest design decision is reading Kubernetes API resources directly instead of querying the Kubeflow Pipelines API service or backend database, so stored pipeline state stays inspectable even when that service is down; the Pipeline view even diffs the latest and previous PipelineVersion specs side by side. Notebook views consolidate pod conditions, GPU requests and limits, volume mounts, secret-backed env vars, sidecars, and tolerations — information that otherwise costs several kubectl describe invocations. The framing generalizes: any CRD-heavy platform can ship a Headlamp plugin that meets operators where they already work instead of building a parallel dashboard that hides the cluster layer.
The honest gaps
Enthusiasm first, then the invoice. None of these plugins is 1.0: Knative leads at 0.3.0-beta, CAPI and Volcano sit at 0.2.0-beta, and Kubeflow is still 0.2.0-alpha. Volcano's own announcement lists Prometheus integration and richer scheduling insights as future work — the one plugin in the set that cannot yet overlay metrics on its views. All four were built through LFX mentorship terms, which means community-maintained code under SIG UI governance rather than roadmap commitments from the Volcano, Knative, or Kubeflow core teams; follow-on mentorships (improving the CAPI and Knative plugins, adding Kubeflow coverage) are already in flight, but bus-factor realism applies.
The architectural limits matter more than the version numbers. These plugins give you interactive visibility and a growing set of mutating actions inside a single cluster context — they do not give you multi-fleet rollups, tenant-facing views, policy enforcement, or an audit trail beyond what the API server already records. Nothing here replaces GitOps as the source of truth or kubectl for automation and scripting; the Volcano authors say so explicitly. Treat Headlamp as the operator console — the place a human goes to understand and unstick things — and keep every mutation it performs reproducible from your manifests. That boundary is a feature, not a bug, as long as you draw it deliberately.
What changes for a CAPI fleet running AI-agent workloads
Here is where the sprint stops being dashboard news and becomes platform strategy. A self-hosted PaaS that wants to host AI-agent work — sandboxes, eval batches, inference endpoints — on the same Cluster API fleet as ordinary tenant apps needs exactly the workload types these plugins cover, and previously needed a separate CLI and mental model for each:
- Agent sandbox and eval batches are Volcano-shaped: gang-scheduled, queue-fairness-sensitive, competing for a shared node pool. The Queue view's deserved-versus-guaranteed accounting is the difference between guessing at contention and seeing it.
- Inference endpoints are Knative-shaped: scale-to-zero, traffic-split rollouts across revisions, autoscaling behavior that depends on cluster defaults you cannot see in the KService YAML alone. The effective-config view and per-revision metrics turn rollout validation from a log-diving exercise into a glance.
- Training and tuning jobs are Kubeflow-shaped: TrainJobs referencing TrainingRuntimes, Katib experiments with early-stopped trials, pipeline runs whose backend may be the thing that is broken. API-direct reads mean the console works during exactly the outage you built it for.
- The fleet itself is CAPI-shaped: machine rollout progress, node health, replica status, and remediation guidance in the same browser tab as the workloads.
One tab instead of kubectl plus vcctl plus kn plus the Kubeflow Central Dashboard plus whatever status page your team hand-rolled and stopped maintaining. For a small ops team, that consolidation is not convenience — it is the difference between noticing a stuck eval batch in minutes and noticing it from a tenant ticket.
Verdict: adopt as the operator console, not the control plane
Install Headlamp, open the Plugin Catalog, and add the CAPI, Volcano, Knative, and Kubeflow plugins for the components you actually run. Use them for interactive debugging, rollout validation, and queue-capacity reasoning. Keep GitOps as the source of truth, keep kubectl for automation, and do not expose plugin UIs to tenants as a status surface they can depend on. Then watch two milestones: 1.0 graduations (Knative's 0.3.0-beta suggests it gets there first) and Volcano's Prometheus integration landing, which closes the last observability gap in the set.
The old Dashboard asked "what is running in my cluster?" These plugins ask the questions a platform team actually needs answered in 2026 — why is this batch waiting, why did this revision get traffic, which machine is stuck mid-rollout — and answer them with the cluster's own API data. That is what a default operator UI looks like. The hand-rolled dashboard had a good run; it is time to retire it.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
