1:49 Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan. And today, we have an episode of Rawkode Live, where we take a look at all the latest, greatest, and best open source software helping us make cloud native and Kubernetes that little bit easier. Today is no exception. We're taking a look at Headlamp, which is a UI for Kubernetes, and I'm joined by two fantastic people from the Microsoft and Headlamp team. Hello. How are you both? Doing good. Yeah. We got a comment about the new metal vibes already. And, like, I don't often do

2:23 slightly heavier music in the intro, but I am a total new metal kid from back in the under. It's sad to think that most or not most, but there's a lot of developers today that weren't even alive during the early two thousands, and that's a that just that makes me feel so old. Anyway, don't mean to digress. Can you please both take a moment just to say hello, introduce yourself, share whatever you wish to share, and then we're gonna talk about Headlamp. Yeah. Hi. My name is Oleg. I'm a center engineer at Microsoft. I joined the Haslam team

2:53 a bit more than a year ago. I've been working on Haslam since then. Excellent. Thanks. My name is Will Case. I'm the product manager for Hedlamp. I've been on the team for just over a year now. Before that, I have a background in as a solution architect working with open source tools, primarily Kubernetes, and I'm just excited to be a part of the show today. Awesome. Well, thank you both so much for joining me. I'm very excited to show people Headlamp and get into the what's, ifs, and whys. But for anyone who is not familiar with

3:33 the project, could we just spend the next minute or two saying, what is Headlamp and who is it for? Sure. Oleg, do you want me to take that one first and you can you can follow-up? Alright. So Headlamp is an open source Kubernetes UI that you can think of it as redefining really how developers are interacting with their clusters, especially those who are new to Kubernetes. Because for all of us, we have a fair bit of experience with Kubernetes, but those first, let's say, two, three, four, five, six months were pretty intense just learning and getting up to speed. So we're

4:16 providing a smoother experience. The core of headlamp is it's fast, it's extensible, and now we even have our AI assistant, so it's now conversational. So instead of maybe having to memorize as much of our cute cuddle commands or digging through as much YAML, users can ask natural natural language questions. Things like, why is my pod crashing? Show me deployments, my namespace, create a new project, which is really an app centric view that headlamp has just put into our our alpha. And and that's the core of what we're doing. So this new assistant with that extensibility,

5:07 we're enabling that assistant to be able to interpret intent, scope, and analysis, and even helps you the feature is connecting it to some of your favorite agents so that you can do a real deep dive into some of our troubleshooting. Right? So it's built for self-service, low friction onboarding, and intelligent guidance, making it perfect for, like, your dev leads, your software engineers, and those who really need to scale up quickly and get going with Kubernetes. Awesome. Alright. Let me try and give my perspective on the history of Kubernetes UIs, and then we'll see how Headlamp kinda fits into the story.

5:57 Because I feel like, you know, I've been in Kubernetes now for ten years and, you know, people can pry keep control of my cold, dead hands. Right? But there are a lot of different ways to work with a cluster where that visualization of something just makes a lot more sense. It's gonna make things faster. So I know you you said that there's a lot of value here for the people that are still in that early journey, mid journey as well, but I I think really a strong visualization helps everybody who's working with a cluster. There was the official

6:29 Kubernetes dashboard. I don't even know if it still exists anymore, but this did ship with the Kubernetes project and, you know, allowed you to browse some of the core resource types. I think the challenge that they always had with Kubernetes is that Kubernetes is super extensible to the point where I can apply any custom resource definition to my cluster. And the way that we visualize these is is just always different. Right? It's not deterministic. There's a dynamic aspect to it. Not only that, as Kubernetes has been really bad from yesterday one as well, relationships are inherently difficult to calculate within

7:07 a Kubernetes resource graph because sometimes it's some sort of reference like a secret ref, sometimes it's just an arbitrary field because nobody really controls the CRDs except for the people that write them. And if not really well, there are some preferred ways than the core API to do some of this one. You're not bound to that as well. But I think as as the UI landscape has evolved and I think one that most people may be familiar with is a terminal based one called canines. I see a lot of people adopting this, especially when I go to conferences and

7:38 events. Everyone's always talking about canines. And it never clicked for me, and I feel like maybe I'm the problem here. But I feel that from a visual GUI aspect, there haven't been that many things after the Kubernetes dashboard and before head lamp except for maybe lens was there for a while, but then there's a whole license change with Mirantis. I don't really wanna get into the the the rumors of that and stuff, but I think it burned a lot of people the wrong way. And I see the need. I I I know why we're here. I

8:09 know what I want people to see, and I know what I want to see from this. So that's my flavor history and context of where the UI has been, and I'm sure I've missed out lots of it. So maybe you could answer two questions for me. And I know that I'm kinda waffling at you now. Right? But why is Headlamp the right choice now? And how has that journey been over the number of years that Headlamp has existed? Because it's not a new project. Right? This has been around for a number of years now. So

8:32 maybe we could just get a bit into how it started, where we are, and what it's been learning, what the learnings have been along the way. Sure. Thank you. Great question. Oleg, do wanna take that one? If not, I'll take that. Yeah. Sure. So and I might be a little biased, but I think Headlamp is currently the best UI for Kubernetes. I think the main differentiating factor between headline and the rest of the available UIs right now is how extensible it is. So you can create a plugin for anything that can be added to Kubernetes.

9:15 So like you mentioned, you can extend Kubernetes with custom resources. You can extend Headlamp with plugins. We try to make this as easy as possible for developers to create plugins to Headlamp to enable all kinds of features, customization for your dashboard, your Kubernetes UI. So I think if you're looking at different kinds of options for Kubernetes dashboard, headlamps answer is, like, we have plugins, and we're really good at extending. Absolutely. I would I would echo Oleg's comments there. And I think what we're seeing is that Kubernetes was inherently complex. And now when you add in enterprise scale

10:09 and all the needs of these really large customers, it's even becoming more and more complex. And one of the things that I like about Hedlamp is that it's positioned well enough that it can grow within an organization. So whether you need to extend it via a plug in like Oleg mentioned or you need to, like, implement some of you need to leverage some of the UI pieces, That's that's something that's going to continue to grow with the project and grow with our our users and their customers. And in addition to that, I think you mentioned

10:52 a great point there about the relationship between resources. Right? Especially and it's and I think you brought it up from the perspective of it's not even just new users. It's about sometimes it's experienced users. Okay. This is my workload, but where exactly are all the resources related to it? How do I make sense of everything? And we're beginning to take steps at that. Right? So and Oleg's been hands on with this from the beginning is our projects feature that we're we have an alpha now. The idea is that if I'm new or even if I'm experienced,

11:32 how do I pick this up and understand exactly what's going on? Like, where where are my config files? Where are my secrets? Where are my resources that are related to this cluster? Where are the things that are important for me? And even if, let's say, you're a dev lead, let's say, you're, you know, some sort of engineering manager, maybe you're at your organization's at the scale where you have platform engineers. Right? How do I then take this platform with the workloads that my team needs to work on, and how do I then share that with them? So those are some of

12:10 the things some of what we see as important steps in continuing to tell this the story about Kubernetes and making it fundamentally more user friendly and easier for for our users because, again, going back to going back to the complexity, and I think we have a mantra that we're that we want to realize now, and it's always beyond whether you're look whether you're working with a health care organization that you're look you you're you have critical workloads in the cloud or, let's say, your banking or any of the other industries, you need to be able to onboard

12:56 your users effectively and in a manner where they really grasp what's going on. Right? And that's what we're continuing to aim for. Alright. So you're let's I'm gonna keep talking about this stuff we're already talking about. I was like, this is really interesting. Right? It's like, know, when you have beginner users, like, there's there's so much value to all of these tools. And their experienced users are still using tools like Argo CD and Hubble, like, if they're using Cilium. And it's because these are value adds on top of their existing knowledge that, again, allow them to visualize

13:32 com complex things with, like, a really easy to understand UI. But these very specific Argo CD UIs and Hubble UIs only really work because they understand all these relationships, right, that a generic tool is really gonna struggle with. And I think this is one of the things I think Headlamp has just got right with the way that they do extensions is that, you know, there's no reason the Cillium and Isabel and team, Cisco team, whatever you wanna call them now, can't come along and and do a Hubble extension for Headlamp, and it's just there for all of the

14:01 Headlamp users. I believe you have worked on the the GitHub stuff and there's the Flux stuff as well and the Argo CD stuff. All of this could be shipped in some way with headlamp, meaning that people don't lose these, you know, these tools that have the understanding of all the CRDs and allow you to visualize them in a way that is very quick to understand what is happening in your cluster. I think GitOps is one of those just classic examples. I work with FluxCD every single day and the amount of times I am sitting there

14:28 running four or five different cube controls on a watch trying to understand the sync between the source and the char and the actual rollout of the deployment, release, whatever. These things are just inherently better with a visual where I can see this thing moving along like a board. So I get it and I love the design of Headlamp. I love the extensibility of it and I'm just really excited to show people today what it can do and where that value comes in because it's a really great open source project that not even you know, I'm talking about

14:58 Flux and Argo and Cilium and Hubble and all this stuff, but there's no reason people can't have their own little extensions within their their organization and ship that along with it as well. There's just so much power in this and the way that it's been built. There's no question there. I'm just saying really nice things about the project. I'm like, this is cool. Well well well, thank you. We really appreciate that. And I I think that's that's what we want to hit on. Have Oleg is going to talk about our relationship with Flux. You're going to see

15:31 some of that demo later, but that gets to the core of who we are and that's extensibility. It's that, hey, we can take a stab at these major concerns that are core to Kubernetes, then you can come alongside us and use us because we're open source, of course, and you can extend the functionality that exist in your tools and you can use that, you can offer that to your users and we're starting to see, I think, realization of it. And so thank you to all of our partners in the CNCF and all the other projects

16:11 that are working with us like Flux. And even those who are yet to join, we'd love to have you, we'd love to collaborate and we love to continue to make Kubernetes more accessible for our users. Alright. So we will move on to the demo in just a couple of minutes, but let's tackle, you know, one more question before we do that. So that is an open source project. I really should know this because I should have checked before the stream. But is it a CNCF sandbox project as well? Yes. So we're actually graduated project. Right? Graduated?

16:52 Wow. Yeah. It happened it happened over QConn EUU in London. We're able to finally get the last pieces together for our project. So we're graduated. We're, you know, owned by the CNCF, the project itself. And that brings up a great point, you know, there may have been other projects who, you know, thinking of headlamp, who might be hesitant to say, oh, you know, this other project, well, you know, they they're no longer open source and someone's essentially now it's a page service. You don't have to worry about that here. We're fully open source. We're a graduated product we're

17:35 we're a graduated project, and we're here to stay. And yeah. And I'll stop there. We're here to stay. Yeah. I I have no idea why I had no idea. I think that's a weird statement. But I had no idea why I had no idea this was a graduate project. I I don't even know why I thought it was a sandbox project. That just shows I mean, I haven't paid attention to the three EOC and the projects in a number of years now. Yeah. It's I really I just need yeah. I need to start signing up some email or

18:05 so maybe I need chat GBT Pulse to start sending me graduation alerts. I need to work out something. But let's lean into the AI side of it now because, you know, there's not a software developer in the world right now that I don't think has got AI on their mind. Because it's either taking our jobs or making our jobs easier and people can't seem to decide. So how does how have you found AI with a integration to headlamp and Kubernetes? Like, what are the wins that we're expecting to see here as AI evolves, gets better,

18:32 and understands our clusters and our code more? Ulic, do want to take the first stab at that? I'll follow-up. Yes. So the value proposition of AI in inside a Kubernetes UI is huge because there is so much information that you can absorb by yourself. But with the help of AI, you can take advantage of the LLM feature to be able to go through a lot of information and summarize it for you or explain it for you. So that's a huge part of it, being able to quickly understand important parts of your cluster that need need

19:16 your attention. From there, there's another big aspect. You can have recommended actions or better insight and understanding of underlying mechanisms that happen in your cluster. So that's also a huge point for AI usage inside Kubernetes AI. We just recently shipped the AI plugin. So it's not part of the Corvette, it's an installable plugin, which is completely configurable. You can use local models. You can use any AI providers that you want. It integrates nicely in the UI right now. So you it's available now. You can check it out and let us know how that works for you.

20:04 Awesome. Alright. I do have more questions, but I do feel that we should start talking and showing people what Headlamp is capable of, and then we can always add more questions as we go along. So, Alexander, if you could reshare your screen, we'll move over to that, and I'll let you kick off the demo. Awesome. Thank you so much. Alright. We see the Headlamp website. Take it away. Yeah. So the entry point to Headlamp is our website, the headlamp.dev. One thing that I think we haven't mentioned yet is how wide range of like, how can you deploy Headlamp.

20:43 So let's say you're a beginner, you can just download an app. We have a desktop app for you. Say you are a cluster administrator, you can deploy a headlamp as is, but to your cluster. So it'll be like a web page you can access when you have Kubernetes UI. So we have this huge range of possible use cases ranging from desktop app, you can cluster deployments or completely custom customizable deployments that you modify with plugins. The simplest use case is you download an app. We have links to download it on Windows, Linux, and Mac. We also have a quick little guide to

21:28 how to deploy Hadoop in cluster. We have a documentation, of course, for all of this, so we would recommend you to go through the docs and install the hat on that way. Can I ask a question? Sure. So if people download as a or when get package, a flat pack, you know, DMG or Mac. Right? I'm assuming they're authenticating to the cluster with their own KubeConfig, their own KubeConText, and they they could speak to any cluster they have access to with the same permissions that they have as a user. If you flip that around and you're deploying

22:12 it into your cluster, how does the authentication work in that regard? Is it using YDC, OAuth, something like that so that they still have that second authentication step? Or can you run it as a private service and use something like Teleport or Tailscale? Like, what is the preferred approach for each deployment type? So when you use the desktop app, it will pick up the kube config, so it kinda works exactly like the kubectl. When you deploy it to your cluster, it will you have an option to configure the OIDC. So Hadland doesn't do its own auth. It

22:48 offloads it to IDC authentication or via token that you provide yourself. Alright. Awesome. Thank you. And does the headlamp have the same permissions as you give it when you deploy it, or is it based on any sort of claims within the OAuth token? When you log in through, for example, OIDC, you get the permissions that are bound to that, like, OIDC user. So it uses just the normal, like, role bindings, native Kubernetes. Uh-huh. Gotcha. Gotcha. Gotcha. Alright. Thank you. Oh, we have an important comment that headline is actually a Kubernetes project. So since recently, we're a part of the

23:45 Kubernetes SIG UI. That's sweet. Alright. So let's assume someone's downloaded this and they're spinning up for the first time. What does that look like? Yeah. So when you open add on for the first time, you will see a list of your clusters. It will be automatically picked up from your kube config file. And Yeah. Once you select your cluster, you go to the cluster overview page, which gives you a quick little summary of what's happening in your cluster along with some events that would highlight immediately things that you need to pay attention to. In Hadlamp,

24:29 the UI is quite simple. On the left side, we have a sidebar with all different resources. We have a search bar up top and that's pretty much it. The base UI is quite simple, should be easy to navigate. If we go to workloads, for example, we have your typical workloads and list of resources. You can go and see each resource in a table. Recently, we added map, well, not recently, like half a year ago, which solves the problem that we mentioned before of how Kubernetes has many relationships that can be on a reference or some kind of different

25:24 reference. So we tackle this problem by visualizing resources as a graph, and we try to tackle all the possible connections and displaying it in a very user friendly way. Even if you're a beginner or if you're an advanced user, I think you'll find it helpful to be able to see the connections of the Kubernetes resources. By default, we show all resources grouped by namespace. You see this border in which signifies a namespace, and within each namespace there are groups of resources. A group is a collection of resources that are connected together. For example, if we look at the core

26:09 DNS group, we can clearly see the workloads, the services, network resources in a very user friendly way. You can also customize it by selecting what kind of resources you want to see. By default, we don't show everything because it will be kind of overwhelming, but it is configurable. If I want to see configurations, I see that there is a config map connected to this one. One cool feature of this is you, as a plugin developer, you can extend this. So for example, if you install the Flux plugin and plug in catalog, So maybe I'm jumping over the place a

27:00 little too fast. So plug in catalog. Sorry. It's a plug in in itself that shows you the list of available plug ins you can install. So we use Artifact Hub as a place, as a registry for plugins, and you can publish your own plugins here, and you can very easily install them. And just like that, you have support for flux in the Kubernetes dashboard. You don't need to install a separate UI tool. So how does that look like? If you go, for example, in the map and see something that was deployed by flux, for example, the flux system things,

27:55 we see everything that's deployed by that customization. The plugin is able to register a new resource and how it connects to other resources natively inside the headline UI. Is the kind of power that headlamp gives you as a plugin developer. You are able to manually integrate into UI of the headlamp as if it's just part of the headlamp itself. Let me show you some other features of headlamp. Let's say you just want to see some logs in the pod. When you click on the resource, we have this pop up panel, and if you open logs,

28:50 you can notice that on the bottom you have little tabs that you can switch between. With this feature, you can see multiple logs of different resources at once, but also switch between them. This is kind of hard to do with other UIs, but in here you can see details, minimize them for later, do an update or deployment, keep an eye on logs, it's quite a useful feature. Mhmm. It's quite easy. Let's try it out. We go to the deployment. There's a show logs button, and this will show the logs from all the pods from this deployment.

30:22 This is quite intuitive, and if you want to focus on some concrete pod, you can also do that. By default, we show all pods, but you can switch to individual ones as well. What else should I show you? So in each resource, we have actions. So we can, like, do the most common things you would do with a resource, like restore it, scale it, add it. When you edit it, we have a pretty nice editor for you. You can make your changes, apply, and see them refresh live. So one other thing about Helon that's really

31:21 nice is that all the views are live updated. So how you use, like, the kubectl, you can use the watch command. This is by default everywhere in headline. So you see all the changes are all the changes happen live when you when they happen. So you don't have to worry about, like, refreshing or wondering if it's live or not. We display changes as they happen. Yep. Sorry. That was my I and I it's because my face wasn't visible on the screen share, so that was just me being silly. Sorry, everyone. My question, which was answered, and I'm sure you've worked

32:21 it out by now, but one of my common frustrations is running kubectl, port forward to a service, heading it locally, and then trying to get the logs for all the different endpoints. I was just asking, you know, I never remember the label. I have to describe the pod, get the common label, then do the the the command line. So we were just walking through that. And I'll try I just try and remember to show my face on the screen before I start talking because that was silly. Alright. Sorry. Where were you going there? Do you

32:50 want something else question wise, or were you gonna show something else? I saw a comment about the permissions granted via roles and role binds. Yeah. That one. So headline by default will only show you the things that you can do. So for example, if your if your role doesn't have access to, for example, editing the resource, you will not see the edit button. You will just see the new YAML button. And this kind of philosophy goes through the whole UI. You only see things that you're permitted to do. Okay. So questions that I have then. And I'll I'll

33:34 stick with the authentication one just now. Mhmm. One of the things I find really useful on the the CLI is running the the auth can I and getting, like, a a table or a matrix of the things that I can do? Is that something we can see through the UI? Like, I know you're saying that I'll only see the things that I can do, but is there any sort of more explicit way of seeing here's your permission set so that you can understand how that needs to change? Yeah. The headline doesn't have like a useful

34:02 summary for your permissions. It's only like ad hoc as you try to do something. So yeah. Pull requests are welcome. Alright. Also, again, I was oh, sorry. I think I can't hear you. Yeah. I my my Chrome just told me that my microphone disconnected, and I'm like, no. It didn't. Can you still hear me? Yeah. We can hear you. Alright. Okay. Yeah. I guess today is the favor. I'm just gonna have all the issues under the sun, but I hope not. Alright. So one of the other things is I always come back to debugging just because

34:40 I feel that every time I need to speak to Kubernetes, it's because something is broken. But, you know, to describe get kind of loop, it's obviously the way that we try to understand problems as long as the kubectl events. So as there like any visual indicators either on the map view or on workloads that show me that, you know, maybe there's a pod that can't be scheduled, maybe there's a missing volume that is trying to mount, missing secrets. How are these things flagged to the user visually so that they know when something is wrong? And, you know, as their access to the

35:12 entire event log with some sort of filler or something like that so that we can understand why this thing is wrong and how do we speed up that debugging for the the the operator? So the default table view, we try to have status column for all the resources. So for example, here in the pods, you see the status of each pod, also each container. So these little dots represent each container that runs within that pod. If there's something wrong, you see that there is going to be a red status. In the cluster overview page, we have a

35:51 list of all events. By default, it only shows warnings. So this will immediately grab your attention about, oh, there's something wrong. We also show a status on the map. So you will see, like, a little a warning sign. It will be, like, either yellow or red depending if it's a warning or an error. And, yeah, like, in each resource, we also have events section all the way at the bottom here for all the relevant events. So let's actually go see what's wrong with the this autoscaler. So this one is in error state and we see in the warning state and we

36:39 see that we have an event, we have the reason. So this makes debugging quite easy because you can see not only events from the whole cluster, you can also see events for each resource and figure out exactly what's wrong with it. Cool. Okay. Let me take my debugging hat off then and put on my security one. Can you go to the the plug in marketplace? I don't know what you call it, but, you know, how catalog. Sorry. What's involved in getting a plugin listed here? And how can you give people some sort of degree of

37:17 safety, certainty, whatever that, you know, they're not gonna deploy something malicious to their desktop or with access to their cluster? Yeah. That's a good question. So in Artifact Cloud, anyone can deploy a plugin. To prevent people from installing some random thing, we only show official plugins by default. So when you open the plugin catalog, by default, you can only see the ones that are marked as official. Also, each time you install a plugin, it gives you a warning about what exactly you're installing. It gives you the link for the exact URL that's going to be downloaded and installed,

38:04 and you can inspect it and verify that you're trusting this. Okay. I don't know how technical we want to get right, but how are these plugins implemented? If I do install one, obviously, it has the ability to access cluster information in some day Mhmm. Some way. Right? But does it also have to like, does it have unlimited network access just because my machine is on the Internet? Like, is there any sort of sandboxing with these plugins or is it just the same permissions as the desktop application? Yeah. That's a good question. So right now, plugins don't have any sandboxing,

38:42 so they act on the same permission level as the Haslimp itself. So on one side, yeah, it's a little bit scary from the permissions point of view, but also it allows you to customize headlamp on the same level as the headlamp itself is implement. Okay. So is it safe to assume the headlamp is it an electron application? Yeah. It's an electron application. Okay. So these plugins are, I'm assuming, a collection of React components that are running JavaScript, Node. Js style code to extend the interface? Yeah. Pretty much. It's JavaScript bundled in. Okay. I'll load. Alright. So if we go back to the

39:24 catalog and you toggle the only official, this is gonna show us where does that list come from? So it's also from artifact hub, but it will show all of them, not just the official. So we show you the warning that, hey, you're about to see complete full list that might be non official and that you should pay attention to this and not install something that you don't trust. But if we do want to see this, we have a full list, which also includes the official ones. Okay. So I mean, right off the bat, I can see

40:08 there's a CubeScape one which has a tech and external secret operators. So these techs are the official ones. Right? Even though they're not owned by Headlamp or verified. Okay. Gotcha. Alright. So the verified publishers, you have that gives us some degree of certainty even though they're not official. Right? Yep. Okay. Do you run any nonofficial ones, out of curiosity? Not really. Alright. Like, I I this the thing is I don't really manage a lot of Kubernetes cluster. There's, like, one in my home lab, but that's pretty much it. Right. Okay. I would I would keep it down that track then.

40:52 I mean, I guess the the message here to people would just be, you know, use common sense. Don't go deploy in a flux plug in with a random username next to it. Like, you know, do your due diligence, check out the artifact hub, check out the repositories, and try and give yourself a degree of certainty before you deploy anything. Like downloading any software from the Internet, I don't think this is a unique problem to headlamp whatsoever. I was just curious about, you know, how this catalog is put together. Because, of course, there is a risk with Internet software.

41:23 So awesome. Thank you so much for sharing that. Alright. Shall we take a look at the AI assistant? Oh, unfortunately, don't have a setup for this AI assistant. So I would not be able to demo that today. Okay. So what are the use cases for the AI assistant? The use case for AI assistant is pretty much anything you do with your cluster. So monitoring, debugging, deploying applications. We give ability to the AI assistant to execute actions on your cluster, obviously, after you, like, confirm that you wanna execute that kind of action. So if you wanna say, like, hey, deploy this,

42:11 it will make a post request to Kubernetes API and deploy something. Or if you want to debug something, it will pull up information and summarize it for you. So pretty much anything you would do with a Kubernetes cluster, you can do it through AI appointment. Alright. Okay. Just checking. Is there anything else that you want to show with the demo or will I move this back over to big face mode? One second. Let me show you the search because I think it's a pretty cool feature that not all projects have. So the advanced search allows you to construct

42:57 a query and look up any resource in your cluster. So this is a feature that advanced users would love because maybe as a beginner, you might not need this, but if you wanna if you know exactly what you need, then this is the tool for you. So in this case, we we can select any kind of resource that's deployed to the the cluster. So we are doing API discovery here for every resource that's available, and you can construct a query that filters out the results. So for example, we can go through all resources and search

43:39 by the label. This gives you a little table with all resources easily available for you to see. This query is just the JavaScript query, so it allows you to quite easily filter out exactly what you need. One cool feature about this is that we have the full, like, types for it. So you you have the suggestions. So for example, if you type in labels, it gives you a suggestion for all the labels that exist in your cluster. So this list comes from all of the resources that are available. So if you don't exactly know, like, how to type out the exact label,

44:30 you have a little help here, and also for all the values as well. Nice. And that's just common expression language. Is that right? No. This is a just a JavaScript expression. Okay. We're running this fully client side, so there is no need to deploy anything on the back end. We'll load the resources, filter out strictly on the client. We ran some tests, and it performs pretty good even with a lot of resources. Like, usually, you wouldn't wanna do, like, filtering on hundreds of thousands of bots, but it can if it needs. And is the is there a cache involved or are you

45:16 creating the the server? Or yeah, there is no cache involved. We're occurring in the APIs directly. So if you do manage a really large cluster, you gotta be careful with this. And does that one have the character type you quitting or is there I'm sorry. So it will load the resources first and then query filter it out as you type. So we do have some more extensible limits, and so we don't completely bombard your API server. But you have an option to increase it if you want to. And, yeah, that's a really powerful feature. Alright. Cool.

45:57 Yeah. I like that feature. That's a that's a nice one. Alright. Let's get let's can you click on the the the storage page? Storage. Sure. Mhmm. No. There's no storage. I I don't really have anything to play with this question. I'm sorry. No. No. It's alright. I was just curious. You know, storage is just one of those things, like in fact, let's go back to Big Face Mode because I've got some more questions. We can always pop back over here. Let's bring Will back in. Missed you, Will. So right now, headlamp gives me everything I get from kubectl.

46:37 That that's kinda what I'm getting from the the layers on that page. Right? And if I can do it in the command line, I can do that visually, but there's a niceties of being able to, you know, go directly to the logs, view the YAML, and all of that stuff. Right? It's just an I'd say a pleasant, happy path experience to working with my cluster. I think what really shines are the two things that kinda go above and beyond to what I can do in kubectl. That is the map interface and then the the advanced

47:03 search with the label selectors, now it'll complete and all that. Right? These are things that I cannot do with kubectl. And I think there's a lot there's a you know, that's a big domain. As you build in with new plugins, understanding of different CRDs, I can imagine adding lots and lots of new things to that sidebar that are very job specific. So I'm curious how have you found evolving the project and what other areas have you identified as things that headlamp can provide a better interface with things that we cannot do in the command line? Like, have you

47:34 dug into that? Have you built a proof of concept, ideas? Is there any road map things? Like, maybe you could talk about that in a bit more detail. Well, Lee, you wanna take that one? Sure. There are a few road map things that I didn't know if I'm at at liberty to quite discuss like that. But the idea or the continuing philosophy behind it is that you wanna be, like, your one stop shop so that everything you need, you can do here. So you bring up a good point about being able to run commands and do things visually.

48:14 And with our implementation of AI, I think we're leveraging AI like Oleg mentioned, we we really see that going in in the terms of accelerated technical understanding. So being able to use those natural language queries on top of it, maybe you don't know the questions you're asking, LMS are excellent at that. Going back to some of our newer users, so a lower barrier to entry, and then less friction and a better experience for even newer users and your experts as well. Right? So some of that seamless integration, and that's where we're going with the combination

48:59 of projects, so that dedicated that you see that app centric view, as well as combining it with AI. And we even have our local cluster now. It's a local cluster environment. So if you needed to learn or spin up something locally, you can go there. You can there go there. So there's not a ton I can divulge there, but the guiding principle is that from a single pane of glass, you can be able to you can understand everything you need for your Kubernetes environment, and that's that's all I can say for the moment. Alright. Let's

49:42 change tack a little bit then. A common theme at KubeCon over the last, let's say, maybe five or six years, Let's say four or five years. You know, platform engineering, everybody is looking for that single pane of glass. And, you know, Headlamp isn't a single pane of glass right now. It's a look at your cluster. But I'm curious if your road map involves maybe broader integrations with things like Backstage. In fact, I think Backstage can embed Headlamp. I'm not sure. You can correct me on that one. But also something else I would love to do again, if I

50:14 have Headlamp in front of me and it has access to my cluster, is the run books or, like, the thing that jump right into my head? It's like, is there a way that I can run a a workflow against my cluster to do things? Like, and how would that be visualized? I think that'd be a really nice thing to visualize because I could see the execution of commands and what comes back and, you know, maybe even write little JavaScript bits of code that hook into that. This is actually something that used to be possible, like, eight years ago with a project

50:40 called Brigade, also came out of Microsoft, but was discontinued. I don't know if it's an adoption or just I I don't know. I think that would be a really slick addition. And another thing that I think would be really interesting is, you know, I have my cluster. There may be Carpenter in there. There may be Prometheus, like the ability to run PromQL queries or low logQL queries that got the low key to enrich and to see what's happening in my cluster, but also the performance of what's happening in my cluster. Are these things that you have

51:11 talked about, entertained, considered, like, maybe you could fill in a bit of the blanks there too. Yeah. Those are things that we've talked about in Japan. And I think Oleg has one of the things you mentioned queued up on his screen right now. If you want to. I knew I didn't make that up. I knew that was in my head from somewhere. Awesome. Yeah. So what happened with the backstage project then? This is and backstage, can just click on the headlamp tab. Right? Okay. So I'm not too too familiar with the Backstage integration here, but I do know that we

51:53 do have it. But I guess that loops back to my question. Right? Like, if people are embedded in the headlamp and backstage, then they have access to, you know, Grafana and Prometheus and other tools there. Does that mean that it's something you wouldn't do in headlamp? Or is that something that you still think there'd be a value proposition where headlamp can, you know, begin to expand its realm and its capabilities to I am not saying you would go and try and replace Backstage by any means but if Headlamp is the tool I am using to look

52:20 and be within my cluster and understand my cluster I think there is still a use case for being able to run PromQL queries and for being able to run run books, etcetera. So Yeah. In in a in a perfect world, we you would do everything for headlamp. And, like, for example, the Prometheus, we do have an integration with Prometheus via the Prometheus plugin. So that plugin is actually shipped by default with Headlamp when you install it. It provides you a nice basic integration with the Prometheus. It will display metrics for resources like bots. So if you go to the details of

53:01 an individual pod, this little button integrates natively into the UI. We it'll show you the Prometheus metrics for this resource. I don't have it installed on this cluster, but you can imagine, like, there is a graph with metrics for that particular pod in headland. And this kind of philosophy, I think, is, like, the core Hedlamp idea is that you integrate all the tools in the Hedlamp, and Hedlamp becomes, like, one stop shop for everything, you know, Kubernetes related. Alright. Nice. Alright. Let's go back to Will's topic then. So let's just zoom in. People are watching this. They see Headlamp. Right? I

53:47 mean, I'm assuming anyone watching this understands value proposition and hopefully they're downloading Headlamp right now. But it is also an open source project, it's a CNCF graduated project, it's a Kubernetes sub project. How do people get involved? How do they write new extensions and plug ins? Like, do they just go to the repo and start working on docs? Like, what is the best path there? What advice have you got for people that that see the value here and wanna help expand the capabilities? Yeah. Thanks. That's a great question. I think step one, definitely get started with PetLab. Go

54:19 ahead. Download. We also have the we're on the Kubernetes Slack channel and you can also correct me if I'm wrong, you can get started through GitHub if you wanted to contribute or even create an issue, you can do that as well. Yeah. There is multiple ways how you can help help us out. So first and foremost, try it out. Let us know what you think. Post something on the Kubernetes Slack channel. Open an issue with just your feedback. What what things that you do like, what things you don't like, what something that you wanna do but is not available yet in Hadland.

54:59 Like, your opinion with us because that's something that we really wanna wanna hear from you. Like, feedback of, like, ideas, what what something you wish to see in handling. So that's, like, the easiest way to contribute is to share your opinion with us. The next point is contribute to code directly. We have a contributor's guide. It should be quite straightforward. You spin up a local instance of headlamp. You make some changes, open up a pull request. We're always happy to see contributions from external contributors. And we do have a lot of external contributors that provide a lot of valuable features to headlamp.

55:43 So, yeah, we're always open about that. Absolutely. So to always point, user feedback is something that we're going we'll be updating shortly. But even if you're let's say you're not a contributor, understanding why this is important, how you use headlamp. That's really important for us in terms of prioritization and making sure that we're really understanding our users. So at the very least, we like we love the feedback. It's it's very a very integral part being a community project. Alright. Awesome. So, yeah, check out the repository. There's a Slack channel. Give some of your feedback. And hopefully, you

56:27 know, if we do this session again in twelve months time, we'll see all of the new amazing plugins and integrations and capabilities for the Headland project. Any last words? Anything you wanna share with the audience before we wrap this up? I would say I would say definitely just download, install it, and, you know, take it for spin. We've done a lot of work making it visual, intuitive, and extensible. So as far as your imagination can take you, those are the things you can do with headlamp, download the AI plug in, let's get some feedback there,

57:12 start using it, and help us continue to create a project that the entire community can use and leverage for our benefit. Maybe I'll also mention that at the upcoming KubeCon, we have a ContriftFest session where you can create a plug in. We'll be there to walk you through it. And yeah. Yeah. And I'm assuming if you're at Atlanta, though, you'll also be on the Project Pavilion. So if you do have any questions that are not tackled by this session, please make sure you go along and speak to them face to face. And, yeah, I'm sure they can help you out. Absolutely.

57:51 Alright. Thank you both so much for spending time with me and walking us through the the Headline project. Like I said, I see the value. I hope everyone else does too. Download it, join the Slack channel, and then get involved. It's just always the best way in Cloud Native. Well, thank you so much for your time. I'll see you all next time, and to everyone watching, thank you again. The heart of the stream. Stay tuned. Stay sharp. Keep that code clean. Subscribe. Dive deeper. Join the team. Rawkode Academy, where clusters come alive.