 It's so great to see so many of you new faces familiar faces all in 3D. Let's start with some introductions. So I'm Cecil Robert Michel. I'm a software engineer at Microsoft. I live in Seattle and I've been involved in sick cluster life cycle for about three years now, but who's counting? I'm a maintainer of several projects include including cluster API cluster API provider Azure and image builder. Hello everyone. Nice to be here. So I'm Fabrizio Pandini. I work from one where I'm six cluster life cycle tech lead contribute to cluster API, Kubernetes and other project in the SIG. And I'd love to get to hear about you all. So quick show of hands. Who here is using one of the cluster life cycle projects or right now with their employer? Okay. How many people are contributing or have contributed to the SIG in any of the projects? Cluster API, QBEM, COPS. Yeah. How many of you are not contributed yet but are hoping to become contributors after today? Yeah. Okay. Great. Let's make that number go up at the end of the talk. All right. So numbers. Who are we? So we're about 400 developers across 80 companies. It's a pretty impressive number. And we have 21 sub projects. I don't know if there's a count of who's the top number of sub projects in Kubernetes, but I think we might win. And then over the last two years, we've had thousands of issues and PRs and comments across our various projects. So what is our mission? The cluster life cycle SIG mission is to simplify creation, configuration, upgrade, downgrade and tear down of Kubernetes clusters and their components. What that means is we're trying to make cluster life cycle really easy and so reliable that you don't have to think about it anymore. Okay. Let's have a look at what we do to make this vision possible. So as I said, we have 21 projects. A way to look at this project is to consider them into four different categories. So the first one is a node bootstrapper. These tools are basically, the goal of this tool is simply to transform a machine into a Kubernetes node. The second group and Kubernetes is a tool that falls in this category. Then we have the second category, which are where most of our projects are, which are Kubernetes provisioners. These tools basically take care of a set of machines, the machines that build the cluster and in some cases, they take care of also the infrastructure where those machines are run. And the first project that we developed in this area were K-Ops and Kuba Spray. And then basically some time later, we started the entire cluster API family with cluster API and all the cluster API provider. We have about 15 of them in our SIG, but there are many others outside the SIGs. And there is also the cluster API operator project that is in this area. The third set of tools is the cluster add-on manager. So when you have your cluster, basically you need a set of add-ons like CPI, CNI, CSI to get your cluster running. And so this set of tools are trying to solve this family of problems. And the last family of projects is kind of mixed. We have tools like Kubernetes that provide a simple cluster for developer experience or we have a tool like ATC-DADM or image bidder, which provide, which support basically the implementation of other tools. So we have a lot of great tools, but also over time we have learned that one does not fit all. There are many opinions, many different needs when it comes to cluster-like cycle. So what we did, we build a set of well-defined interfaces and this makes it possible basically for everyone to pick their own set of tools and basically also to plug in custom tool or made. What is really important is that at the end, when all this tool starts working together thanks to this interface, basically it happens this voltron moment when basically you can start forgetting about cluster-like cycle and finally you can start focusing on building great applications on top of Kubernetes. So moving on, we have a limited time. We cannot talk about all this project. If all of them deserve great attention, let's talk about two of them. I talked briefly about Kubernetes. So Kubernetes was probably the first project started in the SIG. And the goal of this tool is to be a best practice Kubernetes nodeboost wrapper. It is very limited. The UX is designed to be simple, init and join. And it provides a cluster which is reasonably sure, covered 80% of the use case and allows you to address all the data 20% if you need it. The scope is limited. It does not take care of CNI. It does not take care of machine infrastructure provision. It is really designed and meant to be a tool to be used by a higher level, tool like kubespray, cluster API, et cetera, et cetera. All right. And then on top of Qube Admin or Qube ADM, both are accepted and valid. We have cluster API. Cluster API is a tool that provides declarative APIs to manage fleets of Kubernetes clusters. So what that means is we're extending the Kubernetes API through CRDs to define desired state of your Kubernetes clusters and then with controllers reconciling that cluster state across various infrastructures. One of the great things about cluster API is that it's completely pluggable, which means it's at the core cloud and infrastructure agnostic. And then there are many providers. There are 30 plus now across very different infrastructures that allow you to use cluster API in your preferred environment. It's very powerful for managing a fleet of clusters, as I said, from a single management cluster. So think many, many clusters across different tenants, different infrastructures from the same management cluster. And it implements an immutable machine deployment model, which means we have rolling upgrades and all that good stuff that can upgrade downgrade safely. All right, and we're going to do a little digression here and talk a little bit about cluster API updates because we're very excited. Okay, so the first one is we are introducing a release theme for the project. This is a really big deal because we are trying to improve our predictability and reliability of releases to make it easier for users and providers and contributors to know when releases are coming. And we are also trying to make it more sustainable for the team to have a more diverse and bigger set of contributors being able to contribute to the release process, as well as using this as an opportunity to improve our tooling, our automation, and our docs around release. So this is a great area to get involved. We've just finalized the release theme for the first release cycle upcoming, but if you're interested in participating, please reach out in Slack and we can get you involved for the next one. So the next feature that we would like to talk about is a sensibility with R&D SDK. As we discussed before, having a great sensibility point is crucial for the success of the C-class lifecycle. And recently we released this new feature in cluster API that basically allows external tool to plug in into the cluster lifecycle. This is...let me try to explain this by an example. Let's imagine that you are a company that you need for our approval before creating your cluster or before upgrading your cluster, or you need to, I don't know, to check your provider if there are spare capacity for a specific team or whatever. So this kind of process are never going to be implemented in cluster API because there are so many, there are so different in every other company. Okay, so instead of trying to solve this problem, what we did, we created this extension point based on our R&D SDK, and what happened if you develop your own custom component that implements your specific process that could be for eyes or whatever, and then you deploy this process in the cluster and you register it to cluster API in a way that is very similar to the way that you register a book just to make it really concrete. Then cluster API will start calling your component at well-defined moment in the lifecycle. That means that when I create the cluster, before the cluster gets accurately created, so the before machine starts to spin up, the cluster API will call your component, and your component can basically answer to cluster API and tell A, wait a second, I'm not ready, there is not yet for as approval, or please, go on. And that's a very cool feature. If you are interested, we don't have time to do a demo, but if you're interested, pick me, I can show you and give more details. And just to finish this brief digression on cluster API changes, what we like to highlight is that we have a lot of innovation and most of this innovation comes from user. It comes from real use case, not a mini more from the maintainer. For instance, we are implementing support for IPAM providers, and this innovation comes from one of our user companies, and this is really great. We have implemented support for autoscalar from zero. We have implemented a cluster API visualizer, which is super nice to take a look at what the cluster is and learn about cluster API, and this project has been developed by a student, that by the way now is starting his career in cloud native, so cluster API is good also for your career. And many more, we are implementing support for structure logging, so we integrate very well, we fold the monitoring tool. Another company, Daimler, has started implementing kubestat matrix for cluster API, so better operation in production. And many other where there are going discussion on meta Kubernetes for cluster API, so AKS, GKE and so on. There is work about how to improve add-on management. There is a project about cluster paper for Elm and a lot of discussion in this area. And we are working in managing node label and streamline label propagation. Lots of cool stuff. All right, let's go back to the future and talk about our roadmap. Just a few highlights of things that are kind of top of mind for us right now. If you're looking to participate and get involved. So first up is cluster add-ons. We need to improve our story around how to install essential add-ons on clusters. Right now, there's been a lot of different solutions that we have kind of looked at in the past. It's a very complex and opinionated space. There are a few solutions that were homegrown within the SIG, like we had the cluster add-ons project that was mentioned earlier. There's cluster resource set, which is a cluster API feature for installing a YAML one-time apply after the cluster comes up. The reason this is becoming more important right now is more and more components are moving out of Kubernetes. So you have CSI drivers migrating out. You have cloud providers migrating. So now users are more and more having to add plugins and install components on top of their Kubernetes clusters and not having that be installed for free when they spin up Kubernetes clusters. So we're trying to make that story a little bit easier and better for users, and we're exploring ways of also not reinventing the wheel and reusing some of the existing great tooling that's out there for managing packages and add-ons, such as Helm get-ups, CAP, et cetera. And all of those are doing that is also part of our mission as a SIG is to not reinvent the wheel, but instead leverage the work of others in our SIG. So there are many solutions out there. We're currently in the exploration phase, and if you're interested in helping out, that's also a great area to get involved. All right, next up, also a very hot topic, Managed Kubernetes. So Cluster API and the other SIG cluster lifecycle projects were originally designed with self-managed Kubernetes in mind. That's going back several years ago, Managed Kubernetes services were still at their early days. Now we have a lot of major cloud providers that have released Managed Kubernetes services where you don't manage the control plan, you only manage the worker nodes. We have had lots of users come up to us recently and tell us we love what you're doing with Cluster API, but we want to use that with Managed Kubernetes. So they want the get-ups, the declarative spec aspect of CAPI, but they also want to have the reliability and all the built-in native features of Managed Kubernetes services. Right now, the current state is we have working prototypes in CAP-Z and CAPA for AKS and EKS respectively, and then GKE support in CAPG is in progress. But what we're trying to do is really to come together as providers and make sure that we're improving the consistency across providers so that users have a consistent experience across the different providers and that they can manage fleets of clusters across providers without needing to really care about the little differences between each one. Okay, the last area where we see our project grow and improve is about edge or disconnected clusters. So what is the need that our customer that you bring back to us? Kubernetes is nowadays used everywhere. And the problem is how can we make Kubernetes work well in an environment which is not a data center, which is not a cloud provider? Those environments have a lot of challenges. And also they come with a great variety. You can go from shops with a couple of machines to various little devices with maybe connectivity once a week. So given that this space is so opinionated, so different, so complex to take all, we are taking a very prudent approach. So basically we first have to learn to crawl then to walk and finally we can run. So we would like to do this journey with all of you. We have a couple of ideas and quick wind that we are already implementing or working on like refining support for a single node cluster. So a single machine that can host both the control plane and workloads. We are making, we are doing the small changes in order to make our tooling resilient to slow network or temporary disconnected network. So how do we cover when the connection go back, giving good log message in this situation and so on. And the next step will be basically start to investigate and understand how can we take all the most the acoustic environment which are where basically the one with less resources. So how can we downside the footprint of Cast API and how can we work well in these limited environments. The good news is that we can be creative. We can leverage on the strength of the project. And so we have a couple of ideas. For instance, to creating a super fast bootstrap without kind, we would like to experiment in moving our management cluster is a pod. So you can basically move it in edge location. Also the management cluster and you don't need any more the connection with our central management cluster. We are experimenting on faster machine bootstrap so trying to figure it out what makes machine bootstrap slow, how to make image smaller, all these kind of problems and also how to improve a lot. And also we are taking a look at features that already exist in operating system like AB roll out or a cloud native operating system like Flattacar and other botel rockets and other. So we can leverage and take the advantages of the immutability process at edge. So given a Cast API is a topic there is a lot to talk about. There is a great community of provider how to get more info. So we are just at the beginning of this conference and I would like to give you a list of talks where you can have some more information. So today there will be a tutorial about how to develop your own Cast API provider. There will be a talk about user experience, some user telling how they build on multi-tenant provider. So a provider that can work across multiple crowds which is interesting and also spin down from Cast API to CSI, CPI. So it is an interesting talk. Another user experience about how to use Cast API with virtual cluster and Cata for security. On Friday we have another talk for you from Adobe explaining how to scale the Cast API with Fargo CD and vCluster again. There will be a talk about Cast API and BirdMetal and another tutorial about how to operate Cast API in production, some tips and tricks and I will give an early shout out to the two teams working on tutorials because I know that they put a lot of effort in preparing them and they will be great. Alright, so this is all great. Now how can you get involved? So there are a few things you can do which are pretty standard recommendations. You can read our contributing guide, tender office hours, look for good first issues, help wanted, help improve docs and testing, developer tooling, et cetera. But really I think if there is one single thing that you can take away today and my advice would be to honestly just show up, introduce yourself, turn the camera on, say hi. We are all people, we all want to help. And sometimes it can be easy to be the new person in the room and feel like everyone is talking about stuff that is way above your heads but really there are other 20 people in that room that are asking themselves the exact same question you are. So be that person that raises their hand and asks the question. If you haven't, I highly encourage you to go on the Kubernetes Slack and just say hi in the Slack channel of the project you are interested in. Whether that is Cluster API, QBATM, ImageBuilder, any of them, just introduce yourself and tell us why you are here and what interests you. And then that can be a great way to get started. All right, that's the end of our content. How are we doing on time? Plenty of time, 15 minutes, so as many questions as there are. This is the part where you ask questions and we answer. What's the difference, like that I answered, some of the cluster management tool versus using this API? Sorry, can you say that again? So there are some cluster management tool like Rancher and some other things, right? So manage the cluster and manage the life cycle. So what's the major difference between this and that? Yeah, so I think the main difference here is that Cluster API is using Kubernetes to manage Kubernetes clusters. So that's kind of our concept, like turtles all the way down, Kubernetes all the way down. So we are extending the Kubernetes API itself for Kubernetes cluster management and using controllers and all the built-in features of Kubernetes to make managing Kubernetes clusters easier. So that means you can take all your existing tooling and gestures like kubectl apply to manage the life cycle of your clusters. So for example, let's say you have like a note pool and you want to scale it up, kubectl scale dash dash replicas, done. So it's things like that I think that we're trying to differentiate on. And then also we're part of SIG cluster life cycle, which means we're like direct sub-project of Kubernetes. We're not a vendor. So we're trying to work with all the community in every different infrastructure, right? So we're not like prioritizing one cloud or one infrastructure over another. Yeah, if I may add something, I think that one way to look at this is that Caster API and all the projects that we're building in SIG are kind of building blocks that the community, which is basically the sum of all the company, Rancher, Microsoft, WMWARE, and many others, where all of us are basically put together these building blocks, this set of common practice then then are using all the products because if you look at Rancher behind the scene, they're using Caster API. And they have a team, we had some discussion, which is stepping up to use it even more. In Microsoft, in WMWARE, we have products that are built on top of Caster API of Kubernetes and all the other providers and which offer you a set of services. So a kind of magic soup on top of the same common ground. So what we're building here is kind of a foundation or a basic capability that many companies are using. Yeah, hello. My name is Rafael. I'm from Ubal Live Studios. I have a quick question. So obviously you're putting a lot of work into trying to optimize bootstrap times, which I'm sure everybody appreciates. And I was wondering whether it's being considered to add a worm pool functionality to the Caster API providers for the various different types of clouds so that we can pre-bootstrap our nodes and have them shut down and ready for a rollout. It's being implemented in some provisioners like cops to a limited extent, but that would be something that would really help in keeping costs low at the same time as having lightning-fast provisioning of new nodes because obviously bootstrapping can take a long time. So, okay, I think that if I got the question right, there are a couple of points to this. So the first one is bootstrap. And yeah, Caster API. And so we have different solutions in the SIGs that manage down from infrastructure to machine. Some of them are going through traditional provisioning, create a machine, install software, and finally get Kubernetes. Some others, like Caster API, already took a slightly different approach where basically when you create a machine, you're creating a machine using an image that already has pre-baked components in. And this is a first way that brings two benefits to you. One, the bootstrap is a little bit faster. Second, what you get in your machine is kind of predictable because once you test the image in CI, basically you know that all the nodes of the same Kubernetes version, we work all the same. So we kind of already made the first step down this path, but we can do more. We can do more to minimize the size of the image. We can do more to make our image more secure, et cetera, et cetera. If you think from a kind of point of view what we have in the community today, it is some set of example of mage, but then every company that builds on Caster API, basically they offer their own specialized images. What we can do as a community is that since every company is solving the same problem, why not bring all this idea upstream and factorize so everyone can benefit of it? So this is the first part of the question. The second part was about managed solution for spinning image. I think like node pools, something like that in cloud providers. If this is... So some of our Kubernetes manager already supports this. So when you create a machine, instead of going through the process of creating for the machine, so the VAM and then Boostrapper, basically delegate these to the cloud provider so basically you can benefit about all the machinery that the cloud provider gives you to replicate image faster, to bootstrap faster, to perlocate. So we are leveraging on the infrastructure but I can tell you that there was discussion for instance one day in the Contributor Summing for people which are using Caster API with bare metal and there was discussion how basically to embed similar behaviors in their own provider so they can have a pool of machines ready to become a node when there is the need. So yeah, there is work. I think that the best answer is that every provider is trying to leverage on what the infrastructure offers instead of implementing the wheel, which doesn't make sense. Yeah, the only little thing I'll add is just like the infrastructure providers are also modular and pluggable, the bootstrap providers are as well, right? So there's nothing that prevents you from going and writing your own bootstrapping provider with your own bootstrapping mechanism if that's something that you're looking for as well. Hi, this is all great stuff. So you talked about the future projects and I was wondering, you talked about the Caster API at Edge. What's the motivation behind it? Is it something that the maintainers came up with or are these like real use cases that people have come to you about? Yeah, I think this is mostly coming from providers who have needs, so mostly users who've come to us and say, hey, I want to run this on bare metal or I want to run this on this infrastructure and that's where it started from. Yeah, I think what is important is to consider that this is a community, it's built by people. So we work in this community, we kind of are liaison between our company and open source community, so we bring our use case up, but most of the use case come from issues. So if you have special needs, open an issue, describe your problem, or come to the CIG to the office hour and just show up and tell, hey friends, I have a use case, are you thinking about it? And so people start thinking maybe, and I'm pretty sure that you have a problem, someone else in this room, someone else in the office hour have the same problem. And so when we reach the critical mass that we have enough clarity on a use case and enough critical mass basically to implement it, it just happened. So this is the beauty of the open source, really sometime you just throw an idea and then things flourish up. This is why you have to show up, because by just opening an issue you can influence what happened in a product. If your idea is good, other people will say, hey, this thing is cool, let's go on with it. And yeah, we are not inventing the roadmap, the roadmap is a sum of needs, idea. It is a collaborative work. Yeah, and that's true for all the things we talked about in the roadmap by the way, not just Edge, like every single thing we talked about was brought to us for user needs and different companies wanting to explore going a certain direction. Hi, thank you so much for sharing and thank you for laying out clear area where newcomer can join. I've never been a maintainer, I think it's really important to kind of know where I can land my footing at. I'm actually curious on your journey on how you become a maintainer and how was the ramping up, how was the first three months of joining the community? I can go first, I guess. Yeah, that's a really great question and actually it's funny because Fabrizio and I were just talking about this earlier, right before the talk, like how do we get more maintainers? And so I'm so glad you asked. So for me personally, I started just showing up to cluster API office hours like three years ago. The first time I joined, I think they were doing some code deep dive or something and I was like, whoa. It was just really intimidating because there was all these concepts that I didn't understand and everything. But I think the part that really helped me was getting to know the people. So making relationships and then using those relationships to learn and know which areas needed more help where I could get involved. That whole chop wood carry water expression that's really, really helpful and open source to become a maintainer because the maintainers are the ones in the end that are going to be responsible for project health, right? You want to make sure the project is sustainable, people aren't getting burnt out, releases are happening, the community is growing. And so that's the kind of work where it might not seem like the most fun work. I mean, I think it's fun, but it's not always like add this glamorous feature that my company needs. Sometimes it's just like make sure that we have more tests and that they're green. So looking at for those areas of work where the maintainers seem like they're burnt out and being like, hey, do you want me to help you with that? That's a great way to help. And then the other thing that I would say is if you're interested in becoming a reviewer or a maintainer, tell someone. Don't just keep that as a secret and hope that someone will notice you and be like, hey, do you want to become a maintainer? I think the best way is to just reach out to one of the maintainers and tell them, hey, I don't know if I'm there yet, but I'm interested in becoming a maintainer one day. How can I get there? Where do you need help? I would be happy to help you. Is there anything you want to add? Yeah, I think that the key is don't be shy, show up. I am working in this ecosystem by five years. Still have impostor syndrome because there are so many bright people, but at the same time they are all welcoming. When I started, I just sent, I hope in an issue why don't you don't change the default for this flag? Five line of tests. A simple question. Then everything started from them. I met a lot of friends all across the world. It is really a nice experience from both a professional because the point of view, it became my work after a couple of years, but also from a personal point of view is a great learning experience. I highly encourage everyone to give it a try. I think we had another question somewhere over there. Last one, because we are out of time. Yes, thank you for the great talk. Yeah, I think to run the cluster, you need to run the operator on another cluster. We call, maybe we call it a meta cluster. How do you efficiently manage that like an original cluster? Like, is there any... Are you asking about the management cluster? Right. Tell me if I'm wrong. I think the question was, how do you manage the management cluster? Right. So it's outside the control of cluster API, right? Yes. And for you, you need to spend additional time to maintain that cluster. Make sure cluster API operator is healthy. Yeah. Any thoughts or best of practice to manage the management cluster? Yeah. I guess I can go first. So that's a great question. That's a question most people that start getting deeper are like, wait a second. You're telling me I need a cluster to create clusters. So how do I create that first cluster? So there are a few different possible solutions for this. The first thing to know is the management cluster. It can be any Kubernetes cluster. It doesn't have to be a cluster API cluster. It can be a local cluster. It could be a cluster running in a managed Kubernetes service. It can be really any cluster as long as it has the prerequisites and minimum version requirements. Then I've seen people solve this a few different ways. There are ways to... So one thing you can do with cluster APIs is you can have a cluster managing itself. So for example, you create a temporary bootstrap cluster that's running locally or wherever. And then you create a first cluster API cluster with that. And then you can use our CLI called cluster CTL to move the resources over to the workload cluster that you just created, all the CRDs. And you basically make that cluster itself a management cluster that manages itself. So that's one way you can do it. I've seen users do that and have one per region or something like that depending on what your infrastructure looks like. And then, yeah, I don't know if you want to share. Just to add on this, I think that one of the beauty of cluster APIs that at the end cluster APIs is like any Kubernetes components. So if you want to operate it when you set up your Promethals or your login system, you are managing also cluster API like you manage any other operations. So this is the beauty. So it kind of fall into the same category of any other of NGX or anything that you run in Kubernetes. We have metrics, we have logs. So this one. Second, I think that if it comes to best practice, one of the most important thing in cluster APIs is the cluster API. One management cluster allows you to manage how many workload clusters you want. But of course, there are three doffs. You have to think carefully about not having a single point of failure. So typically the recommendation is to split up your workload cluster across many management clusters. I know that companies more or less settle about from 50 to 100 cluster for each management cluster. People doing edge goes up to 200. But yeah, it depends by the risk appetite. But yeah, having more management strategy could be an idea to operate and manage risk. Can I add one more thing? Sorry. Also, one small thing to note is that your management cluster itself it's not keeping your workload clusters running. So that means if your management cluster goes down for some reason, your workloads are not going to be down. They're still going to be up and running. The only thing that will happen if your management cluster is down is that you won't be able to do lifecycle operations like scale up, scale down, delete, upgrade, all that stuff. But there's also what's really powerful is you can do backup and restore of your management cluster resources like any CRD and controller, which means you can stand up a brand new management cluster, restore all those resources over and then adopt the running cluster and be back to running in no time. So the management cluster needs to be up and running. It's not FMRL, but it's also disposable. Like all your clusters treated as cattle, not pets. So you don't have to be attached to it or anything like that. We really are at a time, so we need to stop here. But we are free to come here and ask questions to you. To see the information, please join me in a round of applause for her. Thank you.