2:44 Introduction

2:44 Hello, and welcome back to the Rawkode Academy. We are live as always. My name is David Flanagan, And, today, we're taking a look at Kubevious. Now before we get started, I just want to encourage people to subscribe to the channel, like this video, and, remember, if I ever have audio problems, thank you, Russell, for the comment, to let me know early in the session rather than just persevere with it. So if I sound like a frog trapped underwater, please leave a comment. But, hopefully, I sound alright today. Okay. Today, we're taking a look at Kubevious,

3:20 and I'm going to be guided today by Ruben, a founder of the Kubevious project. Hey, man. How's it going? Very good. Hi, David. Pleasure to be here. Thanks for having me. No. It's my pleasure. I'm looking forward to playing with a new project today. It's always my my highlight of my week when I get sit down and do something interesting and fun on top of Kubernetes and hopefully solve a few problems that I've got in the process. So before I ask you about Kubevious, do you wanna just take a moment to tell us a little bit about who you are?

3:43 Origin and Evolution of Kubevious

3:49 Yeah. Of course. My name is Ruben. I'm the founder and CEO of Project Kubevious. So in Kubevious, we're trying to promise engineers to help their lives with Kubernetes to improve overall Kubernetes and cloud native experiences by making sure that we detect and enforce and detect through misconfigurations, errors, conflicts, or typos of that sort and violations to best practices. And we do that by correlating things that are happening in the cluster and making sure that any changes that you do are in compliance with those practices. I've been crawling for twenty five years. I'm I've been in cloud native space for the

4:31 last six years, and I'm really excited about the that the cloud native and Kubernetes. Awesome. Thank you for sharing. Now I'm curious about maybe you can share why you started Kubevious. Like, most people, you know, they're just trying to solve their own problems, scratch their own edge. Is that true for you and Kubevious? Yeah. Kubevious started as an internal project just to help understanding what's going on in the clusters. As a simple UI, as a relatively application centric dashboard, which helps me understand, right, what kind of applications I have in my clusters without and what is the composition of those apps

5:14 without going into different types of resources and trying to connect the the dots. So for example, in order to see how app is deployed, you have to look at deployments, then you would have to check services that would control how apps are exposed to the outside addresses, like volume mounts, config map, secrets. So it's quite involved. And first of all, Kubevious started as a dashboard, which kind of, first of all, woah, shows you the apps. And underneath the app, it shows all the links and all the references and dependencies of your apps. Then slowly, the project evolved into

5:52 assurance platform. We started edit validations because and and we opened up the doors so users can write their own validation rules. And we're we're we're getting very close to build a fully pledged assurance platform for Kubernetes and cloud native projects. Okay. Cool. Now I guess I what I'm curious about is, like, is it something that everyone should install in their cluster, or is this targeted at people and, like, an enterprise background, maybe, like, banking, etcetera, where they have to have a really good understanding or control in what's in their cluster? Or is one of those things that

6:13 Target Audience and Use Cases

6:31 even if it's a hobby cluster, you just deploy it because you're still getting that visibility into it? I think different users different types of users may benefit and use different areas of Kubevious. Like, for hobby projects, it can really quickly help you get started with Kubernetes. Let's say, you install a Helm chart with few applications. It can quickly let you know and make things more obvious with Kubernetes. Whereas for more complicated deployments, complex deployments, like in larger enterprises, they might more focus on RBAT capabilities, like networking policies, and writing their own more complicated rules to be able to enforce those complex

7:14 scenarios. Yeah. I like that you mentioned Helm charts because I am very guilty of that where I just go to the artifact hub and go, oh, that looks like it might do what I want, and then I do a Helm upgrade install. And, really, I have no idea what that is like in into my cluster. I just kinda have this level of trust, which I probably shouldn't have with random Helm charts off the Internet. So you're telling me that Kubevious is gonna break that down a little bit for me and show me what's happening? Well,

7:17 Kubevious Functionality: Visibility & Enforcement

7:42 it's not a it's not gonna give you a complete safety of it doesn't introspect the the workloads. It doesn't check what it does. But at least when the workload doesn't work well, there's some issues with deployment. You can see those things propagated all the way up to the application level, and then it it would guide you towards the area that needs more attention. Instead of showing things and analyzing things in a, like, table form, it creates a graph of the application. And dependencies are kind of you would find dependencies deep down. So it does namespace application

8:21 and then container. And then underneath the container, you would see the volume mount, like the path where the config map is mounted. And then underneath, you would see the config map. And if for some reason the config map is missing, it would let you know in well, in in advance. Or if you're mounting secrets to environment variables, if one of the keys is missing, it would let you know. And if you have any other issues of that sort, let's say, mismatch with labels, naming issues. So you can quickly detect those names and then at much earlier stages of your of your

8:58 deployment. So Kubevious, as I mentioned, started as a dashboard, but the very recent development was ability to enforce those checks and validations. So you can plug it in into your CD pipeline. And let's say you have a package of your manifest, whether in the form of Helm or they're, like, a directory within your repository, you basically just have to pipe all those files into a special script. And if it detects that, the current cluster will be in a worse shape with your change Oh, I think we've lost Ruben. Oh, you're back. Hello? Yeah. So I was saying so you would

9:00 Kubevious Guard (CI/CD Enforcement)

9:48 have to pipe your directory of your manifest or files into a special script. And if with that script, the state of the cluster would be in a worse shape, then it would let you know in advance, and it would prevent those changes from progressing further into the cluster. Okay. So just to make sure I understood that correctly in my in my head, the Kubevious project, we've got two different components. So maybe more, but two that I think I'm aware of right now. One being we have this user interface dashboard for what is inside of our Kubernetes cluster,

10:20 but you're saying there's some sort of c l I component that will allow us to scan the manifest and that kind of environment to give us warnings before we push it into the cluster. Is that correct? Yeah. Yeah. They're no they're not two separate things. They're different components of the same project. Yeah. So they're not kind of, well, divisible. It's just a different ways of accessing to the enforcement engine. One is through the UI, which is continuously running. It's continuously monitoring any changes that is happening, that are happening in the clusters. And the other one is the enforcement tool

10:59 that kind of runs the same logic. It's just it involves the changes that you're about to apply to the cluster. Okay. So you said that the first version was a dashboard and a UI. Like, was that very intentional to build a UI? Like, to make something that was UI driven first? Because what I don't know. Maybe it's just my my experience. But in the Kubernetes landscape, we seem to be averse to UIs. Although, I do see that changing now. We're seeing a lot more dashboard like things coming out. But that must have been quite a

11:07 UI Design Philosophy

11:28 brave decision or bold decision to be UI first at the start. Yeah. It was very well intentional. Probably transfer my background from gaming. I used to do some game development before. And in the very early version, you wouldn't see it right now, but if I dig a little bit, I'll find the older version. So there is, like, a flat tuned to have the, like, layout where you would see apps, and you can kind of expand and dig into, specific areas like apps and deployments, pods, or how things are mounted, HPAs. And then you will see a tiny mini

12:05 map, like in strategy games, in Age of Empires or Star Draft, but then it lets you kind of navigate. Yeah. It was pretty cool, but at some point, like, being more productive became more important. And then we we got rid of the mini map, and we we edit a little bit different ways of navigating this hierarchy constructor. So the thing with UI is you can put much more accessible information using UI versus just being limited into a text. Even though, let's say, projects like, k nine s, it's really awesome. I think they did. They they got the most out of the

12:53 terminal stream. It's you you kinda probably can do better. But with the UI, you can provide a lot of hints on the same screen area that wouldn't be too intrusive, but it would be much easier to kind of digest by the users with some hints that allow user to kind of dig deeper into further steps that needs more attention. Nice. Oh, my cabling's falling under my desk. But Yeah. As long as we're still on the air, I think we're okay. Alright. You broke my heart a little bit there when you said you removed the mini

13:29 map because Age of Empires was my favorite game growing up. Absolutely. I I lost days, weeks, and maybe even months playing that game. It was so good. Yeah. Well, it's a it's an open source project. There is older version. You're always working things for the the new one. It's like, I think you could go for 0.6 or below it would be the older version. Well, I don't know if you've ever seen this, but I think it was maybe two years ago someone actually recompiled Doom where all the enemies in it were the pods within a Kubernetes cluster. So you

14:05 actually got Oh, yes. Play Doom and shoot pods and, like, this chaos monkey style game, which I just thought was brilliant. Like, maybe we maybe we need to do more with gaming technology and Kubernetes. So maybe you're onto something here. Yeah. I used to if you're familiar with the game Quake, Quake Arena, Quake three Yep. I used to write another three d engine using OpenGL that uses the same data. It just renders things in a different ways with much better shaders. So, of course, it wasn't a full damage experience. It was just a viewer of the of

14:41 the map, but it it it it is quite fun to take something that is old and give it a little bit different thing. Yeah. Definitely. I I I would love to get some some proper Kubernetes clusters and make a game of it. Maybe even Age of Empires, like, maybe I could build up my own pods and then go attack some other cluster pods. But that's not why we're here today, so I'm not gonna go down that rabbit hole. Yeah. No. I've got the Kubevious website here. So I'm gonna pull up my screen share, and I'll move to miss them. I'm loving

15:16 that little animated sun that keeps floating around. That's awesome. Yeah. So we're saying here that Kubevious is going to avoid mistakes and cost the outages. So this this component you talked about is going to scan manifest. We get application insights and the ability to reduce problem resolution domain. So those are three things that I would love to improve on my Kubernetes clusters, and I I'm happy that you get to guide us through this today. So also have a Kubernetes cluster with some fake workloads on it and just so that we can use Kubevious in a way that's gonna get us

15:41 Installing Kubevious via Helm

15:50 a bit more data. So our step one here is gonna be get Kubevious deployed onto my cluster. Are you ready, Ruben? Yeah. Go for it. Alright. So I'm gonna go through the is the documentation the best place for us to get started today? Either Dots or the GitHub project. Yeah. I can probably do GitHub project. Alright. Let's pop over here. And let's it goes to the organization oh, you're using one of those org with me. Those are kill. Mhmm. I don't see a lot of those. So your CLI is called guard? So the guard is the enforcement part. So

16:34 we would use it afterwards. After we install Kubevious, then we could use the guard just to just before we would make the further changes before you would do another TubeControlApply, which would use the guard. But we don't have to start with it. And you really have to have Kubevious running in your cluster to be able to use the guard. Because the way it works, it communicates with Kubevious, and then it kind of asks it, hey. I wanna make those changes. Can you just sanitize and just check what's gonna happen in my cluster if I were to apply

17:09 this change? Okay. Well, I found the installation instructions. So we're gonna create a namespace called Kubevious. We're going to add a Helm repository, and then we're going to install. I am not familiar with the atomic flag on Helm. Is that important? It's basically says either install everything or if something doesn't work, just uninstall. Oh, nice. You don't have to. Usually, it works. But I don't have Helm according to my highlighting here. So this is my new Mac Studio. So I'm gonna install and stuff as required because my dot files were not as complete as I thought they were. Mhmm.

17:54 Let's see. Should hopefully just take a moment. I hope you get the right helm. Have you ever installed helm with apt get? Normally, you get this random binary. Yeah. I think it's 3.9 as long as it's something higher than 3.2, but then it should work. Well, we'll give this just a moment. And then this is going to create a port forward, and we should be able to browse to local host 88. Yeah. I'll just pop that open, and we'll give him a minute. Usually, it takes a minute or so because it has to install Redis,

18:40 MySQL. MySQL takes a little bit more there more time to come up. And then there are couple of microservices, but those should also Well, we can we can follow along. Right? So we could do a Kubeflow, Kubevious, get pods, have a watcher. Oh, wrong context. There we go. So we're just waiting on MySQL to pass in its probes. Yeah. And we should be good. Yeah. Interesting time in Sam in the comments. What does atomic do? So Ruben just said, atomic means that if any component of the helm installed fails, all of it will be removed.

18:52 Debugging Installation Issues

19:29 Which is a nice flag. So I thought I don't know how I'd missed it. But Yeah. So for example, if that my SQL wouldn't come up at some point, there is some time in, think, five minutes or so, so it would start rolling back the changes. Sweet. Not that it always can roll back successfully. That's a completely different story, but but look at it. But at least it tries. Yeah. It tries. Yeah. Alright. Let me zoom in on this a little bit without breaking the view. I think we'll lose the bottom, but maybe that'll be okay for now.

20:04 So do you wanna It does yeah. Just one more quick thing. It doesn't like zooming yet. We're using another library. So after you zoom, you if you just refresh the page, then it would come back into a normal shape. Yeah. Oh, nice. It's a bug. It's we're using the library. Probably, we'll have to get rid of it and do it our own way. Yeah. All all I have to do is refresh. I'm happy with that. So Yeah. You wanted to tell us what we're looking at just now? So that's the mainstream of Kubevious. It's the place where soon we'll see

20:44 the contents of the of the cluster. So there is a summary screen. So it's supposed to load data from the cluster right now. And then there are other more specialized views, like logic, images, gateway. So if we go back to summary, I think it should. It usually takes much shorter. But Okay. So what it's doing right now, it's there is a process called Kubevious parser, and it's supposed to load everything from the API server. And then it's gonna ship those manifest to to Kubevious engine, and then it would kind of correlate all those things and show

21:13 Dubious Parser

21:32 violations and errors and just it should render the UI right after that. Right. Software usually breaks. Let's try to do that. That's how things are. Right? Do you if you just can you open up the loads for maybe Kubevious parser? Yeah. Can. Yeah. So it's it has some logic. It it tries to query everything, then it, there is some weights and checks. There are certain resources that it tries to kind of load. Sometimes it doesn't subside, and it waits a minute or so. Usually, it should be shorter, but, yeah, I think I don't see. At some point, it

22:32 at some point, it gives up and then moves for forwards without those CRTs. I'm not seeing any error message. Am I just messing it? Sometimes there are issues with metric. Yeah. Could it be my cluster? Can we check? I don't think so. Can we check the the other process, the Kubevious pod? Back end? Yeah. The back end. Just scroll up. Okay. Oh, we do have something. Okay. Oh, one of the database migrations not run? It should do it on its own. It says that Kubevious notification snooze doesn't exist. Oh, that's not a that's not a good sign. So

23:46 so if we go you know what? Let's do some dirty trick. If you can just kill this pod, if you can just kill this pod, it's supposed to retrieve the the missing labels. So you said the back end pod started before MySQL was happy and it never Yeah. It's supposed to yeah. It's supposed to it's not supposed to do that, but okay. Alright. Let's give that a moment. So we've got a hello from Siva in the chat. Hello, Siva. And Sam's saying, good idea. You're looking for the error message. Yeah. We love a bit of live debugging

24:31 on this channel. That's for sure. Yeah. So let's see what happens when we pop over here. So the way it works, so the parser will retry within within just a couple of minutes. It's actually If I delete the parser, will that speed it up? No. There is no name. No. Alright. I trust you. We can just since we're doing more more involved debugging, maybe we can open up the logs for the for the patent and see whenever there is something coming in from the. The other guy usually waits for a minute before retrying. Yeah. At least the back end. This looks

25:18 a much better shape now. Like, this is Yeah. We don't see that error anymore. Right? No. I don't see any errors. It seems to set up a whole bunch of stuff. So It could go all the way up. Just waiting for the parser. Mhmm. So maybe we can do a better job in kind of waiting for MySQL to come back up before creating tables. Have you seen the project schema hero from a CNCF? I saw a CNCF project. Yeah. It's really cool. Like, you can What does it do? It does database migrations on Kubernetes. So you you define your schemas

25:58 as custom resources, and it speaks to my scale and manages all for you and handles the migrations and stuff like that. It's pretty cool. Yeah. That's awesome. I'll definitely take a look. There was some activity on GitHub, so there was a suggestion to use MySQL and Redis dependencies on within Kubevious projects so that we don't have our own ways of printing up MySQL. So it would kind of make our lives easier, and kind of we would leverage the existing helm charts for that. I mean, migrations are the bane of every software project. I don't think I've ever worked in a

26:38 software project where it the migrations haven't been the most painful part. So Yeah. Yeah. Well, let's go back to parser maybe. Yeah. Okay. I can take a look at parser. Let's see. If you go up, it there should be some mention of postponing something for I think it's complaining because there's no node metrics, but I need to install metric server. So it's supposed to just to skip it, so it should be able to. I can install metric server if you want. Maybe it would take much longer time. You know what? Let's let's just kill this guy as well and

27:52 Let's just shut down my cluster. Okay. And you're on maybe we'll do that next. We'll try this. Yeah. Mhmm. There's no demo that crashes first. Right? The first one. Yeah. Well, Kubernetes is hard. I'm going to install metric server just in case that helps. It's very common for a metric server not to be obvious, especially on home home environments. So we specifically did something so that it it's not gonna be an issue. But yeah. Let's see. I it's okay. I I don't I don't know if this is is this better? Is this the same? No. I mean, it looks

28:55 okay. It's how it's supposed to be. You said you have another cluster? Can we try it out on that one? And Mhmm. GBCTX. I'll just use Docker desktop. Let's see. Have a look. Meanwhile, I'll try to compare the logs with my own lab. Alright. So it's installing again. So we'll give that just a moment and then track the UI again. Yeah. And I'll switch my contact then here so we can follow along. And it's getting there. Not long. We have a lot of support in the the chat. Sam says, love this live debugging. And, Kenneth, I think, guys can do it.

29:56 Keep trying. Don't you worry. We're we're here till it works. Right, Ruben? Yeah. There's no limit. Right? It's I hope you can look at our plans. So Yeah. Alright. Let's just wait for my SQL and see where we are. I'm just gonna cancel a couple of meetings at the dinner area. And Alright. Just waiting on the probes. So that should keep helm happy. There we go. Refresh the UI. So now we have to wait a couple of minutes for the data. Kinda got the same screen. Is that good or bad? Is it so you canceled the other one. Right? The

30:48 port forwarding for the other one, and now it's from the Yep. This is our New one. New cluster. Let's check the logs for that one from the back end. Yep. Oh, yeah. So this is the migration again. Is it? I'll delete the back end. Quite. Yeah. Let me see. Okay. Let me see which version do we have on the demo. That's very weird. Let's try this. Oh, I just deleted it again because I'm an idiot. Sorry. I meant to get the log. There you go. Alright. No error messages. Looks happy. Mhmm. Oh, look. We have a UI. Okay.

32:00 Exploring the Kubevious UI

32:01 Finally, it only took two clusters. Right? Well, my first cluster is a managed Kubernetes cluster. Maybe I don't know if there's RBAC things that need to be tweaked in that. So we'll just disregard that one unless you use this one. Mhmm. David, if you can just shoot me the logs for that one that didn't work, I wanna kind of get hold of it. If Yeah. I'll give you access to that cluster after the session. Don't worry. You can you can put it. Works. Yeah. Alright. Tell me what we're looking at now then, please. So this is

32:35 probably the first thing that you would wanna do is to look at the browser section. It's really from the left side navigation screen. So the summary, it gives you the top level summary of the cluster and, like, some metrics, how many apps, namespaces, what are the resources within the clusters. And below that, it will show you the top three namespaces that you misidentified issues and top three issues within your clusters. So, for example, since you don't have any other workload, so probably the that's why the Kube system jumps up to the top. But there are lots of service account

33:20 service accounts that nobody is referencing. So it's it's considered a warning until you have a full control whether you wanna disable that warning, made it a error. So you have control for those things. And yeah. So that's that's kind of informational. The next thing you would wanna do, maybe look at the logic logic tab. This is where you would see your namespaces, your apps. Yeah. Maybe okay. Now you can see things. Alright. So you will see the Kube system and Kubevious. If there is not too much interesting stuff in Kube system, we can kind of

33:38 Kubevious Browser: Logic View (App Hierarchy)

34:03 introspect Kubevious. So you you just click on it, and it would show apps within Kubevious namespace. And below, you would see your alerts, what kind of alerts it identified, and what are the affected object. And every single node within Kubevious has its own sets of properties. More often than not, you would see the YAML traffic on the right side, unless those are some synthetic nodes within the UI or some other sets of properties. Nice. It's, like, bringing, like, this familiarity I have with, like, my coding IDE to my Kubernetes cluster. It feels very familiar right

34:50 away. Like like like, I'm using Versus Code in some capacity. Only the details we get in are much more specific. Yeah. Yeah. And you can dig deeper. So, for example, you you can try to open up the the Kubevious backend, the very first node. And it would see show you the composition of the app, how many times it restarted, how many calls there, how many of them are ready. So that's a little bit of health related information. Mhmm. And if there are some other issues there so for example, there is some warning on the deployment. Right?

35:30 And probably says that there are no resource limits over there. But yeah. So, for example, you would see a spy icon on top of the service account. Yeah. I like that little bit of text there. Yeah. So that's also clickable. Just just go for it. Just click on it. And the reason it's it has a spy is that it has a full cluster access to certain CRDs, and that spy icon indicates that something it doesn't mean something is wrong. It's just this workload workload has an access to things beyond the namespace where it is. So just to be aware.

36:11 And the icon propagates all the way up to the to the namespace. So on top of the namespace, can see there are some workloads that are doing things cluster related that go beyond their namespace. Yeah. I love this little resource role metrics down here showing it kind of what I can do. This would be great software for clustered, actually. I bet you this would save the meantime to recovery Yeah. A lot. Yeah. So you do this on the roll. Right? So you don't really have to dig so much down to the roll. You can see that on top of the service account.

36:47 Oh, yeah. So if you have 15, say, 15 bindings and 15 rolls, so it would kind of combine all all them into a single table so you can quickly understand what is allowed in the end of the day to my workload. Very cool. I like that. You can yeah. Yeah. So different types of nodes have different sets of properties. So for example, service account has this table. If you have network policies, it would show which apps are allowed to talk together. And, yeah, on the top level, you have, like, resource uses usages, how much of the overall cluster resources does

37:29 the entire application consume. So if you have addresses, they would show differently. Yeah. I like this kind of breakdown of the images as well used within the application. Yeah. But I can see here this is from Docker Hub, and it could be as back end Yeah. Tag. It's a really Yeah. Really smart way of presenting what is quite a lot of overwhelming information to people when they adopt and learn Kubernetes. Mhmm. Kinda making it consumable Mhmm. In a way where you don't need to just, like, throw your hands in there and say, oh, I don't know. Like, I like

38:00 the Yeah. I'm just gonna keep clicking on this for random until you tell me to to just Of course. Of course. Yeah. I think that no matter how much the clip, it wouldn't crash anymore. So we're good. As when it starts working, it doesn't stop working. So we looked at the we looked at the kind of logic view. Right? But there are other different ways of looking at the same cluster cluster and applications. The other one, maybe we can look at the images tab. Mhmm. This allows you to look at your cluster from the images and replicators point of view.

38:30 Images Tab

38:38 So it would show that are you in I have hard time seeing, but, so there is a Docker Hub, and there's another repo that you have. Yeah. There's Kubernetes.GCR.io, which I assume is the control plane component. Yeah. We have Docker Hub. Yeah. So you can click on the Docker Hub, and you can see there there are seven images from Docker Hub used within my cluster. And then you're trying to can kind of drill down into the image. You can see which tabs are used, by which namespace, and by which which particular app. Yeah. Nice. Cool.

39:24 Yeah. And then you can see the details of the app. If you wanna drill deeper into the app, you can navigate using those target links, the very first group of properties. You can click on it. This is clickable, and then it would navigate you to the other view. Yeah. So you can see the composition. So it allows you to to kind of travel from one view to another, and each view has its own sets of properties, and it's composed in different ways. If you were to use or traffic proxy, you would see gateway populated with domains and URLs and services

40:07 and over there. Probably the next interesting one would be RBAC or if you have Helm charts, that would those would populate in the packages. Okay. Well, I mean, this is my local Docker for Mac. So the gateway tab, probably not that useful to us. What's the the package tab here? So as of right now, it would show your helm helm helm releases. Ah, okay. So this is why I'm seeing Kubevious because Yeah. So it will show version one, and it will show what what is their contents and which apps are installed using this Helm Relay.

40:15 Kubevious Browser: Packages View (Helm)

40:47 And, again, it would map it to apps within the logic view. Can I show you the helm values fail? No. No. I I don't even know if that's available in the cluster. I have I'm not sure. I'm not Probably. I don't know. Maybe I think they store it a good way, actually. I don't know if you have It's it's loaded from a secret. Yeah. That that's a good idea. Yeah. Yeah. Because it would be cool to see, alright. I've got this chart deployed. How did I configure it? Also, of course, I have this stuff in GET as well, but but

41:22 just for there's a lot of cool stuff here. Yeah. Alright. So the We have an idea to yeah. Go ahead. No. I was just gonna click on the Kubernetes tab, feel free. You go first, and then we'll we'll move on. So so regarding that package tab, so we had an idea to integrate our Rawkode CD applications within that package tab. So those are kind of different ways that you would deploy apps, and we have to do a little bit of digging how much is possible to do so that we can kind of understand what kind of

41:53 apps are deployed with our Rusty, what's the contents, and what things are coming from hell, what is coming from Rawkode. Nice. Alright. Three more tabs. Kubernetes tab. Is this just It's just a a resource browser. So you have CRDs, anything you can kind of dig down by namespace, API. Oh, yeah. If API extensions kind of resource. Yeah. Custom resources. Cool. And I can see all the CIDs registered. Oh, nice. Yeah. Okay. I like that bit. Yeah. That's cool. RBAC. I hate RBAC. Alright. Well, we have a whole tab for this. I won't click on it here.

42:03 Kubernetes Tab

42:40 This is my notes and storage. Very nice. Not very interesting on Docker for desktop, but, you know Mhmm. On on my other cluster would be pretty cool. So in the public cloud, if you have multiple node groups, so it would separate the nodes based on the node pools, node groups, depending on which. Oh, yeah. Because all the provider you are. All the notes have topology aware annotations. I guess you're breaking them down for people so that a lot more visual. It's just based on the annotations. We we try to match with the known ones. So if you're

42:41 Nodes and Storage

43:16 from the major public clouds, then it it would work for those. And the RBAC. So this is basically the same thing we did for service accounts. It's just it would show permissions allowed to users and groups. Yep. But my customers only have one role, cluster admin. I just give everybody cluster admin. So I just keep stars everywhere. I like stars. Yeah. But I think there should be other ones. Right? They're about 11. Yeah. There are more. Go by. Yeah. So if you go to maybe second one or it has much more bindings, and you can see that the matrix

43:57 gets much more complicated. But you don't really have to dig into each individual binding. You can see what is allowed to that user. Awesome. This is something not really available in in standard Kubernetes. You have to go roles and bindings one by month to kind of figure out what is allowed to that user. Here, it's like showing those those bindings in a reversed approach. Yeah. Based on the how how would you would approach the the bindings in the in the role? Yeah. You've got this kind of pattern, which I'm really appreciating as we browse around, where you have these little icon annotations

44:41 that immediately kinda draw my eye, and I'm like, oh, there's there's something about this one I need to be aware of. So the fact that these service accounts are are shared, so you've got cascade independence as you kinda write the call out here. And this you know, I'm sure we've seen this on the logic with the the pods as well. Yeah. And you've got, like, warning and stuff. So I like the use of that little tiny bit of iconography across place, which is quite consistent. It just pulls my eye towards it, and I'm like, oh, I should take a look

45:09 at this and learn a bit more about my cluster. So nice touch. Yeah. Thanks. So that hand icon, it comes from Windows era with the from the shared folders. So the idea is that, let's say, you wanna jump in and make changes to this binding because you need to make changes to your group. Right? So what it means that if you were to make changes to this binding, it would affect other users or other bindings as well. Yep. Got it. So that resource is used in other places. And to know which other places it's used for, you can just click

45:48 on it. It will show what are the other places it's used. So it says shared with this other play. Yeah. Kubebly config. And Yeah. And it and it's also clickable. You can see what is it. And over there, it would say it's shared with this with this group. It just shows what would be the blast radius, what would happen if you were to make changes to this config map or secret or Yeah. Or the binding or the role, let's say. Okay. And just to clarify, like, Kubevious is read only view of my cluster. Right? Like,

46:30 Kubevious UI: Read-Only Interaction

46:34 it doesn't give me the ability to modify anything. It's there as a way to inspect and understand what is actually going on within my cluster. Yeah. It's it has been highly requested to to allow you guys to edit things. It's probably one of the things that we try to push back with. Once we start making changes to the cluster, we're we're getting into a very scary territory. But we made some users happy if you go back to Logic, if you or open one of the manifests. Let's say if you can drill down into anything, service account.

47:14 So yeah. So if you can make this config bigger, there is a maximize button on the top. Yeah. Now you can click on the pen. It would get into the edit mode. So it cleans up unnecessary things like manage fields. So you can edit in place and either copy and paste or download this file. And so with and it's read only. Yeah. And you can also choose what would be your tab size, two or four. I like two. But, yeah, you would you would download the file or copy and paste, and then if you wanna apply changes,

47:26 Edit Mode

47:53 just go for it, but Kubevious cannot do it for you. Trust. I think I I like the way it doesn't allow me to do any direct edit in the against the cluster. So I'm gonna I'm gonna say that's good. What's this timeline view? Oh, this is changes, errors, and warnings over time. Okay. So this is the time machine. It shows you the hard bit of the cluster. Maybe we have to wait an hour or so just to get more data populated. But you can see three series. One is the white line which shows the amount of changes happening in the cluster.

48:07 Timeline View

48:30 The red and amber are number of errors and warnings within the cluster. And, usually, what you would say is that you may make a change that would cause a spike in changes, and it would lead to increase in errors or warnings. And that particular time, you can just click on the chart. It would activate the time machine, and anything you see on the UI would be frozen to that particular point in time. And you can do your debugging. You can see why things worked before, why things didn't work before, and kind of slide it a little bit

49:08 left and right and see how it was. We can later on, if you want, we can open up the the demo portal, which already has some data pile populated, or we can wait a little bit. And towards the end of the session, we can try to see how things change. Okay. Well, let's zoom this back out a little bit. I'll zoom in as required. But that's the that's the browser tab. This is our single pane of glass and to everything inside of our cluster from applications, containers, helm charts, Rawkode, Rawkode, and even CRDs. So, yeah, that's a that's a nice feature.

49:38 Transition to Kubevious Guard CLI

49:53 I'm liking that. Are we gonna move on to the guard tab next? Yeah. Let's let's go. Do you have some changes in mind that you would want to apply to the cluster? I mean, we can definitely think of something. Yeah? Let's create a deployment and and try to apply to the plaster. Let's say some some trivial app, maybe engine names or something like that. Well, let's see. And we did deploy I thought I deployed metrics server. I must have deployed it to the wrong cluster. Oh, well. Alright. So we want to deploy need the metrics. Yeah. Engine x. Right? So

50:00 Preparing Manifests for Guard

50:41 let me just say Kubevious directory. Pop open code. Wherever it is. Mac. Oh, no. I'm gonna quit it and open it again. I don't know what's going on. My computer just said See, it's not it's not only Kubevious that does it for the first time. It's a it's a pattern. Oh, that is funny. Alright. Yeah. So I have a small tiny monitor in front of me that runs a preview of the stream, and my Versus code is heading behind So I'm gonna have to turn it off for a moment and then move it and then take it

51:31 back. Why are you there, Kube? Come on. There we go. Alright. Computers. So, yes, I trust this. I'm gonna create an nginx dot yaml, and we'll spec out a deployment that runs nginx. Is that enough for us to play the card? You know what? Let's let's make it more interesting. Let's let's let's have a another config map within the same namespace, and let's mount it as environment variables. Okay. NGINX password secret. K. Yeah. And you want to do an ENV from Mhmm. Config map NGINX. Okay. And to make things even more fun, let's make a typo either let's

52:34 engine double edge or, either in the reference or yeah. Okay. That's fair. Yeah. So you want me to apply this? Since let's assume we're in a in some CD pipeline before doing KubeControl apply, we wanna kind of sanitize and kind of check or link those changes whether decide whether they're good or not. So let's go to the guard. It should have just one or two lines of instructions. So this is what it wants. It wants you to basically pipe the contents of the manifest into a special strip, And that script would take those manifest. It would upload them to

52:59 Using Kubevious Guard CLI

53:21 the cluster, and then Kubevious would be listening to any change requests. And then it would reply whether it passes or not. Oh. That is right. Yeah. Some point, we're going to have a self fully self contained CLI. It's just this was the faster fastest way to get this out and running. Alright. Let's see. So this is reading the input, pausing it, building some sort of package. We have some It has to yeah. It's creating the resource, which is oh, okay. Does it work? Let's go to the UI. Maybe I didn't see if the file was

54:18 broken, but oh, maybe I did. I'm not sure. Okay. When we come back here Yeah. If you click on it. Okay. So it has two changes. You can click on every single change. Deployment. EMV from config map prep. Engine nine. And now the other one. Yeah. Okay. So can you go to the validators? Mhmm. So this is the list of all the checks that Kubevious can do by default. So one of those should be okay. Unresolved conflict map reference container environment variables. Yeah. So if you click on it okay. So it was supposed to is it by default optional?

54:50 Validators

55:20 It's in the header. It's supposed to be error. It was supposed to fail, to be honest. Yeah. Let's do can you try to add the optional false? Yep. And then just run this again? Yeah. Oh. Oh. Alright. Alright. Let's then if it says it's good, let's let's apply those changes with TubeControl apply. But let me tell you one thing. This the guard is relatively new development even though it should work, but there are sometimes issues with that. Alright. So we have our create container config error from the conflict map being unable to resolve. Oh, okay.

56:04 Applying Manifests & Verifying Errors in UI

56:31 Can we can you reference the config map from not using from from, but using just the mapping referencing the data? Yep. So we want name. Correct. And then oh, and then config ref. And the name. Name engine x pick. I think that's valid. I can't remember the last time I used that syntax. Let's see. Okay. We have to Well, there's there's a lot a little bit. There's a lot of validators here. Let's try another one. How about Mhmm. Let's let's add a service. If you can add a service and reference the the NGINX. Alright. Let's do it.

57:32 Add a Service

57:41 So blah blah blah. Service. Engine x. And you want me to break the selector? Yeah. I wanna use another selector. Yeah. Alright. And we'll run our validator. Okay. Something is off. Something is really off. It's probably something for the demo? No. I think let's get back to the guard and see if at at least it could kind of record the the attempt for changes. Yep. I can see the service here. It's metadata name, fake engine apps, and the other one is not fake engine apps. Right? Yep. There's no fake engine. Let's apply that change as well. I wanna

58:45 see if we would see the errors in Kubevious. Oh, wait. I got something wrong. Okay. Explain deployment spec template spec containers dot env. Oh, value from Yeah. And then config. So that was that probably was my fault then. So value from. Try that again then. Okay. If you go back to the okay. If you go back to the EMV from. You can do that. If you open up the file. Mhmm. Okay. So there is an array. EMV from. Okay. This looks good to me. My explainer says I'm wrong. Oh, it wants a key. It wants

59:57 a key. Inside that. Yeah. It wants a key. The name and the key can be it can be password. Right? Name is engine x fate. The Okay. Yeah. Okay. Yeah. Now let's try. This is so odd. Alright. Looks like regardless what we do, it kind of takes the changes. It's it's it's says it's all good. I wanna see what's going on in the browser. It it takes five minutes to refresh. There is a pause of five minutes after every after every single change is detected. So if we go back to browser, we should be able to see that in in

1:00:59 the default. Yeah. Okay. Click the button. Now. Yeah. Yeah. Okay. So it could see all those errors. Like, if you maybe open make the window a little bit bigger from the, like, bottom tool window, So you can see all those errors under the alerts. Yeah. That was it. Oh, yeah. Could not find contact with that. Yeah. Okay. So the drawer doesn't work. Alright. Yeah. I'll we'll we'll have to take take a look and see what what's going on. But Well, this is open source as you. So, you know, do request welcome and open issues. Whatever you think about, you'll open an issue.

1:01:47 Yeah. Can we do one more thing? Yeah. Of a process. If can you restart the guard pod? Yeah. Was the service guard definitely on? Yeah. It's on there. Okay. Alright. Let's restart it. Yeah. Yeah. Yeah. We have logs from that pod? Yeah. We should. There is a guard if you can open up the logs for it. Can you get logs, Rick, of this UI? UI doesn't have logs, but most of the things are in the back end and the I'll draw this here. Can you just chill it? It should come up pretty quickly. What happens if I run a guard just

1:02:44 now? It it it it will just take longer to run until. Yeah. That's I'm really surprised because, I would think that it couldn't kind of there would be an issue with hydrogen delivering those, manifests. But yeah. So the promise is that it's supposed to run the same changes based on what changes kind of issues that you would see in the browser, but it it's supposed it was supposed to prevent those changes. Let's can we do one more thing? Yeah. Go for it. Can you I'm just guessing. Just add a namespace reference in your manifests. Just add a namespace default.

1:03:43 And you want me to run it again? Yeah. Yeah. Okay. Yeah. Okay. I'll have to take one One more issue request. Alright. Alright. So in this validators, this is how it was supposed to work. So if it hits an issue from this validator's list, if it's in a error, if it's marked as a to be treated as an error, then it was supposed to, prevent those changes from getting to the cluster. If it's disabled or it's at the word level, it would be informational. Okay. That makes sense. Yeah. Same would be kind of with the rules.

1:04:08 Validators and Rules Explained

1:04:41 So rules allow you to write your own checks before writing new rules. Maybe that's a little bit more advanced, but maybe let's try to look at existing ones. And if you really wanna write your own rule, we can use the browser that would help us writing the rule a little bit so we don't have to do it from the stretch. It consists of two tabs, two tiny little bit of scripts. The target is supposed to navigate similar to the browser. Basically, you would navigate and land on a particular node in the UI. And in the rule strip, you would determine

1:04:56 Writing Custom Rules

1:05:24 what to do with it. So we can run all sorts of conditions, checks. It's written in JavaScript. And then in the end, you would either raise a warning error, or you can associate custom icon. So for example, in this case, we're going over pods and then drilling down into containers. And if the resource limits are not set, we would say there are no resources limits set. And then you can see there are seven such nodes that are hitting this rule. On the on the top, you can see the affected object seven. And you can see those are the pods

1:06:04 that are that do not have any resource limits there. Alright. I'm gonna try and build my own there. I'm feeling brave. I'm gonna cancel this, and I'm gonna say pod has no team. I'm gonna steal your selector. So I'm just gonna go select namespace. Don't worry about Kube system. We're looking at descendants, which are pods, and then we have this thing called a script. Now in a script, I actually don't need to look at the containers here. So I'm assuming I could say if and item config metadata dot labels. This is gonna be something. And I wanna do a warning,

1:06:59 No team owner. No. This is a map. Is this just plain JavaScript? Like, actual real stuff? Plain JavaScript. This is real JavaScript. Alright. So what I wanna do should be a dictionary. Yeah. Yeah. So I could say team. Yeah. That would probably be enough. Right? Because that would return undefeigned. The team doesn't exist. Yeah. So I'm gonna create create it. So we'll we'll need to wait a couple of minutes until there is a next, next run. But Yeah. I think that should work. So I like that. An easier way to do that. There is a much easier way to do

1:07:42 that. So while it's thinking, let's go back to the browser. Let's find something real that you would really want to check. Because right now, it would raise this, warning on every single pod. Right? Mhmm. Let's land on either on NGINX or somewhere. Maybe we can do run some checks on top of Argo CD because it's pretty complex deployment That was compared with this engine. Cluster. Oh, or we can go to Kubevious. Mhmm. Alright. So Kubevious namespace. Kubevious. There is a back end or the parser, which has service accounts. We can check for app permissions or card or MySQL.

1:08:38 Okay. Basically, if you decide on which node you want to run oh, okay. Let's go to container. So there is the image. You can run checks on the image or config maps that are mounted as environment variables. So if you go down to the rule assistant. Go down. Draw down. Scroll down. Yeah. Just you can do create new rule with assistant, so it would prepopulate the the target script. So you can do there are different syntaxes. So, you could use basically the top example just to target every single container, or you can use the lower one that would target only that one

1:09:28 that you you saw in the UI. So meaning, the less you specify, the more broad would be the check. Mhmm. So in this case, it would basically target every single namespace application container. Yep. Otherwise, if you would use the bottom one, it would be kind of more specific. And then if you go to the rule strip, it would show you the examples of what would be the values of different properties. So this way, you can anticipate kind of it's all it gives you some hints what are the current values of that particular node so you can

1:10:07 expect what would be the values and what rules to how to write the rules. Okay. I could drop this in like this. This gives me item config. And then from there So that would be the result of item dot config. And then you can do dot ports or image. So, like, this unsafe image. And I know that this image is Kubevious parts or I'll just copy this. So we have a target here. It says, look in all containers. And as the image is Kubevious parser one zero eight, I log a warning. But you said there was other ones here. Can I

1:10:54 do an error? Yeah. Yeah. Yeah. Okay. So Just name it. Allow parser image. Maybe we wanna restrict our cluster from running this specific version because it has a vulnerability or whatever, and then I I click create. What I also noticed while we were doing that is our our pod node team worked. Yeah. Mhmm. We can actually see every object. No. I I mean, I trust you, but I'm gonna modify that in GenX. And I'm gonna add labels team Rawkode, and I'll reapply that. So we should see within the next few minutes that my Rawk my NGINX partners satisfies

1:11:37 this rule where it has a two. Okay. So now if we go to the browser, that could be the top issue in the summary since it's it was hitting couple of pods. Okay. So there is if you scroll more, service account not used, there are probably much more service accounts than Yeah. Pods. Yeah. So that's the rule. So and those are the instances that are violating this rule. And those are also clickable. Once you click, it would navigate into the corresponding view where you can do much deeper debugging. Nice. So question Just click on it and Question

1:12:21 Feature Request: Rules as CRDs (GitOps)

1:12:21 or feature request. I'm not sure what I'm about to give you here. Mhmm. I I really like these these rules, but I'm not sure I'd wanna type them in to the GUI. Can we apply them via GetOps fashion? Is that something that's on your road map? Like, a custom a custom resource definition for a Kubevious rule that KubeControl applied to my cluster. That would be really sweet. I think we can do it. It's pretty easy. Yeah. Yeah. Mhmm. Alright. Sorry. You were gonna say something, and I interrupted you. Yeah. If you I just want to say, if you click on any

1:12:57 of those links, let's say the larger namespace, so it would navigate, and you would be able to see that yeah. Indeed, we don't have those we don't have those labels set on those parts. Yeah. Scroll down. Yeah. You you will see the manifest there. Oh, it even is it's the labels as a separate property set. Oh, yeah. There you go. So for that, do you mind to open an issue request on GitHub No. So that you would be notified whenever it's there? Sure. GitHub Kubevious. It can be just one line. This is what open source is all about.

1:13:50 Right? Yeah. Feature request. Right. K. Make Kubevious rules a v r d. I'll come back and edit this issue. I promise. But I have opened. Mhmm. Yeah. Thanks. That's Alright. So what are our markers? Okay. So things are not always good or bad, like one or zero. Sometimes you may want to find things that are of a special interest to you. So markers allow you to check for rules without raising errors, but instead associating special items with your workload. So for example, in this case, by default, it comes with several monitors. It's for workloads that use

1:14:24 Markers (Highlighting Points of Interest)

1:14:55 too many too much CPU or memory or or or average size of CPU or memory. So this is just an example, and you can choose color on the icon from the predefined set. Yeah. I'm pretty happy that I have my notes here now. Yeah. So yeah. Yeah. And just like in rules, it would have affected object. Right? And so now it's it's the it's the snowboarder already. So you click on it. And the way you would associate markers is instead of doing calling the function error or warning, you would do marker and the name of the marker. That's it.

1:15:39 So if you go back to the rules, you would have one of the rules would do that probably. Container memory usage, probably that would be the one. But can I do it here instead of having an error unsafe image, which has actually no match one, which is great? That's exactly what we wanted. But I have to say, you know, this is not an error. So you're saying I can do marker? Yeah. You would just say mark without marker. Yeah. And the name of the of the titan. Oh, should have paid more attention. Just Meet your memory user. Okay. Just create a

1:16:19 new one. You can just create a new one. Uh-huh. Alright. Okay. Mark. Yeah. Livestream. Yeah. Now we go there. I don't think it's saved. Rule oh, no. It does save. Okay. It's just because I gave it a silly name. Okay. Oh, yeah. Yeah. You you you can hide that UI with the with the with an interesting naming. Yeah. You just create new one, add new marker from the top right corner. I guess we'll need to wait a few minutes for the rule to rerun. Oh, you don't have to wait to create the icon. And once

1:17:02 it's it's run, you can change icons. Just type a name. Choose the icon. My livestream. Alright. Hold on. I have to find the perfect icon. Pizza? Or Yeah. Pizza. That's a good choice. Yeah. Let's go with an orange pizza. Cool. We don't have an effect on the object yet, but we'll wait. Yeah. Once the rule runs, then you should Is that what this icon means? Is that it needs to run again? It means you yeah. It means you made some changes that were not yet picked up. And during the next run, you would it should be picked up.

1:17:52 While it's running, there's another capability. It's a Google live search. Maybe we can instead of waiting, we can just try that. Anything interests you in your cluster? Anything you wanna find? Oh, I I'm not sure what I can search, but let's say I wanted to find all resources that are tagged with team Rawkode. Was that something we can do? Maybe. Let let let's let's try. Mhmm. I'm just gonna guess. Oh, I get all complete. Oh, you're too good to me. See, that that's joy face. I like it when that answer. Yeah. Yeah. Okay. Nice. So

1:17:55 Kubevious Search

1:18:37 we can actually see here we have an application, which has a deployment. We got NGINX, and we got our resources on the namespace here. Okay. When when you give me autocomplete, I'm a very happy person. Yeah. Let's try. Let's see my livestream piece. Okay. We're still waiting on you. So that means medium memory. I'm not sure what annotations we have in the cluster. Let's see. Okay. Max replica. Don't know what the value would be. That was the silly one to pick. Vision by? No. That's not gonna work. I don't know the annotations in my cluster, so

1:19:29 I should stop guessing. Yeah. Yeah. Or or you just could just use a free free text search kind of thing. Yeah. Alright. It uses the hierarchy to to find for things. But since things are kind of loosely connected, you can search for port numbers or names of your apps or config map or your or, I mean, volume mount points. So it's and you can add as many criteria as you wish to to file to land on the things that you're interested in. And it uses, fuzzy logic. So if you if you're even if you make a typo or you're

1:20:15 looking for something similar to the term, then you should be able to find it. Yeah. It's a bit quick. Nice. Yeah. That's a really cool feature. I like the UI and the search there. They all complete the breakdown of labels and annotations. I'd love to be able to filter by the the image as well. There's another feature request for you. Alright. Thanks. Not not maybe oh, yeah. You can do that. Right? You can do that from the browser because yeah. Okay. In the search as well, you can just type image Kubevious. That that should work. Just try.

1:20:56 Oh, yeah. No. Just without equals, think you can even do image space Kubevious, or you can kind of filter to be more strict. You can filter by by client. By what? Sorry? Website. There is a the first filter by client, you can search by one single type of object. It will bring you kind of a flat list of all images used. Nice. And images used within the namespace or within an application. So Yes. So we can actually see Redis here because that's used by Kubevious. Redis. Yeah. Alright. Nice. And I have my livestream marker. Look at

1:21:45 the livestream. Yeah. This is a lot of really cool components. I think we should try and summarize what Kubevious does. I'll try my best to describe everything that we're kinda sticking to look at today. And then if you wanna kinda if you're happy to share what's coming next for the project, that would be fantastic. So my quick one minute summary then of Kubevious is a tool that I could deploy to my cluster. We started off by exploring the browser. The browser gave us a hierarchical view of all of the resources within our cluster. We started off with a high level summary,

1:21:50 Summary of Kubevious Features

1:22:22 and let's just say, let's see some of the namespaces and stuff that you've got. And then you provide some sort of a, I don't know, monitoring observability thing where you can actually see a breakdown of the top namespaces and the issues as well, or the issues within our namespace. The logic allows us to break down our cluster by the types or kinds of resources that we have, starting off by namespace and then break it down into I'm sure I could click that previously. Yeah. Those are If there's no resources. Yeah. So if you click on our next

1:22:55 issue, that gets a breakdown. You get to take a look at the applications, and then not just the applications, but the containers and the volume to the service accounts, etcetera. So really good ways to drill down and understand what's running on your cluster. The same happens for images, for gateway and ingress, which unfortunately we can't take a look at on my local one. We also get a look at Helm repositories, which is something which is actually quite difficult to do normally. I don't have great visibility into what Helm stuff is in my cluster, so that's pretty nice.

1:23:22 And then the RBAC one, I think, is the cherry on the top of this browser mode. Like, understanding RBAC in any Kubernetes cluster is always it's it's always a huge challenge. And what I really loved about this feature was the shared symbol, the one that showed yeah. Here we go. This that this role that role here, the Kubevious contact one, is actually shared across multiple service accounts, which is very, very cool. We now take a look at guard, which is a tool that allows you to pass a manifest to the Kubevious instance inside your cluster and report on violators,

1:23:56 and the violators are all defined here. You can disable them or set them up to be warning or error. The one thing we didn't cover is can you add your own validators, or is that something that's coming later? Yes. If you wanna participate, contribute to the project, you can. So for a runtime addition of web checks, it would the rules would be used for my deeper integration of checks, more sophisticated ones. They would have to go through the open source realm. Okay. So these validators influence the browser and that we can see all of the different

1:24:38 errors across all the different resources. On top of the validators and errors, we have the ability to write custom rules that can be deployed to the cluster and scan in resources for different violations. Here, we scanned for a specific image that is being used in the cluster, and we have the option to set either a warning on it, an error, or just a marker. And markers are nice because you get to pick cool logos and colors, which just makes it all a lot more pleasing. So that's that's Kubevious. And if an MS that you wanna highlight before I ask you

1:25:11 what's coming next? I think, yeah, that's a really awesome summary. I would I would probably add that next, we're gonna definitely fix the guard so that it would it would not allow those violating changes from getting to the cluster. Except for that, we wanna do more integration with cloud native ecosystem. So what I mean by that, we didn't try the the gateway. We didn't try addresses, but there was a recent addition and integration with traffic proxy. So if you're a traffic user, Kubevious would validate that, like, the namings of middle layers, the TLS options, and things of

1:25:15 Future Plans for Kubevious

1:25:58 that sort that come with traffic. And if there are any issues, it would kind of not only render those configuration in the gateway view, but also would validate those. So we wanna include more support for such highly highly rated, highly used popular open source projects, like probably it would be in the service mesh and network policy enforcement. So that's another area of of high interest for Kubevious. We wanna open up rules in a form of rules library where people can contribute to a public library and download rules from the public library as well with some

1:26:39 sort of search engine instead of writing their own rules manually. And that's another area for the focus. I would only add that, of course, we spent very little bit of time on the types of rules that we developed right here and was one of the most trivial ones that checked checked one single or or just a couple of variables within the manifest. I think the greatest power comes in when you would start writing rules that would consider charts that go across manifest. Let's say, I wanna find applications that have the certain label and that have certain permissions to my cluster

1:27:23 that have a read access to my secrets or something from that sort. I think the greatest power comes from there. Awesome. Very, very cool. I'm curious about Guard. Is that something that you see would become an a validate in admission controller in the future rather than a curl locally, or do you think it's it's more advantageous to have it blocking or given a warning at CICD? Or maybe it's a combination of both. Like, how do you see that playing out? Because of limitations, it would have to be a combination of both. Because in the admission controller,

1:27:36 Kubevious Guard and Admission Controller Potential

1:28:03 we can only validate one single manifest at a time, and we don't have visibility to other manifest. Right. There is a limitation. So there are some ideas to kind of detect whether the rule spans across manifests, then it would be have to be validated from the Dart as a separate CLI integration or something of that sort. But the rules that are relatively trivial, they're kind of self contained. We would be able to do the validation in the admission controller as well. So this way, there would be three levels of validation starting from the CLI admission controller,

1:28:44 and there would be continuous validation that is happening right now that we've seen in the in the UI as a final check, which would be could be used as for auditing purposes or forensics or anything of that sort. Awesome. Well, this is a really cool project. I wanna thank you for spending time with me today and kinda sharing a little bit of history and motivations and having a kind of look at each of the features that are available here. I've gotta say, like, right off the bat, the UI is is brilliant. I don't know who you have on your front end team,

1:29:01 Conclusion

1:29:19 but cherish them and keep them forever because it looks great. And and Yeah. That that they're brilliant. Yeah. They're brilliant. Thanks a lot, David. It was really fun to I spent really fun two hours. It was really cool to see you jumping in and writing rules and debugging the issues. Yeah. And thanks a lot for your time. It was really cool. Alright. Well, thank you again. Have a wonderful weekend, and, hopefully, I'll speak to you again soon. And to everyone watching Likewise. Thanks a lot. Likewise. Take care. Ciao.