Project Lightning Talk: Get To Where You're Going With Kgateway - David Jumani, Maintainer

This talk covers the K Gateway project, which is a Kubernetes Gateway API built on the Envoy proxy. The speaker, David, discusses major updates including the introduction of overlays for customizing Kubernetes resources, allowing users to override niche configurations that are not typically exposed in Helm charts. He explains the integration with hyperscalers like AWS and GCP, enabling routing to cloud backends. The session also highlights the migration path from deprecated Ingress NGINX, offering tools and guides for users to transition smoothly to K Gateway. Moreover, David outlines advancements in mTLS CA validation per hostname, providing enhanced security for multi-tenant environments. The talk concludes with information about the project's ongoing development and community engagement opportunities.

Hi guys, I'm David. I'm an engineer at Solo and I'm a maintainer of the K Gateway project. So the talk today is get to where you're going with K Gateway. So we're going to talk to you about the major updates that have come into K Gateway, general use cases, and how you can use it and how you can use it to get to get to production. All

right. So first off, what is K Gateway? So K Gateway is an Envoy based Kubernetes Gateway API and it it implements the Gateway API. And not just in not just a regular implementation, but it also integrates with your service mesh. It can it can integrate with your hyperscalers or provides hybrid connectivity as well. And look like the start so you can see the start history. So you

can see that we are growing at a very healthy rate. And within the and within last month, we had over 170,000 downloads of our of our product. All right. Moving on to the major updates. So the first update we had was overlays. So think of a scenario where in your you're trying to use an open source project and it and it exposes a lot of configuration via

helm, but there might be some niche configurations that you might be interested in like let's say your DNS config or topology constraint. But those might not be the those might not have been exposed, right? And rather than and rather than waiting for users to raise issues and then coming up exposing those configurations which are pretty simple and and waiting for the next release, what we decided to

do is we decided to go with with what we call overlays. So all our first our common configurations are first class. So they can be like our images, our service type or other, but the less the less the less common ones, those are some things we decided, hey, you know what? Why don't we give the users the ability to override configs? So what we did is we

came up with overlays. So they allow you to customize all the Kubernetes resources that are deployed via K Gateway. So that's your Gateway deployment, that's your that's your Kubernetes deployment, sorry, your K gateway deployment and your proxy deployment. And the way it works is it works via strategic strategic merge patch. So, you have your regular configurations, which you can see here is our K gateway parameter. So,

that will allow you to define how your deployment Sorry, how your proxy is deployed. But, it might not expose something like your DNS config. So, what we have is we have an overlay. So, that will be patched on top of your existing configuration. And then you get the ability to make all these niche changes, which might not be always available via our helm config. So, this way

it totally unblocks users. They can They can patch whatever they want. All the niche cases are completely covered through overlays. Moving on to the next one, we have hyperscaler integrations. So, again, we're not just a regular gateway API implementation, but we integrate with your hyperscalers as well. So, we have your GCP integrations, we have integrations with AWS Lambda, so you can route all your backends to these.

And we're also adding support for EC2. So, here's an example. You have your HTTP route, and you can see that its backend refers to to a GCP backend, which then routes you to the host and the the audience that you've specified. Similar with thing with AWS, you can specify your account ID, your authentication via secrets, and the lambda function. Moving on to in ingress Nginx deprecation. So,

what So, we all know that that ingress Nginx has been deprecated, right? So, what we want to do is we want to provide a seamless way for users to migrate onto K gateway through it. So, there's already an a really good project out there called ingress to gateway. So, shout out to the developers of those. And that allow that has mapped um all these annotations that are

used in ingress to in ingress Nginx to map it onto the gateway API. So, what we've additionally done is we've looked at the majority of use cases, and we've identified 70 to 80% of the common the common annotations, like session affinity, rate limiting, cost. And we are contributing up to to ingress to gateway and we also have a downstream fork to to allow us rapidly rapidly iterate

and have users migrate over. And we also have an in-depth migration guide along with examples. The next one is we have a per listener or hostname base mTLS CA validation. So, the regular gateway API doesn't allow you the the ability to set your CA certificates per hostname. It does it per port. So, if you have the same port sharing having multiple hostnames, you can validate it your

certificate only on that particular port. But, we've given the ability to do it on a per hostname basis. So, this is extremely useful in situations with multi-tenant scenarios that require isolated mTLS boundaries. And this is something we're also planning to help contribute upstream in the gateway API repository. So, here you can see we have a listener policy and we can specify the section name, which is our

listener, and we can add our client certificate validation onto it. The next one is we have worked with gateway API and we now implement gateway API 1.5.1. We have set our conformance report and we also have listeners and we worked with them to get listeners that's promoted and we support it now. And we have more cool stuff. So, it integrates with Istio as a waypoint. So, it

allows east-west migrate east-west traffic as well as as well as it can work as a waypoint. We have Envoy dynamic modules which allow additional flexibility that we can bake into K into K gateway. And finally, Agent Gateway is now in an independent project where it resides along with the data plane. And we recently have a 2.3.0 beta 3 release. And get involved. We have a contra fest

tomorrow and we have a kiosk tomorrow as well. And you can find us on our on our website. You can get into us get in touch with us on Slack and you can join our community meetings. Thank you. All right. Thanks, David.