 All right, so this is going to be the crossplane introduction and deep dive But I got a bit of a combination of material here to hopefully Satisfy all different folks with their exposure to crossplane so far So my name is Jared and then we also have Nick Bob and Matias here We all contribute to the crossplane project in one way or another All right, so let's start with the intro stuff here first So, you know when you think about what crossplane is the best way to think about it is that it's a framework And you can use this framework to build a cloud native control plane The intent is that you can do that in a declarative way that you don't have to write any code You can write code if you need to You know to do more custom scenarios But hopefully you can do this all in a declarative way and end up with a cloud native control plane So speaking of control planes, you know the cloud providers, they've obviously been using these They've been building control planes and using them to manage their infrastructure for years You know control plane isn't a brand new concept, but now with crossplane though We're hoping to enable you to be able to build your own control plane and put your own opinions into it So if you think about the core crossplane functionality in the machinery, you know, there's two major Extensibility areas to it. So on the back end Crossplanes extensible to be able to basically anything that has an API, you know all sorts of cloud infrastructure Let's say you can may teach crossplane to manage that infrastructure in any environment So that's the extensible back end and then on the front end that you have Extensibility story for being able to compose together infrastructure and then surface that to your application developers with your own abstraction You know that expose the configuration fields knobs that you want to and basically help your developers have self-service Abilities to provision their own infrastructure All right So, you know, this is a CNCF project, right? This is the maintainer track. This is you know It is a community project And so we think of it as a neutral place for people to come together and enable and move forward control planes So this project's been around for a little bit. We first open sourced it back in late 2018 We are the same folks that created the Rook project as well storage orchestration for Kubernetes So some of you may be familiar with that as well and then a little bit of history We've we donated it to the CNCF at the sandbox level like middle of 2020 And then we got to the by the end of 2020. We're at our stable first V1 stable milestone declared it ready for production usage And then by the late 2021 we're at the incubation level just last week We released our latest release, which is the v1.10 release So the cross plane project still moving and making progress and then our next thing that we've got our sights on is Sometime in early 2023. We want to be moving to the full graduation with the CNCF We will need your help on that the whole community and ecosystem and we'll talk about that a little bit later So, you know stats numbers the biggest thing for this here for me is the number of contributions for people, right? We've got lots of people in this room that have been contributing to the project Writing code opening issues giving feedback and this project is nothing without the community behind it All right, so let's start with some the basic functionality of Managed resources and cross plane so we talked about, you know cross plane can manage any infrastructure in any environment An example of this here is let's talk about AWS. So AWS has something like I don't know 700 800 Services that they offer they've got a whole lot of stuff a lot of great engineers building a lot of cool stuff so basically You know using cross plane you can represent and bring all of those cloud infrastructure and services anything with an API You can bring that into the Kubernetes control plane and manage it provision and create all that infrastructure from Kubernetes So, you know networking databases certificates cues caches buckets, whatever all that sort of stuff You can from the Kubernetes control plane provision it and manage it and so how do we do that? Well, probably like you expect we represent all of these cloud provider resources and you know infrastructure etc as Objects in the Kubernetes API. So what we're looking at here on the screen is a Kubernetes API object With cross plane that represents an s3 bucket. So, you know, just like any other Kubernetes objects such as a deployment pod config map, whatever It's got a spec where that takes in the desired state all the configuration How do you want to create this bucket? You know, you can specify all that that desired state in the spec of this bucket object and cross plane will make that happen for you similarly you know with oh Yeah, so similarly with You know the common shape of Kubernetes API objects. They've got a spec for desired state They've got a status for some of that actual state the observed state to right so everything is going to be Represented with both spec and status So we observe things in the cloud provider apis or whatever infrastructure cross planes watching and then surfaces that back up as status fields And then just like many good API objects and Kubernetes They'll generate events as well that tells the story of that infrastructure It how did they get provisioned? Okay, did it run into an issue? Is it operating healthy? Etc. Those events will tell you the story Okay, and then just quick implementation detail here So this probably works exactly how you would expect it to work as well So you've on the left of the screen. Let's go left to right. You've got an API object a manifest You know, yeah, well whatever that represents an Amazon RDS database and so you've got the spec there You're specifying some of your desired configuration desired state you apply that to the Kubernetes API server You can do that with Q control apply or you can do that with you know Get ops methodology, but flux Argo, whatever it gets applied to the API server There's a specific controller that's you know for Amazon RDS that's watching the API server gets an event sees that somebody is requesting the creation of an RDS database and then it uses the Amazon the AWS API to talk to AWS and actually make that Desired state of an RDS database, you know actual makes it happen in the real world So that's a bit of the architecture and then one more detail on that is this tech stack here So from the bottom, you know, we're building this is building on, you know The Kubernetes runtime Kubernetes API machinery right and then you know on top of that the controller runtime is What we use to more quickly accelerate the how we build controllers in crossplane We get a lot of nice functionality there that helps us implement reconciliation of cloud provider resources on top of that We've built a opinionated specific crossplane runtime that helps to further accelerate the implementation of controllers and reconciliation of managed resources cloud provider resources infrastructure stuff You know within crossplane and then the top layer or they're all the controllers for you know RDS Dynamo DB GK you know GKE whatever all those resources they each have a controller that's built on this stack So I'll go ahead and pass it off to my colleague Mattias now to talk about the next bit of functionality in crossplane All right, so so far what Jared has been talking about is getting The API of something like an S3 bucket or yes, and since what you name it also other cloud providers into your system and the next level is that we want to compose them together, so We want to enable building your own platform A platform API right so that is Using the existing granular resources and composing them to you know something bigger something that you as You want to offer to your developers? This can be from multiple clouds, right? That is like a typical example and it's higher level APIs and these can be any anything right that's on your decision. We have a couple of examples But I guess, you know, it's also up to the community to come up with good examples And I know that some folks Talked to yesterday's like oh, I have this very opinionated version of it Like is anyone interested and it's like yes, we are interested in these right because we need to as a community Learn on how we're building these so there's you compose these into You know higher level APIs and offer them as a single API to the developer which we want to see in a second this is all Dilemma and so there is lots of Yamal fun so Conceptually you can think about this like you know high-level you like this right? We have like these manage resources that Gerrit has just talked about and they all are bundled into a provider All right, so they have you have this AWS provider GKE GCP provider and etc. And then you compose them together But you offer this you offer the API with an XRD and the developer Claims it with a specific typed claim that you that you have defined So just as one example, right? So a developer would say I would I would like to have a small postgres instance and This you know is defined how this looks like in the XRD and here's we have a like specific AWS composition that you know takes You know configures it how you as a platform developer Would put it together? Yep. All right, so the first thing that you need to do is create a composite resource This is like a composite resource definition or XRD CRD was taken so we went for the X And we put them all all together So you have your for example, you have your custom API group that you can define you know with the usual Ways of doing it and you have a standard open API v3 schema where you define and how this how your API looks like On the compositions line is then is like, okay, how does it actually work? Right? So I said like as an example, this would be the AWS example. So you take the List you take all the managed resources that you want to compose into a high level API You reference the XRD that you're that this composition works for And yeah, you get all the compositions all the management resources together And you need to propagate Information and we do this by this patching mechanism And there you have, you know ways of propagating the information and transforming the information This is the current way of doing it and Nick is going to show in a minute a new way Of also doing this like yeah in different ways So this is about compositions right and these are the two things that you need to do But obviously you don't want to do all this by hand. You want to use existing packages existing extensions So, you know, if we think about extending crossplane, there's currently two ways to major building blocks that that that are relevant Crossplane as Jared has said is an extensible framework. So we have two building blocks That you that that you can reason about the first one is as a provider There's basically, you know provider for for everything The the easiest way is again the the clouds that you can reason about but also specific services specific other smaller clouds all all very different ways of Very different providers for all sorts of things We also have code generation for these providers So you don't you know, you can take existing ways of talking to an API and generate Providers out of it The second part is configurations and that's where we are Using existing providers. So you have some kind of dependency a way of saying, okay, I need one multiple providers and then you bundle all the compositions that we've seen before into its own package and That way you have like a single deployable unit that you can hand over that you can reason about that you can colorate on Of how you would use a specific Specific API and how you know share that share that with others Yeah, both both packages are Just OCI images. So there's a spec behind it, but it's basically just YAML layers in an OCI image And yeah, there's there's a nice spec around it if you're interested in that We've got a pretty good provider ecosystem We have many providers from the community and there's you know daily. There's something new coming And we have just launched a marketplace and that is open for everyone So we from up on we have specific providers that we offer, but we are not getting this in any way, right? So this is open for the community So if you have a provider and or if you think about a provider, please come to me talk to me We're happy to help And you know listing them in the marketplace just you know gives the community, you know gate great way To reason about these find these and colorate on these With that said I'll hand it over to Nick All right. Hey folks. I'm Nick Senior principal engineer at Upbound and longtime crossplane maintainer so today I'm going to talk to you a little bit about a new feature that we're hoping to land in Cross-plane 0.11, which I guess is due in about a quarter from now. We just released 0.10. Sorry 1.11 We just released 1.10 so this functionality is Intended to extend and give some more power and flexibility to help people do composition in crossplane So as Matias mentioned earlier, you know, I won't I'll go over this context pretty quickly because Matias touched on it But in crossplane you can define your own API types So this is an example of one of those. This is an XR Matias talked about this a moment ago This is defined by an XRD a composite resource definition And the idea here is that you for your org Let's say you're a platform team at Acme Co And maybe you want to let your developers provision databases But you want to take away a lot of the knobs and you want to just say all the Developers really care about are what's the storage size for this contrived simple example? This is how they could do that you define the scheme with this resource and then you teach crossplane what to do When the crossplane sees one of these resources Now as Matias mentioned you teach crossplane what to do using a composition historically as Matias already touched on a composition has an Array of resources effectively resource templates and Then it can patch and transform values Now what this means it can copy values effectively from the instance of a composite resource into the composed resources So in this case, we're saying crossplane when you see an Acme Co database What we really want you to do is make a cloud SQL instance in GCP Now it doesn't have to be one resource It could be a cloud SQL instance and a firewall rule or something like that in this case We're keeping it simple and then you can say all right crossplane you can see the patches towards the bottom there take that storage gig value and Copy that into this other path basically the settings not data disk size Meg And then you can also transform that you can basically say all right in this case, you know multiply it to turn it from from gig to Meg now When we designed this API type we very intentionally kept it as limited as possible we Did not want to grow a DSL in YAML something that tries to compete with a general purpose programming language and Speaking of someone who's been a platform engineer in SRE for my entire career I kind of know that it's really easy to fall into the temptation of oh, I just need this feature from this language I just need feature X or feature Y. I'll add it on I'll bolt it on and then you have this really sort of incoherent weird configuration file So we decided to try and be as conservative as possible. We designed this for relatively simple use cases So things that you can't do today in composition and crossplane for example includes conditionals You can't say if this input then make this resource otherwise don't or do this patch. Otherwise don't You can't do iteration in composition today So you can't say if there are five Resources, sorry if the spec is five then make five something like that. That's not possible in crossplane today So our idea was that we always wanted to give people the ability to use their Existing tooling that they're comfortable with or a general purpose programming language that they're comfortable with in order to do more advanced composition use cases So this kind of balances no code with low code basically if you have a simple use case It's no code. You write one of these but if you start to get a little bit more complex Then we really do think the best thing to do is Either, you know, I guess it doesn't have to be code You could use a programming language, but you could also use something like held inside of crossplane for example And I'll touch on that now So this is this is what we call composition functions You can see that in this example instead of the array of resources an array of resource templates There's an array of functions In this case the function is an OCI container Now this can be mixed and matched with the resource template which is pretty nice So you could actually do both you could have the example from the previous slide You could say I'd like you to just make a simple cloud SQL instance, but then maybe I have to go and Talk to an IP am an IP address allocation Service to figure out what something that I should put it in or something like that And that's something that you can't do with a simple YAML file in composition today, but you could do with a function So the idea is this allows you to decorate your existing compositions with additional functionality Or just replace them with additional functionality. So it touches on a couple of use cases It touches on, you know, maybe you just don't like YAML very much Which I know is a you know a pretty common thing and maybe you prefer to use a real programming language Well, maybe you have a tool that you're familiar with already Maybe you really like helm or you really like J-solid or you really like Q-lang or something like that You would like to use those to do Your your composition for you, but you'd like to do that server side That's that's one of the neat things about crossplane right you don't have to get everyone to go and run Helm or their laptop for example crossplane can go and do it for you server side It's behind an API so people are still making your developers that you're supporting still make an API call They don't they don't know how this is implemented on the back I don't need to know they just say I need an ACME code database and then you specify what crossplane should do So this is a bit of a sneak preview in how we think that these functions will be implemented Shout out to the folks who worked on KRM functions in customize and KBT that was a definitely big influence here So we're following a similar pattern where we think that it might be different kinds of functions in future For instance, you could imagine a webhook function right that I just you know basically calls out to webhook and says what should I do? to compose these resources But to start with we're thinking we'll use OCI containers the idea is you containerize a process the process takes a Standard input on its standard input actually as an a standard this YAML document on its standard input and Then can optionally mutate this YAML document and is expected to return it to standard out And this allows a pipeline of functions. It allows you to stack them effectively with each one mutating the state of the world You can see in this in this document. You've got a config for the function, which is basically just an arbitrary XORM or KRM document that you can use optionally to to configure your function and Then it will show you in this case. This is kind of the input to the first function So to show you the observed state of the world it says hey, there's this composite resource in this case It's called an X postgres instance and it's got 20 gig of storage What should I do function and then the function it's not pictured here But can set the desired state of the world which looks very similar to this it might say Set the status conditions ready true, which is already there so the status conditions may be ready false and Go compose a cloud SQL instance by outputting that Returns this on its standard out then cross-plane sees that and says oh, all right I need to go make a class equal instance or whatever so We expect this to be alpha in the 0.11. It's probably going to be off by default As all of our alpha features are you know, I expect that there's going to be a limited scaffolding for building these functions at first But this is definitely something that we want to have we're imagining having no CLI tooling SDKs All that kind of thing to make these make building these functions easier and we really hope that this is going to Open cross-plane up to some more Advanced composition functionality that will help more people as they migrate away from other tools to cross-plane Be able to do what they need to do and we also hope it's going to be a bit of a proving ground We're not necessarily not saying that we won't extend sort of patch and transform style composition as well But the nice thing is with this in place There's always an escape hatch We can take our time and we can grow the composition language as it exists today Slowly and carefully and intentionally and meanwhile people can still do what they need to do using these functions The first version of the container runner, this is a quick illustration of it We actually think there's going to be multiple different container runners If anyone's worked with or on Argo workflows You've probably seen that it's surprisingly hard to get Kubernetes to run a pipeline of containers in order passing input to passing output to input In a sort of fast and performate way So we're thinking that cross-planes going to ship with a sidecar container that will actually use rootless containers to run these inside it Run little snippets of these are these sort of function containers inside it But we do imagine that this is going to be a pluggable situation So if you wanted to go and build maybe a more scalable function rather that's you know Secure built on by cracker or gviz or something like that absolutely possible as well This is going to be kind of just like the the default one that ships of cross-planes so that you can have something that works out Of the box without having to spit up a ton of infrastructure All right, and now I'll pass you on to Bob to talk about garbage collection in cross-plane. I'm Bob Hattleton I work for Nokia and Contributing the cross-plane for about six months or so I'm going to talk a little bit about the garbage collect deletion processing and garbage collection issues that we've run into And some of the work that's been going on to try to improve this area One thing we found is that managed resources Can fail to delete and you you as the user the claim the person that put the claim in and presumably deleted the claim You may not know that that deletion failed One thing I realized we didn't talk about much was the processing of you know, how you create things well Kubernetes is going to create everything that you tell it to using eventual consistency It's going to follow a path of resource creation that is undefined and Undefined a bowl pretty much And it's also not stored anywhere. So we don't know the order that things got created in and As things stand today, there is no defined order for deleting resources So We found that because of the resources just kind of delete as they go Your managed resources might get stuck in some situations We also found that foreground deletion on composites does it didn't work for a couple of reasons mainly the block owner deletion Field in the controller owner reference wasn't set to true And then the other issue is that the claim itself is namespaced But the composite that is associated with that claim is cluster scope And what that means in Kubernetes world is that you cannot have an owner reference field from the composite pointing back at the claim So now kubernetes has no way of associating the deletion of the claim with the deletion of all the other resources underneath the claim crossplane has to handle that itself so the resource relationship real quick As I said the claim is namespaced It has a reference to the composite object that is that is associated with it So when you create the claim crossplane will see that claim and it will create an associated composite That composite has a claim reference pointing back at the claim As I said the there's no owner reference there The composite then creates other composites or other managed resources as you tell it to And all of those are cluster scope So all of those have owner references to point back up eventually you'll get back up to that root composite Each one of the types the claim composite and managed resources have reconcilers associated with them Those reconcilers have finalizers that they've placed on the resources to prevent them from being deleted crossplane is going to manage The deletion of those resources when kubernetes tells it to So just as an example of a default claim processing Delete processing and this is this is what happens today And we'll continue for this type of example when you do cube control delete on the claim kubernetes will put a deletion time stamp on The metadata for that claim It does some other things too, but for our purposes, that's enough the claim reconciler will detect that deletion time stamp and it will Call the API delete function for the composite because again kubernetes has no way of doing that directly The composite then gets a delete time stamp the claim reconciler meanwhile goes on and finishes its work Right, so the claim is now gone kubernetes control delete is done So as a user you have no idea what else is going on at this point. You think everything is deleted The deletion time stamp that shows up on the composite Kind of in parallel with everything else Triggers kubernetes to go follow those owner references generate a graph follow those owner references and mark basically call API delete all of those sub resources the Reconcilers will then detect those deletions and Do their appropriate processing so the composite reconciler will detect the deletion of the composite It will remove the connection details resource that's associated with composite and then it will remove its finalizer Which will allow the object to be deleted the managed resources the managed reconciler will call whatever delete function is associated with that Manage resource whether it's a delete PPC or a delete EC2 instance or whatever it is Once that's done it will remove its finalizer and those objects can get deleted and that all happens Basically at random You know you have no control over it all those things just kind of happen and everything goes away Which is great until you have one or five or ten managed resources that for whatever reason The the far end of your API can't delete Maybe somebody spun up an EC2 instance on your subnet and didn't tell you about it Which wasn't very nice, but it happens and now your subnet can't be deleted because somebody else has an EC2 instance sitting out There on it right that's what gets you into this situation at that point you have Two choices basically you can either go find the EC2 instance and delete it and what reconciliation Do its thing you can also remove the finalizer But I would not recommend that because now your subnet is left out there hanging in whatever cloud provider you've got So that's kind of the an illustration of the problem that we were looking at In 1.10 we added support for foreground cascading deletion And I want to qualify that a little bit. It's simulated on the claim side. It's implemented for the composite side The claim reconciled we have a composite delete policy that we added to the claim So you can tell the claim when you delete that composite use foreground cascading deletion And I'll show you that example in a minute. The default is still background. It's still going to operate exactly the same way it does today The other thing we did was we set block owner deletion on all the controller owner references So that foreground cascading deletion will work the way we expect it to You can delete a standalone composite. We haven't talked about it really, but you there's no requirement to use a claim You can implement you can instantiate the composites directly That's entirely a user decision This change will allow foreground cascading deletion to work on composites The the other piece here is that if you specify the cascading foreground cascading deletion policy on a claim deletion It's still ignored like it is today and that's cause that's the owner reference issue So the same example that we just ran this time. We're setting the foreground composite deletion policy Same thing is going to happen to set the deletion time stamp the claim reconciler is going to do its thing You'll notice the claim stays at this point At this point you've got an additional finalizer on all the composite resource anything that has an owner reference pointed to it Has in a final additional finalizer on it the managed resources are going to go ahead and delete the way they do today The composite that now has no owner references pointing to it will also get deleted But your stuck mobile managed resource is now going to block the deletion of everything up the tree Behind it. So now your cube control command doesn't return Nothing gets deleted until you go in and you fix this and you now say oh, I have a stuck resource now Hey delete my EC2 instance. It's blocking my subnet and now everything cascades out the next step on top of this is kind of going on now in terms of determining the Deletion order and we've got a couple of POC is going on using caverno to try to simulate that Jared All right, sweet. So let's go ahead and start closing this thing out now So the final thing I wanted to say once again, you know kind of Reinforced this is that you know this project is nothing without its community, right? And so, you know, I definitely wanted to make sure that we give some opportunities here for everyone to start getting involved There's a whole bunch of useful links here You know the main website is crossplane.io you can go there read the docs get the quick start You know start trying it out on your own and we are always around on slack slack as well So our cross planes black slack. We're hanging out there. We're ready to answer questions and talk and hang out And so the last thing I wanted to mention is that You know as we are trying to progress to the graduated state with the cloud native computing foundation and so one thing that we need your help with for that is Essentially hearing about your adoption your success your challenges, etc So I've got a little survey here that you know me as a as the maintainer in the steering committee We'll love to collect this information hear it from you all connect with you and then be able to kind of put That into our graduation proposal with the CNCF as well and kind of share the story of the success and growth of our community together So I'm gonna leave this here on the screen So you can use a little QR code thing there to go to that survey if you want to and and help us out all gets a graduation And so that with that questions anybody Saw that hand go first for sure. That was fast There's definitely no plans at the moment to remove it So technically anything that goes into cross-plane as alpha could be removed that's kind of part of that contract But there's no intention I think the only reason we would remove it is if we added it it turned out to be a terrible idea and everyone hated it Or it didn't work or something like that. So I hope it stays there, but No Contract around that until it hits v1 basically So cross-plane manages the cloud provider Cross-plane providers right and I was wondering what cross-plane does to stay up-to-date with you know, all the updates of all the crowd cloud provider API's And why not use like Azure service operator Google config connector? And let them manage it kind of thank you Yeah, and that's a great question and obviously a challenge So first of all, I think the community done has done a great job and keeps doing a great job of creating these providers The community providers and we see this left and right and I encourage everyone to to contribute there We also have code generation as I said And that's this code generation works on top of Terraform providers So it takes an existing Terraform provider and creates creates a cross-plane provider And we've we've done this from the up-and-side for the major Providers, but everyone can do them and we're seeing this that others are also using this and the way that I try to think about it The vision would be that the cross-plane provider at the end of the day is just a build artifact out of the Terraform provider Now this doesn't need to be the end right? We are also looking into other code generation mechanisms of other things But that but that's the current state and that's why we are Confident that we every resources there or is is can be generated in a very fast way Just to just to add on to that real quick as well the specific around like why not use Azure service operator KCC ACK etc etc It's it's a couple of things one is API consistency Yes, all those things are bounded by the KRM, but you know, we work pretty closely Collaborate with the folks who work on those teams because we're all doing similar work and it's great to swap notes And you know KCC just has different annotations and different settings from from ACK, right? So if you're using multiple providers, it's just nice to have them be consistent I think the other thing as well is that that only covers the big three clouds You know, we have providers for GitHub, GitLab, SQL, Terraform to run Terraform Tons of other things, right? So if we just said you could maybe maybe case Oh, we'll just use operators any operator sort of thing But it's just becomes really inconsistent and it's just a lot for cross-lane sort of administrators to have to understand So it's nice to have the consistency of having our own sort of standards there basically All right, that's all the time we have there But thanks again for showing up and look at the scene in the community