 So hello, everyone. Thank you for coming to my talk, Makeway for the Gateway. My name's Christine. And I work in developer relations at Google. So I focus primarily on Kubernetes and service meshes like Istio. And a cool part of my job is I get to prototype a lot of new and exciting technology in the open source world. So today, we were going to cover a little bit of history on the Gateway API, Istio Gateway versus the Gateway API. We're going to speed run through some demos. And then lastly, we're going to wrap it up All right, to set some context, why the Gateway API? So there's a good talk that goes more in depth about this. I don't have 40 minutes, but I highly recommend that you tune into that later. But the DLDR of that is that the Ingress API, you know, it was good. It's a core stable API that comes out of the box with Kubernetes, but it lacked advanced use cases for people who wanted to implement Ingress controllers. And this led it to bloated annotations and it was hard to port over different implementations. And it was an ideal for sharing between roles. We had everyone in the same kitchen, you know, cooking and touching the same resource, which was not a smooth experience. And so the Gateway API was introduced to be a super set of the Ingress API. And as of July 2022, the Gateway API graduated to beta, which is really exciting. And so what is it? The Gateway API is a standardized set of APIs, a modern interface for deploying L4 and L7 routing in Kubernetes. It's designed to be generic, expressive, extensible, and role-oriented. I really want to highlight the role-oriented part because going back to the Ingress API, now we have these separated resources, which mirror and you can have non-admin people doing non-admin tasks. And we'll go a little bit more into detail with that later. So I know I said the word Gateway a lot. I'll try to make it as clear as possible when I talk about the Istio Gateway versus the Gateway API Gateway. Okay, there's a lot of dragon in the open source worlds. I highly recommend this quick video because naming things is tough. All right, so what's the difference between the Istio Gateway and the Gateway API? So first off, we have the CRDs and the APIs are different. With Istio, you get access to all the good things like the Gateway Virtual Service Destination Rule after you install Istio into your cluster. And then with the Gateway API, after you have your cluster spun up, it doesn't come out of the box with core Kubernetes, so you have to run a simple cube cuddle applied to get access to the resources like the Gateway class, which describes your load balancing infrastructure. You have your Gateway, which is an instantiation of your Gateway class. And then lastly, you have routes like HTTP route, which routes traffic towards your services. And so these are the beta resources that you have access to now, but in Alpha, you also have access to these other routes like TLS, UDP, TCP and GRPC. So you can see that these are route specific, sorry, protocol specific routes designated for different protocols, whereas the Virtual Service is kind of like the catch-all for everything, which is really nice. And then also you have this new found ability to switch gateways because it is a standardized API. So instead of just sticking to one, now you have the ability to port over. So if you want to try a contour implementation, you can, or you want to try maybe an engine next, you can, and it's really easy. And lastly, something that's cool between Istio and the Gateway API is the automatic Gateway management in itself. So on the Istio side, you get your Gateway deployment and your service when you run Istio cuddle onto your cluster. But then if you want to add like a new port, you'd have to redeploy and reconfigure. And so you'd have to manually do that, which is a little bit of a painful point. I've run into errors like debugging and feel like, oh, I was missing a port and I had to rebuild it. But with the Gateway API, now it's kind of like the source of truth. So it automatically does it on your behalf, which is such a nice user experience. All right, so now we're gonna run through some demos. I recorded my demos as gifts, but I'll be talking through them. And I, for some reason, decided to choose three because the Gateway API is so exciting that I had to share everything. So for the setup, just to set the context before I run through is that I have my cluster and then I have my Gateway, which is gonna be maintained by your cluster operator. And then you have your HTTP route, which is gonna be managed by your app developer. And then I also have an HTTP bin sample app, which is a well-known sample app. And I just am exposing my get path with my HTTP route. All right, so I just want to compare the virtual service versus the HTTP route. You can see on the left that, you know, for the most part they both are quite similar. The logic flows through them. And you can see that you can refer to where your traffic is coming from, from this parent revs versus the Gateway. So you have your namespace and then your name. So that's something that carries over from the Istio side of things. All right, so this is my gift here. So I'm just kind of doing a proof of concept that this is the setup I have. I have my Gateway in my Istio ingress namespace. I have my external IP. And then I have my HTTP route there. Ta-da. And then I can just show at the bottom pane that I can do a simple curl and I get a 200 back. So all looks good. Okay. And so let's say that as an app developer, I want to add another path, but then I also want to add some headers to my get path. So you can easily do that with this HTTP route here. So you can see that I add a filter there with a request header modifier. And then I also add another path for the headers path. All right. So then here I have two panes split up at the bottom. So the bottom left is kind of just showing a constant curl on the get. And then on the bottom right, I have a constant curl on the headers. So you can see that after I apply the HTTP route, the new one, you can see the hello world will be appeared right there. Magic. All right. Now let's speed run through traffic splitting. So let's say I have version one and version two of HTTP bin. And I want to roll out 25% of the traffic to the version two of the app. So again, as the application developer, you can easily do this by specifying weights with the different versions. And then you just have your ideal weight that you want to split between. So I have 75 and 25. And so now in this GIF, I have a constant curl at the bottom again. And then you can see that I'm searching on version one versus version two of it. And so after I apply my new HTTP route, I get a traffic split happening immediately. And you can see how easy that is. If I can do it, you can too. Okay. And then lastly, I'm gonna add a new gateway. So this is going back to the idea of portability between gateways and how easy it is. So right now I have the Istio implementation of the gateway. And then I want to try out, say like the GKE gateway, which is just a Google Cloud load balancer. And you can point them towards the same HTTP route. So as the cluster operator, all you have to do is instantiate a new gateway. So you have right there on the left, the GKE L7 Google Cloud load balancer. And then on the right, you just have to specify another entry for your parent roughs where you can say, hey, I want to accept traffic from this new gateway. And so in this GIF, I have just me applying the new resources there. And then I have, I'm just checking the gateways there as well. And you can see the external IPs for both of them. And then in the bottom panes, I'm just curling both the Google one first, which is a 200, cool. And then the bottom right one is just the same old Istio gateway controller that I had previously. Cool. All right, so now what? The gateway API looks so cool, she'd roll out everything, you know, forget everything. No, don't do that. It's cool and it's powerful. And hopefully you can see how flexible it is with the rolled personas being split. And then also the standardization. So you can split between different implementations way easier, but you know, if your current setup works for you and don't switch, you know, you don't have to adopt everything that's new into the CNCF, I promise. But hopefully you can see the benefits of what it's designed to be. And then also another exciting thing is the gamma initiative. So you can probably see that the Istio resources and the gateway API resources are quite similar. And you're like, oh, I have to learn another thing. The gamma initiative is here to, you know, create a more holistic journey between what the gateway API means for service meshes in the world because we're here at ServiceMeshCon. This will probably impact you sometime in the near future. So this working stream is investigating that. You can also check it out, you know, get involved. There's the GitHub repo, the Slack channel, and then the website, which has a great guide detailing different implementations and different use cases for it. There's also a lot of up and coming talks. This KubeCon, so I recommend that you check them out because that will be there as well. And with all that being said, hope you enjoyed my lightning talk. Again, my name's Christine. If you have any questions, please find me after.