Deploy Headlamp on the dogfooding cluster?

[vdemeester]

Deploy Headlamp on the dogfooding cluster?

Hey folks 👋

I've been experimenting with Headlamp — a Kubernetes dashboard from the kubernetes-sigs project — and I'm wondering if it'd be worth deploying it on the OCI dogfooding cluster alongside the existing Tekton Dashboard.

Why?

We already have the Tekton Dashboard for pipeline-specific visibility (TaskRuns, PipelineRuns, logs), but we don't have a general-purpose cluster dashboard. When debugging infra issues — node health, resource usage, RBAC problems, storage, networking — the only option today is kubectl access, which not everyone has or wants to set up.

Headlamp would fill that gap by providing:

• General cluster visibility — nodes, deployments, namespaces, RBAC, storage, events — things the Tekton Dashboard intentionally doesn't cover
• Resource metrics — CPU/memory usage across nodes and pods (with metrics-server)
• A plugin system — Headlamp supports plugins, which could eventually surface Tekton-specific views alongside general K8s resources
• Low barrier to entry — maintainers could inspect cluster state from a browser without needing direct kubectl access

Why Headlamp specifically?

• It's a kubernetes-sigs project, so it aligns well with the CNCF ecosystem we're part of
• Single Helm chart deployment — we already have ingress-nginx, cert-manager, and ArgoCD on the cluster, so adding it would be straightforward
• Lightweight and actively maintained
• Read-only by default, with token-based auth for write operations
• Cloud-agnostic — if we ever need to move clouds again, Headlamp comes with us. OKE does offer a Kubernetes Dashboard as an optional add-on, but it's only available on enhanced (paid) clusters, Oracle doesn't recommend it for production due to limited auth support, and it ties us to OCI
• Plugin ecosystem — @gattytto has already been experimenting with Headlamp plugins (e.g. a Calico plugin, demo) and has an open PR upstream. A Tekton-specific plugin could be a natural next step

What it would look like

Deployment-wise, it'd be another entry in the ArgoCD tekton-services ApplicationSet (or a standalone Application), exposed via ingress at something like headlamp.infra.tekton.dev. Auth would go through the existing GitHub OAuth / Dex setup, scoped to a small set of cluster admins/maintainers — this isn't meant to be a public-facing dashboard.

I tested it locally on a kind cluster with Tekton Pipelines installed and it works well out of the box — TaskRuns, PipelineRuns, pods, logs, events all visible alongside the usual K8s resources.

Not a replacement

To be clear — this wouldn't replace the Tekton Dashboard. They serve different purposes:

• Tekton Dashboard is purpose-built for Tekton workflows and publicly available to all contributors
• Headlamp would be a general Kubernetes dashboard, restricted to maintainers only, for cluster-level debugging and visibility

They complement each other — different audiences, different scope.

Questions for the community

• Is there interest in having general cluster visibility on the dogfooding cluster?
• Any concerns about exposing cluster state via a web UI (access would be restricted to admins/maintainers)?
• Would folks prefer a different dashboard, or is Headlamp a good fit?
• Should we scope it to specific namespaces (like we do with the Tekton Dashboard) or give it broader read-only access?

Happy to put together a PR to tektoncd/infra if there's interest. Would love to hear what people think!

[vdemeester]

CC @gattytto

[gattytto]

Thank you so much for the mention and brief explaination @vdemeester I'm honored, the PR had to be redone a few times to comply with linux foundation signing requirements and atomic commit.

I'll be glad to showcase the status of the tekton plugin with you all in the next community call :D

Here's a few more pros that come from using Headlamp+Tekton:

• Headlamp was back then the "kubernetes-dashboard", it means a very mature project.
• headlamp can connect to multiple cluters simultaneously, perfect for E2E
• It also has a graphmap horizontally left to right which is perfect for timeline looking disposition of tasks and their runs

Security concerns:

• headlamp does not expose apiserver port, it still requires a valid ingress, so it's not a huge attack vector.
• The service account as a first citizen: this is something headlamp is bringing more to the conversation generally, I haven't tested finegrained read-only namespace-restricted serviceaccounts usage in headlamp but design-wise I don't see why it wouldn't work. So having an oauth2 proxy that generates and populates the accesstoken cookie for a user would be a very simple solution to a keycloack-backed user/password login loop.

Inter-operability:
The biggest benefit comes with the possibility to mix tekton resources and other projects resources with which they could interact. For instance: applying labels to a pipeline or pipelinerun to have labels put in the final raskrun pod to apply calico network policies.

[gattytto]

https://github.com/gattytto/headlamp_tekton is the repo for the plugin