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

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cluster API Intro and Deep Dive - Yuvaraj Balaji Rao Kakaraparthi & Vince Prignano, VMware

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.

Cluster API Intro and Deep Dive - Yuvaraj Balaji Rao Kakaraparthi & Vince Prignano, VMware

The Cluster Lifecycle SIG is the Special Interest Group that is responsible for building the user experience for deploying and upgrading Kubernetes clusters. Our mission is examining how we should change Kubernetes to make it easier to operate. In this deep dive, we will examine how Cluster API simplifies the cluster management experience for cluster operators by enabling consistent machine management across environments and quick stamping of Clusters using some new exciting features like ClusterClass.

A

All right, I just want to welcome you, everybody back. I literally haven't seen this crew like for a long time. It's like has been great to see so many familiar faces um and like this community has been growing so much. So it's like really we're really proud to be here. uh We actually had to switch rooms because so many actually signed up so welcome and we'll have a lot to cover um everest. Do you want to introduce yourself yep? Does this.

B

A

B

Hi uh hi everyone, I'm yuvraj, I've been working with the cappy community for about a year. I work at uh vmware.

A

Yep and I'm vince, uh I also work at vmware like and I've been with cluster api since epoch, um and this project has like seen like a lot of iterations. So, um let's start with what is cluster api? Just? Does anyone here already know what it's called? What cluster api is?

A

I see some containers over here raising their hands all right, so kubernetes hard, but managing kubernetes is even harder, changing and understanding the kubernetes apis. It's a steep learning curve and you get into a lot of these reactions like you know, I'm going to make a meme out of it, because that's what I'm going to do we're trying to solve the cluster life cycle, part of it. So this is the definition that we usually give. So we have cluster api running on kubernetes, using kubernetes itself to run other kubernetes clusters.

A

Take that in for a second now we want to focus on the creation, configuration and management.

A

On a wider level, we want to make this whole operation boring. So you know how, like you just open your browser, you just type your type a website in and it just loads.

A

I would like to have the same experience or close enough, at least to that experience, but there's a lot of stuff that runs under the hood when you do that in your browser and cluster api is like really complex as well. We have a few key principles. Extensibility is one of them. We want to make sure that, like whenever we provide defaults, you can actually swap them. That is one of our key principles.

A

We, when we design our apis, we always adhere to these things, and universe is going to go like into a lot of these later on through the demo.

A

The other key principle that we have is to focus on the 80. What that means is like we usually try to collect as many requirements and use cases as possible to really understand what the problem we're solving is because without knowing that, we don't know what to do. So. Whenever we create a new field, we create a new crd, a custom resource definition and we give it out. We make sure to like collect and like just spread out to the mailing list, slack channels whenever we can to get more and more use cases.

A

So, if you haven't done so already, please reach out.

A

So, at the end of last year, in october, cluster api became production ready. This was a major milestone for this team. It took five years to get here.

A

We publish um a blog post with cncf and I'll go into some of the quotes, but I want to stop here for a second. Our best feature is actually the community. That's behind it, there's a huge bunch of folks that are like so kind so welcoming that, like I'm, really proud to be here and to be serving this community.

A

This is the blog post. Please check it out. You just type cncf cluster api, 1.0 and you'll see a bunch of quotes. The reason I'm focusing on this right now is that we have so many end users that use cluster api in production today.

A

So, for example, twilio has a whole team building on cluster api.

A

I won't go into all the quotes like there are on the website. If you want to do that later, but they run a hundred plus production clusters giant swarm, they went all in on cluster api, like a few years back and they're back in the community as well spectro cloud, a heavy user of cluster api tal systems, they have a custom bootstrap provider for cluster api. That's where you know like the battery's included, but swappable.

A

We have cubed em entry, but they built their own provider. So we literally also like are welcoming in our apis. In some ways.

A

New relic has a whole team dedicated to cluster api, they're they're using and building on top of it internally red hat same thing: they use a bunch of the apis that we have today and we expose.

A

Dutch telecom, it's a huge huge company, that's using cluster api. They have done a demo a year or so ago on how their deployments really complex. It's on our youtube channel. Please go check it out. It's really really cool the u.s army. Software factory is using cluster api in production. Today, that's that's something right. It's like the u.s army is using cluster api.

A

I didn't know that until like we actually published the 1.0 release, azure is deeply deeply involved. We have the cap z, cluster api azure provider. That focuses like on, provided like a great experience on for culture api for all their customers.

A

Amazon, eks anywhere is also built on top of cluster api d2iq samsung sds uses cluster api in their production clusters. Sk telecom uses cluster api as well and they're like a hybrid cloud company, and they have like a massive deployment of flush api mercedes-benz. You probably have seen the talk like about the 700 cluster that were moved.

A

We have a few people here actually from mercedes uh you've, seen probably in the keynote they're also using cluster api, and it has been like a great experience at the end. Also vmware is using cluster api, as you might all know like we have a great team focused on on building the best we can.

A

There is a few links here. Unlike all the docks about cluster api, the nodes will be published online later, so please check them out the really great talks. um I think the other one was actually overflowing so definitely check out the video later eubarrage.

B

Hi so we've seen how good cluster api is and how the community is going growing. So, let's take a closer look at. How does it work? How does cluster api work well, it looks like class api is doing magic, let's go under the hood and actually see how how that magic happens.

B

So, in cluster api we have this concept of a management cluster which is responsible for creating and operating a fleet of workload clusters. So workload clusters is where we will deploy our workloads like our kubernetes workloads and the management cluster can be any kubernetes cluster as long as it is conformant. So it could be your local kind cluster.

B

It could be a cluster on any of the managed services like aks eks or it could be another clustered api created cluster, and the important thing to note here is that the same management cluster is creating and operating clusters across clouds and across various providers. At the same time, so you can have an aws cluster, a gcp cluster, an azure cluster, all managed by a single point, the management cluster.

B

So the users have to only interact with the management cluster, of course through yaml, because kubernetes and and and you can have a fleet of clusters managed by a single point. So let's take a closer look at what is inside the management cluster. What makes up the management cluster, so you heard the word providers a few times right now.

B

So in cluster api we have four kinds of providers: the core provider, the infrastructure provider, the control plane provider and the bootstrap provider, and these providers extend the kubernetes api using custom resource definitions commonly referred to as crds, and they come with their own crd definitions and also controllers. So the reconcilers, as you probably already know, are responsible for maintaining the state between what's actually present and what is the desired state right, so the core providers that we have as part of the core providers.

B

We ship some definitions like the cluster definition, the machine deployment definition, the machine set and machines, the infrastructure provider is the connector in between that is responsible for interacting with the cloud right. So, for example, if you have an aws provider, it will be it'll know. It'll it'll know how to interact with the aws apis for us to be able to do cluster abi things, and then we have a control, plane provider which is responsible for initializing, our control plane, bringing up bootstrapping and all of those things.

B

And then we have a bootstrap provider which is responsible for bootstrapping other worker nodes into our kubernetes cluster.

B

So let's take a closer look at how all of these crds are work in relation with each other, so that we get a better idea of how cluster api operates on some of these new types. So this is a rough tree on the dependencies between the objects that we just saw. The crds that we just saw so at the top left. You can see the cluster definition.

B

So that's the kind of like the root of the whole idea and the cluster definition generally holds specifications that are environment, agnostic and it is responsible for maintaining the cluster's life cycle, so environment, agnostic configurations like the pod and the service siders and the dns domains. Those go into the class definition.

B

Some of you might have observed the topology section. With the comments saying this is an alpha feature we'll go more into that in a bit uh in a bit. It's really interesting. So keep that in mind uh next followed by that is the infrastructure cluster, so infrastructure class examples for infrastructure cluster, involve the aws cluster, the azure cluster, the gcp cluster. You can have bare metal, bare metal, cluster instances and so on. So these generally contain the specification involved for the specific cloud provider.

B

So, for example, the aws cluster will have configurations on which region you want your cluster to spin up in what ssh key, should it use and so on then comes the control plane, the most common control plane, at least the one that we ship with capi is the cubedium based control plane. So in the spec you will see that the kuberium configuration is part of the spec, like the init configuration, the the init configuration, the joint configuration and so on and in the control plane spec.

B

You will also see that there is a reference to the machine deployment machine spec, which is used to define how the underlying machine for those control planes is supposed to look like, and it also has a replicas so that we can scale up and scale on our control planes and also the kubernetes version that we care about.

B

Next is the machine deployment. So now that we have our control plane defined, we need something to define our machine deployments which basically make up our work nodes. So machine deployment to machines is very similar to the kubernetes deployment to points a deployment in kubernetes represents a collection of parts that are all kind of similar and emission deployment is exactly the same.

B

A machine deployment represents a collection of machines that are exactly similar, that you can scale up scale down, and you have a version that you can specify the kubernetes version that you can specify so which makes up the kubernetes version of the eventual target workload cluster.

B

So with that, let's check out what's new in the project right now. So, as vince mentioned, we just hit the v1 milestone release and with that we shipped our v1 beta 1 apis, which is huge and special thanks to all the contributors who helped us get to this big milestone.

B

Next, we have a huge ux improvement, called cluster class and manage topologies. We'll talk about that in a bit. uh It is. It is designed to improve how we, how our end user interacts with cluster api, as you just saw. We have to deal with the tree of objects right now to interact with class api and manage your target cluster so with cluster class and manage topologies that improves, and you don't have to deal with a big surface as before.

B

So we'll take a closer look at that and with, and we also introduce ignition support for bootstrapping and also flat car os cluster cuttle, which is our cli that is used to interact with and bootstrap. Our cluster api uh is now available on windows, and we also have arm support for it, and our provider community is growing uh by a lot. These are just some of the new providers that join at the moment. I think we have around 30 plus provider support for class database, so that's a huge community right now.

B

Cluster has managed topologies. So eventually our goal is to create the tree that we see on the right right, but cluster class has this idea that we just want to define the structure of a cluster at the topology of our cluster once and just reuse it across multiple clusters, so that we just have one object, called the cluster object in which we'll have a topology section, which they can then be used to stamp out clusters that are look the same multiple times right.

B

So that would look something like this, so we just have a cluster object at that point which which all reference the same cluster class and then by changing the values in the managed topology, you can spin out multiple clusters, which kind of looks same but are but are different in their own way.

B

Let's take a look at the cluster class and manage topology's demo to better understand it. uh Let's see cool okay, so I have a kind cluster in my local.

B

I have a kind cluster in my local I'm going to use this as my management cluster. It's already been initialized so that it becomes the management cluster and, as you can see, we have the multiple. We have the different kinds of providers already installed on this kind cluster. So we have the core provider, we have a control, plane provider, we have a bootstrap provider and we have like two infrastructure providers.

B

I also have like two cluster classes installed here right now, so one is called the demo, uh the docker demo class and one's called the aws demo class. I know very interesting names, so let's just take a look at the docker demo class right now. uh If you look at the docker demo class, it has a section for how the control plane is supposed to look like and it just references some control plane templates like the qbm control, plane template.

B

It has a section for how the underlying infrastructure cluster is supposed to look like, and it has sections on how the worker machines should how the worker deployments should look like, and all the templates that are referenced in cluster class are also defined within the same yaml file but yeah. So cluster class is just a collection of templates. It doesn't do anything by itself and now, let's take a look at a cluster object that is using this cluster class. So if you look at a clustered object, I have a docker cluster object here.

B

You can see that it has the topology section that we saw before in which it specifies. Okay. I want to use, I want to create a cluster that is based out of the docker demo cluster class right, so the docker demo cluster class already has information on how the underlying infrastructure is supposed to look like like what what templates am I supposed to use while creating the underlying infrastructure? So we just have additional configuration on top of it that most users will care about which is like how many replicas of the control plane do.

B

I want like what labels do. I want to apply on my control plane machines. Similarly, how many replicas of my worker machines do I want, and what labels do. I want to apply and stuff like that and the most important thing we just have like one place where we can define the kubernetes version, so just define it there and you can guarantee that cluster api will propagate the version across and you can you can.

B

uh You can relax and don't have to worry about upgrades, in fact, we'll actually try to do an upgrade and see how that works.

B

So, for the purposes of this demo, I will be using I'll be creating target clusters which are based on docker so that they are quicker. So, let's just create one.

B

So I just created a docker cluster, so if you look at it, so we have the docker cluster created the cluster object created. We have the docker cluster created, we have the control, plane, object created and we we have the machine deployments created. So uh you can see uh so the three watch. I have three watches here right now. The first one is watching the control plane, so they can see that it's actually rolling out.

B

The second one is the watcher on the machine deployments and I also have a section for the kubernetes version just so that we can actually use that while we do an upgrade and the third one is just a watcher on the machines and perfect timing, so the first machine is trying to come up which will be part of our control plane and as soon as the control planes machines come up, the control plate is then considered ready, and once that is done, the machine deployments machines are going to come up and then the machine deployments will also join the control plane and the cluster should be ready at that point.

B

So the machine deployments machines are also going coming up and uh I'm cheating a little bit here. There is something called cluster resource definition within cluster api. You can look it up later and just using that to install the cni so that I don't I don't have to install it by hand right now,.

B

So, as I was saying so, while while this is getting created, uh I can show you that we also have a second cluster definition, which is called the second class docker cluster 2, fancy name, which is using the same class as we saw before, uh but right now it's it's changing the uh topology of the cluster target cluster a little so it introduces a control plane with the same version, but it now has a second machine deployment section which has like additional labels that you can use to that.

B

You can use on your target clusters and then, which could be important like, for example, you want a gpu marker to identify the machines that are that that are based on uh that have like gpu support and so on. So if you go back yeah, so our kcp is ready. Our our machine deployments are ready, so everything's ready um now, let's try and actually upgrade the cluster. So we are on version 123.4.

B

Now, let's upgrade it to one 123.3, let's upgrade it to 123.4. So, as we mentioned before, the goal with the sig is to make cluster life cycle management as boring as possible. And what could be more boring than editing a yaml file right.

B

So this is the cluster definition for the docker cluster that we just created. So if we just change the version here.

B

And that is it, so we just triggered an upgrade for our cluster. You can see that the control plane has picked up the new version, the 123.4 and it started reconciling so that the control plane machines now switch over to 1234, so the first machine, the first machine for the control plane at version, 123 4, is being created the second and once that is provisioned the second mission, the machine that's already at 123.3- will go down and then the process will start with the machine deployments right now. This upgrade is phased.

B

What that means is only after the control plane is successfully upgraded. Will it start uh phasing down the upgrades to the machine deployments and if you have multiple machine deployments it'll, do it one at a time.

B

And that's the demo uh for now.

A

What's next, all right wasn't that awesome, though,.

A

So um if you look at the 2019 deep dive and this one they're completely different, like the user experience and ease of use, that's what we're focusing on today and we will keep doing that in the future.

A

One of our goals is to make sure that cluster api is as accessible as possible that you can use it like in a number of places. So, right now, like you know, we have edited like a bunch of yaml. But what, if I want to do that in a ui? What if I want to do that easily through a ci deployment, we need definitely like, for example, better get off integration and that's what we'll be working on like for the next year or so.

A

The next level that we want to integrate with is operating systems and bootstrap integration. We have seen batteries included, as in like we ship cluster api, with the cube with cube dm, we want to go even further and make sure the cube. Rdm is exposing the machine in the fullness of time, we'll have like the whole configuration in there so that you can change it and potentially also like deploy those changes on the fly, but I'll get to that in a second and the on the os level.

A

We want to understand like how better integrate cluster api with the operating system, so something that, like we cannot do today unless you build your own images, is upgrade the operating system. This is a hot topic we have heard like so much. Feedback for bare metal and edge folks want to run kubernetes both on bare metal and edge, and they share a lot of commonalities. Edge like you, can just see it as a shrink down version, a more limited version of bare metal at the end of the day, we're not there.

A

Yet we have some bare metal providers. We need to do better and the edge it's like a tough story to sell, so we want to do better in this areas and, like I urge you to look at like some of the proposals that will be coming up and there are already up like in the in the cluster api ecosystem.

A

There are some proposals that are already up: um runtime, sdk, add-on management, add-on management is uh kind of needed soon that the the cpi csi integrations, are getting out of kubernetes cluster api is kind of like going to do the bulk of the work to make sure that, like one, we will have like a smooth migration, but also we'll keep upgrading those uh components when we upgrade kubernetes itself.

A

The other one is then extended: integration with managed kubernetes, so eks, aks, gke, and so on. The auto scaling folks from red hat like have been working on the uh from and two zero proposals, so that you can auto scale your pools of nodes automatically and then certificate rotation. This is something has been on the roadmap for a while, but it's 100 needed to make sure that, like your worker nodes, so your cubelets and all and and the api server will keep working.

A

So, um there's a huge road map on like on in in front of us. I mentioned, like the user experience, something that like we want to do, for example, with the github story and the bootstrapping story, we've seen that yuvraj had already a cluster running, so he kind of cheated a little and he admitted it too.

A

It's um if you look at our quick start, it's still hard to spin up kubernetes clusters. Today we want to go even further than that. We want to be able to with one command to just create a kubernetes cluster to go from zero to kubernetes and then the upgrade story. That was simple, but we need to do also better than than that like in, for example like when you upgrade, and things don't go as smoothly as we saw before, you might need to back up and restore your cluster.

A

What if there is a disaster recovery scenario like we are thinking about like, for example like, should we snapshot clusters, the workload clusters, and how do we go about it? Restoring those those those clusters after a disaster, recovery scenario has happened.

A

So I mentioned before too that, like the the best feature that we have is the community and like, I would urge you to get involved any skills you have it's okay, like we'll, have something to do for you.

A

If you have writing skills like our book, quick start, architectural diagrams, we'll need that for sure product skills we need to get better and like understanding like for the user experience across many components, coding skills, we have a lot of pull requests open right now that need to review and a lot of things like that are marked as either good first issues or help wanted there's links in here, um so you can just check them out and reach out to us, like in any of the kubernetes slack channels, we're very active, and we respond to questions like in a timely manner.

A

Last thing we have weekly community meetings, we're also like a look at the mailing list. So if you join the mailing list, you will also receive the invite for the cluster api meeting.

A

I think we have a few minutes for demo, but this is cluster api. Thank you.

A

You have any questions.

A

Sorry one thing.

C

Can I have one cluster using two different providers like vms and bare metal? Can you repeat the question for what yeah.

A

One cluster using two different providers, uh no, like I said like it, has been untested like if you try that like and it works, that's great um technically, if you have network connectivity between the cluster could be possible, but it's definitely challenging okay,.

C

I understand thank you and one more thing. If, uh for example, I have uh metal cube as a bar metal as provider, can I use kuvert to create another layer of provider like vms, like stacked providers.

A

um I would say: yes, you could uh cubevert is still in early staging right now, as our provider. um I think some folks from apple are actually pushing it, but they have a slack channel as well, so I would reach out to them. Thank you.

D

Hi, um I have a question about multi accounts. So if you support multiple providers, for example gcp, but is it a problem to have clusters managed from one management clusters via in different aws accounts? So, for example, I don't know 10 and 10 aws accounts and one workload cluster in every aws account.

A

What is the question uh multiple aws accounts is that the question uh it's 100 possible. uh You can uh like pretty much like push multiple credentials to the kappa controller, the aws provider, or you can also like make them assume roles. So as long as like they have the ability to do so, you can 100 do that.

E

I have a question: we are heavy users of sport instances at our company. So what's the current support for like having custom configurations for running worker nodes with sport instances.

A

um Is anybody from mws here? Yes, yes, we do have support for it. I do remember seeing prs like a while back, so it seems like that you can. In the aws machine template, you should be able to set the spot price. If I don't know correctly. Yes,.

A

Go to richard for more aws questions.

F

Hello, so I have two questions one: how do you handle like uh node upgrades? Like the version? Do you have some some way to drain the nodes before rotating them, and the second question is: how do you handle drift? So if I make a change manually into a eks configuration, how do you reconcile that.

B

For no no drains yeah, we do have configurations that we can set up for no dream time, timeouts and so on and sorry what was the second question.

A

F

Handling drift, so if you make a change manually, for example in an eks cluster, how do you import that change into cluster api? If you want to.

A

So um that it depends uh like so like for eks, specifically, if you do a change like it would cluster api thinks it's the ultimate authority so like it will overwrite your change.

A

A few more questions over here think they're. In back there mike's back.

G

So I was wondering if you were thinking of having a provider for terraform. The reason why I'm asking is because I feel like it would be easier for many people to migrate towards cluster api, since it's kind of a use case to use terraform in the first place to currently provision the apps. Secondly, as you mentioned, there's still some providers that you do not support yet, for example, some on promise provider right that could already have integration in terraform.

G

So I feel like first of all, it could automatically add towards the providers and also be ease of use when it comes to migration.

A

B

So uh for cluster api, as we mentioned, it is uh all most of the components except for the core cluster provider. Components are swappable, so it should be possible for you to write a provider for any of the scenario that you want, and we just had a talk before this on how you can write your own provider that works with cluster api so and the community of the providers that we have right now is growing.

B

So if we don't have a provider support for uh infrastructure right now, it might be added by someone later or you are more than welcome to contribute and the community is more than welcome to contribute and create a new provider that everyone would benefit from.

A

uh One thing that I add for terraform, specifically or other infrastructure as code price, like it, has come up before it's like hey. I want to manage my infrastructure with this other tool, but then I want plus repair to integrate with it. uh There are some talks about it right now, so if you do have use cases like please like do reach out, uh because those are really good. You know it's like we need those more.

A

I think there are a few hands over here.

H

I came in a little bit late, so I don't know if you covered this, but I see you have a rolling upgrade support already and you can define the max search and you know have uh additional nodes available. That way. Is there any plans for any in-place upgrade kind of things.

A

Yes, uh actually it was in the plan to actually talk about it a little bit, but um it's very early. We are exploring some ideas to do in-place upgrades um the problem is that like right now uh we just delete the machine and recreate it, but, for example, for things like edge, you can't delete an edge node, because that's the only node you have so we are exploring like a way to kind of like roll those upgrades in place by using some sort of node agent, uh but how that would work like that?

A

It's still like you know, exploring okay thanks.

B

I think that was a question.

I

Hey thank you for the talk, so I have just have two questions. So is downgrade possible. um No okay,.

B

um Right now, it's blocked by our web book. So even if you try to downgrade cluster would throw a warning saying: downgrade is prohibited.

I

And how rollback is handled so if you have done an upgrade and there is workload um on the clusters, um but it for some reason the upgrade failed. So how is going to how cluster api handles the rollback? I can do a bucket okay.

A

Yeah, so um for a number of reasons we don't do rollbacks, um one of which is like let's say that you upgrade the first control plane nodes and that one fails, but some of the upgrade went through so, for example like if there's a new lcd version, scd gets gets updated um and then you try to roll back. They will be like the the older api server might expect something that scd doesn't.

A

You know has changed um so for these reasons like we prefer usually to to understand why the upgrade was blocked, and usually it's like something like I don't know like, for example, network containing it was lost or, like you just have to retry, because the machine has gone bad or there is misconfiguration um in our experience like we, we try to make upgrades as safe as possible, so we don't proceed even like with the first machine, if, like all the set of health checks are, are okay.

A

So, like we check at cd, it's like all the member healthy. We check the api server controller manager, all of those components of the api server before doing any action. um I know it's like not a great answer for rollbacks, but rollback's like it just gets in too many use cases that, like we're just not ready to support.

A

Are there any other couple, a couple more hints.

E

um Is there a way to kind of um specify versions for the cluster classes like if I want to you know test some upgrade? Is it possible to do that rebase so.

B

The question was: if you can version your cluster classes or.

E

You can specify the version that you want to use when upgrading I mean if you want to roll out or just test a change in your cluster class. Maybe you can try to uh I mean because if you upgrade the cluster class, that will actually upgrade all the clusters. So if it's possible to version.

B

uh So if you want to, uh I think it was designed on purpose so that if you change the cluster, changing one cluster class will have, as you said, ripple effects on a lot of clusters. So it's a who, whoever is doing that, has to like really we make sure that it doesn't ripple effect and create uh problems with the clusters. So cluster class right now doesn't support. uh We don't allow cluster class to define like the kubernetes version within it. uh That version needs to be specified within the cluster object.

B

But if you are talking about other kinds of configurations like let's say the underlying machine type or something that needs to be changed across clusters right those need those can be defined in cluster class. But again you have to be really careful when you are rolling out those kinds of changes and to help with that. There is something called inline patches in cluster class, so you can still do small changes on top of your cluster, which which are all sharing the same cluster class so that one cluster could use. Let's say an aws machine.

B

uh Small and the other cluster could use an aws machine large, even though both of them are based on the same cluster class.

A

So some so we don't have versions like for cluster class itself. um You could copy the cluster class and then change the cluster cost on a small set of clusters. So you could build on top of it to achieve that.

J

Hello, thank you first, uh I would like to know the upgrades uh goes like one by um by one minor or change uh update uh per time. By my time.

A

A

Any other questions before.

C

K

Hi, thank you for the presentation. I have a question. We currently have our clusters deployed with terraform and also some vast scripts, and we have achieved a point where we just write a terraform type state with a url to a git repository for flags, and we just run the terraform and it will also deploy flags for us and then flags will deploy everything else. It's something like that possible with cluster api.

A

uh So the question was like you: have terraformer influx and terraform, deploy flux and then deploys the cluster. Exactly um I mean the answer is like. I wouldn't suggest it today, because we have a lot of. um We need to improve the get ops experience uh like we have a lot of machinery inside of our cli today, with that we need to move server side, um but if you just stick to one version, it's technically possible to achieve what you just said.

K

Okay, thank you.

A

All right we're good all right, perfect! Thank you. So much.