 Hi, my name is Joakim. I'm a software engineering manager at Microsoft. I'm here to talk about Hedlem, an extensible Kubernetes UI that you can use to create custom user experiences for your own tools. So I thought of starting by having a use case here. So let's say you have a tool in Kubernetes. Maybe it works by having a custom resource to deliver some custom behavior. And let's say that if users want to change that, of course they have to go to the cluster and edit the YAML and things happen. So a much easier way would be if you could deliver something a bit easier. So maybe a button where users click and in the background it does those changes so they don't have to exactly know what to change. So in this case, if you want to do something like that, there are of course many options. So one of them would be to have a QPCDL plugin. And if you create that, although that's of course nice, it's a common line tool again. So it still requires some level or some knowledge of what the user needs to do to be productive with it. On the other hand, probably a nicer option, especially for novice users, would be to have a graphical user application or maybe a web app that is run and has a nice UI for the user. So if you want to do this, of course this requires maintaining an entire app. You have to create the app, you have to implement the app, run the test and all that. And you have to implement a lot of the functionality that is common to Kubernetes anyway. So probably you want to list the pause or you want to of course get the custom resource for the user to edit. And of course this also requires promoting the app itself. It's a whole project in itself with a lot of the base where a lot of the base is common to other apps doing similar things. So this is one of the reasons why we created Headlamp. Let's look more into it. So Headlamp is a Kubernetes UI like I mentioned. In this case it's also a vendor independent Kubernetes UI or generic. So we don't make it work only with one flavor of Kubernetes. It's not targeting any specific flavor of Kubernetes. Some UIs you can run in the cluster, others you can run as desktop apps. We wanted it to be flexible and supporting different use cases. So we allow both. You can definitely run it in the cluster or we have different builds for different flavors of desktops. In this case Linux, Mac and Windows. Some UIs also require certain permissions to run. And this can be a sensitive topic because it touches security. So in this case we think it's not a UI that should have the permissions. It's the user. So if a user is running with a service account, for example, Headlamp uses that and will check what can be done through our bag. And this means that the UI also reflects the user's role. So for example if the user cannot update or delete a resource, the UI does not show any edit or delete buttons because that makes no sense. So the idea is that the UI adapts to what the user can do. Yeah, so it's of course 100% open source. We developed it in the open. And very important, it's accessible by using what we call front end plugins. And we'll dive deeper into that. Yeah. Of course, as I said, you can run it in clusters. So there is a container image that we publish officially. And we have the official builds for desktop as well. And in this case, of course, Big Linux, we have a variety of formats in there. Flatback, Davian and Tarpaul, for example. With the four windows, we do have it published to Wingat and Chocolatey. So it's very easy to just run the commands, install and update Headlamp. And kind of the same for Mac with homebrew, right? Now, just quickly about the architecture. There's a lot of text in this slide, but I'm just going to go quickly through it. Like many web applications, Headlamp has a backend and a front end. The backend is written in Go. It's the one that, for example, if you're running as a desktop app, it's the one that reads the Kube config from the user to tell, hey, we got this cluster going on in this machine. It has some other functionality, for example, for running port forwarding and all that. But it's actually a very small part of the whole project. So most of the logic is in the front end. And in this case, the front end is written in TypeScript. Like I said, most of the logic is in the front end and even the logic that concerns Kubernetes. So when we list resources in Kubernetes, actually it's the front end that prepares that API call, sends it to the backend, the backend knows where to redirect and get the response back. But I'm going to show a diagram about that. In the front end, of course, since we support so many different use cases or platforms, we have some flags that tells us, okay, this is running as a desktop app. So maybe do not enable this feature or enable this other feature. Sometimes that's necessary. Another layer here is the application itself. So it's, in this case, an electron application. We write it with TypeScript. Yeah, it's just another layer we have. But basically, the UI is the same. So what you get in the web app is pretty much what you get in the application, in the desktop application itself. And yes, the other big layer is the plugins layer. So in this case, like I said, these are what we call it front end plugins. So they're basically JavaScript bundles. They're written with TypeScript. Yeah. And we have some APIs for plugins to change the functionality. Not only of Headlamp, but also to make it easy for plugins to list resources and just basically interact with the community server. Yeah, so this is a very simple diagram of how Headlamp works. Let's say we have three clusters like those up there. And then the bottom area is representing what is the Headlamp application. As I said before, so the front end in the example here wants to, for example, list the pods. So it prepares the API to be sent to the Kubernetes API server. But it sends it to the backend. The backend knows which cluster to apply that call to and then sends it back to the front end. In the nature, the plugins are also connected to the backend here, even though I just said before that they are front end plugins. But the reason for this design is that it's the backend that knows which plugins are available for the user or installed in this case. This design allows us to, for example, when a user is deploying Headlamp in a shared environment like the web, for example, or running it in cluster, then it's up to the person deploying it to make sure that, okay, I'm running Headlamp and I'm providing these plugins. This is not the end user that should change the plugins or install new plugins in that case. And on the desktop side, though, of course the user can change the plugins and can install and remove, but these, of course, are still managed by the backend in this case. So this design basically allows us to have the best of, or to support these two use cases that are different. So going back again to the initial use case or question, how do you deliver a nice UX for your application? You make a Headlamp plugin, of course. And why would that be? Because the base functionality for what you need from Kubernetes is already there. The whole UI has customizable sections, and then I also wrote there fully custom UI sections, meaning that when you customize, for example, a section, it's not just that you can change the label of this one button. Usually we say, okay, you can deliver a component here in the UI and what the component does or what it looks like, it's up to you. We have some components, of course, to make things look consistent, but the plugins have a lot of freedom in that regard. Yeah, there is a library, like I said, to just get the Kubernetes functionality, for example, listing resources, deleting resources and all that. And even the branding from Headlamp is customizable, right? The plugins have access to, for example, changing the logo of Headlamp. So this allows, I guess, vendors to deliver something that is very customized to them. And to manage all this, we have one script called Headlamp plugin. This is how you create and run and update plugins in Headlamp. So we think this approach is so powerful that we started using it ourselves. Initially, Headlamp was that basic functionality that I talked about. We have the very common functionality to any UI you expect to have in Kubernetes. So listing workloads, getting the description of the workloads, maybe deleting the workloads, that's all in there. But we also wanted to provide our own view of what a great user experience around Kubernetes would be. So earlier this year, we started shipping Headlamp also with our own plugins, official plugins. So now we have these two concepts. Let me just go to the next slide. We have these two concepts, which is Headlamp-based and Headlamp. So Headlamp-based, like I said, has no plugins. It ships without any, there are no plugins in it. There's nothing that you need to install in the cluster for it to work. Whereas Headlamp itself builds on top of that base and ships with plugins. So essentially, it's the Headlamp-based plus some plugins we curate. And this may require some things to be run in the cluster. So if we have, for example, a Prometheus plugin, so it supplies nice charts powered by Prometheus, obviously you have to have Prometheus run, right? We believe that this way we still allow anyone that does not want this extra functionality to have still the base for creating a great user experience on top of Headlamp. And at the same time, we can also deliver something with a bit more value or an advanced user experience to our users. So in the screenshot here, that's one of the plugins we have. That's the app catalog. And you wouldn't find it just in the Headlamp vanilla or base. So in terms of development and how to develop a plugin, the plugins are independent from Headlamp. So they have to be developed outside of the Headlamp core, obviously. So you don't have to fork Headlamp and keep developing plugins inside. That's the whole idea, right? To have things separated. Yeah, and like I said, we have one NPM package called Headlamp plugin that can be used to create or to bootstrap a plugin. But it also is how you can build the plugin and also how you update it. So it manages some of the dependencies that the plugins have. Yeah, and soon we'll have an even easier way to do this by using a VS Code plugin or extension. Yeah, so Headlamp itself uses Material UI and React and other dependencies. So that's all part of Headlamp itself. And since those are common dependencies, even if you are importing from Material UI or importing from React, when using the Headlamp plugin script to create the bundle, things are configured so that only the dependencies that are not common will be shipped with the bundle. So we can save some of the size in the bundle, right? Yeah, and on top of that, we have also as part of the Headlamp repo. In this case, we have a plugin in samples folder and we have all the functionality that we expose to plugins. Let's say, okay, now we're allowed to change the logo. So we create an example plugin showcasing that new functionality. And as for the official plugins that I said that Headlamp builds with, of course, those are just like Headlamp, they're completely open source and they're developed inside this different repo called plugins but under the same organization in GitHub. All right, so let's look at the demo now and let me switch to it. Okay, I got Headlamp running from source here. As you can see, it's running in the browser now and this is the home view. I've got three clusters configured. So let's quickly go into Minicube. And yeah, not a lot going on because this is a Minicube that I started like a couple of hours ago. But yeah, just to show you that this is pretty much the UI that you can expect from a Kubernetes UI. You can navigate to the different sources and types of sources, right? You can select it here and check configuration. For example, let's check this config map. Yeah, but to show you a little bit of the philosophy in Headlamp is that the UI should adapt to the cluster and the users and not the other way around. So in this case, in this Minicube cluster, the metric server is not installed so we cannot get the usage metrics. So all we display here is what's available and we have some aid here saying, yeah, install the metric server to get usage data. However, if we go to a cluster that conveniently has the metric server installed let me jump to this one, which is an AKS cluster. So this one has the metrics available and the UI adapt to show it here, right? So let me show you also what I mentioned before about the roles. So in this cluster, my role can pretty much do anything. So I have all the possibilities here and that's why I'm seeing like an added button and a delete button. But if I could not delete this resource, for example, then the delete button would not be shown. Also for any function that is kind of destructive, we have a grace period. So in this case, we can cancel this action that I just started. Yeah, and let me go here to another section to show you that again, all that you've been seeing is pretty much the headland base. And if I go to, for example, one of the pods, let's check this one. Yeah, so in here, you know, in the pod view, you can see the description, obviously, of this pod. I can check the logs. I can exact into the pod or attach to it or delete it. But this also shows you, well, the first time we're showing something about the plugins here. So this chart, this promissive power chart is actually a plugin. It's running from a plugin even though it's completely or seamlessly integrated in the UI. That's the whole idea. So in this case, promissive is something that is needed to install. And so we have this capability as a plugin that we ship in headland, but not as part of the base. So in fact, if we, you know, the plugins, they, of course, belong to headland as an application. And that means that if we go to a different cluster, the plugin is still there. So let's go to Minikube just quickly and check one of the pods or even this deployment. So in here, I don't have promissives installed. And therefore, the plugin is still running, but it knows that something is missing. So there's some guidance for the user. All right. Yeah, let's... So many parts here in the UI, plugins can customize them. So we offer the functions to do that. And I wanted to show you just quickly how it looks like. So let me switch back to Visual Studio and let's go to this sidebar plugin that I have here. So this is one of the example plugins that we have. And after you run npm install, because again, this is an npm, this is a node module. You just run npm install. And then after that, like any module that you develop, you can just run npm start. I can take a while for headland plugin to check if it's up to date, just because since headland plugin is the one that also keeps the plugins up to date, we want to make sure that it's always the latest version in case some things need to be updated. So right now it says that it's already copied the bundle to its correct location. Let's go back here. And as you can see here, the sidebar already reflects some changes here. So it was already there because it updated while we were looking at VS Code. But every time there is a change to the plugin or a new plugin is installed or so, then you want just refreshes to reflect that. So this sidebar is just an example, this funny one that shows how dynamic it is. So if I click here, it just goes away and selects whatever was before. But as you can see, it's not only just the sidebar that is changed, but actually now we have a new route that was registered by this plugin. So just to show you quickly how the development looks like, let's go back to VS Code. And as you saw here, we have embedded your feedback forms here. That's this very string right here. So we can, you know, let's change it what you want here. Let's make it expressive. Now we save and I'll go back and I will not touch anything. Just to show you that, you know, after I guess some time, it just refreshes by itself and loads the views. So this allows us to continuously, you know, develop and see the changes reflected by the way. Yeah, so this should give you an idea of how seamlessly integrated what the plugins do is in the Headlamp UI. I can also, you know, show you just quickly. Let me, let's stop the this version from source one second. I'll stop it and I'll run the Headlamp application. So now the Headlamp application is running as a desktop application. And as you can see, there's some slides and make it a little bit smaller. Just so you can see that there's some some changes right now. Since this is the desktop application and it's the user that is running the application that is in charge of updating it. It does check for updates. That's different from the the other version where we, you know, if you're deploying it for other users, then you're the one that should be checking for updates. Yeah, in this version, we also have an extra button here because we allow to load clusters. And let me make it bigger. If we go now to one of the of the clusters, you can see that we have this apps sidebar item integrated. And this is another plugin that is officially shipped. So in this case, this is a plugin that displays help charts from the artifact hub and allows us to very quickly install one of the other help charts. Yeah, and even though the menus here are part of the application itself, these are also changeable by plugins, for example. So hopefully this gives you an idea of, you know, the capabilities that plugins have towards changing headlamp and allowing for custom experiences to be developed on top of it. So, yeah, so going back, you know, let me just that was the demo. Let me now mention a little bit about the community. So, as mentioned, we're an open source project. And we besides the GitHub, we also interact with the community via Slack, in this case, the Kubernetes Slack. So yeah, please join us if you want it in the headlamp channel in there. And every time we have news or new release published, we also publish it to social media so you can follow us there. I also wanted to share this screenshot here because this is a screenshot of a headlamp plugin that is developed by an external, by a team that is external to the headlamp core developers just to show something that is kind of a complex application, but also how well integrated it is in headlamp itself when the plugin is available is enabled, of course. Yeah, so this is a good example, I think. And that's all I've got. I hope that I was able to communicate what headlamp can do for you as an advanced Kubernetes UI, but also as a way for you to be able to build your own Kubernetes custom user experiences. So thank you very much and see you next time.