 Hi, I'm Mark Church, Product Manager from Google Cloud, and I'm here to talk to you about the Kubernetes Gateway API. The Kubernetes Gateway API is an open source specification created in the SIG network group for modeling service networking in Kubernetes. So very much like ingress or service resources, it's intended to up-level and be an evolution for service networking Kubernetes that is still a generic standard supported by a variety of different companies, projects, and implementations. There have been a variety of different contributors that have been contributing to and helping design the Gateway API over the last year since it was first proposed at Kupkan, San Diego. And they're already beginning, starting to begin a couple different implementations of the Gateway API that already exists, including ones that model cloud load balancing, cluster hosted proxies, and more. Don't forget to check out the Gateway API SIGs website where you can see more information about the Gateway API, including how to get involved with the community, attending one of the meetings, joining the Slack, seeing how to use the Gateway API in one of the available guides that we have, or just checking out the implementations that currently exist that's growing every day. You might be asking, what's wrong with Ingress? What does it not do for us, and why do we need another new API resource? It's a very valid question. Ingress has a lot of good things going for it. Well, it's very widely adopted. There's many implementations and Ingress controllers that exist out there. It's easy to use and understand. It does basic host and path routing, along with TLS and the ability to reference services. But it's very basic. And so ultimately, Ingress became a lowest common honor and denominator API. It was not very expressive. It was not extensible, other than through annotations. And as a result, it's become not very portable. And partly, this is because it's a tough challenge. There's diverse implementations between hardware load balancers, cloud load balancers, and in-cluster proxies that all have different capabilities, constraints, and ways that they operate. And there's also diverse models in which load balancing really occurs. For instance, there are middle proxies, service mesh, GRPC, all that can do what one might call load balancing in slightly different models. But they have a lot of similarities and overlap between them. And so this is really the challenge of modeling service networking in a generic way. And so that's where Gateway really came about. It improves upon Ingress in four major ways. And the first is that it's role-oriented. And what this means is that different personas or roles that use load balancing within a Kubernetes cluster can have resources that align to the roles and responsibilities that that role needs, that persona needs. It's also expressive in that it provides more features and capabilities than Ingress does. Things like header-based matching or weight-based load balancing. There's simply more things within the core API to do what modern load balancers are expected to do. It's also much more extensible. Extensible in that it has more extension points within the API for projects and vendors and implementations to put their proprietary or custom capabilities to layer it on the API, which allows them to use it without having to fork or rely on their own custom resources to get this done. So that allows load balancing and service networking to continue using a core API while having some of the implementation-specific capabilities lie within the extensions. So let's take a look at the resources that the Gateway API has. So there's a couple new ones that you might see. Gateway class, Gateway and HTTP route. And so these are all different resources that make up pieces of what used to be Ingress where Gateway models the actual underlying data plane or load balancing that's performing the routing. The HTTP route models the actual configuration of the routes and the Gateway class is a template, kind of like a storage class for defining what kind of gateways can be instantiate. So let's take a look at these. So in my cluster here, I have a foo v1 and a foo v2 deployment running. What I'm gonna do is I'm gonna show you some of the resources that I've deployed in my cluster. So one, let's take a look at the HTTP routes I have. And it looks like I have one foo route that matches for foo.com. So let me just show you what I've deployed earlier. And it looks like this. And so at first blush, this might look a lot like Ingress, right? So it matches for the hostname foo.com. And it looks like it's forwarding it to actually two services here, foo v1, foo v2. And it's using a weight of 50. So this is one of the aspects where it's more expressive. It has more capabilities built into the core API. Weights is one example. That's something that wasn't possible in Ingress. And there's some other things here. One thing that we will notice. So let's go ahead and just describe this HTTP route. And we realize that, well, there's no VIP anywhere. And that might be kind of interesting because Ingress has a VIP and a port that it's actually exposing traffic on. So where might that VIP be? Well, I'm gonna go ahead and let's look at the infer name space that I have. And let's look at our gateway resource. So we have one gateway here. Describe gateway internal AP. And so this gateway resource is what actually represents the load balancer. And it references a gateway class. It has listeners that describe exactly what port protocol are being listened to. And it also has an address field with a value. So this is actually the IP address of our load balancer and where the traffic will go to get into the load balancer. And so we have split up Ingress into a couple of different resources and this actually has a lot of power. So let me go back to here. So if we can see here, because we're allowing a load balancer to be split up or at least to be shared by different teams through configuration, it allows teams to share underlying infrastructure more easily and also allows platform administrators to apply policy and centralize certain aspects of the operations of that load balancer in a way that suits their role better. So this is really the role-oriented aspect of the API is that some of these separation responsibilities can be done because the API resources are separated. So if we go back to our cluster and I'm gonna go into the bar namespace and I could see that here is my bar route with a match for bar.com that's probably sending it to the bar service. So let's just look really quick bar out. Yes, so it's doing, so these routes are getting aggregated and then applied to the same underlying load balancer using standardized merging and conflict logic between the routes. And so this allows the sharing of infrastructure to be much more easily done in a multi-tenant and shared cluster. So now I'll show you how the gateway API can also be used for multi-cluster load balancing. So in GKE's implementation of the gateway API we have been working on a multi-cluster controller that allows multi-cluster gateways to exist. Effectively what this does is it programs the Google Cloud Global Load Balancer to be able to load balance at multiple GKE clusters around the globe that live across different regions and different data centers. But this is all done through a centralized configuration model using gateway resources. So this supports both multi-cluster load balancing for internal load balancing, external load balancing and also all the features that come along with gateway such as traffic splitting, traffic capacity, traffic mirroring and advanced routing between clusters which enables a lot of very powerful use cases. And so in this example that I'm about to show you I'm gonna show three different common use cases that might be very useful when you are onboarding a new cluster. So let's say you have a GKE2 cluster that is already serving production traffic and you want to onboard a new GKE cluster maybe because you want to scale more or you just wanna have disaster recovery in any case you need to onboard this new cluster. So at first to de-risk the migration or you might want to send some synthetic traffic to GKE3 and so for that you might just wanna use some header-based matching to send some specific requests that are targeted to GKE3. And then you would want to maybe mirror production traffic from the production cluster or from the GKE2 cluster to the GKE3 cluster. So this would allow you to do capacity testing because you're mirroring real traffic to the GKE3 cluster without actually responding to the clients with that traffic. And then lastly you're gonna wanna do blue-green traffic splitting so you can canary a percentage of the actual production traffic to the new cluster until you validated that everything works fine and then you can put them both at full capacity. So this looks a little complicated but I'll explain it. We're using the service export API and if you remember the service export API both aggregates and exports endpoints outside of the cluster. And it makes those available as service imports in all the other clusters. So we have a service export foo that represents all four pods. And then we have a service export foo GKE2 that represents just the pods on the GKE2 cluster. And then we have a service export foo-GKE3 that represents just the pods on that cluster. And so let's go ahead to CLI and show you how this works. We're now sitting on my Kubernetes cluster. We can see on the right-hand side I've got Kubernetes cluster. I've got three running. I'm gonna look across all of them and see all the pods. I've got foo V1 pods running on clusters GKE2 and GKE3. I'm currently on GKE1 where I have my gateway resource. So it's a multi-cluster gateway of the class GKE Layer 7 RILB. So this is a Layer 7 load balancer running in GCP. I'm gonna look at my service exports which again is the resource that's used to export services across all the clusters. So I could see that foo exists on both. And so that's being aggregated while GKE3 and GKE2 are just specific to those clusters. We can see that the service imports exist everywhere which means that the exports were successful. They've successfully exported those pods across all of the clusters. So let's look at the first route that I have deployed. It's simply matching on hostname foo.com and sending it to the service import foo-gke2. So what this means is we're gonna send traffic just to the foo gke2 which represents the pods just on that cluster. As expected, a traffic is only being received from gke2 which proves that the routing rule does work. So let's go ahead and apply a second routing rule now. So that's configured and I'll show you what this looks like. Okay, so here we have again matching of foo.com except we're using this header, mvcanary, and sending that traffic to just foo-gke3 while the remainder of the traffic goes to foo-gke2. Note that we're referencing the service import resources here. We're not actually addressing this to services. We're using the service imports as those represent multi-cluster services that we can point to across cluster boundaries. So we add the canary header here and the mv header and it does look like we're getting routed only to cluster gke3. So that proves that the header-based routing across clusters does in fact work. Let's go ahead and apply our final route here which is gonna do the weight-based traffic splitting between clusters. So that's deployed. Now I'll show you what it looks like. And I'm referencing three service imports here too. I've got a weight of 70% against cluster gke2 and a weight of 30% against cluster gke3. Let's see if it works. And we're gonna send traffic to foo.com again and it does look like we're hitting gke3 and gke2. Looks like a little bit more gke2 than gke3 which is expected. So great success. It does look like multi-cluster load balancing using cloud load balancers is possible through a Kubernetes native way. Thank you for watching and I hope you learned something.