1:42 Introduction and Guest Introductions

1:42 Hello, and welcome back to the Rawkode Academy. Today is an episode of Rawkode Live where we're taking a look at a tool to simplify your Kubernetes experience. That tool is called kpt. Now, of course, I am not smart enough to get us through learning all these new tools. We're gonna reach out to people with all of the knowledge, and I have the pleasure today of being joined, ta da, by Brian and Justin, both engineers at Google who work and drive the kpt project forward. Hello. How is it going? Hello. Alright. So thank you both for joining me

2:19 today. And for anyone that's not, familiar with you, doesn't follow you on Twitter or LinkedIn or anything like that, can you both just say hello and tell us a little bit about yourselves? And, we'll just start with you in the middle there, Justin. Hi. I'm Justin Santa Barbara. I am a software engineer at, Google. I have been working on the Kubernetes project more or less since the beginning, not quite as long as Brian, but, for, like, since at least before one point o. And, now work at Google on a team trying to help users, make more and better use of Kubernetes.

2:55 And part of that is the project we're gonna be looking at today. And the team I work on is also responsible for customize and config sync and config connector and config controller, so a bunch of those sort of tools around Kubernetes and expanding it to to new areas. Alright. Thank you. Hi. I'm Brian Grant. I was part of the original team that created Kubernetes at Google. I was the API design lead and lead architect. Been working on configuration for Kubernetes for a long time. Keep control apply, customize our tools I created and also kept as

3:16 Brian Grant

3:36 kind of the latest iteration on that. A little bit of a twist on customized approach. Alright. Thank you both for sharing. Before we talk about what kpt is then, maybe we can just because you've both already mentioned a couple of other Kubernetes tools. Like, we're definitely in the Kubernetes ecosystem spoiled for choice, and I don't know if that's a good thing or a bad thing. But there are a lot of tools to help us deploy to Kubernetes. Why do you think that is? Why do we Spreadsheet of more than a hundred tools. Yeah. And configuration

3:48 Why So Many Kubernetes Configuration Tools?

4:15 is is a hard problem. It's a user interface surface. So, you know, it really dominates how people experience using Kubernetes. And therefore, a lot of preferences become involved in how configuration is actually authored and modified. You know? So people may start simple with just plain YAML. And at some point when that becomes too hard to maintain, they will switch to a different tool. Some people will build their own tool. You know, you could just use m subs or sed, for example, to replace some parts of the configuration. That's pretty easy. This is one reason why

5:03 there are so many tools is because with the way the Kubernetes API is designed to be natively declarative, all you need to do is create a way to basically render the resource definitions for Kubernetes, and you can do that any way you want. And then you can just apply them, and you're off to the races. Right? So it's not nearly as hard to build a tool as it is, you know, for cloud configuration, for instance, where, a lot more, orchestration and API calls and trans transformation and those kinds of things are are necessary. For the most part,

5:46 just rendering the configuration, applying it, and let the controllers figure it out just works, which is opens up a lot of different possibilities for how that configuration is actually generated. Yeah. It feels like a lot of the the tooling that we have in this in this space is they're they're all different versions of of of templating tools because we have to be able to build up a lot of YAML when working with Kubernetes. And I think yeah. What a hundred, I didn't quite think it was as high as that, but I'm not that surprised that there's that many tools. It

6:23 just seems to be that, you know, every week, every other week on, you know, hacker news or something like that, there's always this new open source project that's gonna change the way that we deploy to Kubernetes. It's gonna simplify something, which I it's already kinda simple, you know, it's still templating. But for some reason, we're deploying more and more things to Kubernetes. Things are getting harder. So I'm really curious to see and hoping that when we take a look at kpt, we can see something that's a bit different because from my naive perspective here and what

6:44 How kpt is Different (Transformation-Based Approach)

6:52 I've seen on the documentation and what you talked about on Twitter and what I've seen on the GitHub is that kpt is different to these other tools that we have, but at least we've seen in this ecosystem. So maybe now we could talk about what kpt is and why it's different from these other tools. Yeah. I can talk. So the other tools I consider, what I call generators. They generate configuration like you said. Right? So templates is one category or configuration languages like HCL or Q or DAL or, you know, JSON or something like that,

7:11 Generators

7:26 or general purpose languages like Hulumi or CDK. But, you know, in all of those cases, you basically write the entire configuration in code or code like format or template format and generate the entire thing. Now customize took a different approach. It took a transformation based approach where it took some configuration as inputs and transformed it in various ways through built in transformers, like to add labels or to add annotations or to patch the the resources, the so called overlay approach. Now since then, a number of tools have added support for overrides because overrides are effectively,

8:08 you know, one of the most common patterns that people need to do on top of a a base configuration or off the shelf configuration. And that way, you don't have to template the entire thing for every possible thing someone might want to actually change. Instead, you can just override it, so called last mile configuration. So other tools support that now too, but, typically, they do generation first and then transformation or override in some way. So kpt's approach is different in that it completely decouples how the configuration is authored from the transformations. So since Kubernetes is natively declarative,

8:49 we're leveraging that by saying, look. You can generate the configuration however you want. You can write it by hand using your favorite editor or IDE, or you can generate it with a tool, or you can generate it with the UI. It doesn't it shouldn't actually matter. And then we can take that and transform it in various ways, not just on the fly when we're deploying it, but in advance. So I think a lot of the toil and and manual effort around configuration management is overlooked. We're kind of desensitized to it. We expect to have to

9:24 check out files from GET, edit them, commit, tag, push, do a code review, etcetera, before we can deploy anything. And GitOps makes that last deploy step more reliable and and easier, but it's really just that last step that it's automating. And all that process before that point, it's still a lot of work. And with customize, you know, customize can simplify the base configurations, but the rest of the process is still basically the same. It's not any less work to, you know, check out the files from gits, edit them, commits, push tag review, render, etcetera. So

10:11 what we're doing with kpt is extending the set of automation that we can apply to that whole space to really cover the full life cycle of the configuration. And that what we're doing is we're extracting the configuration from storage, transforming it, and writing it back. And I think the best way to really understand this is to actually go through the process and show it, is what we found. So so I'm actually looking forward to do that to see what you think about it because it's, in some in some ways, very familiar to things people are used to

10:30 The Value of a Hands-on Demonstration

10:54 and in other ways, radically different. So different people have different impressions about what's actually going on and what the tool can do and how it can change how we manage configuration. Alright. Yeah. I I'll start on go. Can I, like, I also we like, we really wanna hear what you think of it because, I mean, I think you said something very interesting, which is, you said, like, there comes a point where you like, where the complexity of YAML editing gets becomes too much, and you have to switch to generation or templating or whatever it might be? And I

11:31 think what we're saying here is we are producing something that lets you take an alternate path. So we can avoid all those, like, hundreds of different templating solutions. Here's an alternate path. Hopefully, you don't hit that decision point where you're like, oh, I have to, like, abandon pure YAML. Let's let's make the Kubernetes objects centric to this and give you what is going to be a delightful experience, and your feedback as to how delightful it is right now is gonna be very interesting. But, hopefully, you'll you'll see what we're what we're trying to do even if it's even

12:00 if it could be more delightful in the future. Alright. Awesome. And we're we're gonna get to the hands on component in just a moment, but I I wanna I always like to try and take what people have told me and see if I can spell it back in a way that still could have makes sense, and we kinda covered a lot there. And I it's complete transparency. I had never used kpt before. I don't know what we're gonna see today. So I'm I have we're coming into this with open minds and looking to be excited. But

12:08 Understanding kpt's Role (Not Replacing Authoring)

12:26 what you said was, as you use whatever tools you want to write your Kubernetes Java, like, kept is not trying to hook in at that point or replace that point. That's correct. Right? It is. We we are gonna go through a process where kpt is providing a tool to author the YAML. Alright. Okay. It doesn't have to be it doesn't have to be the only way. The point of the what we're gonna show with in through the backstage UI plug in is one possible way that you can author not just configuration, but actually configuration blueprints

13:05 because that's a capability that's not really possible with any of these hundred other tools. Okay. You also said that kpt will pull from storage, do transformations, write back. I'm curious. Does kpt apply to our cluster or is it writing back to storage? And is that storage could that be get or are we talking about OCIR effects or something else there? Like, maybe elaborate on that. So both both actually. So what we have in the tutorial right now, rights to git. We're also have OCI storage underway being implemented. Kept is multiple components. So one of those components is a GitOps

13:13 kpt Storage Options (Git, OCI) and Deployment

13:50 engine, a GitOps controller Okay. That can deploy for you, but you can use RRBCD, Flex, whatever your favorite way of deploying to Kubernetes is. Okay. And the last question before we dive into the thing. You mentioned Backstage, which I think is the UI component. The homepage that we're gonna take a look at let's take a look at. Like, the first paragraph, it talks about WYSIWYG. So is this something that you think is the way we should be offering manifest? Do you think, like, we should be making this simpler and providing UIs and abstractions to make this easier, or is that just,

14:03 UI and Backstage Integration Philosophy

14:25 like, a fun experiment? Like, what are your thoughts around that? I mean, it is a proof of concept, but I actually do think UI is a way to simplify configuring Kubernetes for a much broader audience of folks. It doesn't just have to be, you know, people who do hard code code hardcore code development necessarily. The you know, I I heard that the GitOpsCon North America last year, you know, even folks using Argo CD who are pretty familiar with it were say saying, look, we would really like to have a UI on I mean, Argo CD has

15:06 a UI, but really for deployment, if you configure an application, through Argo CD, it doesn't write that back to Git. It just, you know, is a lot resource in your cluster. Right? So how do you actually take that experience and enable writing that back to get? The most automation tools, UIs, command line tools, etcetera, they operate against APIs. Right? That's how the that's how the tools work. And there's a long history of, kind of a rich ecosystem of different kinds of tools that can operate against APIs. When we say, no. You can't actually call those APIs. You have to write

15:54 code, templates, text files, check them in to get go through all these manual process to then finally deploy them. What we've walled off those APIs from automation of all different kinds. And, you know, that's considered if you have, say, a security remediation function that says, you know, you can't have any pods that run as privileged, for example. You can do that on the fly using an image controller in Kubernetes to make that change. But what if you don't want any of your con configuration your applications in the source of truth to be configured to use privileged pods? How do

16:36 you check that? Like, what if you do have a home chart, say, that tries to deploy an application that, you know, has privilege or something like that? How do you actually go find that and fix that? That's actually really challenging. So what we're what kpt can do is it can actually make the configuration modifiable and readable again through APIs. You know, it basically can provide a control plane and a data plane for manipulating configuration. So that you know, in terms of the UI, the UX there are lots of UX techniques for mitigating domain complexity and simplifying things.

17:25 And we're just, you know, at the early stages right now and definitely can be made more delightful in the future, as Justin said. But I think we've only really just scratched the surface of what we can do with that kind of an approach where we can simplify but not abstract. Okay. Alright. Well, I am ready to be deleted. And the reason I brought up the UI there is, you know, it's really easy for developers to say, oh, I just spend all my entire life in the terminal, and I just type, you know, white text on a black background or green

18:00 text on a black background. But I think there's been a shift lately. And you mentioned the Argo CD UI and Flux is building the UI too. There's that when we're working with these complicated systems, the UI is actually a really strong value add because it's nice be able to step away from the YAML for just even a minute. But I I love that also we're seeing, you know, lens and all these other I can't remember the name of other GUIs. I feel really bad. They're all awesome. But we're seeing a lot of GUIs pop up for Kubernetes as well

18:28 where you don't even need to run control commands anymore. Like, you just get this wonderful interface that says here's all the pods, here's the ones that are failing, here's all the logs. Like, yeah, that simplification that the UI can bring, I think, is a really exciting thing. So I'm I'm Yeah. A a UI can provide discovery for people who are new. You know, it can take concerns away from you. Like, you don't have to think about how to format the YAML, how how many spaces you need to indent certain fields, things like that. It can help you navigate across related

19:01 resources or auto completes when filling things out. It can give you step by step guidance and walk you through the process. So there are really a lot of ways that a UI can help. And, you know, just because the tool is used by developers doesn't mean that, you know, there aren't cases where people could use that help. Like, if you're using a configuration generation tool, whether it's, you know, CDKed S or Helm or whatnot. You know, you can edit a few parameters maybe in the ideal case and run the tool to generate the configuration. That part is

19:41 often straightforward. But how do you actually create the template in the first place? That is still all manual. It's still all done from scratch, and you have the problems not just with, you know, how to indent the YAML, but how to actually cause the YAML to get generated in the right way such that it will be valid and so on. So yeah. So, anyway, I'm hoping that the experience will be a little bit of a a shift in in how we can think about, you know, what's possible in this space. Alright. I think on that note, we are

20:23 Getting Started: Installation Overview

20:23 ready to jump straight into this and start playing then. Yeah. We should start installing stuff. Otherwise, we'll run out of time. Well, we don't want that. Alright. Let's get my being shared. So we do have the homepage here. If anyone wants to check it out, it's kpt.dev. Yep. Cool. Just make sure I didn't get that wrong. I have a Kubernetes cluster. I haven't prepared anything upfront today except for just filling up a cluster that we can play around with. And if we come back to here and skip over the video for now, we get to the installation instructions instructions as well as

20:54 a book, an entire book, which is awesome. It's always I don't know. I I play with a lot of very new open source projects and the documentation can sometimes be lacking. So I love it when I find a project and it's already started to put on that path or purchase it more longer form consumable content. I really appreciate that. So let's get the CLI installed. It says here on install, we've got the CLI, the package orchestrator, config sync, and the the UI. Are we gonna install all of these today? Yeah. Okay. Cool. So let me just click that.

21:18 Installing the kpt CLI

21:37 Get the executable and we'll move it to somewhere handy so I don't need to type too much. Permissions. The last time I did this, my sudo crashed, and I ended up typing my password on the terminal. That was fun. Okay. That's good enough. And no version of like, but we do have we do have kept. Just say kept version, I think. There we go. Yeah. There you go. Alright. So let's jump back. I don't need to see if there's anything else. Do we need all complete? Is that just Nah. Nah. Alright. So we're gonna install the park package orchestrator,

22:23 Installing Porch (The Package Orchestrator)

22:26 which is called Porch. Let's see. I need to deploy something to Kubernetes for this. Is that what it's saying? Yeah. You do. Go ahead, Brian. Oh, no. Go ahead. You you were just ran through this this morning to make sure it works. So Yes. It's a it's a it's a Port is actually a both CRDs and, an aggregate API server. So it's sort of technically very interesting, and it will be very interesting to see. I have not tried it on Civo or Kivo, so it will be a a scary moment in a second. But yes.

23:10 Alright. I just need to download this. That should be alright. Forgetting her to computer. Oh, it didn't download. Right. I do I probably need to I'm gonna just make sure this path works because that's what my command says. And of course I missed the layer. Alright. Cool. I never thought downloading a file would be my downfall today. We'll get there. GitHub does not make it the easiest, at least when I release this. It's could be improved. I should try some of the other ways of distribution. Alright. Well, we have a bunch of Kubernetes YAML. We're just gonna apply that all to the

24:19 cluster, and we're gonna wait until our porch server is available. Maybe while we wait for that, can someone tell me what parch is? What what part of the kpt does this provide? What does it do? What's its responsibility? Porch is is short for a package orchestrator or package orchestration. And the idea is that it basically puts the kept functionality onto a server so that you can embed what would otherwise be CLI functionality into other components. So, for example, when you wanna build a UI, it can be hard to have a CLI as a back end for a web

24:26 Understanding What Porch Does

24:57 server. And so porch is that, back end, but the intent is that it is, sort of the same functionality as we're building in the command line kept, and you can choose to use the command line or the server as appropriate. So probably, you know, a lot of people will get started using the command line. And, when they want teams or collaboration or things like that, they will likely start using Torch as well. Alright. Yeah. I mean, again, I think people are desensitized to how much work it is to create a package from scratch. Just as one example thing that porch can

25:40 do, you can create a package from scratch, you can add resources to it, you can modify packages and create new revisions of them all through the API. Okay. Have I broken something there? Unexpected r kptrl apply. Have I forgotten how to kptrl? Yeah. Dash f is not glob friendly in Kubernetes in KubeCon. Oh, but Michelle can expand that for me. Oh, no. And this is why we can turn them into a No. I'm just being I'm being really silly. Really, really silly. Just do the directory. Yeah. It's been a while. Skill holidays. Bridge ride. That's driving me crazy.

26:32 So That kube control issue is probably still open. And it because it's probably a four digit issue. I suppose you don't know the number, Brian. You normally know all the numbers. Yeah. I gave up on that one. So Alright. Well, we've deployed porch. We've deployed config sync, which I assume is the the GetUp operator sales thing. And the last thing we're going to do now is deploy the UI. So it wants me to create a namespace, which I'm happy to do. The the original the number for the original kptrol issue is 17 o two. I'm pretty sure. Yeah.

26:57 Deploy the Ui

27:11 So Alright. I guess you two have been working just while that's deployed, working on Kubernetes long enough. Who which one do you want to take responsibility for it being kubectl get deployments and not kubectl deployments get? Like, was there was there a bit of a fight over that at the time, or are you or was that just an easy decision? It was pretty easy. Mean, did start with we did start with the other approach because the g cloud command line tool uses that pattern, for example. When when we were you know, initially, we had a tool called Cloud Config, and then

27:21 Sidebar: kubectl Command Order Discussion

27:52 that was changed to KubeConfig. And then when we're hitting, you know, problems with the design of that initial tool and redoing it, actually, Sam Goads from Box at the time stepped in to help us develop kube control. And, you know, we compared the two different approaches. And one big advantage of kubectl get pods or actually, you know, kubectl apply for for instance is, you can actually, apply these commands to multiple different resources and multiple different resource types more easily if the verb is first. Right? So, like, kubectl apply that we just did there, you know, operates on arbitrary resource types, and

28:41 that's something that we wanted to enable is these bulk operations. So the verb first felt more natural and reinforced the common patterns across different resource types. One reason for the other approach is so people can use more easily create unique commands for each different type of entity, and we actually didn't want that. We wanted the system to be uniform across all different resources. And now we, you know, have that even more generally with custom resource definitions. But even with the initial set of we just had four types originally. Even with those original four types, you know,

29:25 we pretty much wanted the operations to work the same. Nice. Alright. Well, I think we have everything deployed. So I'm just gonna go back here. Maybe I guess the book because that's the tutorials we're running through or is there another part of the guide? Go to the the guides. Yeah. So is there anything sorry. Please, on your call. Oh, I was just gonna say the the guide that I was gonna recommend was the namespace provisioning UI guide. Alright. Before we kick start that then, I'm just curious. Like, we have deployed a whole bunch of stuff to our

30:00 Switching to the Namespace Provisioning Guide

30:08 cluster. Is there something there's something already there we can look at, we can play with, like, play with? What's what's their what's their There's not a lot interesting there until you register some repos and start developing some packages or importing some packages. Okay. Well, I mean, one of the things we can do is we can we can run kubectl API. I'm getting an echo. Getting an echo. Yeah. I do not. I do not. Right? No. Anyway, kptl space a p I dash resources, which lists all the resources registered on any Kubernetes API server. There should be some with ports. So

30:53 if we pipe that to grep porch, I think that's in the guide for installation as well. But that shows you some of the resources that we've we've registered by setting this up. Alright. Alright. Yeah. I'm getting an echo. I'm getting an echo from Brian. I'm just gonna mute you for a moment. I'm not sure what's going on. Alright. We have repositories, resource script functions, package revisions, and package revision resources. Okay. Let's take a look at this UI. So this guide. Sorry. So in this guide, we will be using config as data UI to register a blueprint

31:36 and deployment repositories, create a blueprint from scratch, and create deployable instance of a kpt package and to the deploy the package to Kubernetes cluster. I mean, is it fair to say we're going to be using kpt to deploy a namespace? Is is is that the the example that we're running through? Yes. We're gonna do it using the UI and porch, but we are you know, this is the kpt technology. And and together, we call, I think, the technology configures data, and kpt is the CLI tool, which is the server version. So that's why we have all these different words flying around.

32:11 Accessing the UI (Port Forwarding)

32:11 There is one step, by the way, that we probably need to do, which is to get that backstage base URL at the bottom of the ports UI installation guide. It should tell you how to do a kubectl port forward because I assume you don't wanna put it on the public Internet right now. So, I think we did we do this? I can't remember. But, I mean, we we can work it out. Right? I mean, I'm assuming this is like this. And we can port forward to the service, and it's just gonna be The backstage namespace.

32:48 Let's see. Backstage 7007. Easy. There we go. Nice. I was just pulling up the guys to try to cheat in case it didn't work, but, yes, you got it right. Well, see, I like it when we can take existing knowledge and it just works. But I'm glad that there was no other steps required to get to the UI. That's Yeah. The command for that is in the installation guide, which we kind of skipped over quickly. Yeah. I can be quite bad for that. Feel free just to tell me to stop. Yeah. There it is. There we go. Alright.

33:30 Let's go back to our namespace guide. So we have access to the UI. That's our prerequisite. We can move on from here. So the first thing we need to do is register a blueprint. What Register a repo. So you we'll we're gonna need two GitHub repos, one for blueprints and one for deployments. And you'll need a token with repo scope. Okay. So we need one for blueprints public. What was the other one you said? Sorry. One for deployments. So the WYSIWYG aspect is that we fully render the configuration that we're gonna deploy with GitOps, back into Git.

33:39 Register a Blueprint

34:21 Okay. Cool. And that enables us to just edit it. We don't always have to regenerate it. We can just edit it once it's there. Alright. Okay. So can we what what is the blueprint in this context before we go any further? What do we mean by that? So the blueprints, you can think of it as kind of like a template except that it doesn't have any markup or code in it. It's just configuration data. That's the configuration as data aspect. It's effectively kind of a prototype or a model of the configuration that you would want to

34:31 Understanding the Blueprint Concept

34:59 transform, customize, and then deploy. So it's it's kind of like a customized base configuration in that respect. Okay. It's you you can also just think of it as an example, but it's just literal valid Kubernetes YAML. Okay. So to register our repository, do we do this from the UI? Should be able to do it from the UI. Alright. Let's bring back that for forward. Go to the config data. Yeah. So Backstage is a is a sort of open source project, I think, initially started by Spotify, and there's a bunch of has a bunch of functionality, and it supports

35:21 Exploring the Config as Data UI

35:48 plug ins and and config config as data is a plug in into it. Oh, you know what? I'm aware of Backstage, and I didn't tie the dots when we called it Backstage earlier. But okay. So you're this is a plug in for the Spotify Backstage. Okay. Yeah. So if you have Backstage already, you can add this plugin to your own Backstage instance. This is an image that we created, you know, just to make it easier to try out. Okay. And do I have to log in with Google? Is that Yeah. This is a log in, and it's

36:16 UI Login Issue & Switching to CLI Demo

36:19 gonna act as you on the cluster. Maybe I'll pick a different Google account. Do I need to set something up? Sorry. Can you hear what it says? Can you It says I need to get full screen. Or is the org internal client restricted to users within the organization? It's the it seems like the whatever OAuth application this is used in is restricted to Restricted to Google. Yeah. Oh, well, that's a bummer. Okay. We can create a new OAuth client ID because I'm guessing that the so we ship with one that's it's a bit of a pain to to

37:04 Create a New Oauth Client Id

37:16 go through this process, but, if you wanna create a you know, if you wanna log in with Google, you have to go through and create a client ID. And we have, bundled one in, but I guess we have accidentally restricted it to our organization, I. E, Google, which is a bit of a mess up. And I apologize for create me a Google account. Right? I would love Rawkode@Google.com. I mean, that'd I'll wait. Okay. So we could either set up our own OAuth application or is there an alternative? I'm also worried about whether the authentication is

37:57 gonna work to the if we're not using GKE, is it going to accept the ID the credentials? Brian, what do you think? Clearly, nobody no non Googler is driving. I think that is fine. We can try the can try the CLI form of this, which will be less good. And maybe we could share the UI walkthrough, and we can do it that way. I don't know if that would work. If you want to share your screen, I'm happy to do that if you wanna run through it. But if there's a way that we can proceed

38:40 from the CLI here, we should definitely do that too. I'll I'll let you make the judgment call. You know what's going Why don't we Brian, what do think? Should we should we do the should we go through the CLI instructions, which I don't think rely on or they should just work. There's there's a guide. Let's do the CLI. Okay. Then we can do it. If you wanna share your screen, we can do the UI demo afterwards. Exactly. Okay. So we have this CLI. What? I'll do without that. I can type help now. Okay. But what we were trying to do is

39:18 Register a Blueprint Repository

39:19 register a blueprint repository. So how do we what's the starting point here? This is gonna be the alpha commands. Yeah. And there is there is a guide which we can go through if that's easier. I don't know. Oh, yes. The the name switch version is CLI. Okay. Cool. So I've already logged in there. Oh, I did that too. I love the g h command line. It just simplifies my life now. That's great. Although, I I guess you had to specify public or private, so I'm guessing we I'm guessing that's either a new or an old version of the g h command line

39:55 that now requires it. I think it gets the default to public, and that's just something that started recently. Okay. So we need to have my user as Rawkode and then oh, I don't call them blueprint, so let's fix that. I call it kpt dash blueprint and deploy a kpt deployment. And then we're gonna clone both. Okay. Yeah. So this is a a slightly different flow from what we were planning on doing, but it will give you a better idea of what's going on under the covers. This is the CLI experience. So this is the role experience as it were.

40:50 And then when, I guess, I screen share the the UI, we can see better, like, how we can combine that into a or build that up into a nicer user experience that is sort of easier to just click through and, like, easier to use. Cool. Then we have this cube gen script, which is taking some parameter. Yeah. So this this is just fixing some words in cube control create, basically. We can like I said, you can create the or write the resources however you want. We are just leveraging kubectl create to generate them in this tutorial.

41:34 What Resources Do We Need To Create

41:34 So what resources do we need to create? Well, like, you know, namespace and RBAC role binding service account, things like that. Okay. I do not have They're pretty pretty straightforward of these resources. So we'll we'll go with the kpten. They have snippets for a lot of things, but it looks like I have the RBAC stuff. So we'll make this executable. We'll stick it in my path. That would test that again. You know, I read a story about hackers who can listen to your key tape and when you have a mechanical keyboard, don't work at what letters you're pressing based on that.

42:19 Hello. The noise yeah. I thought my password is just one two three four. It's just much safer. Okay? That way everyone knows it. Well, that's a good method. Alright. Let's create a directory. So this is us creating our package there. So this is our base namespace package. And we're gonna use kpt package in it, and it's gonna write us files. I'm gonna jump in there and pop that open. Maybe we'll change that font size too. Okay for you? Wanna go a bigger? Yep. Yep. Okay. That's good. Alright. Okay. Where's my thing? Okay. So we have a kept file. We have a read

42:39 Initializing a kpt Package (`kpt package init`)

43:07 me, and we have a package context. We have a tree command. We'll run that too. Oh, it's because I ran into the directory. Yeah. Cool. See, I say k for just not following the gates directly. I'm sure every time I change something, I'm like, no. Don't do that. But okay. So we have a a nice tree command. So let's see. Yeah. So the kept file is contains the metadata for the package. If you notice, it's in the same format as Kubernetes resources. I call that the Kubernetes resource model format. You know, so right now, it just has

43:11 Exploring Initial Package Files (Kptfile, package-context)

43:47 the minimal amount of metadata. Yeah. I'm seeing so many tools adopt this format now that don't even touch Kubernetes or even deploy to Kubernetes. It seems to just have become a little bit of a a standard. Well, we used it for things like kube config and the scheduler config and some other on disk config formats from the beginning. It makes the tooling a little bit more homogenous and and easier to build. Yep. And what's this package context dot YAML? So I don't know that we'll keep this long term, but what this is doing is it's actually

44:27 just copying information about the package into a config map that can be used as an input to functions, which we can talk about more when we're actually getting to using the functions. But the functions are what can generate, transform, and validate the Kubernetes resources that are in the package. K. And we have some Ruby stuff, but I think we will stick to the guide. So our next thing to do is we're gonna generate the names of these resources in our new scripts. Yeah. So this is basically just doing a kpt control create and splatting out the YAML

44:53 Generate the Namespace Resource

45:02 instead of deploying it to the cluster. And this is just an example of how you can use automation tools, command line tools, UIs, whatever, to generate the YAML. You don't need to write it by hand. And because you don't need to mark it up with, you know, templates or code or anything, the tools can also modify it, edit it after. And that's really kind of the kept one of the kept superpowers, I would say, is, you know, keeping the configuration in a data format makes it possible to manipulate it as if it were, you know, a live resource, you know, in

45:40 the API server, for example. So if I really wanted to, I could use Pulumi to render out Kubernetes YAML and break that in. You you totally could. In fact, you could probably wrap Pulumi in a karen function and and both of you can. Alright. Well, I think we're gonna save for that today, but that was something for me to experiment with over the next couple of days. That was pretty cool. And one thing I was actually wondering about is whether we could use Pulumi in a similar way with the new YAML support to generate the YAML with the UI or

46:13 however we want and just deploy it with Pulumi. We would need to be able to store the YAML and retrieve the YAML automatically. I don't know if Pulumi can help with that or we'd need to build a new thing for that. Yeah. Something for us to to throw in some ideas for later. There isn't a way to get the ABO back, but maybe in time. So we have our namespace. So this kept package tree, this is this isn't just like an alias, is it? Is it a bit more sophisticated, I guess? It extracts information from the files.

46:38 Using `kpt package tree`

46:52 Okay. So we get, like, the description of what the thing is? Yeah. It gets the kind and the name. Okay. That's a simple example c l s. Of how you can with with the configuration again just being represented as YAML or data format, it can extract information from it. We just started with this because it seemed useful, but you could add other information here or build other kinds of analyses. Alright. So next. Oh, because some scary stuff coming. So we're gonna run kept functions. Yeah. I'm not entirely sure what this is doing. Should I just run it or do

47:24 Introducing kpt Functions and the Pipeline

47:36 you wanna give me a better context? So instead of templates or some other kind of generator, the kpt model is like I said earlier, it's sort of a twist on the customized approach. It takes the the resources from the files, serializes them into resource list, feeds that as inputs to a sequence of functions that can operate on the list, and then writes the files back to the disk. So those functions can generate resources. They can transform or modify resources. They can validate resources. So it's we're using the YAML representation as kind of a intermediate representation

48:35 for operating on it. When we do this through Porch, when we can show show the UI, what it's doing is extracting that actually out of git, transforming it, and putting it back into git. So actually one it's not in the guide, one thing you can do here is just kpt function source, function abbreviated source all spelled out. Yeah. So this is the format that it's feeding to the functions. And, you know, it is a list of the resources including the kpt file that are in the package with some additional metadata so that it can write them back into the same place, like,

49:22 you know, keeping track of the file path names, for example. Okay. So but I just so I'm I make sure I understand this. Right? So we're running a kept function, and we're gonna evaluate this as a mutate or that makes sense. I'm gonna scuff over keywords. I'm not sure right now. But the image is really you're setting the function. Right? So the all these functions are container images that have that they can put and give us output, and then we provide the config. So this is called set namespace. So I'm assuming if I run this on, like, a

49:51 deployment, it would add the namespace from our kept context. Is that close? I see a little bit of a nod. It's actually take it's taking the name of the namespace from that config map. So if you scroll to the right, that package context dot yaml is that config map you were asking about earlier Mhmm. That had a field that said name example right there is yeah. So it's taking that value and using that as the name of the namespace. So what we're doing right now is we're creating a blueprint. So a blueprint is just a package

50:29 that is intended to be used as a base, not to be deployed directly. The reason we're running this function is as a test of the function effectively. Because when we like, customize generates variance from bases. When we create the deployment, we will do that similarly using this function. So this the purpose of this command is just to test that the function does what we expect. Okay. What's the dash dash keywords namespace? I'm not sure how this applies in this context. I don't think we actually need that. Alright. Cool. Yeah. I I think it's I think

51:09 it's for autocomplete. Oh, it says that up right above. If you were using autocomplete, it could help you discover the image if you pass that. Ah, alright. Okay. So this kinda narrows down the scoping. Yeah. The set namespace is in our function catalog, and it has metadata attached. We don't have that many functions right now, so you can browse them all. If in the UI, we do string matching. So if you start typing name, this function will come up. Through the CLI, yeah, we rely on auto completion and need a different way to provide the hint.

51:46 Okay. Got it. So I So yeah. Let's pull in a container image. I'll assume they're pretty small. No values have changed. Are we m one Mac issue, or can we just ignore that? We are definitely having an m one Mac issue. I'm not entirely sure why it's a warning. Let's see if it actually did it. Whether that's just a warning or that's an error error. I mean, it I'm a little confused. Ran. Did it? It ran. Yeah. It it says all these pieces are already the sample. Yeah. So Alright. Moving on. So the next function

52:32 is So this is just repeating the same thing, but what it's gonna do is append this function to the kept file. So whenever people wanna create a variant, we can set this up to run the function automatically. Okay. And now we have our mutators listed. Okay. Things are starting to click my head now. I'm starting to Yeah. So I'll just point out that that automatically modified the kpt file. So that's a general pattern in kpt as it functions, tools, interfaces can actually just modify all the resources including the kpt file in order to automate things and make it simpler.

52:51 Adding Functions to the Kptfile

53:14 Okay. Got it. So that's now showing us that, and then we can do a function render. So what the function render does is it runs the functions that are in the kpt file. So we just added that function to the kpt file. So this is basically just testing that it worked. Okay. And the general pattern that we're using, you can think of those functions in one way kind of like Kubernetes and Mesh control, but applied to your package. So after we make any change, we probably just wanna rerun those functions. For example, if we added a

53:31 Rendering the Package with Functions (`kpt function render`)

53:52 resource to the package, we would wanna set the namespace. So we would just rerun kpt function render. Okay. So kpt function render runs everything that's at the bottom of the kpt file as the pipeline? Yeah. Exactly. Okay. And we're modifying the resources in place. So this is one big difference with kpt compared to kustomize is kustomize will take the base configuration, apply some transformations and patches, and splat out the configuration to somewhere else, like the standard out, for example, so you can pipe it to kptrl apply or apply it with a GitOps tool. Here, we are actually modifying the resources in

54:29 place. And what that enables is we can decouple the the generation and the transformation in time. So, you know, we can we just generated a namespace, and we transformed the kpt file by adding the set namespace function to it. We don't have to do that every time we wanna use this blueprint in the future. It's gonna be there. It's gonna be stored there in GETs, and we can do additional transformations later. We don't have to, like, write a thousand step pipeline to do all the changes that we've ever done in the history of making changes.

55:07 Okay. It's taking advantage of the fact that the contents are declarative. Just saying, like, it doesn't matter how you got to this point. This is the desired state of of what you want it to be. Yeah. Yeah. I definitely I get that. That makes sense to me. So it looks like we got another resource to Jen next. So that's the Yeah. So this one's a little bit more interesting than namespace. Namespace is pretty short. It's not that hard to write from scratch. Row binding is a little bit longer. Yep. There we go. Oh, we are giving away,

55:30 Adding Apply Replacements Function

55:53 an app admin role to the group here. Okay. We've already catered it. We're going to okay. So this is Yeah. I mean, these are just these are just examples. And what we're trying to do is, essentially, if you look at the email address, I think it was, like, example.admin@bigco.com. And the point is that we would imagine that we're doing a scenario where each group each namespace would be owned by a different group. And so we wanna replace in particular that example bit before the dot admin. And so the idea is, you know, you would you would create a group of administrator. When

56:31 you're creating a namespace, you wanna create a a group of people that are able to administer it, and each one of those gets their own group. But now the problem is if we don't have templating, how are we going to replace that example in the very bottom line there, the example dot admin? Because it's not that it's not a simple value substitution anymore. It's, like, just a bit before the dot. So that's the challenge that we're gonna solve with functions. Yeah. As you started talking, I I realized that some of this is also covered in

56:56 your blurb that I've just been skipping by and scrolling through. Kinda just blah blah blah. It's fine. Copy the command. So thank you for providing that extra context. Yeah. So you could write a function to this specific thing. If it's gonna be common, that may be a better way that would involve less configuration. This is the apply replacements transform from customize packaged in a function that we can use and kept. Okay. And it's it's basically doing a patch where the the it can take the input of the patch from a specified location. Okay. That makes sense.

57:39 Yeah. Okay. Got it. So now we can run this. So this is, yes, gonna add this function to the kpt file. And from that point, whenever we need to run all of these transformations, it's just the kpt function render. Exactly. Okay. I can see the workflow here. I can see how you you kind of you make the change. It gets persisted to the kpt file. And then when someone else checks us out, they're just running the render function. I'm assuming people can reuse these packages and provide their own context. Is that kinda where we're moving

58:01 Recap of CLI Workflow (Modify, Persist, Render)

58:15 forward to here? Yeah. Exactly. Okay. Cool. Yeah. We actually need to check-in this blueprint in order to make it, you know, usable as a deployment. But that that'll be coming up in the tutorial, presumably. Alright. Will we skip the quota that you wanna run through? Sorry. You can skip the quota. K. So cut up a directory, add the directory. I don't think I'm in should I move this to the right location? Was this supposed to be inside my blueprints? Yeah. That'd be good. Yes. Alright. So now if I oh, I don't need to do it.

58:23 Committing the Blueprint Package to Git

59:05 Take that off. So we can do add and just over tagging it to alright. Okay. So the the purpose of the tag is to mark it as a particular version or revision. Alright. And that that enables us to do things like discover that there's a new version and suggest an upgrade, things like that. Yeah. So now our our package is in this blueprints repository that we created. I'm assuming as we move over to this deployment repository, we're gonna consume this package in some way and alright. K. So we're gonna go to kpt deployments. And from here, we're gonna run a kept

59:31 Creating a Deployment Package from the Blueprint

59:50 package get. And I'm pretty sure I still have that environment variable kicking around. Yeah. And that's close it. So I'm assuming yeah. That's our directory. Cool. But does that mean that I can met my blueprints with my deployments? Are those set up as sub modules or something like that? Like, how does that work? You do commit your blueprints. You also, like, I think one of the ideas here is that, yes, you do, commit your deployments as well. Brian can get into the the logic there, but the, what the the theory there, there's a strong theory behind it. Mean, it's essentially, it means

1:00:41 you can really understand what's gonna happen at all times when it actually gets to your cluster. It also means that you can just we you have base configuration from the blueprint. You don't have to modify the blueprint or transform the blueprint with functions with kpt function render. You can also just edit the deployment directly. And that's effectively auto generates a patch on top of the blueprint is one way to think about it, except that you can just edit. You don't have to actually think about how to express the patch. You can just edit. Okay. So

1:01:27 Alright. Let's see what's going on here then. So we took that. Then So just so you do a kept function render. Your It was updated now, our namespace example. So I'm assuming Yeah. I think the the important thing to remember is when you created your blueprint, your base package, your namespace name was example. Here you have, instantiated an instance of that package into a directory called back end. That was the name you gave it. And, the name here is an important concept that, with those functions you copied into or assigned to the name of the namespace, which is

1:01:48 Verifying Changes in the Deployment Package (Namespace, Email)

1:02:11 why the name of the namespace is now back end. If you were to create another one called back end two and hit function render, it would be called back end two. So you can create as many instances you want, and the the functions run and they enforce the invariants that you as the author of that package blueprint defined. So the invariants you've defined are that the namespace should be called the same as the package name and that the group should be the packagename.admin@bigco.com. So if we have a look at the role binding, it should hopefully have back end

1:02:42 dot admin. Doesn't it? Yeah. So this is a simple example illustrating what I call the variant constructor pattern where, you know, a common thing is you just wanna create multiple different variants of the same blueprint. You might want in this case, you know, we're creating multiple namespaces for multiple teams or something, but, you know, you could also have dev and prod environments, things like that. So other inputs may be needed to fully specialize the blueprint for your particular scenario. In this case, no other inputs are needed other than just the back conditioning. We're just leveraging that to generate an identity for each

1:02:48 Deployment Concepts: Variants and Merging

1:03:24 variant. Additional hand editing or automated transformations could also be done to the deployment. But here, they're not really necessary. So this is, like, the simplest possible case where all you have to just do is say what you want the name and the namespace to be and everything is generated automatically for you. You don't have to touch anything. Okay. I'm I'm curious. Are these kept merge comments? How the patches work? Are these important? Or are these Yeah. So if we change the blueprints after do after doing this, after creating the deployment, and we wanted to pick

1:03:49 Discussion on Merging Strategies and Package Updates

1:04:06 up that change in the deployment, then we would do a kept package updates to pull in the changes from the blueprint. And that kept merge comment keeps track of the mapping between the customized deployment and the original blueprint. Okay. So if I update in the kept blueprint and change the email address in big code dot com to extra large code dot com and tag that again, we would be able to pull through and update that even though we've already done some changes? We would. We probably wouldn't want that to necessarily stomp what was in here. So

1:04:51 in different scenarios, might want different merge strategies. That's something we're working on right now. But I the way I think of the blueprint is that it provides defaults. Oh, so, you know, if we didn't actually change from the defaults in the deployment, we probably would wanna pick up the change. On the other hand, if we didn't edit and overwrote it, we probably wouldn't wanna pick it up. Right? Like, that's how customize would work. Looking I look at a bunch of helm charts and when people add new fields or change things, they conditionalize them so that existing

1:05:30 deployments of the chart don't actually pick up those changes. So clearly, a lot of people don't want new behaviors picked up necessarily from a base deployment. So that's something that we're still working out as to what behaviors, you know, people would expect or would want for different scenarios. Cool. But but I but I wouldn't like, the workflow you described is is the workflow that that we enable. Right? You create the instance of the package. You can edit it manually, and you can still take in changes from upstream as that upstream package evolves. So if there's a new version of

1:06:08 MySQL, you can go and get that new package, and and it will merge in. The the undefined or the under defined behavior that we're trying to define better is what happens when you change a field, when you've both changed a field, there's an overlap, a git conflict, or what you know, a conflict in editing, and that's, I think, where we are working through still. But when you make the majority of changes, you can just make your local changes and pull in upstream changes as you as you want or do expect to. Alright. I was about to ask a question there,

1:06:36 Committing the Deployment Package

1:06:39 but I see it's the next heading. So I'm gonna go ahead and just commit and push this. Because I was like, okay. Do we just give control, apply this now, or do we use config sync? I think that's what I had in school. Right? So that's yeah. That's pushed. If I recall, we're gonna use kept live, which is more like a a more advanced version of kubectl apply, but you can also do it using config sync. I think in the UI, we go through it using, like, a GitOps tool and config sync in that case. I think in the CLI demonstration,

1:06:56 Deploying to the Cluster using kpt live (CLI Deployment)

1:07:16 we're directly applying it. It's sort of the easier way to get going and doesn't require config sync. We've already installed config sync, so you could also do it that way. But Alright. Well, it looks like we have some sort of resource script thing created with the namespace for the project, and then we just do a kpt live apply back end. It worked. That's it. Right? One of the yeah. One of the cool things about kpt live apply is it, it checks the I believe it checks the status of this. So you can see, you know, pending and successful.

1:07:51 There's a, so it can do things like tell you if your deployment actually apply actually reached a stable state at the you know, when ready as it were. Like, kubectl, we have to explicitly wait. Alright. So I wanna make sure that I understand this right. Kptlive is different from config sync. These are two different ways of applying the configuration to the cluster. They are. They they share code, they're actually, they're they're similar in in logic. But, yes, kept live is the CLI form. Config Sync is the server form. Regardless, what we're doing is we're reading from files,

1:08:32 fully hydrated, like, ready to apply files and applying them to the cluster. So you could use kpt live. You can use kptly apply. You can use config sync. You can use any GitOps style tool that you want to use or or or are already using Okay. Or already using. So I would suggest that we actually run through the UI if Justin can share that, just so can do that before we run out of time. Yeah. Push the scary button. Let's see. I'm gonna get let's see. Let me move I will apologies if I look to the

1:08:51 Returning to the UI Demo (Guest Screen Share)

1:09:09 side, but otherwise, we'll get the, you know, never ending. I think I am sharing the configuration. Very professional setting up a quick Oh, here we are. It even looks a little bit like me in in silhouette. There we go. Alright. Okay. So this is the configuration as data, UI. I have, logged in, and let me just check that it's yeah. Okay. Good. So my port forward is still working. I was a little worried. I might have timed out. So we've basically gone through the first couple of steps here of of the configuration and, very similar we we've done very similar things

1:09:32 Overview of the Config as Data UI

1:09:50 to what you've done in the CLI. So I have defined my own kept deployment repo and my own kept blueprints repo. They're They're actually linked to my GitHub, not yours. We could try registering yours in a minute, but I don't know how we wanna drive this, whether it's shall I go through I mean, I've gone through this or there's already a blueprint or a couple of blueprints that I've created, but we can create another one from scratch. That's that's what the guide Why don't you browse the base in s blueprint? Okay. Perfect. So this is one that I've

1:10:23 created from scratch following the guide using the using the UI here. And we have a very similar set of files to the files that you created using the CLI. So we have the kpt file, a namespace. We have the config map that was created using init. We have the apply replacements that you also created, which updates the role binding, and you can see that that there. We did we did create the resource quota that we skipped over, and here's, like, a role binding. And, why don't I try I wanted to start creating a new one

1:10:58 Creating a New Blueprint via UI

1:10:58 so we can see some of the UI that that is able to be done here. I'm gonna create it from scratch. We'll call it Justin two. We're adjusting one earlier. So this is the equivalent of kpt package in it. I can create it, And then write the kept file and config map. And if I want to start adding resources, then I can do that. So I think first thing we added was a a namespace and, I don't know, x and s. This is this is the blueprints. Right? So I think you do want example there.

1:11:17 Adding Resources

1:11:32 Okay. And let's see. I mean, we can go through and we can add some more. So let's add a, like, let's add a role binding, and you can see that we get a a a very sophisticated, or a purpose built UI for role bindings. So, like, we call it app admin, and, we had a role reference to a cluster role named, I assume, app admin. And we had a subject binding to a group named, if I recall, example.admin@bigco.com. And so I can show show the YAML view, which is what we did before, and save it and

1:11:44 Add a Role Binding

1:12:23 through the UI I'm editing. Is this a bit small? I apologize. So is this pushing us to get repository or somewhere else at the moment, or is it like, where does the state live? We are working through Porch in this instance. The configuration as data UI is talking to Porch, and it is, in fact, backed by a Git repository. And this particular Git repository is the kpt Blueprints repository, which is backed by github.com/bitmsb/blueprints. What did I do wrong? Oh, I'm not logged into GitHub. Scary. Alright. Let me I think I'm sharing my screen. I don't think that

1:12:26 UI State Management (Backed by Git via Porch)

1:13:07 which is right here. And so, there is somewhere a draft where we're working on it. You can see that we're pushing to it recently. But as we go through, we we are working with the git repository here. K. Porch makes a bit more sense in my head now. I understand what it's actually doing. It's a server side component that's backing this UI that is handling. But right now, we just didn't get but you mentioned earlier that that could be an OCIR effect at some point as well. It it can be OCI, registries as repositories as well. And, yeah, that

1:13:35 OCI Registry Support Recap

1:13:39 that support is ongoing, but, yes, it it works as well today. It's a little easier for some people. It's easier for others, and so we support both. Awesome. Got it. And we're we're defining exactly the same resources that you were defining on the command line, just in a sort of slightly easier to use user interface. It's particularly easier to use when you're, like, instantiating packages. So I don't know if should I just save this and we can continue? Is that I have one I made earlier, or do wanna keep going through, Brian? Well, just pull up the kpt file and

1:14:02 Adding Functions via UI with Assistance

1:14:17 show adding a function, I guess. Oh, perfect. Yeah. Great. So if I wanted to add a mutator, let's add the replacements. So, like, before we added apply replacements, here, we can see all the versions that are available. There's only one. And I'm gonna need to create the apply replacements resource yet. You're right. I will do that. I need to create an apply replacements resource to define the the the configuration. Update role update role finding. Typing under pressure is hard. I have empathy for you for doing this earlier. Thank you for driving it earlier. ConfigMap, the sources. You see you see it's actually

1:15:01 it's listed all the objects in the in the package. And once I pick one, it actually shows me the various paths available with the actual values from the package right now. So it's it's a purpose built UI per component or per kind that enables us to give, like, a really great user experience or at least a better user experience. Yeah. So this shows, you know, just kind of a proof of concept of something you can do when you have the UIs. You know, it provides that it's kind of like auto completion, but it provides, you know,

1:15:34 assistance in picking the right values. Yep. I've gone through this process a bunch of times, and I do have to say it's less error prone than doing it by hand. So Challenge accepted, Brian. So there we go. So I I've I've gone back into the kpt file and done up I've now bound to the apply replacements function to the configuration for it. I can add another mutator, I guess, to Set namespace. Yeah. Let's do that. I think add so namespace, and it will find set namespace. There's the latest version, which I think we knew before. And I think for this one, I

1:16:15 need the config map. So now I can save it. I think that's enough. Right? Yep. We could do a resource quota quickly. Should we do the resource quota thing as we skipped that last time? No? We should just we're almost out of time. Oh, sorry. Okay. I will save the package. I will propose the package, which is the equivalent of doing a pull request. Someone else comes in because I never approve my own pull requests, and approves the package. And then you can see And so one thing we didn't we didn't really show is that hide

1:16:33 Proposing and Approving Blueprint Package via UI (Git Workflow Abstraction)

1:16:53 comparison. You can actually diff with I we're creating a blueprint there, so there's nothing to diff with. But you can actually review this and view the resources without looking at YAML, without dealing with the Git provider. You can do it all in the context of the UI if you want. Nice. And I I I just showed that, like, on GitHub, you've you can see that that package Justin two was just approved mere seconds ago and is now on the main branch. So it's it's there and ready to go. And there are two types of repositories. There are blueprint repositories

1:17:31 Types of Repositories

1:17:34 where, you know, this package now exists in the published state version one. So, you know, it's done all the tagging and all that for you. And there are deployment repositories. And, here, we have the deployment repository that I registered in the configures data UI. I have previously created some some packages, but I can also instantiate instantiate the blueprints just as you did, from here. And we can actually drive it from here. So if I do this, I can say deploy. I wanna go to the deployment. I will call it Rawkode B. Okay. Yep. And so

1:17:56 Creating and Deploying a Deployment Package via UI

1:18:23 we're now creating an instance of that package or that blueprint in the deployment repository. We've called it Rawkode Justin SB. I will it's still under draft form of Rawkode seven. Look look at the, like, role binding, for example. Ah, thank you. What you expect. And so it did create the, rule code just in SP just to sort of kept it on the command line. It it put that in. It changed the namespace, of course, to rule code just in SP, the name of the package. So I can now propose this. I can approve it, and I think it

1:19:01 will actually so I've approved it. So now if I go and look at github at kept deployments, it will now be, what did I do wrong? Do you call it just deployments? Is it kept deployment? Deployments. I just yeah. Just to confuse myself, I did not. Thank you. And so there it is. Again, seventeen seconds ago, I guess it takes me seventeen seconds to get to GitHub. And then if I create sync, it will actually, like, do it straight. It will create the config sync, from here as well. So, you know, this is what you do with kpt, live

1:19:35 apply from the command line. Here, we have a config sync integration. There could be other integrations, but is a config sync integration, and it will go and apply it to the cluster. So that'll take a couple of seconds, and it will shortly appear on the I think on the same cluster it's it's bound to. So there we are. Yeah. So that way in the future, when any change is approved, it will automatically get, synced to the cluster. Alright. Anything else you want to show in the UI before I If we wanna try to break one more

1:20:12 Registering an External Repository via UI (Consuming Third-Party Blueprints)

1:20:12 thing, I was gonna think it might be fun to let me show the registration of of repository. So let's try to register the one that you created earlier, which I think is public. So It is? Yep. But does do read only repos actually work? Well, I was thinking it would be fun to demonstrate how we can even if a third party, like David, created the, the blueprint, I can consume them myself. So oh, well, I can call it the same thing. Alright. Let's try that again. But, yes, see. I didn't see where I could specify a

1:20:25 Read-Only Repos

1:20:51 name. Well, perhaps that's a slight bummer. Okay. We need to be able to specify that oh, there it is. Kpt. There you go. Roll code. Thanks. Thank you. Blueprint. The wonders of an ad hoc demo. Exactly. Now it's a real one. I mess it up. I mess up everything. And so now we have another Blueprint repository registered. So, you know, I'm consuming from an upstream expert that has created a base namespace package for me. And so now I can just go and instantiate this blueprint, myself if I wanted to or deploy this namespace myself if I wanted to.

1:21:30 So I'll go to deployments, Click in. Add a deployment of I think you have your own repo as the registered upstream. Upstream. Yes. Okay. So there might be some tweaking to be done there, but I can, create, in theory, I can create one from your blueprints also, and we'll make that a little bit easier, a little bit smoother. I think the UI is bound to that particular one right now. But, yeah, so here we can, you know, create packages, edit them, push changes, create deployments from those, store those in gits and version them as well.

1:22:05 So we actually I don't know if you can show the revisions on one of the package. You can undo by restoring a previous revision. So that's something that you can't as easily do revisions. The revisions tab. I I don't have I I only have one revision of everything. So I'm just creating a second. That's fine. But, yeah, you can you know, this UI is pretty nascent. It's it's basically a proof of concept, but you can interact with the configuration all through the UI without necessarily touching YAML or touching git or the git provider pull requests,

1:22:34 UI Summary and Potential Benefits

1:22:51 all that. So it actually saves dozens of steps for common operations. So I think it's pretty promising. And, like, especially for people who aren't as familiar with, you know, say, Git push mechanics or, you know, the exact formatting of Kubernetes deployment YAML, things like that. Yeah. Definitely. Alright. I'm gonna sorry. Anything else there? I was just gonna say, like, we were able to, like, create that that instance of the of the package and deploy it without, you know, touching the command line. So it is certainly easier if you if I hadn't had if I hadn't showed

1:23:33 you editing the package or creating the package first, that would have been a very simple experience of just adding the deployment. Nice. Alright. I'm gonna pop this back over to our, like, facie mode. There we go. So that was really cool. I really like a lot of what I'm seeing here. I'm curious. Like I mean, I don't wanna say anything bad about Helm. Right? But I I don't find it personally an enjoyable experience for consuming third party software and applications. Like, install in MariaDB and Postgres, MongoDB, all these other tools. And I'm sitting here going, why don't we

1:23:41 Host Feedback and Comparison to Helm

1:24:09 have blueprints for all of this and consume them for kpt? Like, this model, I've been able to have the base that the experts produce and then me tailoring it to the with I need through defining pipelines of functions in a kpt file. And we don't do it today, but I'm assuming I really easily write and publish my own function to make any random changes that weren't already covered by the the kpt library. So it feels like we have a really good end to end flow for tweaking and tailoring base manifest for software and deployment to our

1:24:40 clusters that doesn't require help. Like, I'm not a fan of of Go templates. I never remember the syntax. I always have to Google how to do loops and ranges and all these other things. Like, this just feels like a nicer approach and I'd like to think and hope that we can get to a point where we have something better than hell. But I think kpt is a pretty good and strong contender based on what I've seen. Like, now I'll throw that back at you. I mean, is that do you see a world, and is this why you're working on kpt?

1:25:06 Like, do you feel it can replace helm to a certain degree and provide us a better ecosystem for shipping third party software? And then we can always pull it back and talk about first party software. But right now, I see a big market for third party, and I'm curious if you agree. I think first party is kept as a lot more ready for. I think third party is an obvious target because those templates tend to be more complex. You know, they basically use what I call the construct constructor pattern. They parameterize every possible attributes of the resources that they contain. Yeah. And

1:25:20 kpt's Vision for First-Party vs Third-Party Software

1:25:39 kpt enables a model where that's not necessary. Like, you know, just because somebody might want to change node selector or tolerations or some, you know, obscure field of the Kubernetes deployment API, doesn't mean it has to be in the base configuration. The way kpt can scale across multiple packages is by creating logic that's reusable across all packages containing the same resource types. So for for example, the backstage UI, if we add, the deployment resource, the service resource, ingress gateway, you know, application oriented resources, then we can use that to author blueprints that contain those resources

1:26:22 pretty easily. And then, you know, we will need a complimentary set of functions that perform common transformations to those resources. And once we have that in the catalog, then we can create this kind of low code experience where, you know, over time, people will have to write fewer and fewer functions from scratch, to do these things. You know, you can automatically update images, for example, is a super common one. So we do actually have a function for that because it's something people commonly wanna do in in CICD, for instance. And we can actually write that change back

1:26:47 Update Images

1:27:00 to get and there are some image updaters that can do that already for flux and ArgoCD. Mhmm. But we can change arbitrary fields in those resources with a similar level of automation. Yeah. This is a common frustration I see. I mean, especially talking to people that are adopting GitOps, you know, is that ingress is a a example and and horizontal pod autoscalers. These are things that need to be significantly tweaked from one environment to another. Like, the domain name you use for your ingress is very different in staging as it goes from prod, I would hope. Your HPA rules are not

1:27:11 Pre-deployment Validation vs Mutating Admission Controllers

1:27:31 as aggressive in staging as they might be in prod. And, yeah, right now, it's a lot of value files and helms and template to do that. But actually, this feels nicer. This feels like something that also happens because here's the other way. If people aren't doing this through templating, they're doing it through mutating admission. And the problem with mutating admission is you don't know what's broken until you apply it to the cluster. And that's Yeah. Here we can do predeployment validation, review, and approval, any of those types of kind of change control processes that you wanna apply before you deploy.

1:28:05 Advanced Automation Potential (Bulk Updates via API)

1:28:10 Like I said, after deployment, you can also do undo by reverting to a previous revision if you need to, but you can still get that WYSIWYG experience if you want it or, you know, automate it as much as you want. So we barely start to scratch the surface on this, but since we make all the packages available through an API, we can actually write automation to bulk update packages, for example. Yeah. So that's something that I'm personally pretty excited about. You know, there's lots of work to do, but also a lot of things that weren't possible

1:28:46 before where you'd have to manually, you know, check out and update a hundred packages to, you know, go make some change across all of them. Like, what if you wanna change the API version of some objects in all your packages? That's just super painful right now. But we can actually, you know, just write a simple script to do it with kpt and just extract the package contents, make the change. You can even run set on it and and write it back, and it takes care of all the get mechanics for you. You mean I I don't have

1:29:22 to have four f conditions to check for the last 17 major versions of Kubernetes and inject n v one v one alpha one or know? It's it's this has to get to be true. But as I say, I really like what I'm seeing, and I don't wanna keep this too much more because this is roughly where we said we would end in 10. So I'll just say, is there anything else that you you wanna share with the audience before we finish? If you wanna maybe give thirty second or a minute overview on what's coming next, like, are you just working on

1:29:41 Call for Contributions and Community Involvement

1:29:50 what your priorities, And then we'll we'll finish up with today. Well, we are working you know, this example was a namespace provisioning example. That's something I often see UIs used for. Most Kubernetes platforms have some kind of UI for, you know, creating namespaces or projects or workspaces or whatever they call them. So we wanted to show that you could do that through UI and also get all the same benefits of GitOps and kind of configuration as code but without the code, really. I mean, there is code that's in the functions, but hopefully, you know, someone else

1:30:24 wrote those functions and you don't have to, for every single package you have. So but we are focused on, you know, you mentioned home charts. Definitely, the first thing people wanna do with Kubernetes is deploy applications. So we're we're working on making the application, configuration experience easier. That's, I'd say, the next big priority that we're working on. So adding those resources to the backstage UI, creating bigger portfolio of functions that people will commonly need, creating some examples so people can see, you know, how to actually express blueprints in kept for applications. There are some tricky problems that we need to figure out.

1:31:04 You know, it's a very novel approach, so, you know, not everything is is figured out. But, you know, the if you're interested in contributing, there's lots of interesting things to do. So, you know, definitely contributors are welcome. Yeah. I just I just wanna I just wanna add, like, this is early. Sorry. I'm like, this is early and, like, we want the we is, like, all of us. Like, if you're interested in this space, like, we don't intend to build this and sort of build it ourselves. Like, we need to hear what problems you are experiencing when you try

1:31:38 to use these things or why do you find Helm annoying and why do you find Helm great and what should we copy and what should we try to improve, you know, all these sorts of things. And so please join us on the kpt channel on the Kubernetes Slack and github.com/googlecontainertools/kpt, and we look forward to discussing this and and hopefully building it with you. And is that true that anyone that can contribute to PR gets the Google email address so they can use the UI? That's up to Brian. We will go off and fix that. But but actually, you know, I am interested

1:32:13 also in hearing, you know, whether this makes sense, how do you think about it, because it's like I said, on one hand, it's familiar. It works has the same kind of experience as imperative tools, imperative UIs, ELIs, that kind of thing, except it is actually declarative, and automated under the hood. So we're still kind of trying to figure out the best way of explaining it. So the you know, to kinda communicate the power of what it can do, but hopefully, will also just become more obvious over time as we build out the the functionality to demonstrate the

1:32:59 potential. Awesome. Well, I encourage people to start playing with it, jump into GitHub, start looking for issues, PRs, get involved. It's a really interesting, exciting, early stage project, and I think those are the best ones because people can bring their knowledge, their expertise, and share that with you and hopefully shape what is the the future of Kubernetes deployment. Very exciting thing. Yeah. Yeah. We definitely need that. You know, people who have all the paper cuts from doing it all the other a hundred different ways. Alright. Well, thank you so much for your time, both of you.

1:33:33 Conclusion and Thanks

1:33:35 It's been a really interesting look, and thank you for driving a very ad hoc demo as well, Justin. I really appreciate you just kind of walking us through that as well. And Thank you so much. This was fun. I'll let you both get back to your day. Have a good one. I'll speak to you both soon, Anna. Thanks for having us on. Cheers. Bye. Thank you. Bye.