 Hey, everyone. Today I want to talk to you about Kubernetes, the community, and long-term support. But first, let's talk about how AI tools are making it easier to deal with complexity. Like this OpenAI QPCTL plugin that my co-worker Sirtash made. Large language models are helping us create new things we can create YAML to deploy applications. For example, we could say, QPCTL AI, create an engine X deployment with two replicas, and then we get the YAML. These tools are going to make all of our operational headaches go away. Cluster upgrades are going to be super easy, right? Let's use that plugin again and try to upgrade a cluster. Oh, well, that's kind of a bummer. Upgrading is a complicated process, and we can't just generate some YAML to do it. OK, so then how do we upgrade? Well, OpenAI says we should consult the Kubernetes docs. Shout out to SIG docs. The docs are pretty good. But I'm not ready to give up on AI assistance just yet. So let's ask Bing how we upgrade a cluster. OK, so there's some steps there. It seems like a lot, but I think it's pretty straightforward. We should be able to apply these to all of our clusters across our whole fleet and upgrade things, edit some YAMLs, and we'll be good to go, right? We'll do this pretty quickly. But the reality is that even in 2023, cluster upgrades can be pretty complicated and time consuming. And operational concerns, like maybe you're running bare metal servers and can't get new capacity, or you're in regulated environments that maybe have lockdowns or tight windows when you can do things, might make it difficult to upgrade each version, and suddenly you're upgrading it across four versions or more. Sadly, this isn't really a new problem. So let's take a trip back to 2018. Kubernetes 1.12 is just released. It's the very first release I got to work on. It seems like so long ago. And there's a discussion in the community about the frequency of releases. Are we doing it too quickly, too slowly? Maybe we should do more. How long should things be supported for? What about LTS? From those discussions comes a proposal to start up a new working group inside of Kubernetes called the Long Term Support Working Group. There were a lot of questions to answer, and a lot of people were involved. And over the next two years, a lot of data was gathered, a lot of discussions happened. And at the end of 2020, a new Kubernetes enhancement proposal, or a CEP, was submitted to change the support period from nine months to a year to better align with business cadences. Getting this kind of change approved involves a lot of work. So if you've ever done a CEP, let's give a shout out to these folks, because it takes a lot to do things across SIGs like that. Once this was complete, Working Group LTS had really run its course and was sunset. But change kept happening. A lot of work was done over those intervening years. And we've gone from having four releases a year to three. We've gone from having beta APIs by default to only having stable APIs by default. We also have production readiness reviews now that make things more stable. However, the question remains, is it easier to do upgrades and stay current on things? Seems like maybe there's more work to do. We hear from customers all the time that it is still hard to keep current on things. And it's a theme we see in community surveys as well. The production readiness team does a survey every year to kind of understand how that process is working for making clusters more operational. And this is the survey data from the most recent one done in May of 2023. And we can see that a large portion of people are still running unsupported clusters. So it seems like that's still a challenge. Where do we stand with LTS? Can that solve the problem for us? Let's ask Bing again. Bing is going to help us out. OK, so we see Kubernetes as a project still does not have LTS. But we see vendors are starting to bring that support forward. Oh, but Bing thinks we're going to have 128. We're super excited to have 127 in AKS. But we're not planning to do 128. But it brings up a great question. Which version should be LTS? Which versions? Can we align on that? And we wanted to discuss this with the community. So at the Contributor Summit in Amsterdam, we met with end users, vendors, and a number of other people to have a lively discussion about what blocker still exists. Can the project even afford this? There was an instant agreement that we should do LTS, but we agreed to restart the working group. And at the Contributor Summit, we came with a plan. And we have a new working group that's been founded, being led by individuals from Google, AWS, and Microsoft. Many other folks that were in the working group before, but most importantly, you. We started meeting in August, and we are on a path to determine if LTS is right for the project. But to get where we're going, we're going to need your help. You could help us today by answering our survey about friction of doing Kubernetes upgrades. We're going to collect a lot of that data to help us determine what path we need to take. If you'd like to talk more about this, you can talk to us at our maintainer track session tomorrow. And we'd love to talk to you more about Kubernetes, Cloud Native, and all things at the Azure booth. Thanks.