Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2022, 1 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Crossplane Intro & Deep Dive - Compose Your Custom Cloud Platform

Description

Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Crossplane Intro & Deep Dive - Compose Your Custom Cloud Platform - Jared Watts, Steven Borreli & Yury Tsarev, Upbound; Christopher Haar, DKB AG

The maintainers of Crossplane, a CNCF Incubating project, will lead this session that will introduce the project to new attendees, as well as dive into the finer details of Crossplane’s functionality and roadmap. We will explain how Crossplane enables you to compose cloud infrastructure and services into your custom platform APIs, and how best to get started building a platform of your own. We will take a tour through the key features included in the latest releases, what problems and use cases they are solving, and how you can adopt them into your control planes. Finally, there will be an interactive opportunity to engage with the maintainers, ask questions, and influence the future of the project direction.

A

Yeah, I think first of all the thing to say is that I am absolutely shocked uh and grateful as well if the number of people that showed up to this is literally the last session of kubecon eu. So thank you very much for showing you must not have a plane, that's leaving soon, you're, probably leaving after one of our speakers who has a plane at seven. So let's get this thing going and get get out of here all right. So this is the introduction and deep dive session for the cross plane project.

A

We are all maintainers and contributors on the project, uh we're going to share some of our knowledge and experience with you. So, first of all what is crossplane just a quick introduction to it. You can think of crossplane as being a framework that you can use for building your own cloud native control, plane or platform.

A

You can do it declaratively, where you don't have to write any code to make this happen, but then, let's also take a step back and say what is a control plane. So a lot of good examples of control planes are things like aws or gcp they've been using control planes for years. If you ask for a cloud resource in in their backend services, they've got a control plane running to do all the orchestration of the machines, the storage, compute, etc to provision and dynamically give you services.

A

So that's a control, plane, kubernetes, obviously, a control plane as well orchestrating your applications, containers, pods, etc, but there's a lot more resources than that right. uh So crossplane is something that will help you build your own control plane, but with all sorts of resources beyond just you know, containers and applications, databases, caches buckets, all sorts of things. uh It allows you also to put your own opinion into that control plan.

A

We're going to get into a lot of details on that, as this is just the first slide, but let's think about crossblade as two points of extension. So when you're building your control plane on the back end, there's all sorts of ways with providers, you can extend the control plane and, basically anything with an api. You can now manage with crossplane.

A

You know all the cloud providers on premises, services etc. Then, on the front-end side, you know you can aggregate these resources together and declaratively say hey. This is an api or a you know, abstraction that I want to give to my developers to be able to access my control plane so we'll go into the more details about the back end and front end extensions of crossplane as we get into more slides here so right. This is part of the maintainer track. This is uh you know it's a cncf project.

A

We originally donated the crossplane project to the cncf back in 2020, and then we moved to the incubation milestone late 2021.. So you know it's a neutral place for multiple vendors companies, organizations, individuals, contributors, etc to come together and start enabling and building control plans together. uh So it is a community- and you know that we're glad you all are here and we want you to be part of the project as well.

A

uh We're not going to go into these numbers here, but the project is growing right, like we have this many people here at like 4 55 on the last day on a friday, so you know we're growing and there's lots of ways to get involved in the project to continue being a part of it. So I'm going to hand it over now to steven to start with some of the details about managed resources.

A

Thank you. Jared is my.

B

Microphone working woo all right. Thank you. So we're going to talk about probably the fundamental concept of cross plane. If you understand this, it's really going to help. You understand pretty much everything else about crossplane, and this is something called a managed resource right. So what a managed resource is it's a kubernetes version of something that's external to the cluster. It could be anything in our demos today we're going to talk about cloud resources, but if you've been to some of the other talks, people been talking about managing things like ships and trucks.

B

Basically, anything with an api can be managed by crossplane. So let's talk about examples of this in the case of aws, what kind of things you want to configure? There's hundreds of things you could configure on each of the cloud providers in the case of aws, it would be things like certificates, uh queues, uh eks clusters, uh databases and networking right. So what crossplane you know our goal is with this project is with all these resources that are available in aws.

B

Can we manage these using kubernetes and using all the things um you know all the tooling that you have? The git ops, tooling, all the controls you have around it. um You know things like validation web hooks.

B

So what does this look like in a kubernetes context right, so we're representing external objects in kubernetes, so that means that we have to translate things that are in a remote state into kubernetes. So the first thing I want to show here is um the yaml that we use in crossplane is basically 100 native kubernetes right. So things like groups, versions and kinds are supported. uh We use the same kind of api versioning, that's used in kubernetes, it's all standard and then you'll notice, here that every single kind represents one resource on the remote cluster.

B

In this case, like in the case of aws, some of the providers have over 700 of these that they install, and then we have metadata support right. So every object like in kubernetes is named. um You could also add labels and annotations to this so like. If you want to label that this resource is owned by your dev team, you could just add it there and um you can manage it. However, you manage labels in kubernetes and then finally, we have the spec. The spec is the desired state. This is what we want.

B

The remote object, the state to be, and we have a special stanza called for provider. So this is what we actually send to the remote api server and this spec in a managed resource is high, fidelity right. What this means is that if the cloud provider has a hundred different things that you can configure, crossplane will have a hundred different settings here. That's the goal of a managed resource to be as high fidelity as possible to the remote resource.

B

How does this work? Well, when you apply a yaml to your cluster, there's two things that get installed. We install a cross plane provider. One is all those crds that we talked about and that could be dozens or hundreds of crds. So those get installed in the api server using the crd mechanism starts watching for changes in those and then we install a pod, which is a controller that actually manages and knows how to talk to a back end api server.

B

So what happens is this is running all the time and it's watching for any creates, updates or deletes on the api server. um So when you apply something to the cluster, it's going to say, I know I'm looking to manage rds kinds. So when this gets applied, any change, update or delete we'll go to this, and then this will immediately start talking to the aws api. Now, there's two things that a controller does. First, it asks.

B

Does this resource exist in the cloud and if it doesn't it's going to go, do a create if the resource exists already it's going to create a calculated difference and then it's going to go and change it. The controller runs continuously. So this is a declarative state. So anything you want here. Crossplane will attempt to get this into the remote state.

B

So that's the spec, that's the desired state. Now we want to communicate, there's a two way: communication with remote apis. So what comes back is the status right, and this is the at provider. Ford provider goes out at provider comes back and in this case, when we create a bucket um aws will give us an arm and then there's um the other thing that comes back is events right, like providers don't generate standard out or anything like that, they generate events that you could use whatever venting system.

B

So the kind of events you'll see, you'll, see errors, you'll, see, inability to authenticate you'll, see, creates, updates or deletes right. So if you collect your events, this is how you can monitor things, and I think that's a very quick update and so I'd like to do a very um a demo of a managed resource just to show you what this looks like in practice.

B

So what I have here is just um let's see here.

B

So I'm going to show you a bucket and you can see here again. This is very simple, there's hundreds of things we could set, but this is a minimum and you can see here we have a region selected, a name. You know we talked about groups, versions and kinds and we're going to create a bucket in eus 1 with private acl and we're going to add a tag to it.

B

B

So this is how you create objects in cross plane right, like you're, not running a script or anything like this you're, just applying a desired state to the cluster we've uh created it we're going to go, and now we can just get this right so immediately see it hasn't done anything yet. So we can watch this right so what's happening now. Is that we're just you know, watching what's happening to this resource and crossplane is asynchronous right, so it runs as all controllers. It runs in a loop. The controller saw that something was requested.

B

So now, what it's doing is it's syncing? It's saying: can I communicate with the remote api um and then when it gets to be ready in a few seconds, and now it's ready right. So now the bucket has been created so you're not like running a script or anything. You just say: hey, create me a bucket and eventually the bucket will come to a ready state. Now, if you're doing things like creating a vpc or a subnet, things that depend on that will not become ready until this becomes ready.

B

So there's kind of like a internal dependency mechanism within cross plane, but it's a little more decoupled, so we've created our resource and now what we could do.

B

We can see what's going on there, so we've just created this resource, and you can see here. We have a bunch of conditions right. We got our at provider that I talked about and then we have conditions right. So all the things that came back um so in cross plane, you're, not looking for like the output of a shell script, you're looking at the conditions- and the other thing that's important to note is probably one of the more important con is the concept of an external name right.

B

So um this is the way that cross plane can match a kubernetes object to remote right. If you don't have this crossplane thinks the object doesn't exist so in terms of like backup or restore, or something like that. This is the one piece of data that crossplane uses to reconstruct in kubernetes what the remote state is. So this is- and I think chris talks about this a little bit in this controller writing, but this is really an important concept in cross plane. This is kind of the link between remote and on the cluster and finally,.

B

Here um sorry, there's.

B

Sorry, it's weird to type on this keyboard um and then yeah. Finally, here you see the um you see the events that are being created right, like that we could create a brand new event here. So this is how you know that it's been um so I think, in terms of my time, that's um yeah, so yeah, let's delete this bucket and then I'll move over to yuri he's going to talk about composition,.

C

Thanks david, can you folks hear me all good? Thank you so hi, I'm yuri, and I truly believe that cross playing rocks. Sorry, I always dreamed to say that from stage so.

C

C

Yeah, just a quick one.

C

C

It's apparently a full screen issue: yeah, sorry for that small glitch yeah, so uh steven uh demonstrated the core ability of uh crossplane to be able to describe any cloud resource kubernetes way. So you inherit uh automated configuration drift uh reconciliation, loop and all that kubernetes core kubernetes powers, but uh so it's already very powerful but cross plane has more so crossplane uh provides you this ability to uh just create your custom platform.

C

Api is it, which is very specific to your use case to your company, to your teams and with the help of a composition and composite resource definition, you can implement all of this custom logic uh a declarative way without any coding, no need to write any kind of golden code for controller or any kind of code. Everything is declarative, so this is a simple illustration of uh of the following concept. So here we we define our custom cluster api. So it's purely coincidence it's not copy project.

C

It's just our custom cluster api, which we implement uh to create a managed services. You know manage comprehensive service with associated uh cloud cloud providers, so we have a two composition. In that case, one is a ws and another gcp, and these compositions are actually like a collection of dependent resources which can create your very custom clusters from manage tks down to helm, chart and services like primitives on top and same for gke.

C

The core concept behind that is that you provide a stable api for your consumers like platform consumers, frequently it's application developers in your company and they are not exposed to any complexity of underlying infrastructure.

C

So how? Actually? We can do that. So we have a special client composite resource definition, so it's called xrd, so it's very similar to kubernetes standard customers or definition, but it extends as kubernetes resource model. We can define a custom api group which is very specific to a company and describes a desired api visa standard, open ipa, v3 schema so pretty standard stuff, very, very similar to crd, so how to actually implement the logic behind this uh xrd definition.

C

So again you don't need to cut anything up. You can use a special kind composition and which would satisfy the associated composite type, and you will list you will create a list of managed resources that this composition will manage right. So you can, uh if you can create analogy from a terraform world, it will be like kind of terrifying model or as like a server side helm. So everything is server side.

C

There is no client job here at all, so this is like a list of static research right how so how to make it more dynamic. So we have a concept of patches, uh so we we can propagate the data from uh composite resource, uh which we define, uh create instantiate out of a compositor sort of definition and associated claim, and we can propagate this data down to a manager's source that is composed by the composition right.

C

So you can expose only required uh only required required api fields, and you name this api api fields, as you like, and in addition to that we provide like runtime, transforms for uh as a form of patch. In this specific case, we have like we obstructing the instance types and some cloud provider, and we can expose to our teams only like internal namings, like small, medium large and the actual meaning of the small medium latch can be defined by platform builders.

C

So we can actually make a live demo of this stuff yeah. First of all, what we actually trying to achieve right. We want to expose this minimalistic api to our customers. We want to hide in a complexity of underlying resource, so if we just for the sake of quick comparison right, so that's a miniature source of rds instance in aws, and it's just some possible values there.

C

Actually, I don't know hundreds of them uh for to configure the rda specific rds instance, and we want to encapsulate uh platform builder logic and parameters, security, all that stuff within a composition and exposed to our developers only required parameters like in this case. It's just.

C

Just the size of the database and a password secret to pick up from so that's the goal so how to implement that. So exactly as I mentioned in slide. First, we want to describe an xrd, a complex resource definition right so again, open api, visor schema. It.

C

It describes the required parameters of storage size and a referenced password secret name, so pretty straightforward. So the only thing we should do is just instantiated, so we defined uh this custom platform api right now. What we should do next is actually to implement it and we should we'll implement it in the form of associated composition.

C

So there is a composition that satisfies uh this previously created xrd right postgresql instance, and it couple composes a couple of resources, the main one like rds instance itself and associated param custom parameter group. So here we have like just a couple of resource for demonstration, but it can provide you a picture how we can compose arbitrary amount of resources in the dependent one, and we can create a composition of different complexity and yeah. We have again we have a purchase and.

C

uh With which we can propagate the required data from uh claim instantiation, so, as you can see uh here, we propagating the size.

C

uh With this from field pass to field paths of done of composed managed resource and everything from the associated claim will be uh propagated to the resources that are composed and one extremely important difference. So a composite resource is a cluster scoped one and a claim is almost the same, but it's a namespace scope to one resource which is designed to be consumed by platform. Consumers and xrd is a scope of a platform builders, so how we actually now we are changing ahead and we are going to so.

C

We build our custom api, we implemented in the forum, composition and we now can consume it as a platform as a application in developers platform, consumers right so we're just making. uh We apply the claim.

C

Yeah, so, as you can see, our claim is created. It's our custom resource right. Our custom example or database api group and a postgresql instance, our custom obstructions. That's exactly what we want.

C

We have a sure shortcut get claims, so we can see the status you can obviously get describe any and a standard standard api uh use any standard, cube control commands over this resource. So, as you can see, this claim is created.

C

So so we can use this a full pass to it and see the status it's not yet ready is a database takes some time, so current status, composite resource claim, is waiting for uh resource to become ready and we can get managed. It's a standard cross plane shortcut to get all the list of all managed resources that is uh uh current cross plane. Instances is managing at the at the time. So, as you can see, uh both composed managed resources were created.

C

So it's a parameter group and rds instance itself, and just for the sake of end-to-end demonstration, you can go to rds and double check. The actual state was it applied by crossplane and just refreshing, the page now yeah. So we have a custom group, it's visible, but I'll go to database instances.

C

It's our cross plane deep dive instance in creating stage. That's why it's still waiting for for the database to be ready and we can go to configuration and check, parameter groups yeah, and so it is referencing a custom cross plane, deep dive parameter group which was created as a part of the composition.

C

So that's pretty much it for the demo of a custom platform, api and custom abstraction power, and we can proceed with the provider extension chris, please change the stage and we will do small magic of laptop laptop change.

C

D

So microphone is working cool then, hopefully also the beamer.

D

Okay, so then, let's talk about extending crossplan, so, as we said in the beginning, so crossbone is highly extensible and it's a framework to build uh universal cr control planes and there are both sides. So one is the back end side. We call it providers and with the providers you can uh or you in general, can build providers and manage any anything or any api out of the world. So you get crud operations for cloud resources on premise and whatever you want um on the front-end perspective, we call it configurations.

D

So that means you can compose your resources from the providers. Together, um you can define your control plans, declarative, apis and abstractions like we see before, and this is at the end that what your deaf or your customers see and what I can consume from your control plan and we also take care of the provider versions in general if everything we have is available.

D

So let's have a look here at the visualization in the middle of it we have our crossplane control, plane running. We have on the bottom level, the provider, resources or the providers and the resources so thought about. If you want to create a kafka cluster for your customers- and you have two cloud providers available in that case aws and digitalocean- and it doesn't matte it doesn't matter if the kafka cluster is running on aws or digital ocean, um as in creator of the infrastructure. Here you can say: okay aws.

D

We need the following version for digital ocean. We need the following version and for kafka. We checks this. If it's not available in your kubernetes cluster, then we set it up for you and uh on top of it you have all the configuration stuff. So the composition compositions the uh the uh representation, uh what your app devs can consume in your control plane.

D

um So let's talk a little bit about the ecosystem. The ecosystem, I think in the last months, is growing and growing in the community. I think normally folks, starting using the public cloud providers, so like aws, google cloud azure digital ocean whatever and set up, for example, kubernetes cluster, and then you can thought about. Okay, I need my kubernetes cluster. If it's ready and available hem charts um kubernetes manifests whatever, and then you start with the next providers, and so you can get a lot of resources composed from your control plan perspective.

D

And then you see a lot of guys, uh starting using more and more so thought about gitlab runners whatever, then, you also need um tokens what and you can create it in the gitlab apis and then you can move it back to your cluster and yeah.

C

D

As announcement, I think today, in the ecosystem, there's also now a provider available for uh ansible, so you see for it's adopting more and more stuff um in the ecosystem.

D

So um let's talk about a little bit about the the internal stack, how we build our pro virus in the platform at the very bottom level, we have kubernetes runtime, so the runtime takes care of running our controllers, our docker containers and also things like ingress services, load balancer in front of the services and on top of it, if you're not aware of programming in kubernetes, there's something like machinery.

D

So this is how the apis are composed together in the cluster and a lot of other cool things around. But the thing we need here is uh the custom resource definitions.

D

So that means, if you create custom types in your cluster, and you want to use it like real native kubernetes objects, so thought about and subnet group for elastic cache. You can set it up then, and it feels completely like kubernetes. You can cube cuddle describe, get delete, apply everything.

D

Then the next layer is the controller runtime. So I think almost every kubernetes operators are using parts of the controller runtime. The controller runtime helps us in general for the reconsolation stuff in kubernetes. It helps also to watch for resources. So if, if someone changed the resource in the cluster, then it helps us to get or the the runtime knows what what happened there, um and on top of it, there's the interesting thing from the community here, and uh this is cross-plane runtime.

D

So normally a lot of things are built as operators for kubernetes, but we build things in kubernetes for apis that we can manage them so thought about everything we can manage an external api, so create update, delete- and um this is, I would say, like pre-configured for you and you can thought about your custom logic. So what what do you need to do for for updating, stuff, etc?

D

And the rest is here and the very cool part here is you can use your your tooling from your kubernetes ecosystem so, like ham customized flux ago cd, whatever on top of it, and then you have your cloud infrastructure completely as kubernetes flows.

D

So let's have a small demo. How easy it is to implement a new resource in one of our providers, so I will change to my visual studio. I think it's there. Okay in general, this is one provider here from crossplaying contribution repository it's provider, jet aws. um Let's have a short look. I said to you: we want to implement a custom type subnet group for elastic, so we open this and you see now a lot of auto generated stuff.

D

So like the types from uh parameter groups, replication group clusters, users in the elastic cache group and the specific api version- and what you want to do now is to go um implement the subnet group. We can scroll a little bit, there's a config folder and in the config folder we have provider. Go this this one and as for reasons with scaling issues with a lot of crds, we need to enable or include the resource for generation.

D

So we can do this here now, so this is at the end strings here for the resources, and then we have configurations so config elastic configo and what we see here is a configure function and what we can do now here is to add a resource to the configurator.

D

So I prepared this so you can see now here. It's also avs elastic caches up in a group. We specify now the api version in the cluster, so I pick it up from the other resources here and steven talked about external name and we're using here. Name is identifier because this is represented in the external api. So let's save this and then it's very easy.

D

We have mac, make script and steps there and we make make generate and now the resources are generated, and it also looks for all the other generated stuff here and in a few seconds we can see a new generated crd and we can apply it in the cluster. I will show you this: it takes a few seconds.

D

I can scroll there. We have here now a package folder and crds folder and they are all crds inside.

D

So it's finished now you can see there was one green thing and what we can see here now, okay, cool there's for elastic cache- is upnet group now available. As a new crd. We can apply this in my cluster, so qfccn apply the zubnet group.

D

Then the next thing we can do is to run the provider here locally, because it's now in my environment, so we have also mac run and now the provider is starting up, looks for all the crds in the cluster and start managing them and also the stuff out of it.

D

So clear keeps huge ctr get managed, so we pre-installed the vpc and two subnets, because we need subnets for subnet groups for elastic cache in aws. You can see it everything available. What we can do now cube ctl deployments, f examples: subnet group, I will show you the subnet group directly, also set it up, so you can see are using now our new rcid we created so elastic cache. Here's here you can see the version the kind, so it calls cubeco an example in reaching us west one.

D

We have a description and the magic of references are used here, so we need from the subnets not only the metadata name. We need the ideas, because aws api needs the ids to create this, and let's have a look, cube, cdna get.

D

We can have a look here.

D

So you see, the new subnet group is already choosing true. I will go in the aws console and you can see now here. The kubecon example is there, so we implemented a new resource in the controller in the provider for aws.

A

All right we'll uh finish the microphone on you, yet all right, so yeah we'll go ahead and finish up this session here. I think we just got one or two more minutes but, as we said before, you know this is a community project. It was donated to the cncf, uh so you know there's lots of opportunities to get involved with the project. uh You know if there's functionality or things that's missing, get involved. You know open issues, give us feedback, contribute, pull request, etc. uh So a great place to start is crossplan.io.

A

That's the website there and then all these other links you can basically find from there, but we're super active on slack. I mean you know, we'd love to meet more of you all and talk to more of you all. um So with that we can go ahead on into, I think, maybe one question or so and then I'll be here. I don't have a flight to catch so I'll, be here to continue talking afterwards. If you want to come up uh yes, you're right here on the first over here, the second row: oh nice.

A

Thank you so much brother.

E

Hello yeah, my question is: I'm I thought do do we have any control on on the transition between one state and the other or it's up to the provider to decide what to do, because I can imagine for some resources. You know it might be important. If I recreate or I modify like you know, those kind of decisions.

A

Yeah yeah that I'll take that yeah. So that's a good question. um You know something that I think a pattern you'll find in general is that you know much like other controllers uh in the crew radius control plane. uh You know everything running in crossplane. Is you know actively reconciling an eventual? Consistency is interesting. There uh interesting point there, so you know when certain transitions can't necessarily happen. Yet uh you know the act of reconciliation will continue to try to drive. uh You know the desired state.

A

You have in the actual state to eventually reach there if they're more complicated sequencing or you know other types of operations, I think there's uh probably some declarative ways to describe like this depends on this resource, or you know we need this value from here and once again, eventual consistency and active reconciliation will make that happen over time.

A

So you don't need to intervene, or you know be very specific with it and then, if there's further cases that, in my experience over the years so far tend to be fairly minimal, uh then there is an upcoming feature. That's going to be an alpha uh sometime soon, where you can write some. uh Let's say like imperative code to make some decisions and control the logic even further.

A

um You know right now you can write the whole thing in code if you really wanted to to make sure exactly what you wanted to do is possible, but then otherwise, declarative stuff, and only when you need to pop into code then implement it in code.

A

Awesome, uh let's do a quick time check yep. So that is all the time, but I'll be right here to keep talking. If you want any more questions and thank you so much for everybody for the whole kubecon week, I'd say thanks.