Cloud Native Computing Foundation Crossplane Community Day EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How to Build Your Own PaaS from the Cloud Native Landscape - Jared Watts, Upbound

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.

How to Build Your Own PaaS from the Cloud Native Landscape - Jared Watts, Upbound

As the CNCF showed us in a preceding talk, the Cloud Native Landscape is growing fast and now has so many projects and options that end users are having trouble making sense of it all. The end user community would greatly benefit from an effort to turn these cloud native “ingredients” into “recipes”. In this talk, Jared Watts (co-creator of Crossplane) will take us on a deep dive of the technology, design, and implementation of cloud native “solutions” based on Crossplane. This talk builds on the introduction and perspective provided by the CNCF on the need for cloud native recipes, and brings those ideas to life with a practical walkthrough and demonstration.

A

Hey everybody, my name is jared watts and I'm a founding engineer here at upbound and a co-creator and maintainer on the crossplane project and we're going to talk about how you can build your own platform as a service from all the components in the cloud native landscape. So speaking of the landscape, it's pretty big. There are a lot of entries and a lot of projects in it.

A

People have found some humor in this and uh in recent months somebody actually made a thousand piece puzzle out of the landscape and it sold out that etsy link will show you where, where it was, but it's no longer for sale, because it's sold out it's pretty popular, there's a lot of stuff going on in this landscape right. We see what uh what happened to old, charlie here when he tried to make sense of the landscape.

A

So let's do a little bit better than charlie did let's start making some sense of all of the sprawl in this landscape. So the cncf itself says that complexity is the number one user reported issue in the ecosystem. It's been that way for a number of years.

A

So that's a recurring theme, so one way that we can help out here is that we can start composing these entries in the landscape, together into higher level solutions right turn these ingredients into recipes, and so what we're going to do today is just that: we're going to build our own cloud native platform as a service, and it's going to empower our developers to run their applications um with a rich platform underneath them of all these great projects from the landscape.

A

So we're going to make some sense of of all that into a nice platform, uh we're going to put some best practices, some operational wisdom into it, and then we're going to be able to share it and collaborate on it as well too. um What we're building here today is a starting point, and it's just one opinionated platform right out of that landscape.

A

You could build a number of them, I'm pretty sure so we're just gonna start with one today, and then we can use that as a starting point uh to collaborate in the ecosystem and keep building.

A

So, let's do a quick refresher on how you can build your own custom platform using crossplane. So basically, we can assemble together low-level granular resources from multiple vendors clouds environments, and then we can expose those as a higher level abstraction to our application teams that serves as an api for them to be able to self-service and get the infrastructure they need. So to make a more tangible example, we can compose together.

A

You know gke node, pool network sub network, a bunch of gcp resources and then also some helm charts as well too for our platform, services and projects and compose those all into a single cluster object. That is basically an abstraction of what it means to be a cluster and that cluster object is going to have a small set of config for our developers, so they can tweak what they need to and then all the complexity and the details and policy and all that sort of stuff is actually going to be hidden away from them.

A

That's going to be underneath this simple api line that we're building for them all. This is going to be done with the kubernetes api. So it's going to be compatible with anything that talks kubernetes, basically and we're not going to have to write any code to do this either. This is all going to be declarative.

A

A little visualization for this here uh is that our application developers all they'll see is the cluster object, this api, that we've surfaced for them with some simple configuration and then behind that api line, we can have multiple compositions to fulfill what it means to be a cluster. So in this example, here we've got one for aws. We've got one for gcp with all the specific uh cloud resources that um make up a cluster within those particular environments, but it doesn't have to be a you know, multiple clouds for our compositions.

A

It could be all within one cloud and it could be something like uh fast or slow, expensive or cheap gold or silver doesn't matter. uh We could have multiple compositions that serve as the runtime definition for what a cluster means for our application developers.

A

So, let's talk about what are we going to put into this platform as a service we're building from the cloud native landscape? Well, we're definitely going to start with kubernetes, because we're going to need a container orchestrator uh cluster to run our apps and our workloads and so building on that we're gonna also put prometheus in there. So we can do monitoring and collecting metrics from all of our microservices and then alerting when things go wrong as well too. Yeager is going to be useful for distributed tracing.

A

uh It will give us insight into all of the complicated interactions between the microservices in our distributed system here and find out when things are going wrong as well too. Fluid d will be helpful for our logging. You know consolidating all of our logging, that's being output from our services, rook we're going to be putting in there as well too for storage. So you know: rook provides a persistent block file and object storage.

A

So if a application needs a volume to write to our file system, then it can get it for brooke and then, lastly, we're going to put flux in there as well too. So we can connect our git repos with our cluster there and do continuous deployments of our applications from the git repo using get ops into our cluster here to keep our applications up to date, as developers are making changes.

A

Here's a architectural system diagram that kind of puts us all together.

A

So remember we were looking at our cluster object that our developer will be able to configure and have a simple api with, and then, when that cluster object is created, crossland's going to take a look at it, it's going to render out all the compositions that we've defined and then the providers in crossplane will actually be talking to your external apis and making this system happen uh out in the real world, so provider gcp will be talking to google cloud and it will be creating the network, the node pool sub network, the gke cluster itself and then provider helm will also be taking a look at all of the composed resources that came out from our high level cluster abstraction, and it's going to be deploying all these helm, charts for prometheus and jager, etc into a namespace inside the gke cluster, the operator's namespace and then.

A

Lastly, flux is running inside the operator's namespace. There, too, is going to be connected up to github, to be looking for changes in github and be using continuous delivery to take the application from github and put it into some namespaces inside of our cluster as well too, so that we'll have positive deployments that are running that make up our workloads.

A

Let's start designing the shape of this cluster object, this platform api that we're putting together for our developers what sort of config knobs do we want to give to them to allow them to be able to tweak and configure to their liking. So some things that might be interesting is some characteristics of the workload cluster itself. You know how many nodes it has, what type of machines are going to be making up this cluster?

A

We're probably going to also care about what versions of the platform services they might depend on, and also we're definitely going to care about. What is the git repository that we want to run continuous deployment from, and so we can start thinking of an api here that exposes these knobs for the developers to set and tweak, and so we see here we can specify the count of nodes and then the size of the nodes that we want. Note.

A

This isn't a specific machine type, because this is going to be a universal api for multiple vendors, so we're kind of extracting it into a small, medium large type of format. Then we've got the versions for these services in the cluster and then what github url to be syncing from and note to that. We're probably going to want some policy here uh underneath the api line, because you don't want to just let your developers specify willy-nilly how many nodes in the cluster you want to put some upper bounds on it too.

A

So we're going to need some policy underneath our api line as well too.

A

So here's another kind of diagram of the composition hierarchy really so starting at the top there. You know the developer. All they interact with is a simple cluster object, right, they're, making a claim on a cluster and then beneath the api line. Here's this whole hierarchy of composite resources and compositions that compose them.

A

So we can see here that underneath of the api line, there there's a cluster composite resource and then there's two different compositions that we can be looking at here, one for gcp that is made up of yet more composite resources, a gke one and a services composite resource and underneath those there's more compositions of lower level resources.

A

So the gcp resources we'll see there, the helm, charts for the various landscape projects, we'll see there as well too. So we can see this hierarchy of composite resources and compositions underneath them that put all together make up the entire platform that we're building. We see that all that complexity is yet again underneath the api line, and then the developer doesn't have to worry about that.

A

So let's also talk about. How are we going to get configuration from the developer from this simple cluster object down into this composition hierarchy so that the leaf resources, the granular low-level resources, can get the composition or sorry the configuration that they need as well too. So we see here that we expose, you know the size and node count for the cluster to the developer in our cluster object, and so we can take that from the developers.

A

Object we'll take uh the size and we will patch that down on into the particular gke uh managed resource, a low level resource and note here now that um small, medium large doesn't mean anything to gke. So we were making a transformation of developers configuration into something more specific for gke.

A

We do something similar to for aws as well too, but they're different, specific aws, specific machine types, but basically we're taking small medium large we're mapping that to a specific set of machine types in gke and basically getting our developers intent down into our compositions and into the real world as well too.

A

Similar thing can be done for the node count where we will set that on the you know, number of nodes in the cluster and the auto scaling properties as well too, and this is exactly where we'd want to apply more policy, um something like open policy agent to specify hey developers. You can't set a higher node count than 10, or something like that, so they can't go. Go too high with the node count, so policy being configured into this.

A

These patches in these compositions is very important too one more patch to look at is how do we get our uh continuous deployments uh platform services configuration down into those helm charts as well too, in our compositional hierarchy? So we can see a very similar pattern here. We've got some defaults defined for let's say the flux home chart, but then we're going to patch in everything that comes from our developers, cluster object as well too, the versions and the git repository url.

A

They set we're going to take those from their developer cluster object and patch those down through to the underlying helm charts in our compositions, so that those get reflected into the real world instance that we're bringing up for them as well too.

A

So a quick reminder as well that we're looking uh in deeper into some of the complexity here, but that's all beneath the api line right. This is something for the platform team or the infrastructure owners to worry about, and the developers still focus on the high level.

A

Simple object: simple api that we're exposing to them with a small set of config knobs for them to turn into tweak, and that's all that they have to deal with that compositional hierarchy and patching and all those things are only something that the infrastructure team and the platform team is going to have to worry about. The developers get to have a simple focus still.

A

All right, so, let's hop into the demo now and see all this running together on a you know: live practical system, okay! So let's get this kicked off by starting on the upbound cloud registry, because we have made this cloud native reference platform and it's available in the upbound cloud registry, and so we're going to start from here to get it running.

A

So I'm going to go ahead and just run this in upbound cloud uh so that you know I don't have a crossband instance running right now, so I can just create one on demand here to run this demonstration uh with a crossplane instance. That's in outbound cloud, so that's going to get, kicked off and created a cross main instance for me.

A

Okay, now that my crossman instance is ready in outbound cloud, the cloud native reference platform was installed into it automatically, along with all of its dependencies as well too. So we're ready to get started with this thing.

A

So in my cloud native reference platform here, I'm going to go ahead and connect to the command line and start showing some things there as well too.

A

All right so on the command prompt here, let's start examining what is in our platform that we brought up. So let's take a quick look at the packages that are installed just to make sure everything's on there. We installed our cloud native reference platform there and they brought in dependencies of provider gcp and provider helm. So those are all there ready to go and then also included in that that platform that we installed here it would be the xrds as well to our composite resource definitions.

A

So you can see here now that we have a cluster object and one for gke and services as well too. So those are all look to be ready to go and ready to consume. So, let's take a quick look, then at what we're going to actually create here, so I'm going to create now I'm the developer. My infrastructure platform team has installed everything for me and everything's ready to go and as a developer, I want to get a cluster now.

A

So here is a cluster claim that I'm going to go ahead and create as the developer and we're we've seen this in the slides. Before, where we're going to create one node, it's going to be a small one, and these are all the versions of the platform services that I want and then note I'm pointing specifically at my uh git repository to do the continuous deployment from so that's what we're going to apply now.

A

So let's go ahead uh and apply the same file there, so that gets kicked off and then underneath now cross plane is going to see that we have requested a cluster and all that machinery for the compositions and the composite resource definitions that our platform seem to find that's kicking into gear now. So we can see here that we've got a uh cluster composite resource created now and it's uh not gonna.

A

It's not gonna be ready right away because underneath it there's going to be a lot of infrastructure that is getting brought up in google cloud now, so I'm getting all the managed resources, uh which means all the basically all the services in google cloud. So in response to requesting a cluster, a cloud native platform cluster, I'm now getting a gte, I'm getting node pool, subnetwork network, etc.

A

So all that stuff is kicking off now and installing, and then the helm charts for all of our platform services, our jager, our fluency flux, all that stuff is now actively being reconciled in the actual state is being driven uh to match the desired state that I've requested, and all this is happening right now.

A

All right, let's check in on our deployment and see how things are going now. It looks like all the gcp infrastructure is up see they are already true. So all of our cluster and network and everything is looks like it's ready to go unhappy.

A

Let's also take a look at the platform services that we deployed as well to so.

A

Yes, our jaeger, our prometheus fluentd, all that stuff it looks like they are ready, also and deployed out to the workload cluster and gke that we brought up. So it looks like everything should be about done here. um One other thing to look at is that I have a separate cube config to connect to that remote workload. Cluster we brought up. I just got the cube config from the connection secret, that crossplane uh saved for me from after it completed provisioning the cluster.

A

So if we look at the operator's namespace in that workload cluster that we brought up in gke, we can see that all the operators for yeager and fluentd and uh everybody and rook down here they all look to be running and uh this one's a job so that one completed okay.

A

I think, and so everybody's ready and running so I think the platform is ready to go, so we can now start putting our application into this workload cluster that we brought up from our platform app in order to start getting our applications deployed to that workload. Cluster using flux- let's jump over here to uh my my repo- that has a couple different applications in it that I forked from uh flux's example upstream. So we can see here that we've got um a ghost, blog and and redis. uh You know database and caching as well too.

A

So these are the um components that we would expect through flux's continuous deployment to be syncing from this github repo into that workload. Cluster that we showed you so one thing I need to do to make that finally connected here is that I need to add my deploy key to the um to the repo here so that the identity that flux uses will be um accepted by github to let it access this repo and to start um deploying the applications, the redis, the the ghost blog from this repo into the workload cluster.

A

So we've added the deployment key now and let's go check on the workloads inside the cluster, all right so back at the command prompt here, we're going to run a cube control command to connect to the workload cluster, that's in gke and then we're going to get the uh the helm releases from flux, the ones that it's syncing from the github repository down into this cluster here and we're going to see that excellent uh looks like ghost, mongodb and redis were successfully grabbed from the github repository using continuous deployment to get them into this workload cluster.

A

So it looks like everything is pretty much completed. Now, where we've deployed our cloud data platform, we have gotten the infrastructure provisioned through a simple cluster object that is developer was able to tweak a couple config settings on. We got all this complicated machinery, and you know a full cloud native platform brought up for us on demand, and then we were able to start using continuous deployments and a lot of these operator platform services inside of our workload cluster, to start getting our applications up and running and being able to use some of those services.

A

As well too, that our platform team provided for us- okay, let's wrap this up with some conclusions now, uh basically not everyone's going to be an expert on the cloud native landscape. So let's take this expertise of knowledge and consolidate it to our platform team. You know they can go through the efforts of you know, making sense of the sprawling landscape and they'll define a platform for our developers and all of our app teams will get to benefit down the road from their efforts.

A

um You know, they'll be able to write their apps focus on their business logic and they'll get all that great functionality right out of the box from this platform we've designed. So basically we can now with crossplane we can make a an opinionated platform of our own. We can design apis for our developers to get their needs serviced, and today we made one that was a cloud native environment with all the fixings in it right, and so we can also share this with the ecosystem.

A

um We've done that here today, uh there's a link to the github repo that has this cloud native reference platform in it, and so you can use it directly or you can use it as a starting point to start tweaking and building your own cloud native platform um or platforms in general, because there's a lot of good content in there to help you get started on that journey.

A

You know building your own platform apis with crossplane. So thank you so much for attending and I think we're going to get into some questions now.