Cloud Native Theater | Cloud Native University: How Kube... Michael Forrester and Mumshad Mannambeth

This talk explores how Kubernetes self-governs through a structured governance model focused on Special Interest Groups (SIGs) and the Kubernetes Enhancement Proposal (KEP) process. The speaker discusses the frequency of Kubernetes releases, emphasizing that while knowledge can become outdated, core concepts largely remain relevant over time. They explain the role of the Cloud Native Computing Foundation (CNCF) in oversight and detail how various SIGs are responsible for different aspects of Kubernetes, such as architecture and scheduling. The presentation also covers how to propose features via KEPs and report bugs through GitHub, highlighting the importance of understanding the governance documents associated with Kubernetes. Additionally, the speaker recommends resources for staying updated and involved in the community.

And Michael will be back for a second session in a little bit. So, hope you enjoy this one. Thank you. Hey. Okay, mic check. Mic check. >> All right. >> How good? So, this presentation came out of a question that arose, right? Which was how does Kubernetes actually govern itself? Like, how does this actually happen? How do we get like features and bugs and other things? What

does this process look like? So, we're going to take 20 minutes and we're going to talk about loosely from an educator's perspective what happens inside of the Kubernetes kind of governance model and how to stay current on Kubernetes. So, we're going to dive right in. All right. Hey, everyone. Uh so, I just got my CKA. Just got you know, spent 6 months preparing and working through the

labs and getting certified. but how long have I got before what I learn is out of date? Yeah, fair question. most of you probably know that Kubernetes does three releases a year. You're already aware, right? So, you pretty much after maybe two, three releases, what you know is at least slightly out of date, but the core of what you know, 80% of it is still obviously super

relevant, maybe more, right? So, you know, the answer is is that when you take an exam, right? Check and see if the the the exam version is incremented, but the bottom line is like is your knowledge of Kubernetes out of date? The answer is predominantly no. But at about three versions in, you're probably at like 90%, but it also depends on what was released, right? How many

of us knew Gateway API before it came out a year ago? By the way, a show of hands, how many of you were surprised that Gateway API was on the exam if you took it? Yeah, exactly. Yeah, so I mean, three releases a year year, like all we have time to do is just keep our courses up to date and keep the labs up to date every

time there's a new release then we have to update our entire lab infrastructure with the latest version. And yeah, I mean that's all we do these days, right? >> Yeah. Um, okay. So, is CNCF in charge of Kubernetes? Again, one of those interesting questions, right? Does the CNCF run Kubernetes? Is it in charge of Kubernetes? Technically, yes. It is basically the overarching organization. Kubernetes does sit inside

of it. But oddly enough, special interest groups, SIGs, basically do every all the work inside Kubernetes. And I do want to point out by the way there's an architecture SIG, right? Special interest groups. And so, cuz some people ask they're like, well, where does architecture live? The Aren't there other groups that do that? Don't worry, we'll talk about them in a second. But bottom line is that

there's all of these groups that basically run Kubernetes, whether it's scheduling, node, whatnot. That's where this occurs at. Now, there's other aspects to this. There's sub projects, right? So, in addition to SIG special interest groups themselves kind of owning the code, running the decision-making process, all the rest for Kubernetes, there's also sub projects that frequently pop up, right? That are necessary in order to make sure that

like certain concerns are attended to that arise, right? They also will spawn working groups to attend to specific issues. Those are usually cross-functional. Okay. So, SIGs, um, special interest groups, they're responsible for running the show. Pretty much. >> All right. Um, so, do they handle like everything across the entire cloud native ecosystem or is it just within the Kubernetes project? Yeah. So, so there's an interesting thing

where obviously the CNCF has their technical advisory groups, right? Those technical advisory groups, the five in particular listed here, are the ones who pretty much do all of the cross-cutting concerns. But, notice that the TAGs they're advisory only. They don't necessarily own any particular code, which doesn't mean they don't test things. But, if you have new ideas that are cross-cutting across the ecosystem, then SIGs really only

handle Kubernetes. TAGs are going to handle anything that is broader CNCF-related. By the way, it is worth mentioning that Kubernetes does have a seat on most of these councils. So, Okay. So, SIGs are primarily focused on the Kubernetes projects, and then you have TAGs that are across the uh the rest of the uh CNCF projects. So, if I have to like propose a feature, if if I

want something to get into the Kubernetes project, how do I do that? How does like a feature actually get into Kubernetes? So, the Kubernetes enhancement process, right, is where features mainly make it into Kubernetes. And so, the Kubernetes enhancement proposal, right, which by the way, if you see GEP or some other kind of acronym, that's usually a sub like a SIG subproject, right? It's not core Kubernetes.

KEP is really the where this starts. This is a process that we follow to submit feature enhancements proposals, basically, into Kubernetes itself. Now, funny story, right as I was walking over here to give this talk, there's a poster actually of the entire KEP process over at the poster pavilion, like right there. And I was shocked to kind of walk by, like, I'm going to go talk about

KEPs, and I'm like, "Hey, there's a poster right there." So, also know, if you want a deeper dive into KEPs, there's a great little poster literally right there on the poster pavilion that will dive right into it at a deeper level than we intended to. That being said, most of you operators are very familiar with the KEP pipeline, at least in in of its alpha, beta, and

kind of GA status, its stable status, right? Um so just know that once you submitted the cap pipeline, which I just want to mention this, submitting an enhancement always requires you to talk to a SIG. Just make sure you remember that I said that. Right? Typically, you have to go to a SIG, like SIG node, because you want to make some enhancement to node awareness or scheduling

or something. You want to talk to a SIG first, make sure the issue, right, is valid for the SIG, and then you can grab them on Slack, and then what will happen is that they'll help shepherd you through the cap pipeline in most cases. Yeah? Right, so Kubernetes enhancement proposal cap for features, right? But like uh recently, there was this announcement of the in in-place pod resize.

>> Yep. Like where where did that come from? Okay, so let's say you're like, "Hold I want to find this feature cuz I'm kind of like curious what its history is, where did it come from, who proposed it, what does it look like?" So we we chose a particular one. And so with this particular case, let's say it's cap 1287, which is the one for in-place pod

resize. You can actually go and look at kep.k8s.io, and you can actually like type the number in and find where this thing came from, what versions was it alpha, beta, and GA in. You can get product proposals, architectural proposals, how many basically SIGs did it touch, right? And as an example, this is an eye chart, so you might not be able to read this, right? But just

know, this very first line item here says in-place updates of pod resources, it says an API change, it says SIG autoscaling, SIG node, SIG and then it says stable. So you can literally go and search, you could have put you could have put place pod resize, or in this case 1287 cuz we we what it was, and you can actually see the history and lineage of any

kept that's happened. Notice, by the way, that I didn't have the state set to closed. I just had any state. Because if it was closed, it'd be specific. Otherwise, just know about the default is that if you come here and you click on kep.k8s.io, it's going to only show you open issues by default. So, if you go look at it, you got to change it. Yeah. Uh

I must say, uh caps are a great uh source of uh documentation for like a lot of a source of information for like a lot of features, right? Uh and it is often I I refer to the caps to really understand the why behind uh a lot of features. So, it's really helped me in my course creation process. And and if I were to go in and

try and explain a particular concept, the documentation has the information on how, mostly, but if I really wanted to understand the why behind these features and how it came about to be and how it evolved over a period of time, then the caps are a very uh useful place. So, I would say uh if you can't find enough information on the usual doc.kubernetes documentation pages, uh refer

to identify the cap that's associated with that feature and try and read through that. You get a lot more additional information on the why and then how it's implemented and all of those details. So, uh a a tip there for anyone who's trying to learn uh in-depth on how uh features are implemented. Like I can imagine a few people looking up DRA, for example. Just as a

suggestion. All right. So, you have caps for, you know, big features, but what if it's just like a bug? If I want a bug in Kubernetes, how do I even report that? So, everybody loves GitHub, right? So, this is where we're going to go. Is that filing a bug is actually just as simple as going to the Kubernetes projects under kubernetes/kubernetes on GitHub. And there's literally in

the issues tab, you can click I want to file an issue. And it'll pop up a little list. The very top of the list is submit a bug. I just want you to be prepared, though. This little screenshot does not do justice to the number of fields that are here. So before you actually file a bug, I'm just going to recommend that you go in and look

at the eight fields that are here cuz you do actually need answers for all of them. Like one of them for example is cloud provider details. Most people will be like, well, I'm not even running cloud provider details. Well, you know what? You should go look anyway cuz it might be not applicable, but for some of you, I mean again since most Kubernetes installations predominantly are in

cloud, at least by, you know, certain polls, you want to know what these things are going to ask you even if it's not applicable, right? So if you decide to file a bug, please go look at this first cuz there are eight fields here and they have to be filled out. Um I do want to mention one little caveat this is for bugs that's okay for people

to know about. I think we all know of bugs that people probably shouldn't know about like zero-day exploits. In that case, you're not going to file a public issue. Does anyone agree that that's probably not wise? Hey, I found a great way to get, you know, shell access. I should share this on a public tracker. No. What you're going to do is you're going to email [email protected].

And I want you to know that you are still going to have to submit this information. So you should probably go still look at the public bug tracker, figure out what the fields are, and then email that to [email protected]. Otherwise, when you send the email in, they're just going to send you a response that says, "Hey, can you give us this information?" So just go ahead and

grab that and figure out what's on the bug tracker just to save the security people time. Yep. Uh I used to, you know, subscribe to KubeWeekly while studying. Is it Am I good there? Is that still the latest latest information? what's interesting is that a lot changed in 2025 for like non-vendor Kubernetes sources of information. Just to say this, right? Now, don't get me wrong, vendors are

are emitting all kinds of signals around Kubernetes. but like Kube Weekly, I think their final issue, according to our research, was May 2025, right? Kubernetes Slack, by the way, I thought it was going to get retired, deprecated, it didn't, and it's still here, right? Uh there was even some like, are we on Twitter? Are we on Blue Sky? And the answer is we're on both. We're on

Twitter, we're on X and Blue Sky. And then the Kubernetes podcast, um was December 22nd, 2025 was its last episode, from what we can see. Now, what's interesting is that uh last week in Kubernetes development, which I think is Josh Berkus's like web page, is still running and live. Wisdom of the Cloud is the new kind of newsletter, right? That I think that for the most part

replaces Kube Weekly. You can sign up, it's on CNCF's page. These are all they all work. By the way, there's a repository that goes with this that has the slide deck and all of the resources that it will share at the end. And then, you know, there's always the things like the Kubernetes security announcements, pieces like that. My our recommendation, if you're looking for a non-vendor setup,

is Last Week in Kubernetes Development, so LW LWKD.info, and then Wisdom of the Cloud are the recommendations that we would go after. But if you have a favorite vendor, they're probably also covering Yeah, that's great. Thank Thank you. Thank you for sharing that. Oh, so, worth mentioning. So, this is Last Week in Kubernetes Development, right? So, this is what I was referring to before. Oh, wow. I

I captured my whole screen there, so you get to see all the cloud usage that I have at the top. That's awesome. I use cloud a little bit. Uh and then all the weekly updates here, right? And note that this is actually from one of the SIGs. It actually says it right there, right? Kubernetes project SIG contributor experience, of which I believe Josh is either one of

the primaries for or was. Uh and so, he's still updating this fairly regularly as you can see. March 15th when I took this screenshot is still in play. And then this is the CNCF Wisdom of the Cloud newsletter. Right? Easy to sign up for, obviously. From the source somewhere. So that that's the new one, right? >> new one. >> have you Is the first edition out yet?

Yeah, as far as I know. Yeah. >> Okay. I mean I've got it I've gotten I've gotten the newsletter from them. >> You've got it? Okay. Right. Yeah. Okay. All right, that's a lot. So uh, I'm overwhelmed. Like what do I actually need? So here's the recommendation and there's it comes in two flavors. One if you're an operator and you're running a production facing cluster you ideally

probably need to like be subscribed to security like information, right? So the security announcement, right? Which by the way, I did check that. That actually still works. I know some of you are like, wait a Google group, is that still active? Yes, it is. And then the bottom one, number five, which is the official JSON feed. I would definitely recommend like And these are not the only

sources for this. Obviously there's tons. We just had to pick some. Um, but I would definitely subscribe if you are an operator running a cluster facing production. You need to be up to date on security vulnerabilities. The rest of this I would just say like do last week in Kubernetes development. Right? Josh does a good job of showcasing and making it easy and digestible. Obviously the Kubernetes

blog, right? Does a good job at least letting you know that something there. You can deep dive into a cap or something else at that point in time. And then um, I would say just keeping an eye on the Kubernetes releases, right? Is also good. Um, I will say what's interesting is that when we were searching for information about governance, right? About how Kubernetes governs itself, it

was in four MD files across four different repos to actually get the whole picture. Has anyone else ever looked at this and found it super complicated to try and figure out? Cuz Kubernetes itself runs really well, but like to figure out like where the official kind of governance was was actually a little bit of a challenge. But the answer is if you're an operator, one and five

for security. For everybody else who just wants to stay abreast, it would be two, three, and four, right? Just sign up for those and you're good Yep. Time check. Right, but like if I want to go deeper, like how do I how do I start contributing? well, you're here at KubeCon. So, there's a couple of different options here. One, if you're not already on either of the

Kubernetes or the CNCF Slack, you should definitely be on there and introduce yourself. Yeah. You can you can find like almost anyone you want on the Kubernetes Slack. >> Yeah. Yeah, the the maintainers, the you know, the the SIGs. Uh that's how you kind of build relationship and you know, get in touch with people. So, Yeah. Yeah. if you're not already on, then kubernetes.slack.com, that's that's where

you should be. Absolutely, yeah. Absolutely. And then also know that you're here at KubeCon, there is a general SIG meet and greet tomorrow on March 25th. It's on the schedule. And it is also worth saying that almost every single SIG, SIG Nodes, and Scheduling has a session on on the board. So, if you go listen to their session and then maybe you talk to them afterwards, they

would love to have you. By the way, I haven't talked to a SIG yet who's been like, "We don't need people. We're good." Everybody needs uh support, yeah. I was actually uh yesterday sitting somewhere and uh I was next to this uh Docs, basically. Right? SIG Docs. And it was like, "Oh." And they were like, "Yeah, we we we would love to have people." And then they

say, "You know, we're on Slack. We're talking." And so, just know that this is a great opportunity to find a SIG, right? And just know that all of them maintain good first issue notes in their GitHubs, right? So, if you're like, if I want to get involved, what does a good first issue look like? They will help you figure that out. Almost all of them want Almost

all of them, let me rephrase that. All of them want people. And then there is a new contributor orientation that's happening this week at KubeCon. If you haven't been to any of those, right? Or go join a ContribFest. This is a great opportunity to get involved. And I also want to point this out. Some of you are probably intimidated by the thought of doing a PR or

contributing or showing with any of And honestly, we all start somewhere, so you just going to like have to go and ask how you can help. Uh none of them will say no to that. And I just want to be clear also, if you if you're thinking, well, I'm not that good of a coder or not that good of an operator or whatever it is. First of

all, we probably all say that even after 30 years in the industry. Yep. And second that doesn't matter. They want your help, right? So, go ask. It's a great way to get involved in the community. And so, don't let that stop you, right? It's just even if it's writing documentation, they still want people. Yep. And then there is a release team Uh the uh sorry. Uh when

when the new releases come out, there is the the logo that comes out, and that itself the the graphics that's associated with the logo, they're also uh contributed from the community. So, all sorts of contributions happen. Yeah, yeah. And those logos are interesting, right? >> Yeah. Timber Daddies, World Tree, all that stuff. Octarine. Okay. So, oh, there is by the way the uh uh release team shadow

program. So, if you're uncertain about where to go and what to do, get on Slack and start asking questions. People will help you. We're our last 2 minutes. That was good timing. everything is in this repo. I know, everything I just talked about is in this repository. Right? And we might even put the updated slides here in a little bit. But there is a copy of the

slides that maybe just has some slight corrections. things to remember, Kubernetes ships three times a year, SIGs don't own everything, CNCF is really just kind of like a landlord that kind of lets Kubernetes do whatever it wants as long as it stays within the boundaries. Tags advise the entire CNCF ecosystem. Otherwise, there's SIGs, there's working groups, there's subprojects. Five subscriptions in 20 minutes a week will keep

you up to date. And the contribution path is actually really well documented. They love to talk to you. Get on Slack, go to the contributor meet and greet. Go talk to people. They'll probably say yes to anything that you want to help with. >> Yeah. Yeah. We can start the questions. Yep, this is great. Well, thank you. Thank you so much for listening to us everyone. Hope

that was helpful. And thanks Michael for walking us through everything. Anytime. Thanks everyone. All right. Thank you. Bye-bye.