 Hello, everyone. This is the sequel to the cycle intro. I'm been super good. No, no, I work at red hat and I'm co-chair for the sick And I'm Cecil Robert Michonne and I work at Microsoft I'm one of the tech leads for cluster lifecycle, and I'm also a maintainer of cluster API and cabsie So what exactly do we do here the city is pretty large is one of the largest sigs We have a lot of sub projects won't get more into stats later But the objective is to simplify creation configuration upgrade downgrade and tear down a Kubernetes clusters and their components Kind of a mouthful has a lot of scope But we do a lot of things like cluster API QBDM. What did QBDM do in in the early? Stages it allowed you to create a cluster and node bootstrap it configure it then cluster API on top of it it allowed you to Create follicular clusters So what are we building the vision is to build a metacloud and that's a kind of a bold vision for the SIG We have a lot of tools in the cigarette and cluster API is one of that that allows you to to declare these APIs and We went to production ready in 2016 and we're now talking also like to have like the first v1 release of these APIs We have extensive test coverage a lot of our products are actually also Kubernetes release informing and also blocking soon eventually our Model like how kind of like we build everything with the 80% use case in mind and making the 20% possible Really what that means is we go out we try to ask like people that use Kubernetes that run fleet of clusters What is it to run these fleet of clusters like what are the big issues? But also like we don't want to paint ourselves in a corner to to build niche things They're like only a few build but we want to make Everything extensible and that's the clear will define docking ports. You can just imagine like you have a spaceship That's your product. You have this other spaceship that is cluster API or cubit yam You want to dock them together? You want to like make sure that they can work in tandem? So that's kind of like our philosophy on how we approach our everything in our community in Numbers we have a lot of contributors more than 2600 over 70 companies like all over the globe like Contribute You can see like we have 24 sub projects in this thing and more than 3000 PRs And this is just for the last year If you look back like we had like in TV one off of one days These numbers were actually even higher But now the project is getting more mature every day This is kind of the stock is a kind of it's very simplified view unlike You know what gets you to a Kubernetes cluster? What does the SIG offer to get you to a Kubernetes cluster or fleet of clusters? The very basic foundation we have cubit yam Cute logo and then the provisioner on top of it. There's cops cluster API as we as we mentioned and Cappy plus API has also a lot of providers underneath We have price for AWS Azure GCP and also some bit of metals provider Once you create a Kubernetes cluster. What does the first thing that you got installed? CNI otherwise your cluster does not get ready and then after that It's like, oh, I need to install my cloud controller manager and then I have to install like other things to make this cluster actually useful So we allow to do you all of that Project like cluster API like they do have like a provider like helm, but it's also the cluster add-ons project But let's take helm for a second When you want to create a cluster you want to configure that that whole cluster Maybe you're a good repo or you know another Kubernetes cluster and create other clusters from that To create functioning cluster that then you probably want to give out to other teams And those clusters that have to come with those add-ons, but then what happens? Monitoring node fails. They have to be replaced Cluster API has introduced like a few years ago What we call KCP as in kubidium control plane and it's a full managed solution to run control planes It will check at CD make sure that you can do things that will you know You can show yourself in the foot for a lot of things And it will make sure that like every upgrade is safe like can I upgrade do I have to upgrade core DNS? Can I upgrade to this version of core DNS when I'm running my upgrade? Those are the things that we built in this great community built in to make sure that you can run your clusters as safe as possible But not just run it and just forget about it also like make sure that the upgrade process will work great Okay, so I'm going to talk about something a bit different which is something that we did recently We did a self-assessment survey inside the SIG So like Vince was mentioning we have 24 sub projects in the SIG which is huge and I think it's very Rare in kubernetes SIGs most SIGs have a vertical area that they own like SIG network or SIG API machinery SIG cluster lifecycle is a bit different in that it's a collection of projects that work together And are modular that you can kind of pick and choose which ones you want to use and in the end you build a solution so One thing with that is that when we do the annual SIG survey self-assessment that some of you might be familiar with at the SIG level We end up answering a lot of it depends because it depends on the projects Some projects do some processes in some ways some have each one has kind of their own processes so that doesn't give us a lot of visibility as SIG chairs and tech leads into what's going on into each individual project So one thing we did in the past and we decided to do again this year is to do a survey to learn a bit more About what each project is doing and what their challenges are And I'm gonna go over some of the results here and hopefully that can be helpful Especially if you're looking to contribute, I'll be highlighting some areas Okay, so the first thing we learned is one we should do this more often So the main reason there are two reasons for that first of all it was incredibly Insectful for us to know what is going on with the projects that I said learn more about their pain points learn Where we can collaborate more together and then the second thing is actually I think the projects I actually found it useful themselves I actually sat into a few of the office hours where the projects were going through the survey and Discussing the answers as a group and coming up with Answers and it felt very much like a retrospective where you know, it's like oh, are we updating our owners frequently? are we do we have a Roadmap do we have good documentation and it was a good way to kind of do Take a pause take a step back and kind of evaluate where we're at for each project So that was the first thing The second thing which I think is really good I really wanted to highlight is how diverse the projects are in terms of contributors and that's something I'm very proud of they're I Think you know 95% of the projects that they have contributors from multiple companies Which is the good thing that's something we want to see for project health It makes the project more sustainable And then we also have a lot of end users that are contributing to some of these projects Which is also great to see and we would like to have more so, you know and users are always welcome and I think having their perspective is great because they Bring their own use cases to the table and then we're able to define project direction direction together The next thing we learned which was kind of shocking to me is We don't really have roadmaps So at first we looked at this question and the question was have you reviewed or updated your project roadmap in the last six Month and we saw only 27% said yes, then we were like oh well, maybe they didn't need to update the roadmap Maybe it was already up to date, but then you can see all the extra responses. They're like well, we don't have a roadmap so I think that's a very common theme across Kubernetes projects and This is not something meant to shame any project in particular. I think it's just something that Highlights that we have to work together as a SIG to define visions Not just for the SIG but also for the projects themselves like what is the vision? What is the three-year plan? What are what are we building here? And I think that you know, there are many ways to have a roadmap You don't need always to have an official roadmap document But sometimes it can be as simple as using github milestones to plan your next two releases, right? Anything that gives new contributors a sense of where you're driving so they can help in the right direction And then see if maybe there's something else they want to bring to the table. That's not being looked at currently Is something that we want to help projects achieve So I think this doesn't just apply to the cluster lifecycle of it Beyond other things as well Okay, and the next thing I want to talk about is I want to highlight all the things that the projects that they worked on recently So some of them there's a lot so I can fit everything in the slide But some of these are the key accomplishments of some of the projects recently so I'm going to go through some of them So the first thing is we have now predictable automated releases in cluster API and several of its providers I think this is a really great accomplishment that we've been working on for the past I would say a year and a half with the introduction of the cluster API release team and that not only allowed to Make the releases more predictable for users consuming them and providers consuming them, but it also helped new contributors get more involvement in the community be able to spread the load on some of this chore release work and allowed these people to take on more responsibilities in a way that is Recognized and official so I think that was really great The next thing is we now have the cluster API home add-on provider, which Vince mentioned earlier That's a new project that was introduced in cluster API to allow You know automating the installation of add-ons in a declarative way so things like CNI cloud provider CSI drivers and that is now ready to use there's an alpha release So if you're interested, please check it out and give some feedback The next one is another cluster API project cluster API operator. So that one is not new It's been around for a bit, but I think there's been a lot of momentum on it lately and it has I think a really good Goal which is to help manage and install the Cluster API providers, so that's really management of the providers themselves not the workload clusters in a declarative way Same thing as how you manage your clusters So again here the call to action is check it out try it out Especially if you have a different infrastructure provider that hasn't been tested or documented yet I think they would really appreciate your help Moving on the next one is cluster API managed clusters working group. So this one a lot of the different providers came together who had previously been working on a solution each in their own infrastructure provider on supporting managed Kubernetes so If you're not familiar cluster API was originally built to support self-managed Kubernetes. So We over time added support in several of the providers So cab Z has a key as support Kappa has EKS support and then I think we now have GKE in progress in cab G and then Oracle folks are also supporting the managed provider there So, yeah, so that has been an example of the community coming together and us brainstorming And trying to align and have consistency across clouds and providers And I think that is where the diversity really comes in and being able to you know exchange ideas and come to a consistent experience across providers instead of each provider having its own experience and users having to learn something new every time they Go to a new provider I will try to move on because I don't want to take too much time on this slide But there's a lot of really great stuff here cops usage in sick testing. That's a collaboration with sick testing and sick infra So that's in progress. There's a cap check it out if you're interested the mini cube graphic user interface Also really cool Encourage you to try it There's also a mini cube talk. I think that was earlier or coming up so if you're interested check that out and Then at CDM no longer embeds at CD version Which is great because it means it's more lightweight weights and it can work with new versions of at CD And then finally we've been working with the LTS working group that is newly formed So just want to give a shout out to that We are one of the sponsoring six for it And so there's lots of great discussions happening there in terms of what should LTS look like and should LTS be a thing All right Okay, so I've talked a lot about what was accomplished, which is great. There's a lot, but I think now For you all what's interesting is where can you help right? So where do these projects need the most help and some of these are just Call else that the project themselves gave us that's things that they need help with And so I just wanted to highlight a few if you're looking for a new area to contribute You know the mini cube project needs help with testing and prow And you we also have cuba DM which is looking for help everywhere So if you have you know bandwidth and would like cuba DM is a really foundational part of all of this So it's a really interesting Piece of software to understand and dive into So if you are looking to contribute somewhere, that's a great place to start The cluster API and providers always need help with reviews and contributions the cluster API operator Would love help with documentation. So if documentation is your thing Maybe consider trying it out learning about it throughout the process and then documenting it And then cluster API provider nested wants help with the nested control plane provider or controller vSphere would like help with the Migrations to park for our cluster. So if you've done that in another project and you would like to consult and help Definitely reach out to those folks and then at CDM would like to contribute and collaborate more with the newly formed at CD So in direct contrast of what we just said earlier We do have some roadmap items We have been talking for a while like about how do we graduate more of our API's we we already treat them as stable we're already doing all the work to support them across multiple versions of Kubernetes and The first two are your biddy. I'm off of v1 beta 4 And there's also talks like about what's needed to bring it to stable to v1 and also cluster API both v1 beta 2 and the v1 stable release this will come up soon like so I would just encourage you to join the Community meetings the cost API one happens every Wednesday 10 amp P T and then a lot of other things for cap is specifically Graduating machine pools that has been something that we have had like one robot roadmap for a while that today Is an experiment. It's not enabled by default So we'll need help like to kind of mature it like to the mature devil of the rest of the API's Then we also have LTS carpenter implicit great working groups Something that we have introduced like at this year or last year Is working groups within cost API So they're kind of a little smaller than the usual Kubernetes working group and they focus only on feature set of the cost API for LTS specifically Where we're looking to do is well I want to upgrade my control plane But I do have these nodes that I actually want to keep on an older version of Kubernetes for a little longer So we're working with the LTS sake to kind of provide that feedback and also incorporated like in our own validation Webbook when when you run an upgrade carpenter. It's the new hop thing So we're both I guess Azure look at just Add a support for carpenter AWS already has it and we're trying also to in implement the support Inside of cluster API said cluster API already has a concept of pools of nodes How do we are to scale those and how do we integrate also with the cloud providers themselves? In place upgrade heads a half the potato So there's a good group of folks that are now just like thinking about it both in terms of like What does it take for us to upgrade the operating system itself and Kubernetes but in place do we do a reboot? Don't we do a reboot? What does it take to get there? It's gonna be a long road So if you have experience or any thoughts on it, please join the working group and then something that I'm very excited about is Now that we have done very simple. It's like We can create a single cluster. We can manage it But what about fleets? It's really hard to run controllers against fleets And something we're collaborating with controller on time is How do we do multi cluster support? But then when we do multi cluster support like our go CD has a concept of this It's really hard to understand. Well close to be I already has a registry Can I just run a controller against the entire fleet without me configuring much of it? Can I just run in the management cluster and it will look at the whole fleet that's under management That's kind of what we're looking at and there's a lot of challenges there So again, if you want to help, please reach out and I'll be happy to listen If you testing we talked about it a little and documentation improvement. This is like kind of like across the board We just have to do better and Then what's next sick wide initiatives We have two main things the first one is definitely continue the project health assessment Which is has got really good feedback and we keep on continuing on it on that Something that we have found inconsistency across the board with an arsig is the API's Kubernetes has like an API review Board and which like probably some of our projects will also submit for review eventually But we would like to do like a simple one within our sig so to standardize our API's making more consistent and also kind of Make sure that when we build new API's we we kind of avoid the normal foot guns with custom resource definitions That if you have used them before I'm sure you have had experience with them and the third is focus more on the user experience like Do we think that like a these API should evolve like in a different direction over time? Can we make them more extensible? And and so on Think this is you. Yeah. Thank you. Okay. So this is our final call to action So I'm gonna talk a little bit about how to get involved. This is especially relevant if you're New to Kubernetes trying to get involved, but don't know where to start So here are a few tips for getting started So one of the things first things I always recommend folks do is check out the contribution guide And it has a ton of useful info in there and then also look at the community page for the SIG Every SIG has a lending page where you can find the current SIG chairs and tech leads You can find all the meeting times and meeting notes for office hours, which are public and recorded and posted to YouTube So highly recommend checking those out Attending the office hours just come say hi, you know We always leave space for new folks to introduce themselves and welcome them So tell us why you're here what you're trying to get started on and we'll try to help you as much as we can Also, don't be afraid to ask questions It can seem sometimes intimidating when you're joining for the first time and like everyone knows what they're talking about But really I think people always appreciate questions because it gives us a chance to onboard new contributors, which we love Look for good first issues and help wanted labels on github those are typically good accessible issues that you can get started on with somewhat minimal knowledge of the existing codebase Some of the really good Examples issues that fall into this category are docs and testing And then anything to do with developer tooling or release automation Those are the kinds of things that really help the project health and Really help reduce tech debt and are very much appreciated by maintainers And they're also good because you can get started without having necessarily understood the entire system yet If your project that you're looking at has a release team That's a great way to get involved cluster API has one. We're actually currently recruiting for the next release team For 1.7 There's a call to action on slack So join the slack channel and if you're interested you can join as a shadow Or as a release lead if you're already an experienced contributor in the project And then finally, I mean, this is obvious, but I like to say it over and over again You know chopwood carry water be kind I think the best way to build, you know a reputation in the community and Get to know folks and is just to Get started and you know, we all need help everyone is You know, a lot of maintainers of projects are doing this also, you know on their free time Which sometimes people don't realize but it's you know, any help is appreciated And so yeah, folks will be happy to help you if you're looking to contribute. So Yeah, and then finally, I just want to cover also a few other sessions that are happening here at kipcon If you'd like to get more info encourage checking them out. All of those are related to sick cluster life cycle Unfortunately due to the scheduling of this talk a lot of them have already passed. However You can check out the recording all those talks are going to be recorded and then You know, you can look at that later And I also want to highlight the last one which is the meet the kubernetes contributor Community which used to be called sick meet and greet and has been renamed That is happening tomorrow from 12 to 3 in the afternoon And that is a really great chance to get one-on-one talking time with all of the sick Maintainers. I'm gonna be there. There's gonna be a lot of other sick Representatives that are gonna be there and it's a great chance to just have a chat and get to know The six and what they work on. So definitely consider checking that out if you're interested All right, that gives us 10 minutes for Q&A. Thank you very much And yeah, if you have any questions, I think there's a mic here or you can just shout Hello, great overview. I'm curious if you can tell us a little bit more about if somebody wants to get involved Did that just stop? Okay If somebody wants to get involved Do they already have to have a bunch of access to a bunch of test infrastructure? So that they can somehow come in already super powered like what if they just have themselves and their github and Their computer and a will to help So I think it depends on the project is my mic working It depends on the project if you Look at cluster API, for example, we have all our testing runs with a Infrastructure provider called cab V which is cluster API Docker so provider Docker and it what it does is it runs? Kubernetes in Docker so it uses containers to simulate virtual machines and That is your Kubernetes cluster. So it all runs locally on your laptop. So you don't need any cloud Subscription or anything like that So that's one of the very common, you know testing Mechanisms that we use across the SIG to run things locally and then each infrastructure provider will have its own Testing in for various clouds. I think that cluster API has also dev containers now. Yes, and you can run tilt locally Well, it's a nice user. It's a lovely experience. I guess shout out to tilt Love it any other questions Yeah So I'll repeat the question for the recording So the question was what do you recommend for folks that are less technical who want to contribute like for example program managers or Leaders or some areas where they can get involved in help So I think there's a lot of help needed there. I mean the thing that jumps to mind is documentation That's one where we always need help. I see people nodding. They're all like, please help us So yeah documentation is a great one. I think program management. We need a lot of that in Kubernetes in general Roadmaps. Yeah, I talked about roadmaps earlier, but like seriously, it's one of the things where Sometimes like we don't have pms And it's just a bunch of devs working on their own thing and driving and it's I think having pms there to help also define like the milestones and You know backlog grooming things like that Could be super helpful for some of the projects depending on their maturity So yeah, any non-technical help is always welcome You know, you don't need to codes to contribute That's I think something that is very important to remember of course code contributions are also very much needed But there's a ton of stuff you can do to help even if you're not you know a programmer I think you have a pretty well one thing that may add maybe it's like if your product manager or like a literal company and you have use cases that we might not have considered just because they're not in our project purview Come to just speak to us like it could be something that like we might not have thought about Or something that we have thought about and we have my already discussed that's too difficult to do today What is not the right time? But we're always welcome like a new use cases feedback and things that we can put on the road map eventually Yeah, that's a great point. Yeah I'm actually surprised by the turnout this 4 30 p.m. Talks Well, thank you everyone for coming