Cloud Native Computing Foundation ServiceMeshCon NA 2022, 1 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Make Way for the Gateway - Christine Kim, Google

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Lightning Talk: Make Way for the Gateway - Christine Kim, Google

The Kubernetes Gateway API has graduated to beta! As the successor to the Ingress API, the Gateway API has been created with the goal of having the superset of abilities previously provided - with more. The legacy ingress in Kubernetes has been limiting in the past, so what does this mean for someone who has grown comfortable using Istio’s Ingress? Will you have to learn something new again? Have no fear - we’ll go through a quick run down on the similarities and differences of Istio’s Ingress Gateway and the new Gateway API, and see a simple demo on how to use the Gateway API. We’ll mainly focus on the 3 main APIs (GatewayClass, Gateway, HTTPRoute), and see how the setup enables role oriented behavior and work towards having better DevOps practices.

A

So hello, everyone thank you for coming to my talk, make way for the Gateway. My name is 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 as I got to prototype a lot of new and exciting technology in the open source world.

A

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 with some key takeaways 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 ladr of that is that the Ingress API, you know it was good.

A

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 wasn't ideal for sharing between roles.

A

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 superset 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.

A

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 world I highly recommend this quick video, because naming things is tough, all right.

A

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.

A

With istio you get access to the all the good things like the Gateway virtual servers destination rule after you install istio, enter cluster and then with the Gateway API after you have your cluster spun up you, it doesn't come out of the box with core kubernetes, so you have to run a simple Cube cuddle apply 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, UDC, UDP, TCP and grpc.

A

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 newfound 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.

A

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 in your service when you run istiocuddle 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 painful Point I've run into errors like debugging and just be like.

A

Oh I was in a single port and I had to rebuild, deploy 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.

A

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 going to be maintained by your cluster operator. And then you have your HTTP route, which is going to be managed by your uh 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.

A

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 refs 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 guess here. um So I'm, just kind of doing a proof of concept that this is the setup I have I.

A

Have my Gateway in my istio Ingress namespace I. Have my external IP and then I have my HTTP route there 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.

A

So as you can see that I added 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.

A

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 httb, then and I want to roll out 25 of the traffic to the version two of the app.

A

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.

A

If I can do it, you can too okay and then lastly I'm going to add a new Gateway. So this is going back to the ideal, the idea of portability between gateways and how easy it is so um 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 cloud Google Cloud load balancer and you can point them towards the same HTTP route.

A

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.

A

You just have to specify another entry for your parent refs, where you can say: hey I want to accept traffic from this new uh 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 eyepiece 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.

A

One is just the same old uh istio, Gateway controller that I had it previously cool all right. So now what the Gateway API looks so cool. Should you roll out everything? You know, forget everything?

A

um No, don't do that uh it's cool and it's powerful and hopefully you can see how flexible it is, but the roles of 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, I'm, don't switch.

A

You know you don't have to adopt everything, that's new into the cncf I promise, um 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 istia resources in the Gateway API resources are quite similar and uh you're like well. 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 service mesh con.

A

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, I hope you enjoyed my lightning talk again. My name is Christine.

A

If you have any questions, please find me after okay.