Reading materials on Kubernetes, you probably have repeatedly come across examples of various kubectl commands and tricky YAML configs. For people who are well versed in K8s, this approach, no doubt, does not cause any rejection. But in the age of ubiquity of web interfaces, it cannot be called friendly to ordinary users. It complicates the learning process for newbies and acts as a barrier for those who are not very familiar with Kubernetes.
Of course, there are various GUIs for K8s, including the Kubernetes Dashboard , which is part of the Kubernetes upstream itself. (Note translation: We have already talked about many of the existing solutions in this comparison .) However, exploring all the variety of options, we could not find a solution that would completely suit us. I wanted the interface:
- was 100% Open Source;
- actively supported by the community;
- was universal in the sense that it was not tied to a particular vendor's Kubernetes distribution;
- was modular and extensible;
- had a neat and modern appearance;
- was implemented on a stack familiar to our developers (Go, JavaScript / TypeScript, React);
- was interactive (i.e., not only collected data, but also allowed certain actions with the cluster);
- supported multi-cluster mode.
Despite the rather rich choice, none of the solutions we tested met all the criteria listed above (or could serve as a good basis for creating a new solution). Therefore, according to a time-honored tradition, we decided to make it ourselves ...
Introducing Headlamp
Today, I am proud to announce the wide availability of a new UI for Kubernetes called Headlamp .
Headlamp is a universal and extensible user interface for Kubernetes that meets the criteria above. Of course, being the brainchild of Kinvolk, it is 100% Open Source. We hope that many Kubernetes community members will not only appreciate Headlamp, but will also contribute to the project.
Let's take a quick look at its main characteristics.
Extensible UI
We strive to ensure that Headlamp is suitable for as many use cases as possible. The target audience of the project is not only newcomers to Kubernetes, but also experienced administrators and K8s vendors with very different needs. Often (especially for UI projects) such a variety of use cases is implemented by creating a large number of forks, each of which is maintained by its own downstream team. But keeping forks up-to-date is more difficult the larger the changes in them.
The plugin system solves this problem. That is why Headlamp supports out-of-tree UI plugins. They are JavaScript files loaded by the Headlamp backend and passed to the client, which dynamically loads them.
This approach opens up great opportunities for innovation, contributing to the emergence of many new features. For example, it is easy to make a button in the pod details block that will redirect the user to a service showing the financial cost of that pod.
The Headlamp plugin mechanism opens up great opportunities for the community. And we are ready to cooperate with everyone who wants to participate in the development of new plugins for Headlamp, and to develop the mechanism itself, adapting it for new scenarios of use.
Traceloop
To demonstrate the full power of the plugin mechanism (and the tool itself), we developed a Headlamp plugin for the traceloop gadget , which is part of the Inspektor Gadget project (a set of tools for inspecting and debugging applications in Kubernetes - approx. Transl.) .
After installing the Inspektor Gadget and enabling the traceloop gadget, it starts writing all system calls from the pod to a circular buffer. This buffer can be viewed in real time while the pod is running. In other words, traceloop gives you a peek into what the pod is doing right now. In addition, the data in the buffer is saved for pods that have exited. This way you can determine the cause of the failure after it has occurred - a kind of "black box" for Kubernetes applications.
Selective UI
The problem with many CRUD user interfaces is that they know nothing about the internal organization of access control. For example, the presence of buttons for editing / deleting is confusing to the user if they do not actually have permission to modify the resource. Headlamp checks the RBAC settings of Kubernetes and only shows the controls for the actions that are available to the user. For example, if the user does not have the right to edit the resource, then the “edit” button will not be shown.
All this has an extremely beneficial effect on the user experience: after all, the operator immediately sees what actions are available to him, taking into account the current rights. This is great for situations where time-limited permissions are granted (such as temporary permission to delete a resource).
Available buttons for actions with the pod when the user has edit / delete rights
Available buttons when the user does not have edit / delete rights
Design / User Interface
We aimed to make the Headlamp design as laconic and modern as possible, while adhering to the "traditional" Kubernetes UI or dashboard style. For example, we are convinced that the familiar tabular view is great for work, and we hope that other types of visualization (for example, the presentation of a cluster in the form of graphs) can be implemented using plugins.
The frontend is implemented in React with the Material UI library (it is modern, neat and supported by a large user community). Plus, it is included in the technological stack of our other project - Nebraska (update manager for Flatcar Container Linux - approx. Transl.), allowing us to share experiences and resources and ensuring a consistent UI across all products.
Locally or in a cluster
Most Kubernetes UIs fall into two groups: remote (the backend is often in a cluster) like Kubernetes Dashboard or local (the application is installed on the computer) like Octant from VMware.
Each of these approaches has advantages and disadvantages. For example, in the case of a remote application, it is very easy to share the URL with other users and implement their login via OIDC. It is available “everywhere” and is easy to keep up to date. On the contrary, in the case of the desktop version, there is no need to think about the placement of the UI. This approach provides better isolation, but it is up to the user to keep the application up to date.
With Headlamp, you no longer have to choose between these two approaches: both are supported. Headlamp can be easily clustered using our YAML files (and customizing them), or installed locally on a Linux, macOS or Windows machine.
Multi-cluster mode
Most Kubernetes deployments consist of several clusters (if only to separate dev and prod environments). Headlamp provides access to all of these clusters: the exact method depends on whether you run it locally or remotely.
When running locally, Headlamp will read the kubeconfig and display the contexts available there, allowing the user to change them if necessary, simply by setting the local environment variable to the appropriate cluster.
Multi-cluster mode is very simple: a proxy is created for each configured cluster, and requests from the UI (with calls to the Kubernetes API) are redirected to the address of the desired cluster. The K8dash project should be mentioned here, modules for managing requests / API of which we used when developing Headlamp.
This approach can also be combined with running in-cluster, however, to do so, the cluster in which the application is running will need API access to the other specified clusters.
Lokomotive Kubernetes connection
As you probably know, we also have our own Kubernetes distribution - Lokomotive . We use Headlamp at Lokomotive for its intended purpose, but we want to emphasize that these are independent and independent projects. We're not going to tie Headlamp to any K8s service provider, and we're designing it to work on any typical Kubernetes cluster.
Try Headlamp on your cluster!
It is very easy to do this: deploy deployment in your cluster and go to the corresponding address in the browser, or download and install the desktop version for Windows, macOS or Linux. Details are in the documentation .
Headlamp is a completely open source tool released under the Apache 2.0 license. As mentioned above, we made it independent from Kubernetes service providers and versatile in use (covering a large number of use cases). Today we invite everyone to take part in the development of the project! To do this, please read the relevant guidelines .
We hope you enjoy Headlamp!
PS from translator
Read also on our blog: