Moving Kubernetes Dashboard workflows to Headlamp

The Kubernetes project has published guidance on the transition from Dashboard to Headlamp. Dashboard is now archived. The article maps familiar resource-browsing and editing workflows to Headlamp, then explains its multi-cluster support and optional extensions. It explicitly leaves a detailed installation walkthrough for a forthcoming guide.

I would begin this migration by listing the tasks people use Dashboard to perform. Replacing a visual interface needs evidence that the intended users can still inspect the resources relevant to their work. It also needs a decision about which interactive mutations belong in the new interface. Installing a replacement does not settle those access and workflow questions.

My Kubernetes perspective comes from eight years of use, including Talos clusters with Cilium and GitOps. I value the API machinery and controller model. A useful graphical interface should help me understand the resources and controllers involved in a change. I would assess Headlamp against that requirement, with particular attention to whether a view explains the ownership of the objects it presents.

Existing authorization remains relevant

The transition article says that Headlamp follows standard Kubernetes authentication and RBAC. It supports manifest inspection and editing according to the user's permissions. It also exposes actions such as deletion and scaling. Those capabilities make the effective user identity a central part of migration testing.

The Headlamp README available before this announcement describes controls that reflect user roles. It warns that a token with limited permissions may not provide a complete resource view. I would preserve that explanation during onboarding. An incomplete list can be the expected consequence of a restricted identity, so it needs to be distinguished from a failed installation.

I would test with the identities that users will actually use. A demonstration under an administrator's credentials cannot establish the experience of someone with access to one namespace. The acceptance checks should include the resources that person must read and the mutations they must be prevented from making. That makes the interface migration a review of existing access expectations without assuming that every user should see everything.

The article says existing access models carry over in most cases. I would retain that qualification in the rollout plan. Authentication details still need verification for the selected deployment mode. The migration record should identify how users connect and which Kubernetes identity each path uses before production users depend on it.

Multi-cluster access needs clear operating context

Headlamp can present multiple clusters through one interface. The transition article contrasts this with Dashboard's single-cluster model. This is useful when related operational work spans environments, but I would evaluate how users identify their target cluster before taking an action. The test should reflect ordinary inspection and mutation workflows with similarly named resources.

I would include a scenario where a user inspects an application in one cluster and then moves to another. The user should be able to establish which cluster and namespace the current view concerns. That is an acceptance criterion I would apply to any multi-cluster interface. The fact that the application can connect to several clusters does not establish that its presentation meets the operating procedure.

The project supports an in-cluster deployment and a desktop application. The announcement describes the former as appropriate for centrally managed shared use. Desktop users can connect through an existing kubeconfig without installing anything in the cluster. These choices let an organization evaluate the UI without assuming that every user needs the same deployment model.

I would select a mode according to who owns configuration and access. A centrally operated UI needs a clear maintenance owner. A desktop deployment needs a documented expectation for the user's local configuration. Both should go through the same resource-access checks, because the relevant requirement is what the user can do through the chosen connection.

Application context is an optional view

The announcement describes Projects as an application-oriented grouping of related resources. It says Projects use native concepts including namespaces, labels, and RBAC. They do not require users to abandon individual resource views. I would evaluate that grouping with an application whose resource relationships are already understood.

A grouped view should help a user identify which workloads and supporting objects belong together. I would check it against the application's declared configuration and investigate unexpected omissions. The visual grouping should have an explanation that survives a change in labels or namespace layout. Otherwise it risks becoming another undocumented representation of application ownership.

This matters to my preference for Kubernetes API machinery over any particular built-in workload type. Platforms often need to understand relationships among custom resources as well as ordinary pods. Headlamp's extension model is relevant here. The README identifies plugins as a core capability, and the transition article says platform teams can build their own integrations.

GitOps needs an explicit editing policy

The transition article uses the Flux plugin as an example of bringing GitOps context into the interface. It describes viewing application state alongside the resources Flux manages. I would evaluate whether that makes the source of a resource's configuration clear enough for the users responsible for it. A resource editor and a reconciliation workflow need an agreed operating policy.

For my use, I would document when an interactive edit is appropriate and where its lasting configuration belongs. This is a policy decision I would make during migration, because the new interface supports changes as well as inspection. I would also ask application owners to identify which troubleshooting tasks need only read access. That can keep onboarding focused on the actual workflow requirements.

Plugins are optional. I would begin with the workflows needed to replace Dashboard and add extensions after evaluating their purpose. The migration does not require adopting every capability discussed in the announcement. Each extension should have an owner who can explain the task it supports and verify that it works under the intended permissions.

Before retiring the old access path, I would have representative users perform their documented tasks through the selected Headlamp deployment. The record should identify any changed authentication steps and any deliberate change in editing policy. It should also state which optional views and plugins are part of the supported setup, so that later troubleshooting starts from a known configuration.