 All right. Start the timer. Five minutes. All right. Thanks everyone for joining me today. My name is Cynthia Thomas. I'm part of the Kubernetes networking team at Google. So let's talk about where did all my IPs go when they start building Kubernetes clusters? A lot of you are going to rather love me or hate me after this. Oh, my slides look different. We like yellow, right? Okay. So why do I need IPs? First of all, Kubernetes uses the Internet protocol for addressing for network communication. And that's for two fundamental networking reasons that Kubernetes clusters dictate. So the first being pods need to communicate with other pods in the cluster without using NAT or network address translation. And also agents on a node need to be able to communicate with pods on the same node. So we use IP for that. There are several implementations of IP addressing depending on different architectures. And those can be attributed to different networking models, flat, island modes, but that could be a whole other talk. So let's talk about where did all my IPs go when I started building my Kubernetes clusters? So what are those IP requirements for a cluster? Well, there's at least three big IP blocks that are required when you're building a Kubernetes cluster. The first for pods, also for nodes, and then finally for services. So since the early days of Kubernetes, when we build a cluster, we assign large blocks for these Kubernetes constructs. And that's because we didn't have a great way to adjust cluster-wide allocations back in the day. But this actually in turn caused organizations to face challenges when they assign networking IP ranges and such to Kubernetes operators because private addressing can be a great fragmentation problem within their organization, taking into account various types of existing workloads that already exist in consuming private addressing. And finally, when you think about what happens when you outgrow those blocks that you've assigned to a cluster, what's a good way to move and grow your workload? Do you have to build a new cluster and migrate over? This is something that's not easy for Kubernetes operators to handle. So how have we been making it easier in the Kubernetes community? Well, the first is single-stack IPv6 and IPv4-only support, but namely IPv6-only support, to tap into a whole new addressing scheme, IP address family, that's mostly untouched, minimizes IP conflict. But what if your workloads aren't ready to be v6-only? It was difficult to have a migration path to get there. So next, and most recently, we have introduced dual-stack IPv4 and IPv6 support for Kubernetes clusters. So this helps the story of migrating to v6-only, ensure you can reach v4-only services still, and make sure your application's ready to move in that direction. Finally, we've also introduced multiple cluster-siders support for Node-IPAM. What that means is you no longer need one large contiguous block for your pod-siders. You can add discontiguous blocks and continue to grow as your application, as your workloads grow on your cluster. So which caps are on the horizon that are going to help us? We have the first being multiple service-siders. So what does that mean? Similarly to the multiple cluster-siders, now we can add and actually tune the allocation of service-siders. So we can change that sider size, we can actually tune the IPv6 default, so to meet some of the best practices on the IPv6 side. So something along the lines of what I expressed earlier with the pod-siders. The second is actually reserving static and dynamic allocation for service IP ranges. So this comes in the scenario of minimizing IP conflicts when you might have specific services that need a static or specific service IP. So this new cap is actually helping define what that service range looks like in terms of balancing the fraction that is reserved for static versus dynamic applications. So where will all my IPs go? Well, with those changes that I've mentioned that we've introduced and are up and coming, we can think about the way we move forward for best practices when building Kubernetes clusters. So what does that mean? Let's think about maybe starting with a smaller allocation for these IP address-siders and slowly building and adding dynamically new-siders for the relevant ranges and then build up. The second point is Kubernetes is actually making that push for IPv6. This is what we're actually seeing more and more organizations want to move there. And this might just push what we've been talking about for decades in the networking industry. So moving to IPv6, which is really exciting. And I'm out of time, but before I take off, I want you to get your thoughts on what do you think about mixed-mode service? So a mixed-mode service. We want to hear back at the networking community whether you'd like to mix single stack and dual stack for a service. That's the limitation today. So we'd love your feedback on that. And that's my time. So thank you very much.