Hello everyone, and welcome to Comp 42, cloud native 2023. My name is Shane Utt. I'm an engineer who works on Kubernetes networking at Kong. I'm also a chair of Kubernetes Networking special interest group and a maintainer of Gateway API. And today we're going to talk about Ingress and going beyond ingress in kubernetes with Gateway API. So for this talk, our agenda is we're going to do a review of the Ingress API. It's likely familiar to many of you, it's been around for a long time. Then we'll do an introduction to the Gateway API, why it exists, and what it can do for you over Ingress. We'll do an overview and anatomy of the various API resources that are available in Gateway API. We'll talk about Kong's involvement with Gateway API and our use of it, and we'll provide a brief demo that shows you it in action. And then we'll discuss upcoming features for the project and talk about subprojects and basically what's coming next in Gateway API in the coming years. So to get started, let's talk about Ingress. Ingress has been around for five plus years. It's simple. It provides host and path matching. You can forward to a service, a Kubernetes service, and you can do TLS configuration. On the right here you can see the basic example where we have a demo app that's listening on port 80 for HTTP traffic, and Ingress is exposing that so that you can access your demo app. But there have been historically many limitations with Ingress, things that we've learned over these years. One of the big ones was for 22 plus implementations. There ended up being a ton of non portable extensions. Annotations ended up being everywhere, and still are. We call this sort of the annotation Wild west, where no two ingress controllers behave, usually even like remotely, that similar to one another. There was an insufficient permission model and it was mainly focused on HTTP traffic. There are some caveats to this, but for the most part it's about HTTP traffic. To a lesser extent, it was limited to north and south traffic, which we'll get into a little bit later. And then it was heavily reliant on the Kubernetes service API. It uses service you kind of are bound to service. So these are some of the things we want to change. And in general, there are some very high level things that were the impetus for change here, extensibility, multiprotocol support, and conformance. So extensibility with conformance was a really big part of this. We wanted to have conformance test suite conformance levels, which we'll talk about in a little bit, and basically be able to have conformant implementations while also accounting for the future of extensibility. And then multi protocol support literally means we wanted to be able to support GRPC, TCP, etc. So with that and these impetuses for change, let's talk about what Gateway API is, how it tried to bring around that change. So Gateway API is the next generation of Kubernetes routing and load balancing APIs. It is literally the successor to ingress. New features are not being developed for Ingress, they arent being instead developed in Gateway API. It's designed to be expressive and extensible. It has multiple API resources. There's not just ingress and ingress class anymore. I guess it's Gateway class, gateway and HTTP route, which you can see from the diagram over here. And there are other routes like TCP route, GRPC route, which we'll talk about later. And it's role oriented. So a cluster administrator might be responsible for your gateways, but then an application developer might be responsible for the routes to their applications, et cetera. At a high level in kind of mostly focused on HTTP. These are some of the features of Gateway API. We have TLS configuration, HTTP matching with host path header method, and query params. We also have cross namespace gateway to route binding. We have cross namespace forwarding HTTP filters with header modifiers, request mirroring, request redirects, and URL rewrites, and weight based traffic splitting. Quite a few features, and to be clear, the top are the features that are available to you in ingress today, and the bottom are only available in Gateway API today. So how do we get this extensibility? Well, we came up with a concept called conformance levels. We have three conformance levels, core, extended and custom. Core is where every implementation of Gateway API has to basically adhere to this conformance level has to meet the standard here. Extended is where it's optional. An implementation can opt into this, but we expect that only a few implementations can implement an extended feature. Custom, which also is kind of like implementation specific, kind of goes into the we are aware of this feature, we don't necessarily provide a whole lot of guidance for it, and that's how we can kind of at least bring some of that back into the upstream and make sure that other implementations are aware of things that are out there. And for anything along this path, it is possible for them to graduate up. So like custom could become extended as implementations start to adopt something, extended can become core and so forth. So we talked a little bit about high level what Gateway API is. There are some specific resources, API resources that we're going to cover. These are kind of the current ones that are in beta, and the most commonly used ones, gateway class, gateway and HTTP route. So Gateway class is similar to ingress class. Your gateways basically are going to attach to a gateway class. And what that does is it tells your operator, your controller, what have you. This gateway class, which may be a named one like Kong, is responsible for provisioning these gateways, and then those gateways are responsible for provisioning these routes. And you can see that from the diagram here, that it's possible with Gateway API to have multiple gateways. And in this diagram, Kong Gateway one, Kong Gateway two. These would be like actual separate gateway instances, actual separate instances of the proxy, all with their own routes and all potentially defined by different groups. Maybe an operator of the cluster is responsible for creating the gateways, but maybe it's different development groups that create the different routes. Just a brief overview, just to kind of take a look at what these look like. Gateway class is very straightforward. There's a controller name, and it basically says this is the controller that's responsible for this and the things attached to it. Gateway can be as simple or as complex as you like, but one of the main things that it's comprised of are listeners, which in this case we only have a basic HTTP listener and then the Gateway class name, attaching it to its gateway class and saying this is the controller that is responsible for me. And then HTTP route, which is one of many routes, and we'll get into some of the other routes later, has rules, basically. It too has parent refs, which says what gateways it's attached to, and that can actually be multiple. It is possible to even do things like migrate between different implementations by having both implementations serve a route at the same time and then removing or adding whatever you need to do as you're kind of moving between implementations. There's rules. And this is similar to what you saw with ingress, a little bit different structure with backend refs, which by default refer to services. So in this case we have a basic HTTP route that is supposed to get HTTP traffic to a demo app listening on port 80 with a service named demo. You are not limited to services with HTTP route. For the back end refs, there's a type field that's optional, that you can add practically anything you wanted to if you have an implementation specific way of doing this. You could do it with Gateway API. All right, let's talk a little bit about what Gateway API is at Kong, what it means to us, and kind of our journey with it. For a high level overview of what Kong is, we consider ourselves the cloud native API platform, with products ranging from API design and testing with insomnia north south traffic into your Kubernetes clusters with Kong Gateway and Ingress, and Kong Mesh for east and west traffic. Our Gateway API journey started with Ingress. Like most people, Ingress has historically been the top user configuration option. It's what most users are using in Kubernetes today to configure their Kong gateway for extensibility reasons, similar to what we talked about in the previous slides. We ended up with custom resource definitions and annotations everywhere. We were part of the annotation Wild west with custom things you can only do in Kong with crdes and annotations kind of available in our product for several years. We wanted to have a common upstream API. We wanted users to not have to learn things that were very specific to Kong, to be able to do things in the networking space. And this was a common thing among multiple implementations in Kubernetes in previous years. So we got together and got involved in the early days and helped drive the Gateway API project, which was meant to, as we've discussed, kind of take it to the next level, take Ingress and step it up a notch. We currently maintain three separate implementations of Gateway API, including in our Kong Kubernetes ingress controller, which we call the Kick, our Kong gateway operator, which we call the KGO and Kuma, and Kong Mesh, which is our service mesh offering. So let's talk a little bit about Kuma. I'm going to focus in on Kuma today, Kuma's implementation of Gateway API. We'll start by just a really simple definition of service mesh traffic. We're going to have services in our Kubernetes cluster and they're going to talk to each other over the service mesh. So you have two services here, both with an envoy proxy sidecar, and they can communicate with each other through the mesh. Well, what if you wanted to be able to get traffic into one of those services from outside of the Kubernetes cluster from the Internet? We have the functionality in Kuma today in the latest release to be able to create gateways, that is, use the gateway resource available from kubernetes and make a Kuma gateway that will create, in this case, you'll see it'll provision an envoy gateway that will then have ingress access from the Internet and then you can create HTTP routes so that in this case, let's say if the service on the left was our demo app, we tell the gateway this HTTP route is connected here to our gateway so that we open up a route to our service for port 80 traffic. Pretty straightforward. And all can be done with upstream Kubernetes API resources. Let's do a brief demo of this and show it in action. So for this demo we have a basic Kubernetes cluster. Actually this is a kind cluster Kubernetes and docker running the Kuma control plane. We're using the Kuma counter demo which is a repository up online. You can grab after this if you'd like. And in it there's a demo yaml which will apply. This creates a small app. Let's take a look here. A demo app which is a web API and a redis where it persists, a counter. Basically the web app is capable of incrementing and decrementing a counter and redis is where it's stored. And you'll see here that we have a couple pods initializing for each, or a couple containers initializing for each pod. One of them is the sidecar from Kuma. So these are connected into the Kuma service mesh. So now what we want to do is we want to get access to the demo app's service. We want to communicate with it and open it up in a web browser. So we can do that with Gateway API and HDB route. By default, Kuma will come with a gateway class. It is just named the Kuma controller. The gateway Kuma controller. You can see here that the Kuma control plane has picked up the gateway class and said, yes, I'm ready to start serving gateways and routes. With this class we have a gateway that we can create. It's really basic. We're just going to open up port 80 80 connected to the Kuma gateway class that we just showed. So let's apply that. Take a look at the gateway. Okay, so the gateway is there. It's been assigned an ip address. It's not quite ready yet. Give it a couple of seconds and it's ready. We should be able to start at least poconet. There we go. This is the Kuma mesh gateway. No routes are ready yet. We haven't actually exposed our demo app yet. So we have an HTTP route to expose our demo app. This is pointing at the Kuma gateway, which we just created to the demo app service which we looked at earlier on port 5000 and it's just doing a path prefix. So we're just going to send all the traffic there, we'll apply that and then we should start seeing our demo API, which you can see the HTML for there. Let's open that up in a browser. So here's our demo app, and what we have here is we're accessing the app through ingress, through HTTP route from the outside of the cluster, and we have the demo app talking to its redis on the inside of the service mesh. So it's pretty straightforward, it's simple. The code's here if you're interested in kind of doing the same demo yourself, but you increment a counter and then it persists in redis. So you can refresh, you can reset it, you can have it automatically update it, et cetera. So that is a very simple way to kind of get ingress traffic into your Kumas service mesh using gateway API. All right, so now that you've seen just the basics of using HTTP route and gateway, let's go a little bit beyond HTTP. Let's talk about the other APIs available, and we'll also talk about what's coming next. So we'll do just a brief overview of what other APIs are available today. Now these APIs are in Alpha currently, whereas HTTP route is in beta and on its way to Ga. We have GRPC support which is in Alpha currently, and we arent building conformance tests and stuff like this to move it on its way to beta. As you can see there's parent refs and rules similar to what we saw with the HTTP route, but also a hostname TLS route which is similar in spec to GRPC route but meant for TLS communications, and also takes a hostname UDP route which can be used for UDP traffic, very basic, as well as TCP route which is similar and is used for TCP traffic. These are part of our layer four story, which I'll touch on a little bit later. And then we also have one that isn't a route called reference arent. This is a particularly powerful API that is actually in beta today, and it gives you the capability of granting a reference from another namespace. So as you can see from the diagram here, if a gateway needs access to a secret in another namespace, you can provide a reference grant which will say yes, that is allowed from the referent namespace. This is actually getting some traction in other places in upstream Kubernetes including Sig storage and stuff like that. So you may actually see this become a more General Kubernetes API as opposed to a Gateway API resource soon has. There's a lot of interest in this functionality. So let's talk about what's coming down the pipeline, what's coming next in the project. There's a lot of things going on. Gateway API is one of the most active subprojects within SiG network. General availability GA is kind of the big next thing. We don't have a specific due date. We'd like it to go out this year. We expect that we'll have three APIs in version one, gateway class, gateway and route, which are what we covered in the demo. Today we are tracking this as the road to Ga and via a milestone called one point. If you're interested to go take a look at kind of how things are flowing as we kind of move towards general availability. We also have the gamma project, which stands gamma stands for Gateway API for mesh management Administration. So the idea here is that we have service meshes interested in using gateway API resources like HTTP route in a service mesh context. For east and west traffic. We have several contributors, including council Istio, obviously Kuma and Kong Mesh Linkerd. There are others. These are just the ones I got a hold of for the talk, and we are currently in the early stages of getting some conformance around how we would use HTTP route. If you're interested in using some of these resources, like in using Gateway API in a service mess context, we would invite you to join. And I'll have a community page coming up here with some information about where to go to join the community and kind of join in on this. Another project upcoming which is relevant to GA is conformance profiles. So we have a conformance test suite today, but you opt into it as an implementer and it's kind of hard to keep track of who's implementing what and who's running what tests. So the conformance profiles project has high level testing profiles like you can subscribe to. I do HTTP, I do GrPC, UDP, TCP. Eventually we'll have mesh, et cetera. And then there's a test suite that you can basically plug your profile and say, I'm going to subscribe to, for instance, HTTP. You'll get the test suite to run with automatic reporting, and then there's a certification process where you can send your report back to Gateway API. So on the right here you can kind of see the pipeline. Kong Kuma, istio, any number of implementations can pick their profiles, run the test suite, get certified, and then produce a conformance report automatically, which they can send back to the project. And this gives us the ability to see what people are actually using in a way that we couldn't really do well with Ingress. So in addition to the conformance levels, which kind of allow us to track things that maybe not every implementation is doing, we can now track who's actually running tests for those and make sure that we're kind of keeping track of what's being used in the ecosystem. This is a requirement for GA. It's currently in a provisional state and it's under active development. We have a lot of other things coming up in the experimental phase. Right now we have layer four support, which is something that I'm personally actively working towards getting into beta. Hopefully this year we have policy attachment. So with all of these APIs that we showed, we have kind of the ability to set up routes and stuff like that. Policy around those routes is something that we want to be able to provide some prescription for, even though that does often get into implementation specific territory. So we have a project just for talking about policy attachment. We have a policy attachment resource template, and we're working towards basically providing the documentation to show people how to do policy attachment for their routes. We also have multicluster services, which is a new project. It's up and coming path redirects and rewrites, which is currently an experimental and should be something that is kind of on its way to standard, hopefully soon. And then in the provisional section, which is kind of newer stuff, or just stuff that isn't has teased out yet. We're working on timeouts, which historically had been something we'd kind of pushed into policy attachment territory. But now we're trying to do some explicit timeouts. So we're experimenting with that. We're kind of looking at how that will look. It's a little hard to do that well across every implementation, but we're giving it a go. We also have a new effort coming up from some members of the community for egress traffic, which is kind of a big thing. So that's kind of a roadmap of what's going on. There's definitely other things going on that I didn't cover. But way down the road one of the things that we're kind of interested in doing is being a replacement for Kubernetes service. So Kubernetes service has kind of become an overloaded API and new requests come in all the time for new functionality on it. And in general in upstream Kubernetes, we're not really in favor of continuing to grow its scope. We want to keep its scope clean because Gateway API has multiple APIs and just a wider berth. It's kind of the place where we're starting to see where we might put more of this type of functionality. For instance, one of the big things we call it kind of like a North Star issue is that we'd really like to see gateway itself be a possible replacement for load balancer type services in the future. Today, many implementations of Gateway API coincidentally or subsequently use service type load balancer under the hood to actually get traffic to their proxy. In the future, we'd like to eliminate the need for that. So you might see a lot more load balancing functionality, things that have been proposed for service kind of heading into Gateway API in the future. So let's talk about what's next for you. If you want to get involved and kind of learn more about Gateway API, first things first, you can just try out an implementation. We have 20 plus implementations and there's like three integrations which are all available on our website, gatewayapi sigs k IO implementations. Go find the one that suits you, set it up, try it out. Obviously I kind of covered this because these are the ones that I've contributed to. But Kong's implementations include the Kubernetes ingress controller, Kuma Kong mesh which we covered, and the gateway operator which there are links here for as well. And you can get started and try, but creating a gateway and setting up some routes, there are multiple subprojects within Gateway API. We covered Gamma a little bit. That's for the service mesh use case. It is in an early maturity state. And again, if you're interested in kind of using these kind of routes or having like a standard upstream Kubernetes API set for service mesh, join the gamma project hit us up on our website under contributing Gamma. Join our meetings and we'll be happy to have you and help us grow this and develop this part, this sub project. Within Gateway API, there's ingress to Gateway. So we understood there would probably be a general need from the end users to be able to take an existing ingress resource and kind of convert that into Gateway API. So we have a tool for that under Kubernetes ingress to Gateway right now. It is capable of doing some of the basics. We want to be able to add things like annotation support and stuff like that. That's in scope, but it's still kind of early in the project, so if you arent interested, we'd love to have you join us and help us develop that and get it to where it's kind of a really robust conversion tool for a variety of different annotations and extensions. It's written in go, you can use it as a command line tool or as a go library. And then we also have a project called Bleaks which is started at Kong as an experimental layer four load balancer written in Rust and using EVPF. It is being donated to Kubernetes Sigs as a testing and reference implementation, something that we're going to use in our CI, and also something that's helping to drive forward layer four support which had traditionally or historically been kind of lagging because of lack of people coming together and being able to help build the conformance test for. So this project helps with that. Plus it's something that we're going to plug into our CI for automated testing and also the control plane written in Golang eventually is what we hope to be like a reference implementation for people building rather building controllers and stuff like that to kind of see how you would implement gateway API. So yeah, those are some of the sub projects. There's a lot of things going on in the ecosystem. We would love to have you join our community. Our website is Gatewayapi sigs caves IO. We have lots of meetings, the main one, which is all you have to go to if you really just kind of want to know what's going on. It happens every Monday and you can find that on our website under community. We have our gamma meetings on Tuesday and we have a code jam meeting, which is kind of like a for fun pairing meeting that we do on Fridays. If you're looking for a really lightweight place to kind of jump in and just see what's going on, that might be a good place for you too. Please feel free to join our discussion boards. We use GitHub discussions for our forums and catch us on Kubernetes Slack. So these are my co maintainers, Rob Scott and Nick Young. We are all available on Kubernetes Slack. We would love to hear from you. Please feel free to reach out to us. The main channel for us is Sig network gateway API and you can reach us there. Thank you very much. So I hope that you enjoyed this and hope that we'll see you in the Kubernetes community. Also enjoy the rest of the conference and have a great day.