 Hello, I'm Locky Evenson with Microsoft Azure. If this is your first CubeCon, CloudNativeCon, welcome. Joolstack work for Kubernetes began in late 2017. If you're at the last in-person CubeCon in San Diego, autumn of 2019, you may be wondering, wasn't there already a keynote about Joolstack? Are we actually living in a time warp? Because that would explain a lot. Spoiler alert, no time warp, no time travel, but yes. Tim Hocken of Google and Cal Hennedak of Microsoft talked in their 2019 keynote about the alpha release for Joolstack. And then came 2020, anybody remember 2020? When all our plans took an unexpected turn. In the case of Joolstack, we ran into challenges with the implementation. That's where we learned the first lesson. The simplest change might not be the right one. Sometimes you have to tackle the giant intimidating refactor. Back then, a Kubernetes service could only have a single IP family. So to create a Joolstack service, you needed to create two services, one IPv4 and one IPv6. Turns out end users did not wanna do this. Finding that out early, well, that's the beauty of alpha. Sure, minimal change to the, minimal change to this services API was the fastest way to allow Joolstack. And only after exploring that path did we fully realize that the complexity tax on users was way too high. No big deal. Let's just rewrite the Kubernetes networking stack. What could possibly go wrong? Right? That brings us to the second lesson. The Kubernetes project is vast and it seems hard to make big changes. The process is too hard. It's just too much. The reality we experienced is that, yes, change is hard, but possible. Reach out to those, not so horrible geese wandering around in the community. Community collaboration is the strength of Kubernetes. We iterate and learn. We make big changes in the case of the services API, the Joolstack PR pull request. We had 11,088 lines added and 3,432 lines of code removed from the networking substrate of Kubernetes itself. This was definitely a look ma, no hands moment, riding on a bike, hoping that we don't fall over. With a lot of eyes on alpha, we were ready to go to beta. And I say beta, you say beta. I say tomato, you say tomato. And 1.21. Beta features in Kubernetes are actually on by default. Don't tell your mom. And hey, the networking infrastructure has Joolstack where the feature gate is enabled on a given cluster or not. And surely the code was perfect from the get go. Yeah, right. Yeah, of course not. The community found and fixed bugs together. And the Joolstack feature is slated to go stable in the upcoming 1.23 release. A round of applause for the community. Thank you. The third and final lesson, it's really hard to land an enhancement in a single release, but you don't have to pay attention to the release schedule, the timing for when you land your KEP and your code matters. You'll need a production readiness review and testing and docs. The release team is us. It's you Ray, it's me. With a little upfront planning, we could all be that much happier. It's worth remembering why we embarked upon this journey in the first place. IP addresses are not infinite, believe it or not. Public IPv4 addresses have been largely exhausted. And when you're talking about the flat network address topology of a Kubernetes cluster, even IPv4 addresses are going to run low. Joolstack support removes such scaling limitations with native IPv6 routing to pods and services, while still allowing a cluster to use IPv4 as needed. The future is IPv6, Joolstack is the bridge to get us there. And on this very long road to Joolstack and Kubernetes, we learned three lessons. The simplest solution isn't always the right one. Change is possible with community collaboration. And we wanna time our changes to work well with the release schedule. In short, we can do hard things together. If you wanna talk about Joolstack Kubernetes or see it in action or anything else open source, you can find me and my team at the Microsoft Azure booth on GitHub and in the community. Cheers.