0:55 Introduction & Welcome

0:55 Hello, and welcome to today's episode of Rawkode live. Today, we're gonna be taking a look at cdk8s, a component library, SDK, and extraction for working and defining and templating Kubernetes resources. Before we end, there's just a little bit of housekeeping that I'd like to cover. First, please remember to subscribe to the YouTube channel and click that bell. That means you're gonna get notifications for further episodes as we explore the cloud native landscape together. Also, we have an active Discord channel and server. Please come and join us. If you wanna communicate after this because you're not watching

1:09 Housekeeping & Sponsors

1:30 live, you have questions, or you wanna suggest new technologies to cover on a show, Discord is the best place to do that. And also, I'd love to thank my employer. They allow me to spend a good portion of my time working on these episodes, producing content for us to continue learning. The cloud native landscape is vast and we all need all the help we can get to make sure we understand that and leverage it as much as possible. If you wanna check out Equinix Medal, there is a code of Rawkode Live. This will get you $50 in credit. That $50 will get

1:59 you around a hundred hours of compute on a modest instance. Have fun with it. Let me know how you get on. Okay. That's a bit done. Now cdk8s, I do not know anything about cdk8s. I haven't used it before, so of course, I'm not gonna go on this journey alone. Today, I am joined by Elad Aben Israel, the maintainer and I think founder of cdk8s. Hello there, Elad. How are you? Hey. Nice to be here. Thanks for having me. No. No. It's all my pleasure. Thank you for joining me today. We're really looking forward to learn more about cdk8s and yourself.

2:15 Guest Introduction: Elad Aben Israel

2:33 So why don't we start there? Please give us a little bit of an introduction into who you are. Okay. So I I'm Elad. I'm a software engineer at Amazon at AWS. I've been there for about six years already. And in the last three plus years, I've been working on the on the CDK, the cloud development kit. It's a project that, originated from, from from some work that we did, when I worked with Amazon search and basically kind of trying to just, you know, solve real world problems of of being able to define complex systems through software.

3:01 The Philosophy and Evolution of CDK

3:19 In a sense, it's kinda like the evolution of infrastructure as code towards, the software space. And the first three years almost of the project, we've focused on a product called AWS CDK, which is in c which is, which is a software as a, sorry, infrastructure as a software, tool for defining applications on AWS and, you know, using AWS resources. And at some point, we realized that the approach is very applicable to other domains, and that's how CDK for Kubernetes, was created. We we were, like, looking for for areas where the same approach can can apply,

4:02 and I can talk about it. And we'll talk about it a little later. But, basically, I've been doing CDK for the past four years. It's been an amazing pleasure. We have a really awesome team, distributed across the world of maintainers of of AWS CDK and CDK for Kubernetes and the CDK ecosystem. And, the most fulfilling part of my job is that I've seen this community kind of evolve from nothing. You know? Like, we've just basically put this tool out there. We didn't even spend too much energy or or re or investment on, like, marketing or

4:37 trying to, like, push this too hard. It was very, very organic. And and I feel like it's fulfilling because I feel like this organic growth is is based on value. It's based on actually solving problems for people, and, that's been that's been incredible to see in the community around the CDK, AWS CDK, and CDK for Kubernetes, and there's a CDK for Terraform now. And and so this this CDK kind of ecosystem is starting to evolve. It's very early. I feel like we have so much to do and so many things to to still to, like

5:14 can still happen there, so it's very nice and fun. But I've always been a developer tools person. I've always the one that's that's like writing these tools and shoving it in peep my friends', you know, my friends' face to, like, use. And finally, I'm doing it. You know? I'm I'm I'm doing it as a as a as my day job. This that's been incredibly fulfilling. Yeah. And I think there's a couple of things we can definitely touch on there for sure. I I definitely consider myself a developer tools person as well. I always find it

5:36 Developer Tools and Infrastructure as Code

5:43 much more satisfying, right, in tools to automate and help my developer colleagues rather than probably work on the products themselves. It feels like, you know, you've done exactly that with cdk and cdk8s and all of these other kind of variations of that as well. Yeah. There's something really fulfilling about like helping people do their job better and faster. And Yeah. CDK just in in general, I think is one of those really awesome things. Like, I think we've all been through the last, what, ten years of infrastructure as code and the different variations of it going from obscure DSL to

6:17 obscure DSL, being constrained and confined by whatever the original creators of those DSLs thought we needed to do. And, you know, this really trivial and simple idea of, well, why don't we just use our favorite programming languages in order to be able to build our own abstractions? Why did we not do this sooner? Like, I just you know, in hindsight, it seems like It seems yeah. I think I think that, you know, I can totally understand how that happened, and it's happening in many fields as well. I think the infrastructure space, was originally not a developer

6:57 led space. Right? Like, it was led by people who were, managing data centers. Right? Like, in infrastructure in the past was basically a bunch of machines. And so, you know, your data center engineers would provision those machines and maintain them and make sure they're, you know, up and running, And then developers would come in and just, like, shove their bits into those machines. And so that separation was very, very clean, and it was very easy to to manage. And and so the tools around infrastructure as code kind of came from as an evolution of that. Right? In a

7:31 sense, their evolution to to solve problems for for ops engineers, which are not or which which in some cases are not developers. In many cases, they are, but in some cases, they are not developers. And the complexity that they needed to manage is is is was very small at the in the first place. Right? It's like, okay. Let's define how my fleet looks like or maybe the fleet in the database. And and and I think what happened is that and AWS is definitely, like, leading in this space in a way, is, like, there is a proliferation of managed services and managed resources,

8:06 that are available to develop to, you know, to app creators. And the there's a there's a shift between from ops people to developers to manage those resources because the bound the line that kind of defines what is an application and what is the infrastructure is really becoming very blurry. Right? Like, when you're when you're building a serverless application and you're using Lambda functions and, you know, day Dynamo tables, is the definition of your Lambda function and the Dynamo table, is this part of the application or part of the infrastructure? It's not that clear. Right? And so I

8:43 think that's what happened. Right? Like, can that it's literally what happened to me. Right? Like, when I needed to build a big complex serverless application, when I worked at Amazon Search, I was like, wait. Wait. Wait. I'm not gonna rewrite this huge JSON file and deploy that to, like, multiple regions and accounts and have, like, parameters tweak things out for each one. Was like, I have all those like you said. Right? Like, I have those incredible tools and that I'm using every day as a developer. I wanna be able to just use them to define

9:16 my entire application, not just this little Lambda handler. Right? Like, my so that's how I feel this evolution, is happening, and I'm I'm pretty excited that that we're if they're making that available to developers in their, like, native tools and familiar spaces. Yeah. Definitely. I think, you know, you must be now getting to a position where you're seeing, I guess, teams within Amazon and even externally are using CDK to spin up their own EKS clusters and provision or an s three buckets and then using cdk8s to deploy their applications to those clusters. All within the same tooling, the developers are

9:37 The CDK Ecosystem and Interoperability

9:54 really taking control of probably the entire stack and a very natural way to work with their own tooling. I think one of the understated things as well about cdk8s and other tools like it is that because you get to leverage, if you choose TypeScript, you have this strongly typed definition of what an EKS cluster should look like or what your deployment should look like in Kubernetes. And even just that moving away from, you know, everyone's favorite programming language, YAML, can give you a lot of value add as well. So I'm very excited to to be playing with that today. Yeah.

10:25 And and and I think that's an inter interesting thing. Maybe we can talk about it in the end if you're if you're if we have some time. But this interoperability between CDKs opens up a lot of interesting possibilities. And we've actually, like, added some capabilities, the AWS CDK, to support CDK for Kubernetes definitions, pretty natively. As and as you say, you can, like, literally define your cluster and you find your your resources within the cluster in the same code base. Right? Like, it's the same application. Yeah. Definitely. I I think that probably leads me on

11:01 to my my first question. Oh, well, before we do my first question, we have a hello from Sunny. I'll pop that on the screen. Hey, Sunny. Thanks for joining us. Does writing the CDK for Kubernetes, is it more difficult than, you know, a domain like, you know, spinning up an ETS cluster where the APIs are well defined? Like Kubernetes, it's so extensible for custom resources. Was that is that a challenge or does cdk8s really can actually make working with those custom resources easier for your Kubernetes operator or developer? It was it was an it was not a challenge,

11:09 Discussion: CRDs and Kubernetes API Extensibility

11:37 but it was definitely an evolution of the way we thought about the CDK because and and in a sense, it's it's funny because a similar thing happened in the AWS CDK, but after we've released CDK for Kubernetes, I'll I'll roll back a little bit because the AWS CDK has the has a fixed low level surface area, which is CloudFormation. Basically, synthesizes CloudFormation templates. And CloudFormation is the is a well defined schema. Right? Like, it there's many, many resources, but they're all very well defined, and we know them in advance. And so we we do in this AWS CDK,

12:13 we statically generate classes based on that schema so that you can use, the AWS CDK. So you can use your programming language to define those low level resources, and then we have higher level resources. We'll talk about that a little later. In Kubernetes, like you said, the surface area is not fixed. Right? Basically, there's the core Kubernetes API, which is also a moving target. Right? Like, tons of changes and versioning and deprecations and alphas and betas and blah blah blah. And then there's an an basically, an open ended surface area for custom resources. And so when we approached CDK for Kubernetes,

12:53 we were like, okay. We need to take a slightly different approach here because we can't statically generate all those things because we don't really know what the what users would would need. And so one of the key ingredients of CDK for Kubernetes is what we call CDK's import, which is this capability to basically point the CDK for Kubernetes a CLI to a resource definition, whether it's a CRD or the Kubernetes API at a specific version Yep. And automatically generate those classes. We'll get we'll we'll see that, obviously, when we when we play. But but that was an interesting

13:28 difference. And the thing that happened after that was that CloudFormation had announced that they're opening up the the resource model for CloudFormation through CloudFormation registry, which basically means that we actually have the same, the the same problem in c AWS CDK. And we actually didn't we still didn't implement CDK import, but this is definitely the plan. Right? Like, the idea is that these, these, like, dynamic surface areas is something that's, it's not too hard to support, but it's definitely a difference from what we did in the AWS CDK. Awesome. Nice. Well, I think we should dive straight in there.

14:08 Starting the Hands-on Introduction

14:08 Let's let's start playing with it. Yeah. And let's see what we can do here. So let's pop over to our screen share mode. We're now floating bubbles. We have the cdk8 documentation. And I I always start these streams from a complete newcomer perspective. There's no tools installed or anything like that. So we're just gonna kinda get ourselves through the documentation and get started with a very simple example and then we'll we'll have a bit of a conversation and we'll see if we can do something slightly more elaborate. I really would largely kinda really wanna touch on the CRD

14:41 stuff, so we'll we'll hopefully get to that as well. Okay. So I think one of the superpowers of of cdk8s, sir, is that, you know, we can see here we have some prerequisites that tend that allow me as a developer to work with the tools and languages that are native to me. So cdk8s supports TypeScript, Python, and and Java. Is that correct? It's correct. But there's also, technically, we also publish dot net support. It's not it's still not documented because we we wanna make sure that we get the best experience. And we even have very, very preliminary Go support,

15:17 which is, just, just last week was, was when we finished working on the the the thing with with these language, bindings is that we actually generate them from the TypeScript definitions. It's we use this technology that we built for the AWS CDK called JSII, which is pretty pretty cool. And so when we add support for Go AI, then suddenly we're able to deliver CDK for Kubernetes and AWS CDK and CDK for Terraform. And, basically all this all the all the libraries that use JSII as their compiler. In a sense, it's kinda like a a subset of TypeScript that supports

15:59 binding to other languages. And so we've actually we're we're wrapping up support for developer preview for Go, and that means that CDK for Kubernetes is also gonna be available in Go soon. So that's pretty exciting. Yeah. I can imagine that's a fairly popular choice among cloud native developers. Yes. Exactly. It's probably the default language in 90% of the cases. I'm gonna hope I'm not the first person to ask, but is is Rust on your road map? It's definitely on our radar, especially given that some of the Rust maintainers are now, working for AWS, and, we're really excited to, like,

16:37 use Rust internally a lot. And and so, yeah, it is definitely on our road map. It's it's a big investment to add these languages. Go check us a year to work on. Oh, wow. And so we really need to be strategic about which languages we use, we we support because it's it's quite a lot of work. The surface if you can imagine, the surface area of a language is pretty large. Right? If you think about the primitives that we need to support every language, like classes and interfaces and inheritance and methods and optionality and data types. And and so to that

17:10 end and Go was actually super interested interesting in that way because it it has its own, you know, idioms and and primitives and so mapping those. Anyway, it's definitely on the list. I don't know if it's the second it's the next one on the list. That's that's what I'm trying to say. We're we're still we're still thinking about it. Yeah. For all those good developers that mess at our check-in every three lines, they can now do that with their cdk8s as well, I would imagine. So I I read a lot of Go and I I really enjoy Go, but I I I

17:41 really wish I had like, you know, the question mark operator and rust where the errors would just automatically be propagated up, but I'll run into that another day. We don't need to talk about that today. Okay. So the first thing I need to do is install the cdk8s CLI. So I should have NPM. I do have NPM. I'm pretty confident there. So I'll let that run-in the background and then we can use the cdk8s CLI to initialize a new project. Is there anything special about that? Or is it just a standard, you know, kind of node based project with

18:06 Initializing a New cdk8s Project

18:15 just some stuff bolted into the package you start JSON, I would imagine. Very very strict. It's very empty. You'll see. Yeah. Cdk8s is basically a library. Like, AWS cdk8s, it's just a library and the CLI. Right? Like, it's basically this combination. But you can technically use cdk8s without the CLI if you wanted. Like, it the CLI is basically just a kind of like a, you know, some gives you some workflow tools around the project. But it most of the logic, almost all of the logic is actually part of the library. Okay. Well, let's just take a look at

18:51 what we got there. Now, the sidebar is always a bit difficult to read, when I pop stuff open, we should have a much better view. But it looks like a pretty standard node project. I'm looking at the package dot JSON. I can see that we're pulling in a bunch of things. So the cdk8s plus 17 and then constructs. Maybe you just wanna give us a little bit of information on what each of those are. Yeah. So cdk8s is the main library. It's basically where it's basically the core the it it contains the core classes and

19:01 Exploring the Project Structure

19:27 basically allows you to use cdk8s, but it doesn't have any high level abstractions. It doesn't have any specific support for Kubernetes resources. In a sense, we sometimes call this l zero, level zero, because it basically gives you the ability to synthesize Kubernetes manifest using a CDK paradigm. And it has all the kind of base classes. It has the chart class. It has, API object class. So, basically, classes that represent the the the Kubernetes, you know, abstract primitives, let's call it. Now c d k cdk8s plus is what we sometimes call l two, which is layer two.

20:11 Core Concepts: App, Chart, and Constructs

20:15 And we'll we'll cover it, maybe later because I think that's worth a separate discussion, but we we we really recommend using that. It's actually a pretty powerful layer, and it would be interesting for me to, like, hear what you think about it when we get there. And then, constructs is actually the low level programming model that's shared across all cdks, and that's a component model that allows you to compose these abstract things together into higher level concepts. And everything in the CDK, in all CDKs, is a construct. The app, the chart, the API object, and everything that's higher level than

20:53 that, they're all constructs. So if you you can think about them as as a programming primitive in a way. They're like composable functions. You know? Like, they're they you can take these two constructs and multiple constructs and create a higher order thing from them. And we'll see them in use, I think, probably. Alright. Perfect. I have to see we have a bunch of scripts. So I can see the import here. I'm assuming that's for bringing in custom resources. I'm sure we'll play with that. I'm assuming send for just gonna is that the generate the gamble for me?

21:24 Yep. Okay. And then we've got some TypeScript stuff. I I find the inclusion of jest on a test command interesting because I can speak from my own experience and I can speak from, you know, you know, when I speak to people or used to speak to people at conferences that testing their their codified infrastructure and application deployments is something that people have wanted to do for a long time and has always been very, very painful. So I'm curious if that's something that cdk8s is gonna make easier for me and and what that looks like. So

21:30 Testing and Snapshot Testing

21:53 that's really exciting. Alright. What else do we have here? So the package dot JSON is is what we've just spent. We have our cdk8s dot yaml, Just some boilerplate, I would imagine. This yeah. This is basically configuration for the CLI so that it knows about your application. So it knows what language you're using. The app attribute basically tells the CLI how to execute your application because it's in a sense, when you're synthesizing, you're executing your code. Right? Like, the execution of your program is what produces those manifests. And so when you're doing cdk8synth, it needs to execute your application. And in

22:31 in in in since we support multiple programming languages, we need to tell the CLI how to execute your application. So that's basically why we have this app thing. And import is basically a set of imports that you can specify via this config file, but you can also import via c the CLI. Right? Basically, just run the command line to import, and we'll probably play with that a little later. Cool. Awesome. Alright. Let's see. I see that we have a main TS and a main JS. So let's just pop that open. So we're pulling constructs, app chart and chart props. We can kinda

23:09 cover this when we get to or example, we have a class. Is it fair to say that this hasn't deployed anything or is there some magic on there? No. Like, you can, let's try. Let's synthesize and see what app what's what's the output. Alright. So I could I guess you would do m p npm run synth? Yeah. Or you could do Or you could do cdk8synth, whichever. It's the same thing. Alright. And we get hello dot kubernetes dot yaml in our disk directory. Yeah. Very nice. Cool. That's Good job. What I was expecting, I guess. I looked at, you know, there there's

23:59 nothing Kubernetes here. That just looks like it's setting up our app and chart. I'm not entirely sure what those mean yet, but we'll get to that, I'm sure. So there's also the inclusion of a main dot j s. Oh, this is just generated right now. This is a compiled output. Yeah. Exactly. Okay. Do we ship with any test? Yeah. Okay. Cool. We've just got a very simple check that thing. Yeah. So this is in just there's a concept called snapshot testing. I don't know if if you're familiar with that. But, basically, it's coming from React from the React world.

24:20 Introduction to Snapshot Testing

24:33 It's very good for for things like React and things like the CDK, and there's actually pretty interesting, analogies between the two the two frameworks. But the the nice thing about test snapshot testings is that they're it I kind of think about them as, and I use them a lot, so I can say that. It's like testing for lazy people. The it's they're very, very crude in a way. Right? Because what what they do is they basically they say, okay. Let's synthesize this thing and take a snapshot of the output and then commit this snapshot into my source

25:11 control. And then if something changes, my test will fail. And so to that end, it's basically, kind of like an end to end unit test in a way. It basically tests the entire thing. And, obviously, you can, like, test smaller pieces of it if you wanted, but, it's it's powerful because it a it basically protects you against unexpected regressions. Because one of the things that we'll see is that as you go higher level, you encapsulate and you abstract, and then things can change without intention. Right? Like, can, for example, some low level things some some suddenly changes. You're you're, you

25:45 know, downloading a new version of some dependency, and suddenly your your manifest changes in a way that you didn't expect. And so this approach of snapshot testing is a really powerful and simple way and cheap in many in many senses to to see what's happened. Right? Like, to basically connect the this this stack of abstractions to the output and make sure that you know what what's going on. And we'll we'll probably we can play with that later if we have some time. Okay. Perfect. Yeah. I'm yeah. I'll just leave that. I haven't I mean, I've I've babbled with TypeScript and React

26:22 and, you know, I think I've rebuilt my blog like 14,000 times in the last one month probably. But the testing is something I've always avoided and I've always I always read about jest and the way that it can help. Maybe my way into getting better, that will be through cdk8s, which would be nice. Yeah. It's definitely it's definitely one of the killer features of of of the CDK paradigm is the ability to write tests and get more confidence. Yeah. I mean, I I I will speak for don't wanna put words in, you know, anyone else's mind,

26:57 but I'll speak for my own experience. And that's that, you know, when I have what I have what what I want as a deployment mechanism for an application on Kubernetes is like, other than the image, I probably don't want it to change that much. And the image, don't even want to change in my manifest. I want that to be something that happens within the cluster. So like, I can understand why snapshot testing is gonna give me that really quick feedback of, hey. This changed. And at least if it's correct, I can still review that and

27:22 say, okay. That's that's the change that I was expecting when I reran it. So Yeah. And and the nice thing about about using snapshot testing is, as I said earlier, you can you can do snapshots on a smaller on smaller pieces. So if you, define if you create a construct that represents an an abstraction, right, and you use this construct in your app or you publish this construct as a live user, you can test this construct through snapshots. And so it's not necessarily about snapshotting the entire application. You can snapshot any scope of that application.

27:57 And and so it's basically it is a unit test in many you know, for all intents and purposes, and the granularity is yours to decide. But at the at the minimum, I would recommend using a high level, you know, basically, a low resolution or high level granularity to basically make sure that you're protecting yourself against unexpected changes or regressions. Alright. So if we continue then through our documentation, we're now being introduced to kind of two new concepts, which is the app and the the chart. Are these as I would expect them to be? Are they specific to CDK?

28:28 Deep Dive: App and Chart Structure Explained

28:32 What is an app and chart in this context? So an app is basically the root so let's let's go back to the concept of constructs. Okay? So though these constructs are these is composable units of abstraction. And the way you compose things is basically you create a tree. So there's a there's a root, and then the root composes a bunch of other things, and then that and then these other things compose other things together. And so in a sense, you can think about it as a tree. And in in the CDK, it's an also in the c AWS CDK,

29:07 the root is called an app. Right? This is basically the root of the construct tree is the app. It's the everything starts from there. And then the second level is normally, a deployment unit. And in in cdk8s, we use the chart we use chart this chart name as the deployment unit, and we borrowed it from from Helm, of course, because they do resonate with each other. Right? Like, it's kind of like and and but practically or mechanically, a chart is basically a manifest. Basically, synthesizes into a manifest. The reason we didn't wanna call it a

29:47 manifest was because CDK terminology is about the result. It's not about the artifact, if that makes sense. Right? Like, for example, I have a class called pod. And so the class is is not called pod manifest or pod definition. Right? It's called pod because it represents it models the idea of a pod in the in the output. Right? And so to that end, we use chart to represent a single manifest. And and so what you can see here is you can see an app as a root and then a single instance of a a chart type.

30:23 And like oriented, you know, programming language, there's a type and there's an instance. And so in this case, we're defining we're declaring a new type called my chart, which extends the base type of chart. In this case, it's it doesn't do anything with it. So it's basically the same thing. Right? Like, it doesn't come it doesn't there are no no specifications here yet, but it is a type. So so I can, like, instantiate it as many times as I want, which is a very powerful idea. And then I'm instantiating it once and adding it to my app. And this the the

30:56 programming model the the programming syntax is a little odd. I'm aware of that. Like, it's definitely been kinda like the cdk quirk, I would say. It's basically when you're work you're you're constructing a tree in a way that you're doing that during the initialization of the objects. And there's a very power it's a very powerful idea, but it it people sometimes it throws people off a little bit, because you're basically passing the parent as a parameter to the constructor of the of the child. And this way and this is how you basically bind the child to the parent.

31:35 I can talk probably I could spend an hour just talking about why we did it like that, but maybe maybe we can do that later if Yeah. I just wanna kinda It's an interesting design decision. Let Let me just make sure I understood this right. So like an app then, like for every repository I have that is doing some sort of cdk8s deployment, I'm likely just to have one app and it's there to hold all of the charts that are created. The charts themselves, you mentioned something there that I wanna make sure I I I definitely understood is that

32:04 a chart is one manifest. Now is that just one YAML file that can contain multiple Kubernetes objects, or would it correlate to one to one with a Kubernetes object? It's it's one YAML file. Basically, when you're doing if you if you add another so in your code, have one chart. Right? Let if you let's let's play with this, and and I'll show It's Okay. Why don't we just yeah. That's a good idea. Why don't we just come into this thing here Yeah. And, like So it's Sorry. Go. Just to to give you just to explain the

32:33 the the the the mapping. Okay? So let's add another on line 14. I can even I can even do this. Right? Yeah. Yeah. Yeah. We can let's add another one here. Okay? A low one and a low two. Okay? K. And so now if you call cdk synth, let's see what happens. You're in the right directory? No. Did we say wait. Oh, we since since the CDK cdk8s.YAML if you look at cdk8s.YAML, it actually executes the node version, not the TypeScript version. Not here. The the yeah. CDK. Cdk8s. Yaml. Oh, yeah. Yeah. Yeah. Alright. Okay. Yeah. The So what we

33:31 what what we need to do is we need to actually run compile the code. Right? Like, you we've changed the TypeScript code, but it's actually running the JavaScript code. So you can either compile it explicitly, or what I would recommend is run a watch in the background. So if you open another terminal window yeah. You can do that in here and then open another one and to use. So that's continuously gonna compile your, your stuff. Give it a second. I think it's probably just Yeah. Still compiling. Okay. Try now. There we go. Two YAML files. We go.

34:00 Adding Our First Resource

34:11 So now we have two YAML files. Both of them are gonna be empty. But then if we we change our chart, you'll see that these two YAML files will will have the same output. And so let's, let's continue like this and see how that Okay. So why don't we add our first resource in their chart? Like Yep. A very standard thing on Kubernetes would just be to add a deployment. So I feel like, why don't we just add a NGINX deployment and have that render out, and then we'll see how much we can kinda tweak and and modify that as

34:26 Adding Kubernetes Resources (Low-Level API)

34:40 we need. Okay. Sounds good. So as we saw earlier, cdk8s.yaml imported the core Kubernetes API by just saying k eight s. Mhmm. We can do that manually if we wanted. We can do that by changing the the YAML file, but kinda like when we're initializing a new app, it kinda comes in with an imported core Kubernetes API. And the importer import imported, constructs are gonna be under the imports directory. So if you see you see that there's an imports directory over there? Yep. There you go. So you see there's a k a s dot t s file.

35:20 If you go to that Oh, go to it. Okay. I was just gonna wait a minute. To show you, like, going on inside. So you see this is generated by k by cdk8s, and it's a it's a big file. It contains all the core Kubernetes resources as classes, as constructs. Yep. And so now if you go to the main file, we can we can try and use the deployment one. So let's do import. Go ahead. One of my favorite things about using TypeScript is that generally thing because the the language server stuff is also good is that you can generally work

35:55 my way through it without actually knowing what the hell I'm doing. So I'm gonna see if that works here. Okay. Do it. I'm not gonna say anything. So if I just say deployment Hold on. Now I'm gonna start typing go and rust and a whole bunch of other languages like I always do. But if we do kits and then deployment oh, kube deployment and there we've got scope. And we're gonna assume that's a string. In fact, no, it's a construct. Yeah. I'll come back to that. Let's just do that for now. And then an ID

36:25 and then props, which I'm assuming Yeah. There we go. I'll give it a name. Call it engine x. I've got my spec. And I think this is one of the you don't get this with DSLs. Right? You don't get this autocomplete greatness. At least not built in. Yeah. Exactly. Alright. Container. You should also you should also a little pro tip with the Versus Code. If you'd showed the the the completion list list before you just show the just, like, hover over on one of the options. Yeah? Mhmm. So no. Actually, what I meant is that

37:09 if you let's yeah. Here. Exactly. There's a little, scroll. Stand on one of the put put your mouse on one of the there's a little icon. Click click here. Click here. There you go. So now you're gonna see if you if you if you, hit butt bottom and up. If you just, like, scroll around, you'll see all the documentation. Yeah. There you go. That's what I'm it was very hard for me to explain. But, basically, you get, like, the full documentation API documentation here. Nice. Okay. Yeah. That's really good tip, actually. I I had no idea about that. That's

37:48 cool. Let's see if I can use that to work out what a construct does then. So there is a way to get the parameter thing, but I can't remember. Yeah. You you can hover over the cube. Yeah. Exactly. Okay. So we we have this class called construct. I don't know if I'm supposed to do this. No? Alright. Okay. I'll I'll let you get me. What what's the construct? Yeah. This is this is in this is exactly what I said earlier about this quirky idiom. You always pass in this for scope. Oh. Not scope. This. This. This

38:23 is basically how the tree is structured. Right? You basically say, I wanna define this cube deployment in the scope of my chart, right, as part of my chart. So it's always this higher there's a there's a kind of, like, this relation between your, AST or your code, your the structure of your code, and the structure of your construct tree. And the way we we capture this is by asking you to say which scope and in which scope you're defining every construct. So that's the so, basically, the rule of thumb, just always this. Always this. Got it.

39:01 Alright. So I'm gonna just sorry. I need to go. Yeah. No. And then the second, the second parameter is an ID, and that's actually an interesting there's an interesting point about it. Because the name if you look if you hover over the metadata name field, scroll up a little bit, you see that it's optional. And that's actually almost the most important the single most important difference between writing manifest by hand and using cdk8s. You should not specify names explicitly. And the reason this is important is because these names are these these automatically generated names are the only way for cdk8s

39:49 to allow you to compose constructs together. Right? If you give it an explicit name and I add two instances of this construct into the same Kubernetes cluster, then they conflict with each other. Right? Like, it's it's a very common problem. And cdk8 solves this by by creating relative naming. So the the ID that you give a construct is relative to the scope in which you define it. And so if you define a subscope and you can still call something NGINX, but then the actual, Kubernetes resource name would derive from the path of that resource in in the construct tree.

40:25 So it's a very powerful mechanism and probably one of the most important pieces to enable composition. Okay. That makes make sense? It does make a lot of sense. Yeah. Okay. So I'm assuming I can still pass in my namespace, though, as normal. Yep. You can pass in namespace. You can even specify namespace at the chart level, and then all the resources will get the will be in that in that namespace. You can even I think you can even specify namespace at the app level, and then all the resources in the entire app will get the same namespace.

40:57 Awesome. I like that. Okay. Now another awesome thing about us using TypeScript and real program languages here is that we can see this red squiggle. It's telling me that my manifest doesn't have all the required fields, and it's complaining about the selector here under the template spec. So here. Oh, no. It's here. Here. Yeah. I swear I've done Kubernetes before. And this wants a Kubernetes label slider, which seems to be its own type. So I'm just gonna do that and rely on auto complete again. And then I can do match labels. In fact, that's probably a list, isn't it?

41:40 Of objects. No. No. I think match label is a is an array is a is a map. It's just a map that I can put anything in. So I'm assuming I can Yeah. Just put whatever. App engine. App. Yeah. And now what we have here is, almost working deployment. We'll just do engineering. And I can also need to label the the in the template, right, to add a metadata section in the templates. Not yeah. Yeah. Exactly. Labels. Yeah. Those those are stuff. That's always bugging about Kubernetes, to be fair. I feel like you should only need to define that once,

42:20 and we're forced to define the the same redundant options twice. But Well, wait until we get to cdk8s plus. But even without cdk8s plus, we can already do some some incredible optima you know, some some magical thing. Let me let me drive for a second, if you don't mind. Yeah. Go first. It's called a constant. It was invented in, like, fifty years ago, probably. Yeah. Oh, yeah. So yeah. We can we can refactor those duplications out to new variables, drop them in. In fact, I've been using Pulumi to do stuff similar like this for a long time. And there's some

43:12 weird quacks using Pulumi and it's like Terraforma has state. I don't don't actually want that. I just want the YAML. But one of the things that I do there is that because again, this is real programming language. Because I can just grab this. Unless I'm assuming this is maybe what cdk8s plus is doing. But I could just drop this in as a function. Right? Mhmm. Create You could nginx equals that. Although I've lost this, so I will need parameters. So I guess I need to pass in scope. Yeah. So you you can define it as

43:51 a function, or you can define it as a as a as a construct, as a custom construct Yeah. Which is again, as I said, there's a the it's it's a it's a type of a function. Right? It's an object oriented function. Alright. I just want some of the types. I'm I'm gonna revert this. I I do love the fact that I I have this flexibility to kind of layer on my own helper functions to my team. Like, if I wanted to provide a really simple not simple, but, you know, a complex head and simple interface to what

44:24 we expect Kubernetes applications to look like within our organization. Like, this just opens up so many different new possibilities. But let's push us back. Okay. So we should be able to synthesize this. Right? And we will get there's a there's a good point. There's something there's a disconnect in my head right now. All we're doing is to find the two constant values on a constructor. Is that all we have to do? Is that do we need to connect these up somehow? Two? Well, because this constructor is creating two variables that aren't stored on this. They're not properties

45:02 of the chart. So that's that's that's going back to this quirkiness that I talked about earlier. The fact that you've created this instance and passed in the same scope, and as I said, this needs to be this, it would it would bind it to the tree. Right? Right. And so you really don't need you really don't need this. Right? Like, you can really do this. And I know it looks a little odd to some people, but you get used to it very quickly. It's it basically the CDK programming model that's based on this construct tree. So you

45:37 say new Kubernetes deployment inside this scope, and that's all that's all you need. Okay. Yep. So the fact that we are passing through this, the the output Exactly. Instance of this doesn't really matter because it's bound to the tree. Yep. And it would matter if you wanna bind it to other things. Right? Like, you could take an output, there's an actually API behind it, and we can check it out later. But for this use case, you really don't need anything. Okay. So I'm gonna I'm assuming our watch is still running. I'm gonna synthesize this. And what we I guess, I'm expecting to

46:08 Synthesizing Output and Resource Naming

46:12 see is that we're gonna have two deployments with NGINX as a base name and something tacked on the end possibly. Yeah. There we go. So this is our chart name, the ID for the deployment, and a random identifier, if that's correct. It's not it's not random. It's a hash, basically, of the path. Right? So it basically cons it's basically rendering the name by concatenating the the components of the path and and, adding a suffix that's the the hash. Because if it's it it needs to trim the size. Right? Like, there's a limit in the size. It needs to trim the size.

46:54 It needs it it uses this hash as the unique fire. Yeah. Of of course, it's a hash now that I think about it because it was like, if I run this again in my continuous integration system, if there's no changes, I don't want to be rolling out a Exactly. Different name. Alright. Exactly. Now I'm gonna go out on a limb here and just throw something out there. But I'm assuming that cdk8s plus doesn't really want me to interact with cube deployments in this kind of fashion. In fact, I'm gonna kick a wild guess and assume that if I want to deploy

47:14 Introducing cdk8s Plus (Higher-Level API)

47:25 NGINX with a service, there's there's probably something to make that easy in cdk8s plus. Did you wanna walk us through Yeah. Let's try to do that. That's a that'll be a good way to check that out. But I'm just gonna now instead of yeah. Delete all this? Yeah? Or you're gonna say something else? No. No. No. That's exactly what I wanted you to do. Instead of importing, k eight s, let's, let me let me Yeah. Go for it. Drive for a second. Okay? If you don't mind. So so now let's import k plus. And here,

47:36 Using cdk8s Plus for Deployment & Service

48:04 I think I I can see the you so now you type from this point. So now do do a new k plus. Yep. New k plus. K plus dot okay. So here we have deployment. K. This looks familiar. Right? Yeah. It does. Now if you open the props, this looks now different. Right? This this is this is what we call an intent based API. It's a high level higher level API for Kubernetes deployments. It's not opinionated about how you use deployments. It's opinionated about the API. Right? Like, basically leverages the object oriented API capabilities. And so in this case, just do containers.

48:54 Right? And then it's an array. And then each one basically only requires an image because we can probably give you a a reason a reasonable name, and that's it. Now let's, synthesize this. Why? Up here. So you see that it's it was it actually it it actually did some cool things for you. For example, it created a label that matches the, you know, this the the pod template with the selector of the deployment. It also added some defaults to image pull policy. It gave a default for for a name, and then all the rest is it it specified

49:49 a replica for you, which is one. Obviously, you can change all of those things. But now let's let's add this, let's add let's a service. Right? So let's do this like this and see the API and explore the API of deployment. So type deployment and dot. Okay. This looks interesting. Yeah. And there's a method called expose. That's it. Let's just use the default and see what happens. And this is kind of like a design principle we have at the higher level. You know, the k plus is basically minimum minimum required fields and options and properties. Right? Like, be

50:45 Discussion: Intent-Based API Design Philosophy

50:45 very we're very eager to to come up with correct, safe, sensible defaults. Look at that. We get a cluster IP service exposed in port 80. That's I think the ergonomics here and the developer experience is, you know, just what people would expect. Right? They want these tools to help them very little friction. I think what I also I'm gonna take another stab in the dark here because, you know Yeah. That was fun. Is that this looked like it was like some sort of builder pattern. So in theory, can I just chain all these together? We're actually it's not really a builder pattern

51:31 because Expose is not returning a deployment. We deliberately try to avoid builders mostly because they're not very familiar to every programming language. So sometimes they feel very odd in certain languages. And so, like, as a design principle, we try to avoid them. So, yeah, you could do expose if you don't wanna do anything else. Right? Like, it's definitely it would definitely work, but this is this is normally how I would write it. Right? Yeah. So keep it's actually returning the the service itself. Right. Exactly. So expose returns the service, and then you can do something with the service. Right?

52:07 You can explore the API of the service if you want. Cool. So and just let you I mean, besides the boilerplate, we're, what, four four lines of TypeScript there and we're managing to generate our engine x deployment with a service, synthesize it, and that could quite easily be deployed to your cluster and jobs done. Right? We're we're moving on to solving real world problems on our domain and not focusing too much on this. Yeah. Right. Yeah. Yeah. That's the idea of this higher level API. And, again, people can choose to use it or not, but

52:45 we're we're working on this higher level API. It still doesn't cover the entire surface area of the core Kubernetes API, but I think we have the right patterns thought out. And so now it's basically our job is to basically just, like, continue to cover. Okay. There's two there's one thing in my head right now that I'm a little confused about. So hopefully, we can kind of expand on that. So when we use k plus, we're importing the library. However, for the Kubernetes objects, they're actually generated at an imports folder. Why why are the why is the core Kubernetes API not delivered

53:19 Generated vs. Handwritten APIs

53:27 as a package as well? Mostly because we don't need to deliver it as a package. Right? And because we wanna give you full flexibility into, deciding which language to you sorry, which version to use. And k plus is handwritten. Right? Like, this we have we we are handwriting these these these classes, and we're thinking really hard about the, you know, the the heavy lifting that we can do at that layer. And so in that sense, we can't generate that. And that's why cdk8s plus says cdk8s plus 17 because it basically it's compatible with 17 plus, right, for

54:10 version 1.17 and above. And that but we will need to write one for eighteen and nineteen and twenty. And and, obviously, because we're using standard programming languages, we can reuse a lot of stuff that we did in '17 for stable resources and add the new. It's not that we really need to rewrite the whole thing for every language version of the of of the Kubernetes API, but it's it's it's a it's a hand you know, it's a it's a manual process as opposed to the imports, which is completely automatic, and every new version of Kubernetes would automatically be supported. You don't

54:30 Working with Custom Resources

54:47 need to you don't need to do anything. And maybe that's a good leeway to, like, maybe looking at the CRD support. That could be fun, fun thing to I was just thinking that myself. I was like, why don't we grab a custom resource and see how we can bring that into this kind of of workflow? Cool. Alright. So Do you have any particular one that you're interested in? Well, I I do a lot of work on the cluster API project. So why don't we import their types? Okay. So they should have a release artifact here

55:20 Hands-on: Importing CRDs with `cdk8s import`

55:20 with the YAML components. So did I just download this YAML to be able to import it? Can I throw a URL at it? What what You could throw a URL. K. So what do we want? We want the core component. Just a second. My battery's almost stopped. Oh. Please. Is that better? Yep. Sorry. Does this stop yelling at you now? Okay. So let's see. CDK import. Nice. The support stocks dot c r d dot dev. Yeah. That's a that's a contribution from Crossplane, which is awesome. Yeah. Dan from Upbound slash Crossplane is I know he's been very

56:11 publicly working on the docs there, do that dev stuff. So a great job that he's doing there, definitely. So types to import and then And then URL. Yeah. Alright. Nice. It's imported our add ons, CRDs, and our clusters and our machine. Yeah. And if you look at the imports directory, you'll see the results, basically. Yeah. Awesome. So now let's do you wanna try and use one of those resources? No? No. Okay. Okay. So oh, from import. Let's try and do the cluster thing, cluster. Okay, so we have access to the cluster API cluster resource, so I should be able to do

57:18 new cluster scope, of course, my cluster, the spec. I wish I had picked that easier example now because composing a cluster. That's a pretty ambitious Yeah. It doesn't really matter. But I think you I think you I think you can I think you see what Yeah? What what I wanted to see how easy that was. And I think the answer was stupidly easy. Like, literally just cdk8s import, point it to you, you know, a GitHub URL with YAML, and now I can begin to compose these types. Like, that is that's really cool. And, of course, I I

58:08 I could spend the next twenty minutes adding infrastructure, machine pools, machine deployments, and Yeah. But I I don't think that's particularly useful to the audience. But that is really, really simple. I didn't actually expect that to take us thirty seconds. Glad to hear. Okay. So that, I'm assuming, just works for all custom resources. I'm assuming they have to have no. Because we didn't even look at the open API spec. So oh, that's all embedded. The CRD includes it. Yeah. Okay. If the CRD doesn't include the schema for the API, it'll basically be kind of like

58:50 an any you know, like a an open map, which is nice, but it's definitely not as nice as having full, you know Okay. Yeah. So completion. As they don't provide the open API schema, you can still work with it with it, but it's just not gonna be as kind of Tight. Fluid as yeah. Tight as you would expect it. Like, you know, there'll be dragons. You have to worry about your own fields as possible. Okay. Exactly. Okay. That was very easy. Is there anything else on cdk8s that you wanna take a look at before we kinda

59:26 wrap up for today? Is there anything we've missed that you think is particularly cool to show off? Maybe let me go let's let's go back to the code just for a minute. I'll I'll show you how to create a custom construct because I feel like, that's a very powerful tool that, would be nice to, like, show if you if you don't mind. No, please, Naomi. Okay. So I'm gonna delete this for a second. And let's say, as you like you said yeah. Like you did ex earlier, let's say I wanna take these two, you know, maybe add some more, but let's

59:48 Hands-on: Defining a Custom Construct

59:59 just take these two and extract them into a custom construct. Okay? So we'll call that construct engine x. So, basically, defining custom construct is basically the creating a class that extends construct. And from an API perspective, it should be compatible. Right? So it's basically the way NGINX props this is kinda like the standard way of sorry. And we can define NGINX props here and get empty for a second. And then all I need to do is basically just move these here. Right? And let's say, I can add a property says port. Okay? And I'll I'll just

1:00:54 document that the default is 80, and then I can do here props dot port or 80, which is basically and now let's say I want two NGINX deployments, I can just do this NGINX 80, and this would be like this, and then whatever. Just make this up making this up. Does that make sense? Yes. Yeah. You can synthesize this and see see the output, but I think it's pretty evident, right, that it will work because I didn't do anything special here. It's just programming. Right? Yeah. So all you have to do is create a new class that extends the

1:01:38 construct. You can define your own properties that you wanna accept just by adding an interface definition. And then you just spec out what you want, allowing the overrides wherever possible. And then you provide this really nice API for your team or the organization to just say, hey, I wanna deploy a web app or I wanna deploy Internet or I wanna deploy Exactly. You know, a cron job to my customer with certain constraints, etcetera. Like, all of that Exactly. That everything that's doing upfront can be Yeah. And and since these are just regular classes, then you can publish them as open source

1:02:12 libraries and share them with, you know, with your team or with a company or or publicly or right? Like, they're just classes. There's nothing special about them in that sense. So I guess that's very powerful. Yeah. I guess this is getting into the territory now. It's like, you know, I think what we showed off at the start was that we can remove the YAML template. Like, you know, we've all been using Helm for years, would imagine. It's painful and quirky although it is getting the job done. But, you know, the problem is is these charts are trying

1:02:44 to encapsulate so many different optional components and configuration that just isn't really meant to be handled through Go templates or YAML. So we can bring that in house and we can say, actually what we wanna be able to do is provide all of these classes that everyone can use and they could be shared. But then the second thing in there that you're doing is the same as Ashley, you know, we can provide our own, like elastics come out and say here is a CDK definition for elastic search that can be tweaked with all of these parameters by defining

1:03:12 a proper interface and just say go nuts. This is how we think we should deploy elastic search, and you can override whatever bit you want with proper programming, not crazy go templating. And I think that is really powerful. Yeah. One more point to make is that you can also you can also just use Helm charts in cdk8s constructs. So if you do new Helm let me just quickly do this. Whatever. Elastic. And then if you yeah. You need to import it. Let me just import it here. There you go. Now if you do code completion here, you'll see

1:03:28 Using Helm Charts within cdk8s

1:03:55 the API. Yep. So you can basically specify the chart and the release and the values and whatever you want. And so that's a really nice way to basically reuse Helm charts, but you can wrap them in a custom construct. So you can define an Elastic construct that leverages the Helm chart for Elasticsearch, for example, but offers a high level intent based API and l two, right, API. So it's not necessarily that you need to rewrite everything that you've done in Helm, for example, if you wanna create these ergonomics, cdk ergonomics for them. Yeah. I I'm assuming with the the presence

1:04:38 of this executable parameter that it's first running a Helm template locally on my machine and then consuming those YAML files. Does once I do the Helm template, can I then modify that YAML or do I just take that as is and that's just the way the Helm stuff works? Not sure I've understood the question. Yeah. So, like, if I were to say, you know, this is the elastic search chart. Oh. What's the return on this? Is it So cdk8s has this concept of overrides, which is a general concept. Sorry. We call it also escape patches.

1:05:12 Discussion: Patching and Overriding Output

1:05:14 You can go you can look at this at the at the documentation. It's actually something that, maybe documentation can help with. And the concepts escape patches. And that's a general thing we add in every CDK, but it basically allows you to patch the output via code. And so to your question earlier, you can add the Helm chart and then patch it to your heart's extent, and you can encapsulate all of that within a construct. And so from a user's perspective, they don't know what's going on. Right? Like, it's basically just a construct that represents a

1:05:50 Elasticsearch cluster or Redis, whatever. And but you can literally fully control the output if you need to using JSON patching. Yeah. Okay. Excellent. So if you really, really need to, there's always that way there to make any Exactly. You have to. You can you can eject yourself into into YAML land, But it's still a but it's still code. Right? And it's still part of your code. So I think it's even you still have that safety, which is really very, very important. Yeah. Definitely. Awesome. Very, very cool project. I I but it's when I play with things like

1:06:31 Multi-Language Support and JSII

1:06:33 this, I just I don't know why we would default to other ways of doing this. Like, I I think TypeScript is such a great language for stuff like this because of the strongly typed stuff, the good language server support, and the ease of use, especially within the node JS ecosystem for just wrapping things and functions that take functions all the way down and really providing abstractions that are tailored to each unique team and organization. And so very, very cool. Very happy with that. Mhmm. Alright. Let's jump back. Yeah. We had we we we have an sorry. And just

1:07:07 anecdotally, we we have a lot of peep like, we hear a lot from CDK users, AWS CDK and CDK for Kubernetes, that they've used types for the first time because of the CDK, and they fell in love with it. So it's, I'm happy to hear. But, again, a c d all those all those tools are available in multiple programming languages, and and, we're really, really trying to make sure that the experience in every programming language is as good as as as we can. It's not always the as it it's not always as good as we want it to

1:07:42 be still, but then there's definitely room for improvement. But, it is we have, you know, big enterprise customers who are using, you know, AWS CDK in Python or in Java, and it's it's all working very well. So it's not Yeah. I guess TypeScript. You know, not to trivialize it in any way, but, you know, all of this code that we see in front of us regardless of the language. I mean, you're really we're building up a big data structure of different types and parameters. And then, you know, being able to jump between languages and then

1:08:19 spit that out as YAML. Again, just so much power. So I can really understand why teams are using Java all the time would want to use Java. I can understand Python and go because these are idiomatic languages and infrastructures code and especially in the cloud native ecosystem. Yep. But, yeah. I I think I'm I'm a TypeScript converter for this stuff now based on based on, you know, my experience with Pulumi and CDK. It's in CDK. Like, it just it's a really good language for for manipulating and working with with types in this way. Mhmm. I shoved a little link to this little

1:08:53 Exploring the Construct Catalog

1:08:54 thing called we call construct catalog, following up on our earlier conversation about, publishing, constructs. And so if you search for cdk8s in the search box, you'll see that there are a bunch of things that people already had already published that could be interesting to, like, check out. And this is basically kinda little prototype for this for this catalog. We're we're we're we're looking into, like, productizing it, so it's a it's a little nicer. But it's a good it it could gives you a sense of some initial, you know, sparks of, like, in this initial sparks of an ecosystem that's starting to build

1:09:37 around this. That's very cool as well. I'm pretty sure I mean, I've I'm supposed to be recording my cube talk cube con talks this week, and one of them is commoditizing cluster API as code using TypeScript. And I've I I really just wanna kinda rewrite all of it in cdk8s now and publish that as a module. So I'm trying to work out in my head if I could do that in under two days and still record a talk. So watch this space. Well, let let me know if you need some help. Alright. Let's jump back over to here.

1:10:09 Thank you so much for joining me today and guiding us through that. It's such a powerful tool. I hope everyone watching kinda gets a taste of this that goes away and checks it and checks it out. I really do believe these tools are the best way to deploy to Kubernetes. Is there anything that you would like to finish with before we wrap up for today? Anything you wanna share? Anything you wanna link to? Anything you want in the show notes? I guess the only thing that I can that that's important to say is that, cdk8s

1:10:34 Project Status, CNCF, and Community

1:10:37 is in beta, so it's still not final. We still have some work to do to get it to a place where we're comfortable calling it, production. But I I think we know that there are you you know, we have people using it for production purposes. I think the the main thing that we wanna make sure we have right is, you know, the API patterns that are solid that we can cover the core Kubernetes API with these high level abstractions, make sure that we that supporting multiple versions of Kubernetes is solid. It's a very important piece in

1:11:14 the Kubernetes world. But my point is that it's a great time to get involved and influence and collaborate with us and help us, build this. It it was accepted to CNCF as a sandbox project recently, so we're also very excited about that. Oh, wow. I was I must have completely missed that. Awesome. That's really, really cool. So it's the CNCF sandbox project. It works across multiple languages and runtimes. It's m beta. Contributions are welcome. Get involved. Hopefully, help shape the future of Kubernetes deployment. Let's leave it at that. Thank you, Pleasure for you to join me today. Really

1:11:48 Conclusion and Farewell

1:11:53 cool technology. Looking forward to playing with it. And I will let you know how I get on with my cluster API hack Yeah. Over the next forty hours. Yeah. Please. I'd be very curious. Alright. Thank you very much. I'll speak to you Thank you for having me. Bye.