 Hello, everyone. Welcome to this talk on Gateway API, a new set of Kubernetes APIs for advanced routing. I'm Harry Bhatti. I'm a software engineer at Khan. And with me today, I have Rob Scott, who is a software engineer at Google. We have been working on this new API for a while, and I want to take some time today to introduce you to the API and demonstrate some use cases that it enables for the problems that you might be facing. Before we get started, I want to mention that this API is a result of a community-wide effort within the SIG network API group in Kubernetes. And this wouldn't have been possible without contributions from all the members in that group. Now, to set some expectation, we're going to give a little bit of background and then give some quick examples of the API, which should give you a good feel of how this API looks like. And as we go through these examples, we'll explain some key concepts and how why the API was designed the way it is. And then we have some cool demos to show some existing implementations of this API. And then we conclude with some roadmap and future that is for this API. Please feel free to ask questions during this entire talk. So Ingress API has been around for a long time. It has seen a lot of adoption with over 15 implementations of the API. But Ingress was really aimed for simple use cases. In time, users have expressed the need for more complicated and advanced use cases. And this has resulted in a wide variety of annotations to extend the Ingress resource. Now, while these annotations don't get the job done, they result in a very poor user experience. As you know, annotations are free for form streams. So users have no validation. There's no consistency between features of different implementations and so on. At the same time, we have the service resource, which is seeing almost the similar problems as Ingress resource. It too is getting a lot of custom annotations. And it is now becoming bloated with features which concern different areas of Kubernetes. One such area is load balancing, and it's been getting a lot of load balancing features. The resource has become complicated enough that it's now going to be a little difficult to manage and evolve as you go on. So these problems have existed for a while. And then at KubeCon San Diego in 2019, we came together and an idea started floating around on how a new API could be used to solve these problems. Now, with that background, we're going to present a simple example to get a feel of the API. We have Acne Company, and Acne Company wants to launch an e-commerce store on its website. Alice, Bob, and Carol are three employees of the company who are in charge of the launch. Alice, here is our infrastructure provider, which means she's responsible for provisioning new Kubernetes clusters, and including the overall environments that those clusters operate in. Bob is our cluster operator. That means Bob is responsible for administration of the entire cluster, which includes day two operations like network access management, ensuring that applications have the right permissions, and application developers also have the right permissions to deploy their applications under the cluster. Carol is finally our application developer who's going to use the cluster that's been set up by Alice and Bob to deploy her application, which means she's responsible for application as well as routing configuration. Let's see how Alice, Bob, and Carol use Gateway API to deploy their application. So first, when Alice creates new Kubernetes clusters, she ensures that each cluster gets provisioned with two Gateway classes, an external LB and an internal LB. Now, what is a Gateway class, really? A Gateway class is a way to abstract away a type of load balancing infrastructure that is available within the cluster. So external LB and internal LB here represent a kind of load balancing infrastructure, and these two Gateway classes are being controlled by a controller called acme.io slash GatewayController. So once these Gateway classes are present inside the cluster, Bob takes the external LB Gateway class and creates a Gateway resource. What this results in is behind the scenes when a Gateway resource is created, an external load balancer is provisioned for the cluster. And the load balancer here is listening on port 80 for HTTP requests. And as requests come in, those requests are matched based on HTTP route resources. Notice how we have a selector label here with the key of Gateway and the value of acme external. This would feel a little similar to how Service Resource has a label selector for pods. So once Bob has the Gateway resource created, Carol can finally deploy her application. So Carol goes ahead and creates an HTTP route resource with the same label as you can see here. Now this resource would feel very familiar to a lot of you as it relates very closely with the ingress resource that we already have in Kubernetes. Here what this configuration is directing the Gateway is that all requests for acme.io with path prefix of slash store should be forwarded to acme store service on port 8080. So this gives a overview of how Bob, Alice, and Carol work together to deploy this e-commerce store application to their Kubernetes cluster using Gateway API. Now, you might ask a question, this was already possible with ingress. Why should we use Gateway API which seems a little more complicated than ingress and the answer there is Gateway API really shines with day two operations. So let's say, for example, Carol wants to do a canary rollout of a new version of her application. So in this case, she'll add a new forwarding target and forward one in every 10 requests. So about 10% of the traffic to acme store canary application. Now, as she gains confidence in the new version of the application, more traffic can be shifted from the old version to the new version and ultimately all the traffic will be served by the new version of the app. Notice how she can do this without interacting with any of the Gateway class admins. Now, at the same time, imagine that Bob wants to test out a new load balancer that their provider has exposed to them. So here Bob goes ahead and creates another Gateway resource with a new Gateway class. And notice how the listener sections here for the old and the new Gateway are exactly similar. So with this configuration, all the existing HTTP route resources are associated now with two different Gateway resources. So now Bob can go ahead and test out all the flows from the new resource, from the new Gateway and once satisfied, can upgrade the Gateway in their production environment. This is really cool because it does not in... Because Bob does not have to talk to any of the route owners and can get this job done without any interruptions. Now next, imagine that Alice is provisioning clusters in new environments. And for some reason, you have to use a different vendor in these two environments. So in one cluster, the implementation from vendor A is being used while the other cluster, Gateway API implementation from vendor B is being used. Now even though these are two different environments, Alice wishes to provide a consistent and seamless experience across these two environments and she can do that using Gateway API. So hopefully this gives you a bit of feel of how the API looks like and how it's designed. We're going to get into more examples in the demo section of the talk, but for now, I'd like to focus on a few key concepts. So as we have seen in our example, we have Gateway class resource, which is abstraction of a type of infrastructure. And then we have Gateway resource, which are a manifestation of the class, meaning gateways represent actual load balancing infrastructure within your company. And then we have the route resources, which are bind to one or more gateways. Now even though this model looks a little complicated, it's day to day. Now, even though the model looks a little complicated, we expect most users to spend over 90% of the time in configuring and creating route resources. We did not expect users to deal with Gateway and Gateway class resource on a day to day basis. Those would change much more infrequently. Now, why is this hierarchical model important? And it's important because we are dealing with a shared infrastructure problem here. With shared infra, users want maximum flexibility to make optimal use of shared resources. But at the same time, they want a centralized control over that shared resources. This is to ensure governance and proper administration and make sure that the resources are utilized fairly and correctly. And to do that, roles are mapped to each resource type. As we have seen in our example, the infrastructure provider takes care of the Gateway class, the cluster operator takes care of the Gateway resources, and then application developers create route resources. Now, the separation of privileges with each role, being responsible for a specific component, strikes a very good balance between flexibility and control. Now, with this resource model laid out, I would like to invite Rob to explain the goals and other key concepts of this API. That was a great intro to the API. Thanks so much, Harry. I'm going to continue where Harry left off and talk about what our goals were as we were developing this API. Now, of course, we really wanted this API to be role-oriented, and you've seen that throughout as Harry has introduced the API. He's shown how an infrastructure provider, a cluster operator, and, of course, an application developer can all work so nicely together to enable really powerful use cases, from the most simple example to more advanced use cases. And this is a really important concept that resources line up with roles and organizations, because we really want to enable effective and powerful RBAC in your organization so that you can grant appropriate privileges to each person in your organization. Now, we also want to ensure that this API can be portable across a large number of implementations. So, similar to the Ingress API, we envision a world where there are just countless implementations of this API. And I've been really encouraged to see the existing implementations, the first early implementations of this API, do really well. And we're going to be demoing some of them later on in this talk. But that's really a goal. We've tried to involve as many implementers as possible to ensure that we're building an API that can be supported broadly and is truly portable. Now, of course, we want this to be an expressive API. So, instead of trying to find just the smallest set of features that everyone supports, instead, we're trying to support a broad set of features that a lot of people would like to use and then trying to build support into these implementations. So, there's a lot more to say on why we're going for this more expressive route, but that's a key feature, a key goal in this API to enable much more advanced configuration. And then finally, we wanted this API to be extensible, because although we want this API surface to be fairly large, we also want it to be easy to extend. We don't want people to have to rely on all kinds of custom annotations or whatever to tack on to this API. We've built very intentional extension points throughout this API to ensure that not only can it support lots of core use cases, but also your custom implementation-specific use case if desired. So, how can we really make this portable? How can we really achieve this goal? We have, you know, pretty big goal here of covering a broad surface area and still making it portable, so how can we do that? Well, first, we do want that wide set of functionality in the core API, but we also want to ensure that whatever doesn't fit in the core API is easy to add in either through custom route types or really ways to extend existing types that we already have. We have custom filters, we have really extension points throughout different resources that feel very natural and also patterns to extend the API by attaching policy or other types of resources. And finally, we want to establish three unique conformance levels. So, what we've decided here is we'll have core, extended, and custom support levels. So, instead of an all-or-nothing approach where you're either conformant with the API or you're not, we have core features that we expect every implementation to be fully conformed with, but then we also have extended features which we recognize not everyone is going to be able to support, but of the implementations that support it, we expect them to follow a specific set of patterns that are lined up out in the stack. And finally, we make room for custom conformance, which is really just that last tier of implementation-specific features and implementations of concepts. So, this allows us to have a pretty broad surface of what can be configured in the API, while also ensuring that a large chunk of the API is truly portable. So, a key concept in this API is that of routes. And most of our demos and most of the talk so far has focused on HTTP route, but I want to take some time and mention that we have other route types. We have TCP route, UDP route, TLS route, and, of course, we've left the room open to add additional route types. We envision that there will probably be more route types added to the core API, but in addition to that, implementations may want to add their own custom route. Let's say they have a custom protocol or some very custom matching logic that doesn't fit within our existing extension points. Maybe that turns into a custom route type, at least as a start. We believe this provides a great deal of flexibility with how you route your traffic, and I think a large portion of users are going to be able to configure their traffic with the core route types we already support. Now, when we talk about routes, we really have to talk about how they're connected to gateways. And the key thing to remember is it's a two-way handshake between gateways and routes. So really, routes and gateways both have to agree that they can be bound to each other. That may sound a little complicated, but keep in mind that within the same namespace we have some pretty sane defaults that makes it pretty easy to connect gateways and routes in the same namespace. But there's also a new kind of functionality which is gateways referencing routes in multiple namespaces. This is a really powerful concept that I think can be used really well, but when that happens, we really want to make sure that both the gateways and routes are on board. And that's why we have this kind of two-way handshake where both the gateway and route have to agree with it. And you can read more on our docs. You don't have enough time to cover it in proper detail here, but that's a core concept of this API. And finally, we can't talk about this without talking about Ingress, because Ingress is really a lot of inspiration for this API. And you may be wondering, well, okay, what's happening to the Ingress API? And I'll say that I know of no plans to deprecate or remove this API anytime in the near future. I think it's going to be around for a very long time. We're possible. We're trying to pour concepts back to Ingress. So as an example, there are tiny little tweaks we've made to the Ingress API to help keep it consistent and up-to-date with the gateway API. But I should say that a lot of the new functionality we're adding, although it fits very naturally inside the gateway API, doesn't really fit well inside the Ingress API. So the intent is still to keep the Ingress API very simple and straightforward. And the gateway API will be the home of more advanced routing features, functionality, and all this new effort. So Ingress is still there. And if you like using Ingress, if it's serving your use case as well, that's great. But gateway is going to enable a lot more functionality, and I'm excited about what it can offer. All right, we've made it to my favorite section of this talk. And that's the demos. I get to highlight some of the great implementations that already support gateway API. And to get started, we're going to use Contour. And in this case, we're just going to use a very simple example that looks very similar to what we already showcased earlier. In this case, we've got a Acme Contour gateway and a Acme Store HDB route that we're going to use to publish the Acme Store. So this will look familiar, but we have a very basic gateway. It's listening on port 80 and it supports HDB routes and it will match or bind to any route that has the label gateway Acme External. So now our route obviously has that label. And then you can see it's matching requests to Acme.io with the path Store and it will forward those requests onto the Acme Store service. Okay, so let's see how this works in practice. First, we want to apply the YAM what we showed in the previous slides for gateway and route. And once those are installed, we want to go ahead and check for our external IP for Contour. In this case, that starts with 35188. We can use that to make some simple curl requests. But first, we want to get a quick overview of the service, Acme Store, and the pods that will actually be routing to. Now, when we do a simple curl request against that IP address, you can see the pod name is one of those Acme Store pods, so it's getting routed correctly. The reason we know this is all the containers through all our demos are going to be using a Where am I image that prints out all this useful information for us when we make a request. And of course, if we do a few more requests, you're going to see that our requests get routed to different pods each time, just as you'd expect. Our second demo is really just an extension of the first one. And in this case, we're going to add a gateway with Istio. Now, this is admittedly a really simple demo. We take the existing configuration we already had in the first demo and we just add a new Istio gateway. And you may look at this and say, well, yeah, this is really simple and that's by design. You can imagine this has really cool implications when you're starting to talk about day two operations. You've had gateways running for a long time and you want to test an update. You want to test new configuration or a new implementation or just a different vendor altogether, whatever it happens to be. You can just spin up a new gateway, send traffic to it and see what happens. Alongside your existing gateway, that's continuing to serve all your production traffic without Istio. And you can reuse all your routes. You don't need to reconfigure anything below the stack. It just works. You can just add a new gateway. So you can imagine if you're trying to do seamless replacement or gateways, smooth upgrades, whatever it happens to be. This is a really powerful concept. But also I think this shows just how powerful the portability component of this API is. So we're going to take a new gateway and this is going to be really identical to the gateway we showed for Contour, but instead we're going to use the Istio gateway class. Okay, let's test this out. First we need to apply the Istio gateway that we showed in the previous slide. And now we want to get an external IP for Istio so we can send some sample requests. In this case that starts with 34.122. We'll send a quick curl request and you can see that we're getting serve responses from the same Acme Store pods as before. We can curl a couple more times and again the same pods are responding. Alright, in our third demo we're going to use traffic to show how route header matching works. So this example may look familiar to you. We're going to do canary traffic splitting. But instead of before where we did percentage based traffic splitting we're going to do something a little bit differently. We're going to say any request that has a specific header should go to our canary service and everything else should go to our stable service. Okay, so in that case our gateway looks very similar but for this demo we're using traffic so create a new gateway and we use the traffic gateway class. And with that we're going to use an HQ route that is just a little bit more complicated. In this case you can see our first rule says match any request that has header serve equals canary and send it to our Acme canary service and every other request by default should still go to the Acme stable service. That's all there is to it. So to start we're going to apply the gateway and route YAML from the previous two slides. With those in place we can get an external IP for traffic. In this case that starts with 34 123. We'll use that IP to make a couple sample requests. First a request that specifies that header serve equals canary and you can see we're getting a response from the Acme canary pod. If we make the same request again but without that header specified we'll get a response from the Acme stable pod. So traffic is routing our request exactly as we hoped it would. And finally my favorite demo is a way we can combine two new APIs to work really well together. So of course SIG network has been hard at work on gateway API and we're demoing that here and we wanted to bring in some work by SIG multi cluster as they've been working on multi cluster services. And we can combine those both on GKE and show just how powerful the combination can be. So if you look at this diagram we're going to say well this looks like almost an exact copy of the example we just showed. And you're right it's very similar this is still traffic splitting but the difference is that we have three different clusters involved here. So we have a cluster one which is includes store C1 as a service we have cluster 2 which includes store C2 as a service and then we have a config cluster which has a gateway and a route that's targeting both of these services. Okay this seems pretty neat and simple but of course it's not quite as simple to make that cross namespace reference instead we need some help from the multi cluster services API. So for that we add this concept of a service export and a service export is actually really simple it just create this tiny service export resource right alongside your service and you say I want to export this service to the rest of my connected clusters that's all there is to it and then those service import resources you see are automatically created and they represent services that can be reachable in other clusters. So in this case we'd actually have service import resources in all our clusters but I've only highlighted the ones that we're actually using right now. So to illustrate that let's look at what these actually will look like. So first we have a service export that's the only thing we have to create and that says take my store C2 service and export it to the other clusters I'm connected to and then automatically you get service import resources created in those other clusters and that's what we can target with our HTTP route. So again let's take a quick look at our gateway this is also going to look very similar but we're using a GKE gateway class instead and one detail I want to point out in this specific example we're using an internal load balancer instead of an external one. There will be a number of GKE gateway classes supported by this API but in this case I wanted to show what an internal load balancer looked like. Now the second part of this is the route and you can see that so far we've been focusing on forwarding the services but you can also forward to any kind of generic back end with an object reference and in this case we're forwarding to a service import so that multi cluster service resource and so we're sending half of our traffic to store C1 and the other half of our traffic to store C2. Alright let's see this in action. We'll apply the gateway and route YAML that we saw in the previous two slides and then we'll get the IP address associated with the gateway we just created. In this case because it's an internal load balancer our IP address it starts with 192.168 so we can use that IP address SSH into a machine on a network and export that IP address to simplify making curl requests and with that export we can make some simple curl requests to this load balancer and what we're seeing here is our traffic is not only going between different pods it's going between different clusters. In this example we have two clusters one is called AP and the other is GKE5 and we're bouncing back and forth between those clusters with each request we make. That was a really cool demo and I love when we can see the Kubernetes community working so well together across CIG so we've got CIG multi cluster and CIG network APIs working well together. And these APIs enable a lot more functionality than we can demo. So header modification cross namespace route selection advanced TLS configuration custom route filters traffic mirroring all four protocols there's just so much more that we can do here and unfortunately I don't have time to demo it yet. Now I should also point out that this is just the start we're in v1 alpha 1 we're still working on adding new functionality new features to this API and I'm excited where it's going to take us. So let's talk about our roadmap one of your first questions is probably how can I use this how can I test this out and the great news is there's already some awesome implementations in progress we've got contour GKE Istio Kong solo and traffic and in many cases these implementations are already ready for you to test out so if you want to use gateway API you can go to any one of these implementations docs and see what their status is for gateway API and as far as the API itself we're planning on launching a second alpha version soon v1 alpha 2 and also to improve experience and consistency we're working on conformance tests and webhook validation we're hoping to release v1 beta one later this year and that will bring much more API stability but until we get to that point we can still make significant changes so your feedback in the next few months is critical if you have ideas for how we can improve this API how we can change this API please let us know we have community meetings meetings every Wednesday everyone's welcome it's an open agenda feel free to add something to the agenda create a GitHub issue whatever it is we'd love your ideas and of course we're on Slack find our Slack channel where SIG Network gateway API and ask any questions join the discussion whatever it might be and finally if you're just interested in more information about the API check out our website that's gatewayapi.sigs.kh.io thanks so much for your time have a great rest of your KubeCon