Steering the Ship: Ask the Kubernetes Steering Committ... Kat Cosgrove, Maciej Szulik & Antonio Ojea

This talk features members of the Kubernetes Steering Committee discussing their roles, responsibilities, and recent changes within the organization. The steering committee acts as the governing body of the Kubernetes project, making high-level decisions regarding policies, project management, and community engagement. The speaker emphasizes the introduction of new policies regarding AI contributions to mitigate burnout and legal risks associated with AI-generated pull requests. They explain the processes by which special interest groups (SIGs) operate within Kubernetes and how new SIGs can be formed based on significant architectural changes. The discussion also touches on the influence of big tech companies on the committee's decision-making and reassures attendees about the governance structure that protects the project from potential corporate takeovers. Overall, the session provides insights into the challenges and joys of maintaining Kubernetes and emphasizes community involvement.

Welcome to the Kubernetes Steering Committee AMA with three of us. Um fun fact, this is the first time in I think four maybe five years the Kubernetes Steering Committee has been able to have an AMA at KubeCon itself instead of just the maintainer summit. Because this is the first time in four or five years that the Kubernetes Steering Committee is not all men. So there's that. Yeah,

that's why we never had one. It was uh no man's allowed. We don't get an exception to that just cuz we're the Steering Committee. Yeah. uh if you are not familiar with us, this is who we are. There are uh seven of us normally, but uh rarely do all of us make it to a conference together. So this is the the whole picture of all of the

members of the Steering Committee. And the reason we are not always seven is like for security reasons. Uh yeah, yeah, yeah, yeah, yeah, for sure. The critical thing we have to maintain and keep the cube running. No, I'm just >> We have the keys to Kubernetes um and we can just turn it off. Um if you're not a Kubernetes maintainer and aren't familiar with what we do,

uh we're the uh overriding governing body of the Kubernetes project. We're we're Kubernetes' um parents, basically. So um something goes wrong or you need to whine, you can come to us and it is our job to fix it. So that means making like broad changes to the project if necessary. It's policies, it's rules, it's charter, and on and on and on. Um we're also >> on and

on in a in a way that we only do that for two years and then either you're out or people think you did a great job and you're going to do it for another two years. >> But you can only do it twice. You can only do it twice and usually we roll every single year so that the new members can still sync with the old members

and there's a nice tran- transition period and everyone are properly pulled in into all the uh shenanigans that the Kubernetes steering uh does because there's a lot of stuff that we do in public, but there's uh a second half of the stuff that we do in private, and we rarely can talk about it. All right. So, um this is a QR code to a Slido. If you

open that up, you can ask us a question anonymously if you want to ask something spicy. If you want to ask something spicy and you don't care about us um knowing who asked an unpleasant question of the steering committee, you can use this microphone here. So, um I have the Slido up on my phone, so uh if you do accidentally put your name in there, I will

see it, but nobody else will, and I promise I'll keep it a secret. unless it's personally hurts my feelings, and then maybe not. But, it should be alive. Let me see. It says it's >> It says it's alive. the slide also says year of 2025. Isn't that the wrong QR code? No, uh no, this is just the um wrong slide template. Well, we can log into >>

Interestingly enough, nobody complained Yeah. >> three of us looking at it. Yeah. We all had to look at this. Um so, if anybody has questions that they would like to ask um not anonymously, it says it's active now. The right QR code, yeah. You can scan that one? That tiny? Okay. Go for it. Yeah, so that's where the anonymous ones go, but if you Oh. Hm. I

can make another one Or turn this other one back on. Sorry, y'all. It worked just fine for the maintainer It did. Maybe they're down. I know that SCAD had some issue because I got logged out half through the day today. So. I know. Or maybe there was an end date end date the last time because it usually it seems like it's creating for a day. Like a

brand new one? If it's still doing that then I think we have to assume Slido is haunted and we can't take anonymous questions. Am I >> Anyway, we have mics. Yeah, ask a question at the mic. It works now? Okay. Yes. Can I still ask my question? Of course. Totally can. Um what is the hardest part of being on steering and what is the easiest or most

delightful part of being on steering? I I think the answer for both is the same. Um we are we get to take the glory when something goes really well with the Kubernetes project at large. Um like if we implement a policy change that's really popular or Kubernetes gets used somewhere really cool. We we get the glory. We do the press interviews. Our pictures are all over the

internet. Um if you like that kind of attention, that's a good thing. But also uh when something goes poorly with the Kubernetes project or something is dramatic like um shutting down ingress engine X, um we publicly have to take the heat for that. So like like part of what we are elected for is to be human shields for the rest of the maintainers and contributors, but you

know, I don't mind that part. I think it is our responsibility, personally. Um we got a slide you question are there any talks this week going over each SIG? no. Kind of wish there was. yeah, there's just the meet and greet, but there isn't really like somebody would have to submit that talk. Um probably it and it would probably have to go through the main conference CFP

instead of the maintainer track CFP, too, unless we did it. No, no, but there is like, you know what, there is some content that exists on that. If it's you personally that's curious, we do that in the uh SIG release shadow onboarding. So, I can send you that slide deck if you want. Uh interestingly enough, it depends what kind of uh question around uh going over what

each SIG does because every SIG that works within the project has the ability uh to show up and if you look through the sketch, you probably notice uh some hidden behind uh I don't know what's new with kubectl, for example. That's basically SIG CLI talking about what they are working on. Uh I'll be covering what SIG Ops does and right after this session on the other side

of the building. Uh uh so, different SIGs, if you look through it, will speak about what they are working on, what the stuff they've done over the past year, what they have in the in the pipeline for the next and the following releases this year, usually. if you want to have something around what is the list of SIGs, roughly what they are doing. There was a uh

contributor orientation, and that is also a presentation that is happening like once a month being done by SIG ContribEx. They are going through the entire governing process, what it looks like to submit a PR, roughly helping people to make their first contribution, and find their way in the in the broader Slack me and I'll send you that that slide deck. There's also a recording of that talk,

and it does include like a pretty extensive overview of who they are. Yes, Nat. That's true, it does. That Yes, that's true. There has been over the past couple of years, there has been multiple blogs posted Can Can Can we use a mic for the question because we're streaming? Yeah Yeah, you Yes, good point. Um all right, so >> I'll I'll make sure that it's being passed

on. Yes, thank you. Um next question is with all the AI doing damage to open source projects, what are the plans to prevent burnout of maintainers from organizational perspective, usage policies, etc.? Was that asked by somebody who knows what we're doing already? Cool. so we we are going to institute some policy changes that relieve some of the burden on maintainers and contributors. Um we already have an

AI policy, but it's not it's not very firm. Um so we're changing the language to make it more firm, less please and must and more you must. Um so you uh must disclose disclose use of AI in your PR description specifically. Uh you may not co-author a PR with an AI tool. You may not co-sign a commit with an AI tool. You may not use the assisted

by or co-developed with or anything like that commit trailers. Um period. We're we're not really negotiable on this one and I will explain why we're doing this. With the um co-authoring and co-signing, that is a legal issue. The Linux Foundation says we can't do that and we agree. Uh because it's a liability. Um who who actually owns that code? The AI cannot sign a CLA. So, it's

a hard no. With the assisted by and co-developed with trailers, that is a marketing issue. Um those things persist in get history and we are concerned that companies would functionally use it as a way just to advertise their startup. So, they would uh assisted by some paid tool and then slap the Kubernetes logo on their website as if we personally as a project endorse this AI tool

and pointed a merged PR to back it up. So, we we can't really allow that. So, the CLA issue with the banning assisted by and co-authoring, that's going to like automatically reduce some of the junk PRs maintainers are dealing with because they they are being opened with AI co-authors. And now that easy CLA is checking whether or not co-authors have signed the CLA, uh those those PRs

are no longer going to fly. The we won't waste any reviewer effort on those. This is a policy that'll change a little over time though. Like this is our first run at it. We're going to make additional changes in the future, but this is where we are starting and you can expect that probably like what? Next week? Steering meeting? Yeah. Yeah. Well, one clarification for people not

familiar with Kubernetes, the easy CLA that she mentioned is when you send a pull request, there is a pre-submit job that checks all this in, right? So, this is a Uh, an automation we'll have that is going to validate this and just ban the the pull request. Yes. Yeah. Um, would you rather fight one horse-sized duck or 100 duck-sized horses? Um, 100 duck-sized horses cuz I'm going

to pick up um, one of the duck-sized horses and swing it and What What is the I don't understand. What is the >> That is a It's a It's a stupid question that uh, people feel ask for fun because it's like it's hard to conceptualize what you would do if faced with 100 duck-sized horses or one horse-sized duck. I Yeah, I personally think 100 duck-sized horses is

easier. Um, Okay. Okay. That's a You want me to continue? Just just for the opportunity to use the other duck-sized horses as weapons, right? Like you can get a little bit more reach that way. I was trying to figure out what is a duck kind of horse to Um, but work done with AI contribution by active maintainers even if early contribution is still accepted. We don't have

a problem with you using AI. You are like more than welcome to do that. We're not We're not saying you can't use AI. We're limiting uh, the way in which you must disclose it, which is drop it in the PR description, and saying that you can't have your AI tool like pretend to sign the CLA so that you can co-author a PR with it, which is like

that's both a legal issue and also a no marketing of paid products in the Kubernetes project >> An important aspect of contributing to Kubernetes or basically any other project is that the humans at the end, us maintainers, have to review the PR. We will be going line by line, and we expect a person on the other end to respect our time. And with that we mean you

can use as much tooling as you want. But we will ask you the question. You must answer the question. If you will provide me an an answer to my question copy paste of whatever the tool you used which is basically instead of I'm asking for a simple thing and you're providing me like this huge essay I'm not going to talk to you. >> want to read six

paragraphs. I I I I don't want to uh We don't have time. It's totally fine that you use an AI to answer the question. But I wanted the gist. I don't care the entire thing. I can read it on my own. If I want to talk with AI, I'll run it on my own and I'll close your PR because I don't need a third party to talk

to an AI. Yeah, for for context on how bad this is, we're we're talking about like we're getting PRs that do not compile. Like like code that doesn't compile, nobody even tried testing this. Um PRs where the content of the commits does not at all match the description in Um a couple of them will have like fixes issue number and the issue number is like fully hallucinated.

It doesn't exist. And then the commits contain God only knows what like >> Yeah, structure structure members that do not exist in the code base. New structures that do not exist in the code base. Like completely out of nowhere. And people will open up. But because um if you're a Kubernetes member uh we will automatically run all of the tests with your PR. If you're a new

contributor to the Kubernetes project, we will not automatically anything run. We will not run anything automatically unless a current GitHub Kubernetes org member will tell the our testing infrastructure to yes, it's okay to test it. Uh, so only after actually looking through the PR, you'll notice like, oh, this is like complete. Uh, what is the coolest feature on the road map? Um, Kubernetes doesn't really have an

overarching feature road map. Individual SIGs do, but the project itself does not have an overarching road map. That's an important distinction between the steering committee and the SIGs. Steering committee only ensures that the entire project was works as smoothly as possible. We are the enablers, but the actual people doing the work is happening between all the special interest groups. Every special interest group has their own area,

whether that will be the CLI, so that will be cube cuddle. Uh, the SIG node, they will be handling everything that is happening on on your, uh, Kubernetes nodes. API machinery will be handling everything around API, and so forth, and so forth. Uh, the steering committee ensures that the the all the SIGs are doing whatever they were supposed to do. It helps, uh, establishing new working groups

for, I don't know, there's a new fancy thing that we want to get added to Kubernetes, I don't know, AI related or otherwise. and there is a group of people who are interested in in in working together. Very frequently, this, uh, this crosses several SIGs. For example, one of the recent additions to the working groups is a node life cycle. They are discussing how we can expose

information about what's going on with a node, whether it's pre- being prepared for a drain, should we, uh, not move workloads, and so forth. There's like a lot of discussion around this topic, and this is a perfect topic for for folks from the node, from folks from the SIG apps, maybe API machinery as well, potentially something else, cloud cloud infrastructure as well. So, those are the things.

We don't own the code, that's why we don't know what is the new feature. Each of us works in a different special interest group. Some of us through a couple of them. So, each of us will tell you a different feature that they are exciting on they're excited on to see that will be happening whether they'll be in in their area or or some other area. But

yeah, that's that's probably a question better to be asked at the at those specific SIGs or working groups meetings. When would a new SIG be created? So, there's two different kinds of SIGs. we call them horizontal SIGs and vertical SIGs. Horizontal SIGs touch like many areas of the project and may interact with many SIGs. So, that's things like SIG docs, SIG security, contributor experience, release. We all

have to deal deal with a bunch of different SIGs. Vertical SIGs own code for sure and own like very specific parts of the project. I don't know that we would I mean, we would have to like have a significant change in the architecture of Kubernetes to need a new vertical SIG right now because we would need a whole new like area of code. We'd need a whole

new thing like kube control that needs to be owned. And also, don't take him saying kube cuddle and me saying kube control is like official word of the steering committee on how it's pronounced. But for for a new vertical SIG, it would it would take like a significant architectural change in the way Kubernetes functions, I think. For a new horizontal SIG, I don't know. Is there something

you feel we need that uh manages something in all SIGs that um we don't currently have? But like that's what it would take pretty much. >> SIGs are created very rarely. >> Yeah. We've got like 30, 28? 24. Uh the newest addition to the SIGs was etcd. Uh but that was because etcd has been moved from a standalone project to be part of Q because uh of

how closely it is uh related with a project and the people were already working with uh with the Kubernetes itself uh very closely. So it felt natural for the project to take ownership of the uh etcd project, especially that the people like I said were uh already uh working on both in parallel. But uh war groups is something that will come and go frequently. And those are

designed to be ephemeral. >> Yes. Like we expect to wind down a working group. >> And they are sometimes they are uh keeping for a couple of years. The batch working group is one example where it is I think it's like three, four years in the making. And there were like a bunch of AI-related working groups for within like past year that we literally spun down in

the past two, three months. Four, three of them. Yeah, LTS is spinning down I think and something else spun down recently. >> Yeah. ongoing back and forth depending on what's going on. LTS is one interesting working group which was It was spun down a couple years back. And then eventually they reached a conclusion, they closed it down, and then uh a couple years recently they uh they've

reopened it. did some additional progress towards the long-term uh support. And they are currently uh closing down or they already have. Uh so we will be as the steering members are responsible for actually saying, "Yes, you're good to close down." or "No, you're still missing something." or "Yes, you can actually create the working group. You are meeting the require the the requirements that we put in front

of the working group." Um, with regards to the scope of the work, what is your how what are the exit criteria and all the documents that you can read about in the community repo. We got a question that's definitely, um, for Antonio. Um, Antonio is, uh, from SIG Network. So, are there plans to deprecate Ingress overall in favor of Gateway API? So, this is this this is

an example of of But, I think that there are important things here. So, there is a a policy that is about APIs that I think that is SIG Architecture. Then, there is a definition. An API that goes to V1 is never is never removed. It can be deprecated, but doesn't mean that it's not going to exist, okay? Then, there is the the technical direction of SIG Network

that say, "Okay, this API has some problems. We had all this drama and everything. So, we're going to do Gateway API." So, that's a technical decision. And then, there is the the problem damage control that Kat was mentioning before that is, "Okay, we have now, uh, the Ingress engine in situation." And that get escalated to to steering to handle all these, you know, impact on people. So,

this is an example of how, you know, something that is is a four five words question implies several SIGs, several bodies, and and several people, okay? That's the technical part is is handled by Architecture SIG Network, but then things go wrong and it it need to imply more bodies on the on the project. At the end, you see, I mean, the SIG Network, you are in release,

CLI, and and other things. We are the same people in different with different hats. We try to communicate between uh between each other and and try to solve the problems. So, not really. Like it's just so many working so many moving pieces. No. Um like the the way we shut down Ingress and Nginx was like it was an emergency. Like that that was an emergency that kind

of like lit a fire under our asses. That's my second cuss word on stage of KubeCon. Um it lit a fire under our asses and we didn't really have a choice but to respond. Um and it had been like a problem we'd known about for years. So, if if Ingress were to be deprecated entirely, like it would be it would be years before something like that happened,

I think. >> a lot of backstory around this topic that um we unfortunately cannot share that also affected this decision. So, uh you have to trust the project that we've made the best possible decision long-term. Uh but it would when it comes to deprecations in general, I know that you might be away already and you're not using it. But at the at the in the long term

correctly or basically we always have to think about the entire uh user base. And trust me, whenever you publish an you will get people using it in a very surprising ways. Um interestingly enough, I can take I can quickly give you a story about what we've done with uh Super quick cuz we've got Yeah, that will be like a minute. Uh we bumped to newer version of

uh library to do the cron parsing thing. Uh people were able to figure out that they can actually inject um time zone in the field because the newer version of the library was capable of parsing that thing and we've never admitted that it's possible. and they started relying on this thing. And so, for us to remove that capability from those users took about a year, a year

and a half of work just because people started using and relying on it. So, it's like Oh, yeah. When When we release Kubernetes 2 Kuber- Kubernetes 2: The Reckoning um then yeah, that'll be that'll be Kubernetes 2's problems. We've got two questions that I think are related Not me. That's not going to be us. Oh, no. We'll be We'll be out of here. We'll be dead and

buried by then. Hopefully, God. Um all right. How closely do you work with the hyperscalers? And how big is the influence of the major sponsors, Google, AWS, et cetera, on the steering committee and its decision-making? They do not have any control over us. They do not have any control. They do not have any influence. Um some of us work for big companies. I don't. I work for

a startup. He works for a startup. You work for Intel, right? Google. Google. Yeah. Google doesn't Um It's okay. It's okay. We're not going to throw you in. But like they don't they don't get to tell us what to do. We also have um provisions in our charter called uh maximal representation that prevents us from having more than two people from the same employer on the steering

committee at the same time. If uh a third person from the same company were to be elected, one of the first two would have to step down for that person to take the seat. So, it isn't possible for a hyperscaler to like take over Kubernetes by force. That's not a thing. And um personally, none of them have tried bribing me yet. Um I do I do like

free stuff, but um so they're welcome to give me free stuff, but I'm not bribable. Um and I don't think any of us are. We weren't hired or elected We weren't hired at work for these positions, and we weren't elected because of where we work. Um that's cuz I cuz I work for a tiny startup and I got elected. So, like we don't have the voting block

to force it to happen and it still happened. So, uh none. Um Uh on on that thing is it's that's important as a steering has this mechanism to protect the project of of this take over. So, it's not that there are seven members right now. You can only have two members from each company. And then we have a majority vote for Yeah. Yeah. >> Uh you need

four members to agree on some change and then there is a super majority vote for all the more >> The minimal routine work is four, which basically is the majority. For more significant decisions, we will require a super majority, which is basically six of us has to say yes. Uh when it comes to the majority of the decision-making or whenever we're making any kind of public statement,

um and trust me, you don't want to know what kind of stuff people ask us to do a public statement we are trying to make sure that all seven of us agree on what the wording is and what we want to say. And usually only when the seven of us agree that yes, it's a good decision. Yes, we agree on the wording. We go forward. >> Yeah,

we wouldn't do a lazy consensus unless it was an emergency. Um if it's a public statement, at least. Um we have 2 minutes left and one question that I can answer fast because we talked about this at the maintainer summit. Um how about AI review tools? This could actually help maintainers do a PR module that triggers it. Um yeah, so we're not going to replace reviewers entirely

with an AI tool. Like we need humans in the loop there, but we are definitely open to some kind of AI tooling that handles the toil for us or functions as uh somebody had a really good idea at the unconference at the maintainer summit the other day that uh not only run. Yeah, look at her. Uh for like kind of an AI linter that runs before a

real human reviewer looks at it cuz there there is a lot of like little stuff that takes reviewer time to catch before we realize that a PR is no good and we need to just close it. And it would be good if a robot could handle that for us. Some of it prowl can do and it doesn't require AI. Some of it is prowl just like asking

the user questions. Um, then that's not an AI problem to solve but like yeah, totally. If you have a thing that you would like to build for us um, that is like a pre- review linter we're happy. Uh, yeah, but it commits. Doesn't it? We can look into it. Um, I think Copilot is on for our work but um, yeah, we can look into it because it's

it's definitely a thing that we are open to doing. We're not like Mhm. We can we can for sure look into that. Um, I don't like some of it we're just going to have prowl do by itself. >> What is the sentence? I want the AI to do the dishes and the other thing. >> Yeah. That that's how that is in my opinion, right? Uh, that is

us for time. Um, thank you for coming. Thank you for asking us questions. Um, if you have more questions later we are all easily accessible online, on slack. Hi. >> Hey. Thank you.