Table of Contents
Headlamp is an open source web UI for Kubernetes created by the team at Kinvolk, which was recently acquired by Microsoft. It’s a great-looking alternative to the built-in Kubernetes Dashboard. You can check out the GitHub repository here.
Installation
Most of the tools in this space either provide a local app that connects to your Kubernetes cluster or a web UI that runs in the cluster itself. One of the super cool things about Headlamp is that you can use it both ways. There’s a desktop app that you can install locally. It runs on Linux, Mac, and Windows, and the installation doc is very clear. Or, if your team likes Headlamp enough, you can run it in your clusters and folks can connect to it using their web browsers.
I installed the desktop version on my M1 MacBook Pro, and it worked great.
Headlamp detects the clusters and contexts in your kubeconfig. It’s straightforward to choose a cluster to work with.
Authentication
I expected that I would be able to authenticate with my user account in the Kubernetes cluster. I was using Google Kubernetes Engine (GKE) and had already authenticated with the gcloud CLI. But Headlamp seems to want the user to authenticate with either a system account in the Kubernetes cluster or OpenID Connect (OIDC).
I went the service account route and used the instructions in the Headlamp docs. I created a service account and added the associated token to Headlamp. The instructions were straightforward, and it was pretty easy to set up. I was left a little confused, though. Service accounts are generally used for things inside a cluster, so perhaps this option is more intended for teams running Headlamp in their clusters. It was odd to me that I’d use a service account to auth from a desktop application. I would have liked more context in the docs about why that is a recommended path.
Cluster View
I was able to view metrics from my GKE cluster without any additional setup. The default cluster view shows some basic metrics and a list of recent events, which is very handy. In the example below, I had a pod that couldn’t deploy, and by mousing over the entry in the events list I was able to see the cause.
Viewing and Editing Objects
Viewing Kubernetes objects with Headlamp is excellent. The UI is very clean and functional. There’s a mix of metrics and lists of objects on the pages, and I appreciate having different ways to parse the state of the cluster visually. It feels like there was a lot of attention to detail in the design.
Headlamp is a read-write interface to the objects in your Kubernetes cluster. As discussed in the previous post about Lens, editing objects manually is unacceptable for many teams. If your team uses a GitOps workflow or other automation to manage your cluster, you’re not going to want out-of-band changes to be made through a tool like Headlamp. Most people operating production Kubernetes clusters will regard making those kinds of changes a huge antipattern. However, if you’re operating your own local clusters, like for POCs or other non-production work, it might be very convenient to edit objects using Headlamp.
Clicking on an object in the UI takes you to a page with an overview of its state. For example, in the case of a deployment, things like the annotations, the update strategy, and the selector are exposed there.
Clicking the pencil icon in the upper right of that screen takes you into edit mode.
When I first tried this, I waited a while and objects didn’t seem to load for me, but clicking the button to use the minimal editor worked. To edit an object you make changes to the YAML and then hit the Save & Apply link in the bottom right of the window to apply them.
One great touch is the documentation tab.
It’s great to have the docs for the object right there, and I think clicking around and looking at those docs could be a good way for someone to learn more about Kubernetes.
As was mentioned earlier, most teams won’t want users making changes to objects with Headlamp. When it comes to editing objects in Headlamp, though, it’s important to remember that a user could make those same changes using kubectl. As always, cluster administrators must use tools like RBAC and admission control to prevent people from making the kind of out-of-band changes we discussed earlier, especially in shared clusters.
Plugins
One thing I almost always look at when evaluating tools is how extensible they are. Most teams end up in situations where they have a need outside of what the people who built the tool anticipated, so it’s essential to be able to make customizations. Headlamp has a plugin system meant to “allow vendors to build and deploy Headlamp with extra functionality without having to maintain a fork of the project.”
There’s a great guide to Headamp plugins in the documentation, including writing, building, and shipping them. Headlamp plugins are written in JavaScript, which isn’t a language that most platform engineers specialize in. But there’s a lot of great information out there on how to write JavaScript, and you likely have coworkers who use it a lot.
Conclusion
I think Headlamp is one of the more capable Kubernetes dashboards that I’ve seen. The design is very slick, and I love the idea that I could choose to run it in my clusters or as a desktop app. That kind of flexibility is great.
The recommended authentication path is my main complaint. Setting up service accounts or OIDC is something I’d rather not do for my local clusters, and I’m not convinced that using service accounts outside of the cluster is a great idea. But if I were using Headlamp with production clusters, I’d likely set up OIDC, and it would be fine. Headlamp also seems to perform well, and it felt a little snapper than Lens.
If you are looking for a Kubernetes dashboard, Headlamp should be on the list of tools you evaluate.
