1:25 Introduction

1:25 Hello, and welcome to today's episode of Rawkode live. I am your host, Rawkode. Today, we're gonna be taking a look at one of my favorite tools for managing Kubernetes manifest. That is Kapitan. It helps reduce the complexity or manage the complexity of your Kubernetes Terraform and other deployments and configurations. To do that and to join me today, I have Alessandro and Ricardo from the Kapitan team. Hello. Hi. Hi. Hi, David. Thank you for having us here. No. It's my pleasure. I really do mean it. See this is one of my favorite tools. I'm really glad that I'm joined by

1:59 both of you today, and we can share that and show that to everyone that is watching. Shall we start briefly then with some introductions? We'll start with Alessandro since you're first on the screen, and then we'll move down to Ricardo. Yeah. So my name is Alessandro de Maria. I'm head of SRE at Synthes, a company that deals with automation in biology. So it's a it's quite a a a relative kind of a a field, know, in in this case. And I used to work at DeepMind before, so that's where I met Ricardo, and we got together to work on on

2:36 Kapitan. So at the moment, it's, I think, three or four four years that we've open sourced it. And I think this year, we've seen much more interest, and we want to take advantage of as much as we can view on everybody else in the community to see if we can make it more popular and give it, you know, better better opportunity. That's for me. Cool. Hi. I'm Ricardo. I am currently a software engineer at Google. I think it needs no introductions. More specifically, Google Health. And be before that, I was also a deep mind, as Alessandro

3:15 said. And we were running a team of SRE there, and that's when we, you know, had the idea to create something like Kapitan. And thank you for having me here. Awesome. Thank you very much. Alright. So why don't we start then and just tell people what Kapitan is? Do you wanna give us the slides for that or do wanna talk about it first? Yeah. I think the slides is a is a good way. We try to I think let me open, make sure that they are open. Yes. So we try to it, and pretty much every time it comes

3:35 What is Kapitan?

3:51 out in a different from a different point of view. I don't know if these slides are already visible. Yeah? They are. Please. Yeah. Yes. Perfect. Yeah. So Kapitani is a tool, again, that we created in a deep mind at the time where, there were fewer opportunities, fewer other tools. I think, Helm was already, out there, but we were looking for something slightly different, especially because we were we had a a very kind of particular setup with DeepMind Health where we were we were working on lots of components that we were doing doing ourselves. So I'll start with with this kind of slide

4:34 just to explain a little bit what led us to to work with to work on Kapitan. With Helm, sorry. With with Kubernetes, we realized at the beginning that there were so many resources, so many manifests for each given workload that we have to manage. And, pretty much, we realized that, a good part of those resources were, well, ball boilerplate. There were some application specific kind of configurations, and and they were also, like, environment or release specific. But pretty much, you you kept repeating the same kind of configuration over and over and over. And while I think other tooling like Helm was

5:22 had the advantage of a a packaging kind of application that were written for, like, off the shelf kind of application. We were looking at we were not gonna use that anyway because we were developing our own application. So we looked at it in a in a different way and from a different perspective. And, I think the point is that we wanted to be able to not just configure, the one application, but to, like, act actually manage the full deployment, the full environment. We wanted to make sure that if you, if you write a piece of configuration information

6:01 of something that you have it within your infrastructure, you could share it across many other systems. And I think probably this is what we are going to explain today. So first of all, now mean, this is now jumping to, nowadays. We have Kubernetes resources coming from many different places. So we have, like, a Helm charts, which is, by by far the most popular way to get, kind of a to get started with Kubernetes. We have customized. We have some controllers that sometimes, like, create new inject kind of configuration right into the cluster, and many other kind of different ways that

6:44 you basically end up using every day to, to to get your deployment, to get to get your infrastructure running. With on top of that, there are new CRDs being added every day. So it it is really, if you look at, from a from a user perspective, if you imagine how many resources you have to deal with, when using Kubernetes is just a a a huge amount a huge number. And so we started to to look at, you know, the this kind of tools. So we we keep comparing with what's out there. Like, the most, known,

7:23 tools are Helm, Customize, Tanka. There are many others. I don't want to include all of them. But I I think pretty much what the the reason what led that led us to develop Kapitan, we still haven't seen, like, an alternative for to to fill our need is that most of these other application tend to focus on one component at a time or one application at a time and don't have, like, the the ability to capture the full deployments or the full setup you have across all your infrastructure, at least not in the way that we we we we become

7:57 used to to do. They don't allow to or or promote the reuse of configuration data. Oops. Configuration data. And I think, in general, every year of these kind of components have a slightly different kind of approach for for some aspect of it. So the way you deal with the secrets on Helm would probably be different than you do it with customized probably different than you do in Tanka. Yeah. And in general, I think another component, I think this is something that would become more clear when as we go through the presentation is that we all these components that all these other

8:43 systems tend to defer rendering the produce manifest to the last stage, while we think that managing the the compiled the rendered version of the of the manifest is is a is an important feature that helps us, when we want to, review our changes. So and again, in general, these are all kind of Kubernetes centric. So at the end, it's like you have this idea that everything you will be dealing with in on a day by day kind of everything to do with Kubernetes. In reality, we have many other components. And this is what, I mean, gives

9:24 gives brings back to the idea of we we always call it a generic configuration system. It's that the same system can be used for Terraform, can be used for Istio, can be used for Spinnaker, pipeline, can be used for Ansible, and and for many other tools. We've also seen that some people are using Kapitan for for for generating basically a configuration for their internal or legacy tools. And we wanted to be able, from a center point, to manage playbooks, documentation, and dashboards. I realized that in these slides, I'm pretty sure I have it somewhere, but I think it's it's

10:10 in a little bit. I think I I these are basically setting up the the kind of understanding of what Kapitan is and what we're trying to achieve. We're trying to to give you a single place from which you can manage playbooks, documentation, dashboards, and every systems that you have out there, ideally. And so, basically, with that consideration, we were trying to basically have that one single thing can control all of your infrastructure. And this is basically what I'm trying to to explain, to introduce what Kapitan actually is. Kapitan is effectively a a tool that allows you to generate

10:50 files to be consumed by other systems. So it doesn't Kapitan is not a tool for Kubernetes. It's not for Terraform. It's just something that somehow does its job of creating configuration and then gets out of the way. And I think this very generic approach has the the the benefit of allowing you to pretty much enable the same workflow and the same kind of approach when managing different classes of, systems and different classes of technologies, which is unfortunately where we stand right now. We don't just deal with Kubernetes at the moment. We deal with many other kind of systems at once.

11:37 I think this is a a stop right here. I think I talked already enough, and I don't know if you have already questions regarding this. I also realized that I don't have a view of a of a of you on the screen, so I'll just quickly move the move the presentation out of the way so I can position it somewhere else. Otherwise, I don't get any here you go. Alright. Very good. Back back here. We're we're back on the now. So thank you for that those intro slates. If anyone watching has questions, please feel free

12:02 Key Concepts and Features (Inventory, Targets, Classes, Generators, Workflow)

12:09 to use the comment section on YouTube. Leave a comment to us, and we'll do our best to handle them as we go or group them at the end depending on how relevant they are. Now I think what we should do is just get started. Right? We're gonna show people how this works, how to install it, and how to start using it. So So we sorry. We we I do have more slides. I didn't want to just I I just wanted to give you the time to to you know, if there was some any specific question right now.

12:36 Unless you you think we should we should move on. But I I just wanted to quickly explain some basic concept before we move on. Otherwise, you you you know, up to you what what you want to do. No. I mean, that's what I was when I pulled up the website there, I was literally gonna go through the key concepts to give the the audience a bit of a vocabulary and what that means. Okay. We have slides, then that's perfect. I think I think yeah. I think we have slides with that, and we we let's see if if we made

13:00 a if you made it clear and and if you can help us later. So let me go Your slides are visible. Yeah. Here we go. Yeah. Now I I can see myself before I was a bit blind. Sorry for for that. So, like, Kapitan, first of all, comes with batteries included. I mean, the tool itself has a a a range of features, which we will discover through the website as well. So first of all, we have this concept of the inventory that allows you to reuse values and share configuration data across many of the systems

13:36 that we will be dealing with. So you will be able to define the configuration for something and reuse it in a cup Kubernetes, Terraform, documentation, and so on. So that's the the kind of first thing. Second, the same inventory data that you have can be reused through a number of very powerful into input types. So you can use, Ginger, JSON, it, Cadet, Helm, or other kind of tools to to render, to create, templates for whatever you want to whatever your task is. And I think the the third important key is that, Kapitan handles natively, secrets with a with a very kind of

14:20 a very nice kind of a support for, for secrets. And we handle the majority of secrets back end with the the ability to easily extend to to add more and more secret back ends as we go. And in general, we have a, like, a an an external ability to fetch dependencies externally. So instance, because we have the Helm integration, we can fetch Helm right from the repository, and we can now just bring it in through through Kapitan. So the inventory is I think it's the it's the the one concept I wanted to be able to explain. The inventory

14:55 is basically becomes the single source of truth for Kapitan. So it's a a YAML based structure that lets you define configuration in different files and then merge them together in a way that it makes sense to you and in a way that I think will become clear as we start using it. I think so sorry. Sorry, Ale. The thing another thing we can say is that the the inventory is somewhat inspired by the puppet Hira. No. It's essentially a essentially a tree of values that you can refer to within your programming of templates. So you can always

15:34 ensure that the values exist somewhere. You don't have to have them hardcoded in your code, but they'll belong in the inventory. That's the idea. So, yeah, define it once, use it multiple times, use it across multiple targets, multiple templates. And the basic idea revolves around the concept of a target, which is what what you are working on. So your current project you're working on, and classes, which is pieces of inventory that you can share across different targets. The the one new thing that we have so if people have experience with Kapitan before and they run away from it because they

16:13 thought it was too difficult, the one thing that we would like to show you today is this kind of new approach that we have to easily generate configuration straight from the inventory, which I think is extremely powerful. And I think this is what if we have to if we have to do any demo or any kind of a a way to show how to use Kapitan, and I think that's that's what we we will be doing today. So there is no JSONET doc cadet at all. So if you if you've if you've always associate associate Kapitan

16:49 to just on it, it's a a a it now becomes clear that JSONET is something that can power Kapitan, like Cadet or Python, but it's not necessarily the only way to to experience it. And the way to describe is like a a a very powerful plug in where you can define something that you want to create, the Kapitan will generate it for you. So we can go that in a into into details soon, but the plan is to release at the moment, we have a Kubernetes one, which we will be playing with today. But we will the plan is to release more

17:20 and more generators as we go as we go along. And any I think, probably pretty much, this is the last part. Everything else, I think we can even go back later. But this is basically the workflow we will see today as we play with the Kapitan. So you will be editing the configuration in Kapitan. Usually, we generator usually will be editing the inventory. So every edit editing kind of a YAML structures. Kapitan will compile and create outputs for you, like output manifests. And once that kind of review process has finished, you you do what you want to do

17:59 with those outputs. Most of the time is to deploy to your environment. They can be anything else. It can be including, you know, like, a running script or generic documentation and everything else. And I think with this, I've covered the main concept. There is a little bit more, but I think we can, go on with the with your demo and and the on the website and and we can see we can discover new things as we go along. Alright. Perfect. Thank you very much, Alessandro. Yeah. I I mean, you you've covered so much of the project there that I just

18:35 I think I'll highlight a few of the things that that I really like about Kapitan. The first one is just the way that I can actually have reusable composable artifacts by using this, and it's not a case of, like, this hierarchical designer if I have to inherit a whole manifest and then be able to, like, overly tweaks in a weird way. Like, I feel like that constraint is removed from me, which I think is really powerful. The secret management's built in, I think, was one of the reasons that I got drawn to it in the first place, not having

19:03 to manage and deal with, you know, sealed secrets or or SOPs and also tools and trying to daisy chain them together was a big one as well. And I guess lastly, a feature that you haven't mentioned, but I think it's really important is that every time I say the name, I sing El Kapitan by OPM, which I think is is really important to having a happy working day for me. So that's really cool. Now, let's get started. Right? We have to do that? Okay. Let's do it. Yeah. Absolutely. Okay. Let's see. So this is the

19:30 Getting Started with Kapitan

19:36 Kapitan website, and we are gonna go to the getting started page. Or do you wanna start somewhere else? I'll let you two guide me a little bit here. No. That's good. Yep. Overview is good. Alright. So we need to get Kapitan installed. Oh, Sam, you're have to go back and see. So I I yeah. I think if you if you probably the best way to if you go back to the homepage and if you follow the Kapitan reference, our reef reference repository to get started with Kapitan, which is in the community section, the third, right in the middle of your screen.

20:20 There you go. Yeah. Exactly. So I think, because Kapitan, basically, it's a it's a tool that obviously requires the, inventory to be set up, for you. So we've done is we've created, like, an ideal kind of a setup that you can use to get started. And I think this is probably the best way for you to experience it literally as not as simple as cloning it and and running Kapitan from there. So I think that's something that we can Okay. Alright. We have the Kapitan templates. Yeah. So there is a we will go through the you know, this kind of repository, but

21:11 pretty much you can see that as soon as you have a terminal open and you run Kapitan compile, you will be able to, hopefully, see Kapitan downloading the latest image. So we're using a Docker image to speed up kind of the the process of getting started. You can also install Kapitan yourself, but I think Docker image is is is the the approach Universal way. Yeah. Yeah. Exactly. Yeah. So Kapitan is available through PEP as well, isn't it? Yep. Yeah. Yes. And and so this process that you can see here, these are basically a example and

21:48 templates that have been compiled for you. So from from here, we can we can carry on and discover how to get started with Kapitan. Is this you want to go through the slow walkthrough, or should I go back to the getting started guide? What's your preference? I think this is basically an explanation of this repository in general. I don't know. Perhaps we can I I can guide you? So if you go back to Kapitan reference. Yeah. And, if you go to the top, of the repository sorry. If you go just scroll up a little bit, and there is a, just after

22:27 Kapitan reference, there is a manifest generator documentation That could be a a good way to to kind of get started. Mhmm. It's it's kind of assuming that you already know that you need to create a target. So I I think the the the one thing you will discover is that we need to work more on on getting Kapitan, you know, to be to be used more easily. But, yeah, basically, if we go here in the repository and you navigate through the targets inventory targets folder. Yeah. And then you can create a new file if you want.

23:07 So create call it, like, demo dot yaml. So he this way, we're basically telling Kapitan we want to create a new project. We want to work on something new. So if you compile compile now, if you run the the the compile process you run before, this time you will have to do it quite often. So perhaps I don't know if you want to have a, like, a a view right right in Visual Studio code. I think that will be quicker. But the the process is always like, you edit something, you compile, and you see what happens, basically. So it's something minor thing.

23:44 Sorry. There is a limitation, the moment in inventory. Your your files need to be a dot YAML without a without an a. So y m l, not y Oh. A. Oh. Yeah. Well, that's perfect. Yeah. Yeah. Yeah. Go for it. And so you will see, hopefully, your Also, you have to put stuff in there. Right? Oh, yes. Okay. I I just wonder what it was gonna do with an empty YAML file. Is it just gonna magically make it up? But I don't know. I don't know. I'm just gonna say, the fact that you didn't crash is already

24:25 at that time. So So so the the the target is is is we just need to add a little bit of boilerplate. So if you if you create, like, the the top plate, if you in the the top part, if you write classes and you create, like, a list of classes and the first one is common, that's the boilerplate you need. And I think from from then on, you can probably follow the the rest of the documentation you have now. So if you go back to that document the, you know, the the page that we

24:55 opened before with the agent yeah. This one. So you can, I think, already start using with with this generator? So as I said before, the generator is, like, something that allows you to quickly create configuration for you. So in that case, we will be creating a configuration for a component called the EcoServer. Okay. Can we then just take a moment to maybe explain to people what a target and a a class is in this context? Yeah. Yeah. So this is something I went through in the presentation, like, briefly before. But, basically, a target is is like your leaf file

25:20 Vocabularly: What are targets and classes

25:31 to get to get Kapitan started. You know, you define a target, and that will usually be mapping to a manifest or a number of sorry. A namespace, a Kubernetes namespace, or, like, an application something you want to work on. It can be if you're working with Kubernetes, most likely will be all the application that you want to stuff into a namespace. If you're working with Terraform, it could be, like, a project that you want to create. So without app or correlate like, when I think of a target, would that be, like, my production environment? Would it be my staging

26:05 environment? Exactly. Exactly. It's up to you, really. It's really up to to how how you or your team work. Some people share environments, some people share clusters, some people share namespaces. So Yeah. It's really your your deployable group of stuff in a way. That's how you should think about it. So here, we'll call it call it namespace, but, essentially, it's a target. That's what it is. Yeah. Some people ask us that question. And the thing is that the inventory in Kapitania is so generic, and you can reuse in whichever way you want. Ultimately, it depends on once you

26:40 get the feel for it, you will understand how to organize it. Sometimes it's a namespace. Some other cases, perhaps you want to define an application that you want to deploy to many clusters at once. So, you know, how how you use it, it's up to you. Our typical way to use it is to define all the applications you would want to install on a a Kubernetes namespace, which I think is, in this case, we will be defining a target called demo, and we will write all the applications that we want to create within it. Okay. And

27:13 the classes is still an inventory file while the target is the first one Kapitan goes to look for. Classes are other YAML file that looks exactly the same, but they they group other kind of configurations. And so they're they're used for sharing that kind of information with the with the target. So as you add the class, the class will bring in all these other kind of values from from the files they are defined. And ultimately, we've created, a merge to representation of your inventory, which will be composed of all the classes you have imported plus the definition you have at target level.

27:58 So one one thing that we can also show in a minute is, you know, this might be a bit hard to picture mentally how it ends up, you know, merging everything. So you can run the inventory on the command line. You will see it's rendered. So you don't really have to try and understand what will happen. You can actually see it before you create anything. Yeah. So now if you run Kapitan inventory inventory hyphen t Oh, for that. Yeah. Space hyphen t and then demo, which is your target, you will basically see the inventory that so far has been created for

28:44 the demo target you're working on. And this is basically brought in by the common boilerplate kind of a class, and I use I use that word. But, basically, it's like a predefined set of configuration allows you to get started with it. Okay. From from that Try and summarize that a little bit. Right? So I think the targets were well explained. You know, they're they're groups of things or targets, like namespaces or environments that you wish to deploy to. Classes can be as small or as large as you want, and they can be composed together. So you can have loads and loads

29:17 of small classes that can be grouped together by some sort of aggregator class allowing you to, you know, really get down to the nitty gritty of small tiny classes, but then provide a single class to deploy to your target. So Yes. A really, really flexible and composable solution, which I think is Yes. Yep. Is key for people to understand. Yeah. I I I think the key aspect to which I I like to to to talk about is the fact that the class can you can name class with the in whichever name you want, which usually

29:48 is it's helpful to map them in in terms of business concept or at least things that are related to your activity. So, if, say that you are changing a value for a, Java server that you want to have no memory, rather than just, write that kind of a a value in a in a values file somewhere, you can map it as a a profiles dot production or profiles dot high memory. So it allows you to basically group together values that would normally not have much meaning, but you can you can attach some sort of meaning by just naming the class in in

30:27 in a way that makes sense to you. Yeah. Although, at Java, JVM need more memory. It's completely unheard of. So that was a terrible example. Terrible example. Sorry. Alright. Okay. So we have our wrong folder. We now have our demo target, which is pulling in the common class. We can take a look at the common class here. We can see that it's just pulling in another class, Kapitan common, and we've got a few parameters that can be provided. Yes. Okay. What you wanna go back to the manifest generation step. Right? Yes. So if you now

31:00 Creating and compiling targets

31:04 cut and paste this first part, so the yep. That one. And you will add it to the target. Yeah. So here is where you start basically adding your own custom setup to the target. So you are add you're defining something up in the parameters. So classes and parameters, you will see them replicating all the other, classes as well. And here, what we are doing is we are defining a special kind of a through a special syntax. We are saying, I want to basically create a new component. I want to call it echo server, and I want an to to have an image

31:46 called like that. But this is a a beautiful project I always use very easy to get started like a a a web server, and it's very easy to to to play with it, basically. If you compile right now, you will see a couple of things happening, and we can go through that as they happen. So you obviously, you see your demo being compiled up there. So next time, if you compile with hyphen t demo, it will speed up, and we only compile that specific kind of environment. I think that's if it takes time here, it's for Docker.

32:20 It's not us. So if it takes a little bit longer, a couple of seconds longer, it's just for for the for the fact that we're using a Docker image. K. Now when you compile target, the output gets producing the compiled folder. So if you do get this now or if you go and look at it through oh, sorry. Get get status so to to have a look at the files. You will see that several files have already been compiled for you. And the and the the one for your target will be under the compiled demo.

32:57 So the manifest folder is the one where we would be interacting with the most because that's where the generator places the the files that you are that you are creating. So if you, you know, in the editor, open that folder, you will see already that there is already some magic happening there, and we can go through to basically explain a little bit more what what's happening. And and yeah. So with the the configuration you've defined allows us to say to to to generate the default object that we use most commonly, which is the deployment. So it's just, basically getting rid of all

33:39 the boilerplate and, adding all these kind of a a kind of a sane initial setup for your, generator for your for your deployment in a way that, you know, you have something already working out there. Okay. Can we maybe try and break down how we got from from this Yeah. To a deployment? How does that generate or work and interact with what's going on? So so the the generator is is essentially a a plug in that we have within within this repository we have installed here that basically activates on whenever you define this the structure you have here, and then

34:00 Kubernetes generator: Deployments, Services, and ConfigMaps

34:23 you can expand it to to add more value, so to add more components. So every time you find something other components, it will basically take that object and try to do something with it. So, you know, the I I hate I hope I'm not getting I'm gonna get, like, a a a a a CRD. You define your own CRD of how you want the deployment to look like. I've used a very bad example here. But, you know, it's like you are defining, like, something that you wanted to turn into a more complex kind of a a a representation. Presentation.

34:59 So in this case, we want to create a component. We want to call it echo server, and we want to have that image. And we can see how we can build on on that quite quickly. I think one one more thing we can say sorry, David. One one more thing we say is that every inventory has the classes and parameters. So every every file has the cam classes and parameters keys. The parameters essentially feed the input parameters to a template. And in this case, the template is what Ali said as the you know, it's the what we've brought in

35:36 by cloning the Kapitan reference, Kapitan templates example. Right? So we already have a a a baked in template for you to use. And that another way you could use this, you can actually write your own templates, but for the demo's purpose, we have a baked in template for you. So that's why there's a lot of magic happening. So what we've just done when we've done compile was we have now created a new directory compiled, and we've added a new target, which is a demo target, with all the files that it generates for you. And in this case, it generates,

36:08 a bunch of Kubernetes manifest files based on this input from this target. Okay. Now would it be fair to say in my naive assumption here that this components and echo server keys correlate to this file, that Ginger template file that we have over here? That's a coincidence for now. We we will use it. We will use it. It has nothing to do with that. So this is the the bit that is difficult to get. It's like, with Helm, just to give an example, with Helm, you have a value files, and then you have a a templates that are made of goal

36:43 line templates, basically. Right? The text templates. So you see that kind of a you're now what you are doing is you are looking around and you say, Where are where is where is the the the magician hat? Where where are the templates are coming from? Right? What we have effectively is what we called generator, which, you were right to to go on the components. I think if you go to components, generators, Kubernetes. That's it. Don't look into it. Don't open. No. I mean, it's just It's just Python Python code that basically using this software no. I'm kidding. You can open

37:22 if you want, but it just it will it will look nice. It's basically Cadet, which is kind of a our own kind of language that that Ricardo has written that simplifies the generation of manifests or files or templates in that way. And so that kind of generator has been created to react to the configuration that you define. So if you write components echo server image, it will create a deployment with that image. Okay. Can I test the hypothesis then? What if I Yes. Index image, NGINX latest. And if I what if I just start going a little bit crazy here?

38:03 Okay. You you you need to get the right setup, but that's the general idea is correct. You're almost you're close there. So NGINX, perfectly fine. Image NGINX, perfectly fine. Ports, rather than making it a list, just add the h t t p under that. So, like, create another key on the ports, h t p, and then add the container port but with the yeah. Okay. Just okay. And then container underscore port because that's how port a. And compile away compile away and please make it crash to to embarrass me and everybody else. Go for it, and let's see

38:43 let's see what happens. Pace on crash. Pace on crash. There we crash. So Anything else? So now so what do you expect what do you expect to happen? I have expect to see an engine x deployment with this image and the container port configured with a name and exposing port 80. Alright. Exactly. You got it there. Yeah. There you go. Alright. Let's see. So Okay. Nice. So now now now you're wondering how far we can go with this. Right? Yeah. Okay. I mean, maybe you could help me understand why, you know, because this is starting to look

39:21 like a pod spec. I know it's not a pod spec, but this set is probably gonna be unfamiliar to people coming from Kubernetes. Mhmm. So how do how do I learn how this generator works then? How how do I know what other keys are available to me? So if you if you go and look at the page that you skipped through to to the because you you you you are so excited to to work on this. You you can basically understand a little bit more about how it works. And I think the easiest way is to go through the examples that we

39:51 have and we see what we have available. So you're right. Obviously, we've this is a Kubernetes generator. So it looks a little bit like a a pod, but there is a bit more. So some of those commands apply to the pod, but some some of those kind of definition apply to the pod, some other apply to configuration file config files or secrets. I I think as we go through this, you will you will understand all the other capabilities. So if you skip this two kind of main section, global general setup, and and you go to ports and services.

40:33 So here should explain exactly what you were working on. So you've created, like, a port setup. So you define a port with a with a name, so I should be port. And then you've you went for container port eighty eighty, which is intuitively, you got very close to to to actually the the configuration of of this setup. And you can basically it it's a it's a a new format that you need to learn. So, obviously, you need to learn how to configure it that way. But the main advantage you have already here, and you can see over the other

41:05 software, is like and by all means, I use Helm as a comparison just because it's it's easier to most people know it. It's like, while with Helm, you still have to do pretty much the same job in the values file. Right? Each values file drives the template in perhaps a completely different way. Right? So depending on the template, you will have a different value file that you need to. Every time you have a new chart, you need to go through the values file and understand how to fill it in to to to to make it behave the way

41:37 you want. Now, obviously, there are standards and people tend to use templates in roughly the same way. So the values that you define are pretty much always gonna be the same. But but that's down to to to to code in standards. It's not because Helm enforces you to have a specific structure. In our case, those definition, once you learn how to use it, you can use it to create any other kind of template you want to create. So it's a it's a it's a good to be use of that those configuration right there. Yeah. Well, I I love what this one

42:10 is doing. So I I need to see this see this happen. I mean, this is you know, nine times out of 10, and that's arbitrary, but probably a pretty close number. Nine out of 10 times, what I'm doing with Kubernetes is deploying a deployment that has a service that exposes that thing. Right? And Exactly. Exactly. Exactly. Just template that down to something as simple as, hey. My Yeah. You know, target should have these components, and this is how I tweak them versus Yeah. Yeah. Fantastic. At the moment, for for the benefit of the demo, at the moment, we are doing

42:43 everything in the in this target directory. You won't find a service there yet. Just give me a second. I'll recreate the service as well. But, like, at the moment, we are doing everything in the targets file just for other convenience. But effectively, you will be moving this kind of configuration in the more appropriate class later. But for now, let's let's carry on. So to have the, if you now scroll down and you find expose a service, and then, there should be a a service directory as, directive as well. So okay. So let, if you go back to the, target.

43:21 Yep. And and let me make sure that I don't make a mistake there. But if you write service, so you create a new key called service alongside ports. Yes? Yep. And and then another key type, and you say cluster cluster IP. Mhmm. Yeah. Now if you compile so here, I think this is the one problem that we have right now is that probably possibly we haven't been extremely I might have made a mistake there. Just double check with the Thank you. That's okay. So if you go on Did you create it? Oh, yeah. Just look at look inside

44:06 the bundle. Yeah. Exactly. Yes. This is one of the thing that annoy me the most when I start using Kubernetes is that you have to match the labels across deployment and service. And I was like, you know, it's a beautiful kind of a a power ability to decouple the service from from the Kubernetes. But, you know, how many times do you actually use it like that? It's like, it's just that gets in the way sometimes when you want to do things your way. Yeah. So that that's why the default is to make sure that the deployment is called echo server, the service

44:44 is called echo server, The labels are consistent across the two, and and you carry on building the the service as as you need. If you need to deviate from it, you can still do it. But for the time being, this is an ability to quickly get started with it. So does that not have an implicit cluster IP by default? Would that just now remove that from my bundle? It will and now it will remove it. Yeah. Right. Okay. Cool. Okay. Thanks. So yeah. So I think if you go through that page, you will be able to see

45:20 other examples. And and I think if you look in other kind of a components classes, you can you can understand a little bit more what you can do. But let's carry on with what we have here. So if you go down a little bit let's see what else. Yeah. Like, liveness and readiness checks, you want to add them. So I already defined the fact that he he can talk point to the specific port. I just hope I haven't checked that page in quite a while, so I'm just hoping that everything works. In case we can route

45:56 immediately to to an example that is already built for that. Yeah. There we go. Great. There we go. Okay. Now, obviously ahead, And one thing one thing that we should mention is that when I when we briefly mentioned in in the in the in the slide of the workflow of Kapitan is that you are just generating stuff here. And and the idea of how you should use is really you generate the the compiled files, and you check them in into your in your, you know, get whatever. And then these ones are are deployed as they are into the cluster. So it becomes

46:34 really super easy to know exactly what you have. Basically, your your your snapshot is your your your your state is all defined in Git. As opposed to, for example, Helm or other tools, you don't really it's don't really see by default what it is actually rendering and applying to the cluster. We just have that view of the parameters you you are exposed to and everything else kind of magic unless you dig into the code. Our approach is a bit more verbose, which might be a bit more overwhelming at first, but eventually, you have a much clearer

47:04 picture of what you're applying to your cluster. Excellent. Okay. So what should we wanna look at next? Let's look at config maps. I think that's where the fun starts from my point of view. You've not been having fun yet? Come on. I should buy stuff. So, obviously, one of the things they use most of the time are, like, again, config maps and secrets. And with the generators, you basically pretty much define it exactly the same way. So if you now copy and paste that into your configuration, you would see more magic happening, which is basically

47:48 yeah. Add it whatever you want to, whichever component you you expect it to happen. So this is just make sure it's indented. Yeah. It's it's the right indented. Yeah. So here, I can add key and secret value pair, whatever, and that's just gonna work. Yep. Yep. So what we tend to do is every time we make a change, you, like, get commit so that then you can easily see the diff, like, of of what you're changing. Obviously, in this case, it's you know, we we just playing with it. As you can see, has generated another

48:27 file, NGINX config with with that content. And nice thing is that on top of the simple value that you can define this way, this is just to add value to the Necoserver. We also suffer support to the the idea of connecting of rendering templates that come from an actual Jinja file. So the one the the the Jinja file you pointed at before under the components folder, that is just a a file that is there that we can now reuse and see how it works. So if you if you remember that you were in the components

49:04 folder and there was a a Ginger file that you pointed up before. Yeah. So we could we could we can now tell the generator that you want to use this template in in the in the compile the in the example we are doing. So if you copy that component cycle server if you if you copy the path to this file, and then we can define it here, and you call it another name. So create that other key. Say saying, like, example.comfour. If you go one level before. Yeah. It just inside data. Exactly. And then add a key called template,

49:47 and then you put up path. And then you add a another key. Oh, wait. I'm lost. So what is m server config? Yeah. I mean, this is just a an example. We have others, but pretty much any kind and then you have another key called values, which is where you basically specify the context. So in this in this case, if you write example, which is what the valuable that that kind of a template is looking for, Right? Hello. And, yeah, compile away, and let's see what happens. Yep. Oh, it didn't crash. Great. I'm just waiting for that to happen. There

50:38 you go. There you go. Yeah. So very simple, very quick to get started with it. Now in the values kind of key that you defined, you have access to the full feature of the inventory, which is variable interpolation. So you can now take a value from anywhere else in the inventory and And then something like a target name, just to make it easy. What we are saying here is we are telling Kapitan or we're telling the inventory to replace that value with the inventory value called target name, which can be defined in any other class as long as it's within the inventory.

51:38 So this is very powerful because allows you to basically refer to to other kind of values that you have configured somewhere else. So now, again, if you compile, you will see the expected change, Hopefully. So far okay. For this demo. Yeah. It it can be much more complex. So if you look at the com the example for component sorry. Inventory classes components, my SQL, likely, I added it, right, yesterday, a bit more of so inventory, classes, components, MySQL. So this is obviously a little bit more of a complicated setup. If you want, we can look at it

52:27 later. But pretty much, you can see other kind of configuration, and you can see that the templates here reads the the the settings block that you see up there. So we are referring to another kind of a part of the inventory configuration, allows you to easily play and and and change with these parameters as you create different components of MySQL across all the different components. So I think one one thing we can also look at is something we we already mentioned before is, if you go back in the terminal, David, you can type Kapitan inventory

53:02 dash t demo dash uppercase f. Yeah. So it flattens out inventory, and it renders the inventory. So now you will see everything rendered for you. And, for example, you can grep for target name. Well, there you go. Right? So this is that this is just a simple example of how you can visualize the inventory rendered and how you can actually use other validating the inventory in your templates or within your classes, whatever. K? Nice. Alright. We have a question, which may be quite tricky, but I'm gonna give you it anyway. So Yeah. Sharath is asking, is it possible to give

53:57 Kapitan knowledge of what Kubernetes version is the target so that I can adjust the API version and kind appropriately if needed? Yeah. So at the current generator, it doesn't do that, but we are planning on on on allowing it. At the moment, we are you know, this generator is something that it was originally originally generated created a a synthase, which is the company that where I'm working. And I've then converted into cadet. We are adding more and more features, one of which is adding schemas and add adding the ability to also target a specific Kubernetes version. So at the moment,

54:37 it's not possible. So we tend to default to the latest version available, but we see that that's something that is needed. And effectively, it wouldn't be more difficult than just defining somewhere, you know, an inventory value that points to the Kubernetes setup that you have, and then from that, it will understand what version to use. So not possible at the moment, but definitely something feasible. And if I might if I might reiterate a little bit, not possible generators. If you use plain Kapitan, you're completely free to do this feature yourself, if that helps. Yeah. So

55:20 the this is an important thing. So if people have experience with Kapitan before, before the path to do what you've done now was to create, like, a JSON or a cadet file for each component, and then every time you had to repeat pretty much the same stuff. So you could reuse some some things. Like, in in this way, we realized that pretty much all like, in our situation, my company, we have, like, microservices all configured the same way, but with a couple of variations. And I just got tired of dealing with all those different kind of variation across TAM.

55:52 So I say, I think there must be a better way, which is what led us to to use the to to this approach. Do you want yeah. Do you want to continue with more fun? I think we have a couple more things that might be of interest. So first of all, the same setup you see now with the config maps. If you even just create instead of config map, you create the same setup with written secrets, it will work exactly the same. So interface for for both of them is the same. And you can do all the things

56:28 that you're expecting out of the same setup. So you can mount the config map into the pod you defined like that. Yeah. Oh, that's the minus go on. We can close that. So here, I can just say that I actually want to maintenance. Yes. Under that directory. And yeah. And then we do all the conf needed configuration for it. And if I pop open our bundle again, we should see we have our volume and configured Yeah. And our volumes here. Very cool. Yeah. Now the standard setup that we have is that every time you create, like, a a configuration

57:18 config map, it's named after the component you define. So if you have only one config map, it's named after the same component. Obviously, this is doesn't work if you if you, for any reason, you need more than one config map defined. In that case, the name morphs to be component name and then the config map name so that you can have a you know, the the the default is to make sure that it's as as easy as possible to refer to to to to that specific config map. Yeah. So we can also I don't know if we have all the

57:53 the the explanation here, but you can also mount only specific files. So you can also just yeah. You can also do the sub path bound. So you can say, I want to just mount this specific file under this directory. Not sure if I if we have to come into the all of it, but it's it's all possible, and it's it's something that in any case can be improved very quickly. Alright. Oh, yes. There it goes. Filtering files to mount. There we go. Look at that. Oh, yeah. So we can use an ATOM. There we go. Yeah.

58:30 Secrets management

58:33 And secrets are pretty much just the same thing. Right? Yeah. The secret the only difference is that you also have the ability to base 64 encode it. So if you create, like, a simple if you create a simple value and you want the base 64 encode it, it it does it for you. Right? That's the only difference with the config map, really. K. And we have the ability to hook into various cloud KMS systems or local GPG in order to actually store and encrypt those secrets at a safe in Opsi fashion? Yes. And or the best of them all,

59:08 base 64, the most secure them all. This setup. Yeah. I don't even just I just string the key and just YOLO it all the way. So Yeah. So so, like, you won't be able to use this example right away now. But if we just accept the fact that we are in a demo and we are all friends, and and if you change the if you copy this and you change g k m s with you you replace with plain, so under under the oh, yes. That's perfect. Yeah. Yeah. Just change it to plain. So let's

59:46 pretend we are on a a safe network and a safe Internet. This is I think if you compile, I think it gives you a very good idea of of what happens. So the import so this is basic Safari encoded. So, you know, you have to, yeah, decode that. That's true. But, basically, the the, important, feature that I would like to point out is that, Kapitan's when they are generating a secret, Kapitan has a number of functions that you can use to bootstrap the value of the of that secret. So you can automatically generate a random

1:00:32 string, automatically generate, like, an error say key and the and the relative kind of public keys, and and we can add more and more function as we go. And I think this is what we call, like, declarative secrets in a way with a very fancy name because what we want to do is capture not only the fact that you have a secret, but also how you generated it. And I think that's quite important. I think it's a it's it's a nice approach that we we tend to use and we tend to tell people to, you know, to go for.

1:01:05 I think one cool detail is that if you go back to to your previous file and you change plain to base 64 and then you compile again, you will see something a bit different. Right. So that is what we call the reference. And if you check the Kapitan. Dev documentation, it actually calls that a reference, and which means that that it actually points to the state that is saved, you know, directly called refs in your repository, which means that the next time you compile the same thing, the reference to that compiled state is reused. So, for example, if we were to use

1:01:54 real encryption, not base 64, it's not encryption. For example, a GPG or GKMS, you are the developer. You are deciding what the secret is like. You commit that. The second developer does not necessarily need to have access to your the same secrets, but he can still recompile stuff and have the same results. Right? Decrypting is a different story, but that's the idea. Yeah. And so when you apply, you have to reveal the file, by the way. And and if you look at now at your directory, there will be other files being created under the refs

1:02:33 directory, and those are the one that I think Ricardo Ricardo is referring to that hold the information about the password. So in in this case, we are basically generating the password, writing into this reference file that you check-in. Obviously, not the basic c four one, but the when you use a a a real back end, like a secret back end, you can securely store with you the encrypted version of that password, and you can share it around only at the act of revealing. So only only when you need to apply that configuration to the cluster, only then you

1:03:12 need the the permission to read that secret. So all your other colleagues can be using Kapitan without having to need access to these secrets, which is already, for instance, a difference with I must say, I don't use other tools, obviously. But, like, if you use GitCrypt or if you use other alternatives, I think, much you need to set up your environment to be able to read those secrets even if you are not the person that is meant to consume those those secrets. In this case, we there is a nice properties, the fact that you only need to

1:03:46 reveal these secrets when you are applying this kind of configuration to the cluster, which is something that we can also delegate to another project we have, which is Tesoro, which is basically a tool that runs in the cluster. It's the only one that needs to be able how to decipher the secrets, and then everybody else can be locked out of of understanding, you know, even understanding what the secrets is about. Very powerful secret management there, I think. Lots of flexibility to and then just being able to hook into those cloud KMSs, I think that's important. We

1:04:23 shouldn't be using I would argue we shouldn't be using local GPG or shipping around private keys and things like that. You know, that's how excels there. This is this is something I'm I'm trying to get people to understand is that even if you have your own kind of bare metal installation of Kubernetes, you can still use, like, KMS from Google or KMS from AWS to you know, you you can use just those tools, and they are so cheap to use. They doesn't even make sense unless you have a specific need. Bringing up the whole vault setup just to

1:04:56 make sure that you have the, you know, this couple capabilities, it doesn't make sense to us. So that's why g k m s is standing over the AWS version of the Azure version if you really, you know, fancy trying all the different clouds. They are they are available for you through Kapitan built in, and you can just, you know, get going very quickly. Yeah. I often work with bare metal Kubernetes environments as I think you may be aware, and I often use GKMS pretty much. So it's just yeah. You're right. It's almost free to a certain point depending

1:05:00 Kubernetes generator: NetworkPolicies, Prometheus Operator Service Monitors

1:05:29 on how much you need to access it. Yeah. Perfect. Alright. Let's show off some more cool stuff before we finish off then. And if you wanna lead us towards I I think I think this is something that I think you got to the other nice section I would have wanted to explore. The fact that so far we defined basically things that are related to the deployment, the secrets, and coughing maps, you know, the the typical stuff that you normally expect to to have it on deployment. But sometimes there are kind of other features that you want to other kind of

1:06:04 characteristic you want to build into your deployments, which would normally require you to have a specific template just to deal with that. So the generator takes care of that. So, like, in the case of network policies, if you define the network policy kind of block, you will create a network policy for you. Prometheus rules, if you define the this kind of a setup, it will basically automatically create all the Prometheus kind of configuration that you all the kind of related to. This is the example where you're using the parameters operator. And the same if you go down, there

1:06:38 is another service service monitor. So now if you cut and paste this into your configuration, you you basically by adding a little bit of a of a of an extra configuration bit, you you you can generate many other associated ancillary kind of resources that logically belong to that application. So within the same application, you can define many other kind of behaviors without having to deal with a specific template for creating service monitoring and network policy. And and also while with the other tooling, again, because they they require you to have the templating specific for the feature you want to enable.

1:07:28 So in if you are unlucky enough to use a, like, perhaps a a chart that hasn't been looked after properly and probably doesn't have the service manager configuration, I think you need to add it yourself. I don't use it, but my the my understanding is that you need to go and add the template to that chart and make sure they work for you. But if you go down the generator route, you can basically every feature we add to the generator can be can be used by any, component you define. So is that to say that I could

1:08:05 have Kapitan reference a helm chart that I'm still using, but I wanna enrich with new manifests and Kapitan can generate or compel them into it for me. So that's what we we would be working on. It's not possible yet. What I meant is that both the echo server and the NGINX that you defined can both benefit from these kind of features, which is something that, you know, like, you can have, like, 20 components and easily add to all of them consistently the same configuration, the serve same service monitor configuration, and the the same kind of network policy

1:08:43 policy, like, consistently across all of them. So I'm I'm just saying that even if there is a feature missing of the generator, the moment in which we add the feature to the generator, it automatically it's automatically available to all the manifest all the definition you've created of all the components. I don't know if you if that was clear, if you feel like if I can explain if I if I need to to to repeat that again. But I think I find it interesting that we can easily add more and more magic kind of a generator

1:09:20 kind of a a incantation. And the moment in which we add it to the to the and we publish that kind of a a feature, it's available to all your components that you've defined through Kapitan. It's very easy to to deploy a feature across all of them. That makes sense. Awesome. Okay. What next? I think I just ended the reference. Right? We kinda covered the generators, how they work, what they do, what's coming. I mean, you've covered quite a lot there. Is there I think think we can pass some of the stuff he places into the target into a a

1:09:40 Cleaning up our classes

1:09:58 class. So just to make a target a bit neater. Right? Okay. Yes. So to be honest, you can also yeah. Or you use a class that we have there. So if you want, you can so the echo server is sending with the final ready. So if instead of defining your own version, you you load the class called so if you yeah. If you in the classes section, if you load the class called components echo server, yep, which has already, like, lots of configuration defined, which are beyond the the what you had before. So if you just load that class, it

1:10:41 will basically inherit all these features automatically. It's it's like an example class that we have there. And at the same time, if you want, you can install MySQL by just simply adding component components MySQL to the classes section up there. And so we could in theory, I mean, we could just remove all of this and use those classes that were provided. Right? So that would be And I think this is good because we can show you how you can override the content of those classes, which is something that until now we didn't need to because we were

1:11:13 doing it, by the way. Yeah. We could do that. Right? That's I think that's okay. Yep. That's fine. Then we can recompile, and we'll end up in a pretty similar place. It said, now we're gonna have an added MySQL bundle and a modified echo server. So Yes. See. So, yep, we've got our Mhmm. Yeah. Table set for MySQL. And where is our echo server? Very, similar. Nice. Yes. And if you look at the echo server class now, the inventory classes component echo server, you basically it's it's a you know, it's a it's probably the most complete example that

1:11:40 Kubernetes generator: additional containers, probes, and vertical pod autoscalers

1:11:56 we have. So that everything you can think of has been added to this class. So but we can see that another kind of you know, you have network policies defined. You have a a side container as well, you know, additional containers. So you have a side container with NGINX, which is also nice. And you could see that pretty much the the configuration is pretty much the same. So pick something that you want to override, and we can override it on the at the parameter level. Yeah. So this is Alright. And something that may be common then,

1:12:28 like, if I were to take if I wanted to deploy this echo server across multiple environments from staging to production, then the probes may change slightly. Like, I mean, in production, be a little bit more hesitant with or a bit more aggressive with the time out, whereas in staging, I make it a bit longer. Exactly. Exactly. So we can do that. Right? So in the target, because it's a demo environment, perhaps we the time out of what we want it to be, instead of three seconds, we can we can it can be, like, I don't know, eight

1:12:55 10. Yeah. Ten seconds. I know. Yeah. So the the way it works is that you can now in the demo target, you basically recreate the the YAML structure up until the parameter you want to change. So it will be components, echo server, liveness check, I think it was called. Will underscore. I think it yeah. And then time out. Yeah. Just make sure I was just checking. Yeah. Excellent. And then we can turn to health check liveness time out seconds. There you go. Health check. I'm at I can't Yep. And What we should see when you tile this

1:13:58 in is that our echo server bundle, we're gonna have this time out of the liveness probe, which is here. We should see lane 40 changed at ten. Yeah. Which is where committing it to get, you know, like, helps in this case because you can see easily see the diffs between them. There you go. Has it changed? Yeah. Changed. Gotcha. Now now this is now this is an important thing that I think you can go back to something I said before. If you go back to the target, what you've done here is to add a time out seconds. But the reason why you

1:14:37 wanted to add the time out second is because you said it's different environment type. So if instead of doing it this way, you you create a class called, like, a a subdirectory called profiles, and then you say, I don't know, testing or them demo or low latency or Whatever. Whatever you want to call it. You can then copy this configuration that now doesn't make sense. In a in three months time, you won't remember what this is about. Right? But you can add it under something called profiles, you know, testing yeah. Testing. Well, you know, you you come

1:15:17 up with a word that you you like. So we have a new class? Yes. It can. There's a new class called whatever you want. Like, I think staging and oh, yeah. Like, environment staging. Let's call it forgiving. Let's use the forgiving. Yep. Forgiving is good. And then we call this whatever we want. So let's just see. Main dot YAML. Yeah. We that's okay. Sorry. Something we need to work on. Yeah. And then from here, I could just augment this with my forgiving Main. Main. Yeah. Forgiving. Now you you managed to turn into something even more difficult to understand what he was

1:16:05 referring to. But but but you you you get you get my point. Right? Well, I think what I'm in my head, what I was thinking is, you know, there are certain constraints that I wanna apply to different environments. And I'll forget it was a terrible name, but, you know, I'm gonna be running maybe consistent performance performance testing on this environment. I'm using debugging tools enabled. So things will generally be slower. Yeah. We have Exactly. Chaos being artificially injecting time out, whatever. So being able to group these together as a a component that is reusable to apply to the target environment as kinda

1:16:39 what I was going for there. But yeah. Maybe Exactly. And and I think something else you can do just because we are we are playing with the with the organizing it better. In the forgiving main or even in the echo server setup, instead of defining the time out like this, you can actually define a time out seconds on on the on the under parameters. Exactly. You're already there. Yeah. So this means that now and and if especially if you apply to other components, it it define it means that you can define that across all the components that you have around your

1:17:16 you know, all the components you are deploying, you make sure that you consistently apply to all all the different kind of deployments you have. And, also, you can go ahead and and duplicate that targets and call it prods and then change the value. And now you have two very similar targets. With Yeah. No. I've got no no. My forgiving name is getting worse and worse as we change the name. Right? But Hey. The the name should be something that makes sense for you. If it makes sense for you, then we're good. Right? Yeah. You're right. Okay. So and then, like

1:17:46 you said, we can say, hey, Rawkode. We're gonna have a slightly different performance testing one. So hold on. Wrong. Yeah. No. That's the right directory. Okay. Performance.YAML. And, actually, we we really wanna test this, and we're gonna go with with a one. So now that's these are factored, but we that's not today's lesson. So Yeah. So, basically I think this is Sorry, Nico. I was on the No. No. Go. Go. Go. Go. Go. Please. I I just, you know, I I I love confirming why I really work I enjoy working with a tool, and it's just this composability. The way that we're

1:18:19 moving things around and grouping things into use cases and behaviors that we wanted and augment into our targets. I think this is really, really powerful. There are some some aspects of it that you will become even more clear as you use it. And it's something that I had a colleague of mine that used it for several kind of weeks, and then he did, a a refactoring of the inventory to, you know, to shuffling things around. And he compiled, and he didn't see any change in the compiled folder. It was like, oh, something is broken. Something is not working. But that's exactly

1:18:51 the beauty of adding the compiled files together with the template is that you can refactor the inventory or the templates as much as you want. But if you don't change the kind of a functional behavior of what you're doing, you have a immediate guarantee that whatever you've done hasn't disrupted your your workflow. So now you can you can move things around and it it doesn't change. Yeah. Kinda like TDD for your manifest. When you're refactoring, you wanna make sure all your tests pass here. You'd wanna make sure your output doesn't change. So Yeah. So what what

1:19:24 we Actually, you can actually you write can write test for you. Right? You can write test to validate your YAML. So you it is it's gonna be up to you. Yeah. I can imagine once you do the compilation step, being able to run some sort of over rego against it to, you know Yeah. Make sure that it conforms to all the rules that we have in place for those environments, which we're really careful as well. Yep. Yeah. So before we had a JSONET based generator. So when I wrote the cadet based one, the Python one,

1:19:27 Getting Started: Setting up a Project

1:19:52 the only thing that changed was the speed of compiling. Other than that, it was pretty much it produced no output, which gave me the immediate guarantee that whatever I had done, I was able, with the cadet version, to basically recreate exactly the same behavior in the JSONX version. And and and so you you have an immediate reassurance that what you've done hasn't impacted any any component. Yeah. Excellent. Is there anything else that you would like to cover before we finish up for today? What's your favorite feature? Have we touched on it? Have we done it? Have we shown

1:20:29 it? We've we've touched on a lot of stuff. I know that it's potentially gonna be a demo. Did we cover everything that's in your demo, or would you like to go ahead with that? Yeah. Pretty much, basically, the only thing I was going to do is, like, through go through exactly the same. And and, you know, I think we've covered everything. I think another bit that we can show actually, we can even tell without even having to to go through the pain of of recompiling. But you can add if you want to have virtual pod auto scaling, you know, just do

1:21:07 VPA auto. Boom. It works. If you want to have a a pod disruption policy, you just have to define pod structure policy and it works. So it's all kind of a small other kind of features that you can we can add and we add it to the generators so that you can easily take advantage of a of a of a other kind of Kubernetes features that otherwise would would have to be maintained manually. Yeah. Think it's called auto, uppercase uppercase auto. That's it. Yeah. I'm not gonna that's an opportunity here to see if I can add

1:21:45 a BPA to this. So you know? I guess another thing we can do is just really show the scripts, which is probably a controversial feature, but you can actually generate executable scripts, which we already did. There you go. Added it? Yeah. Got it. Yeah. Oh, it's I went too far down. There we go. There we There we go. DPA. Yeah. Nice. Yeah. So if you if you now open the another target file so for instance, the tutorial one, it should be one called tutorial. Yes. So in the top part, you see that project to local host Kubernetes kind.

1:22:30 Generating shell scripts

1:22:37 If you copy and paste that into your configuration, into your target file yeah. So and compile. What we are doing here is that we are and you can open that class to see basically what it has. We're basically you'll see here a change in the scripts file, which is actually was already there. Mhmm. What you see now is that we've basically imported information about a specific Kubernetes. As you can imagine, it's called KIND in this case. And do you have KIND installed in your machine just to prevent actually, open setup cluster. Yeah? I I do have KIND available. Yes. Great.

1:23:19 Yeah. So now if you run on the terminal, compiled just execute it right from where you are. So compile. Demo scripts. Demo scripts cluster. Yeah. Go for it. Let's see if it works. I mean, this is a I think The demo gods, man. So far, they've been with us. Demo. We haven't we haven't broken a single compile. I mean, we just have to, like, break it on purpose. This is insane. This is live typing. I promise. And I I think the time it takes for here to set up to remind everybody listening on the stream to retweet and talk about

1:24:04 Kapitan and and sponsor us if you can. And file bugs. Basically, we we are, yeah, and and the file, all the bugs you find. But we are going to spend much more time to make it working this year. So I think we are on a on a good path. I think we have a good idea, and it would be nice to see more people taking advantage of it. I guess adding new automations to the generators could be a really good way for people to contribute, adding new keys that Yeah. Get expanded into behaviors that they wanna see,

1:24:39 you know Exactly. Trivialized. So the the beauty of the generator is that, for instance, we can create now a spinnaker generator. For instance, for in my case, we use spinnaker at work. The spinnaker generator can see the compiled echo server. They compile the deployment you've created. And based on that, you can create a pipeline to deploy those kind of configurations. So and then if you have a secret, you will automatically instruct Spinnaker, then now there is a new manifest to be deployed. So, actually, by using the same kind of configuration, multiple generator can provide a different behavior. So if

1:25:22 you add an Argo CD generator, you will create all the Arco CD configuration that you need to to deploy your configure. So I think the generator pattern is something as trivial to add, and it will give a lot of benefit to the people using Kapitan. So now if you do and run compile demo scripts setup context and you actually don't even need to run this because it it's automatically when you run cube control, but yeah. And then you run cube cube control get bugs. Get bugs. I mean, there's nothing now, but Yeah. And then if you

1:26:05 instead of instead of cube control dot s h, you run apply dot s h. Yeah. And the here, we actually see if if they we've generated a rubbish or or if they actually yeah. Here we go. Yeah. Our secret. Okay. No. I see. It's a secret. Yeah. Exactly. And the vertical pod autoscaler, I think it's a different version just to need to update that. I think you already I don't know what that question we had earlier. Exactly. Yeah. I was just going to reply to. It's very relevant to that comment. But, basically, the the point is here, if

1:26:50 we just take away the the good part of it, not the fact that it crashed, is that it enables you to create scripts that are already configured to operate with a specific deployment. So it doesn't matter on which context your machine is is funding at. You can you know that you can run get pods under using the script to to point to exactly the version that you're you're you want to have you want to be working with. So the same thing is that if you now go compiled tutorial scripts apply right away so we we try this and

1:27:33 probably we fail for the same reason, but it basically will recreate the context and and deploy these values without you having to do anything with it. If you do yeah. So this this this is a very a very powerful obstruction. I mean, for people who work with Kubernetes every day, fine. It's perfectly obvious. But we had, you know, people who were not so familiar with it, and they've got extremely confused with the difference between namespaces and context and clusters. So the idea is that we we can actually template all of this in the script that is runnable, and the script is basically

1:28:00 Exploring the Inventory

1:28:10 omnipresent. Right? If you run that, it just works for that particular setting. It doesn't work for anything else. So you you basically end up running the scripts for the target you I think you're think you're breaking up, Ricardo. Don't know if it's just me. No. Was okay on my side, I think. Okay. So it's it's just me then. I I know about all that stuff, so it's fine. Alright. Excellent. Yep. Do want to show anything else? Last chance. Good. I think the only other other example that I would like to show is if you look at so you open briefly

1:28:50 the we works class. Uh-huh. Yep. So if you go inventory classes. It was there. I have the feeling I have a yeah. Inventory, classes. Yeah. Ah, there we go. Components. Yeah. Workshop. So now here here, basically, I have replicated all the configuration for the WeWorks soft shop example that they have on on the repo. I was looking for something with enough kind of a complicated kind of setup just to to prove the point that manifests work nicely. If you open any of these files, you can pretty much see the configuration of how to recreate that kind of a specific

1:29:42 component. The information the bit I wanted to talk about is this application sock shop that is a way to basically define a common variables that you want to apply to all these components at once. So now if you go in the inventory inventory classes, applications shop that you see right there Sorry. Application stock shop. Yep. Yep. That that's the one. Yep. So you can see that from this kind of application, we've obviously called in all the different components, but we also some define some default behavior at the end. If you go scroll to the bottom. So we define some

1:30:29 defaults that we want to apply to all those components that match the same application class at once, which is yet another way to define kind of a a characteristic that you want to to be applied to all your components at once that you're generating. So in the case that you went before for changing the time out, if you change the time out with this kind of a if you basically make your comp all your component belongs to an application or even if you just change the generator default time out version, you can then apply that time out to

1:30:59 Using Kubernetes Generators (Components, Ports, Services)

1:31:06 all your components at once without having to go through echo server, MySQL, NGINX, and so on. So I think that's another important aspect. The fact that the generator has different level of in of of kind of defaults, you can override that as well. Excellent. Alright. And I think that's it for me. Yeah. We we covered an awful lot actually there. I'm really happy with how much we've gotten through there, and we never broke up never broke a single compile. So that was pretty successful, I'll say. I wanted to say thank you both for you for joining me today. You know, I

1:31:44 think it was really good to go through Kapitan from start to finish. You know, I think we covered all of the major vocabulary that people need to be familiar with. You know, we broke down the generators and and what they're useful for and how they work and just really showed a really great way for interacting and working with Kubernetes customers. So, again, thank you both for joining me, and that was really good fun. Anything you want to say before we finish up? I know that you want to encourage contributions. So, you know, the repository is at github.com

1:32:12 slash someone help me out there. Yeah. Sure. So so You, me? Me? You gotta find something. Maintain it. It. Yeah. Good luck on it out there, Alessandro. So I'll let Ricardo give some details there. Yeah. Sure. So, yeah, if you wanna contribute and you shared, there's no reason why I shouldn't, you can go to github.com/kapitan. Kapitan with a k, just like Kapitan. As many bugs, as many ideas. There's a lot of people actually helping out in this really fun community. We're also on Slack, the Kubernetes Slack under, hashtag Kapitan. Oh, crap. I don't think I'm in there.

1:32:53 I'm gonna have to get in there. Alright. Mhmm. Alright. Again, thank you very much. That was that was great. Really great project. Everyone should definitely check it out, I think, to get a lot of value from adopting Kapitan. Have a great day. I'll speak to you both soon. Thank you. Thanks. Thank you, David. Take care.