 Hello everyone. Hey, welcome to IstioCon, the virtual IstioCon 2023. My name is Keith Maddox. And I'm John Howard. And we're going to be giving you a look at Istio's journey with the Gateway API. And if you don't know what the Gateway API is, you will also learn that during this talk. But before we get there, we need to understand where we're coming from. So I want to give kind of an overview of some of the history of Istio's traffic management APIs. So if you've used Istio for a while, I'm sure you're familiar with some of Istio's kind of what we call the traffic management APIs. This is the Gateway, the virtual service, the destination role, kind of all these things that are configuring how traffic goes from point A to point B and kind of modifying properties in London does. But even before that, and currently in Kubernetes, there was this API called Ingress. And Ingress did a lot of these things, but it was all in one resource. And it was kind of this awkward fit of, it was so simple that everyone could adopt it, right? It was a single API that had multiple implementations like Istio and GenX, Cloud load balancer, like everyone's implementing the Ingress API. But it's so simple that no one can actually use it in a real world environment and meet all of their needs, right? It's really constrained to just have one resource handle everything. Like we have the same single resource that's managing how routes work, like, oh, the food pass, you go to the food service. But that exact same resource is also provisioning a Cloud load balancer, which is like this highly privileged infrastructure admin operation. It's also managing certificates, which is probably somewhere in between the application and infrastructure admin, right? So we had this mix of personas all bundled into this one API. And the API itself still is kind of too simple to meet all these cases, right? There's no, nothing like retries or timeouts or I don't even think header based matching, like all these kind of features that we kind of won out of routing APIs wasn't there in Ingress. So it was a nice starting point, but it's not sufficient for long term. So that's what brought about the Istio APIs. That's why Istio had its own APIs rather than using kind of the vendor neutral Kubernetes standard Ingress one, right? So gateway and virtual service kind of take the roles that were previously all in Ingress and split them apart. We have kind of the infrastructure layer, the gateway, which opens up ports, listeners, things like that. And then we have virtual services that attach to them and configure the routing and also expose a huge array of functionality that Istio provides is not in the core of Ingress. Things like cores, mirrors policy, retries timeouts, like I mentioned. There's a whole assortment of things. And additionally, destination rule, that's kind of completely new to Ingress. It's kind of how we connect to a back end. So we may say, for example, that I want to use TLS when I connect to it, or I need to use a circuit breaking policy or any other, but again, there's a lot of options in these Istio APIs for customizing how traffic is routed, right? So this is all great, right? We have a new API. It's a bit easier to use in Ingress due to the split of concerns. We offer a lot more functionality. Everyone's happy. And to some extent, that's true, right? We have a lot of Istio users, hopefully a lot of happy Istio users, but there's still a lot of issues with the API that I'll go into in a bit. So let me show just an example concrete. If you're not super familiar with the API, here I show a gateway and a virtual service. And this is just doing kind of a simple case of I want to match request on some external host name. Here I've got hbbn.example.com. So in my gateway, I'm opening up this, what we call a server. And then the virtual service will bind to that. We have this matching host here. And then we set up a few routes for different APIs to expose and we route them to our actual hbbn service on some internal port. Istio wasn't alone when it came to how it, you know, experienced the Ingress API. There were various implementations all doing things slightly differently. And the, you know, folks behind SIG network saw this in the community and said, no, I think we can do better. And so around 2018, there was a user survey that was sent out to collect information and feedback about the Ingress API and what people wanted to see from networking APIs in Kubernetes. And from that conversation, the gateway API was born. The gateway API was introduced by Kubernetes in order to attempt to build a unified service networking model. And big pieces of, big areas of focus for the gateway API is to learn from the mistakes of Ingress and to try to be more just a lowest common denominator. So in gateway API, you're going to see lots of things that weren't present in Ingress, such as a standard way to do a header modification, standard ways to do traffic splitting and things of that nature. And it's extensible by default. There is built into the specification a way to, you know, create CRDs that follow a certain, certain fit and have those be policy. So for example, you can configure a timeout policy within gateway API, and there's just a standard way that that should look in things of that nature. And so the gateway API recently graduated to beta and it's got at this, at the time of, you know, recording here, about 24 implementations. So it's this very widespread, widely adopted specification that is in use across multiple different networking platforms on top of Kubernetes. And Istio, similar to the upstream API, Istio has beta support for the gateway API. So, you know, we talked about one of the main benefits around persona development here, but want to go through and talk about them a bit more in detail. So the first thing that you, first big benefit of the gateway API is that now you've got a common ecosystem. Ingress have the same benefit as well, but the issue with Ingress was a lot of the feature, lack of feature parity with custom implementation API, such as, such as Istios. And so what you really saw is that people who wanted to build cloud native integrations had to do bespoke code and bespoke workflows for each Ingress provider. Both gateway API, the features are rich enough and the extension patterns are explicit enough that you can really have a common specification for integrations to plug into. Things like cert manager, Argo, and Flux, and typical GitOps workflows can target the gateway API instead of implementation-specific behavior in order to build their ecosystem. Similarly, you know, when you're out trying to figure out how to accomplish traffic splitting or how to accomplish header modification, if you look out at all the different Ingress implementations from IngenX to Contour to Istio, you're going to find a ton of different APIs with different nuances and all kinds of different proxy implementations and things to keep in mind. But with gateway API, by and large, you're able to share from the knowledge of different implementations, all 24 implementations, when they have support for the core gateway API resources, you're able to benefit from those knowledge and the shape of things are going to look the same and the Helm charts are going to look similar and the documentation is going to look similar and so you're able to benefit from multiple communities all rallying together under the same platform and ecosystem. We alluded to this earlier, John did, about the different personas that are in use when you're deploying a company of applications today and one of the big friction points with Ingress was this overlapping and this coupling between different personas. So the application developer who just wants to expose a route on the application has to touch the same resource as the platform admin who wants to configure TLS or even the cluster admin who the cluster operator needs to expose a new load balancer to expose traffic to the internet. With gateway API, those different responsibilities and personas are broken up across different resources. And so with less coupling, you can have increased cohesion across the organization and have your application developers just focus on the routes to their services. Your cluster operators can focus on provisioning gateways and provisioning infrastructure to expose traffic to the public internet. Each persona can have ownership over just the scope that they need to manage and that creates better efficiency for teams who need to just write business logic and get things done. And then lastly, this is a really big one that John is going to talk to us a little bit more about in a second, but with gateway API and Istio, you get automated gateway management. And what does that mean? Well, right now the situation in Istio is a little bit split. You have to provision the service and the load balancer in a separate step from configuring it and programming it. With gateway API, by deploying the Kubernetes gateway API gateway resource, the Istio control plane is going to take that resource and create all the infrastructure in the background. And you only have one API that you have to deal with instead of two. And so you really get this really nice automation in lifecycle management by adopting the gateway API. And so John can talk a little bit more about that specifically here. Yeah. So in the world, kind of the old world with the old Istio APIs, you would have kind of two parts if you want to deploy gateway. First, you would have the installation, which is on the right side. This is the service deployment. And you probably also have a few other things like roles and maybe a pod disruption budget, whatever. These are usually configured through Helm or maybe Istio Cuddle install. And then in a completely separate operation, you deploy a gateway resource that programs that, right? And these things need to be in sync. So you can see I have these selectors that's matching the Istio Ingress gateway. This is a pod label. So this pod label needs to be matched on the deployment, the service, and the gateway. And they also have some port numbers. These need to be matched as well, right? Now consider I want to add another port maybe to expose my database. The obvious thing to do is go out into the gateway, try to send traffic to it, and it doesn't work, right? And the issue is, of course, it's not actually in my service. So my traffic is not able to go there. We've only configured one half of the story. So the fix is obvious, right? I go add the port to the service. And it seems trivial, and it seems obvious. And to some extent it is. But this is just a simple case. In the real world, I may have hundreds of these gateways that may be managed by different teams than that managed Istio install. I maybe have one shared Ingress gateway used by many different teams, or I may have multiple Ingress gateways for each team, or some combination of the two. Once we started getting into more and more complex things, like target ports, mismatching with the service port, like all these weird edge cases, it ends up getting quite complicated. And it kind of makes management and lifecycle of Istio just a little bit harder. Is it the hardest thing in the world? Of course not. But there's a lot of these little cuts, and over time they add up to a lot of friction, and in some cases could even cause like an outage or something. So with the gateway API, like you've mentioned, we've kind of improved this quite a bit. Absolutely. So with the gateway API, as a user, you only have to interface and focus on a single resource. And here, like in this example, you create the gateway resource, you set the listeners, you say, I'm going to listen on this port, on this protocol. And then what the system will do, the system will do is it will, the service subsystem and the deployment subsystem of the Istio control plane are going to take that single resource and manage it for you and generate the accompanying deployment in service and handle the lifecycle of that infrastructure for you. And so with this gateway API approach, the configuration and the lifecycle of the gateway are handled via a single resource instead of disparate resources spread out across your cluster. And so going to the next slide for me, John. Taking that same example, you still have the listener that's defined, you're still saying that this gateway is going to be listening on port 80 with HTTP protocol. But instead of the user, you, the user happened to go and synchronize the selectors and the ports, et cetera, across multiple resources. Now the system was going to take care of that for you. So if you wanted to change the same, hey, I got a call from the security organization, we can't expose plain text ports anymore. And we have to move this to TLS. And so if you change this listener from port 80 to 443, now the system is going to update that for you, instead of you having to go to both resources and make the change and keep them up to date. And as John mentioned, this sounds simple, but you spread this out across multiple organizations within your company, multiple different timelines, multiple different requirements. And this can cascade really quickly and lead to an outage or a hidden productivity. Yeah, before we move on from some of the benefits, we now have a slide for us, but I wanted to touch point out, like we showed this one example of one nice feature. And it is nice, it is great. But I think in general, the gateway APIs provide just a lot of small improvements over these two APIs. In many ways, I see it as kind of taking the learnings of Istio over the past five years or so, and as well as other projects, and then kind of iterating and learning on all the mistakes that we've made. And so a lot of these are really subtle, like you may look at the two APIs side by side and say, those are basically the same, there's only surface level differences. But in many cases, these subtle differences all add up to make a very large user experience difference. And the gateway management is one example. Like, could we have done this with the Istio API? Maybe, but there's all sorts of edge cases that the Istio API exposed that made that really, really hard to do, but the gateway API doesn't do, which is why we've enabled this only for the Kubernetes gateway API. And the same thing applies for some other features as well, like one common one is cross namespace certificate references. We've tried for quite a while to see how we can adopt that into the Istio API, but some of the namespace boundaries in the Istio API are a bit fuzzy, which makes it hard to do that securely. That's something that the gateway API has improved upon. And so cross namespace references are available in Istio with the gateway API. And there's many of other cases of these minor improvements that add up to big user experience changes. So we can keep going on about the benefits, but we're gonna move on. So here's another end-to-end example. So this is the same gateway resource, just name, tweak a little bit from the previous example on exposed on port 80. And now, as an application developer with my cluster admin provision this for me, I can now expose a route to my HTTP bin application on this host name. And, you know, we've got a couple of HTTP routes to status and delay the same ones from the first example that John walked us through with the Istio APIs and route it back to HTTP bin with a back-end ref. So you see very similar functionality, but with some very subtle user experience improvements that make things that are going to really add up and make things better for organization. So, you know, we've been talking about gateway API for the lens of ingress, right, getting traffic from outside your cluster to inside your cluster. But, you know, around July of last year in 2022, the Istio community, you know, joined the Vanguard and was really part of this effort to use the gateway API as a standard specification for mesh configuration as well. Similar to the ingress space, all the different meshes in the ecosystem have very similar but slightly different ways of doing the exact same things. Routing traffic, setting up MTLS, authentication authorization policy, things of that nature. And so several different folks from several different communities came together in an effort called the GAMA initiative. And this has initially started between SMI and Istio. And for the past year, we've been iterating on seeing how we can make a gateway API specification fit for east-west traffic as well as that north-south outside of cluster and inside of cluster step. And as a gateway API version 080 that just released a couple of months ago, mesh support was officially added to the gateway API spec as experimental. And I'll note that, you know, we were very purposeful about the way we went about doing this and no API changes were had to be made to get the API resources to get this to work. The only changes so far have been semantic. And so you'd be curious to see what this looks like in action. So you've got this example here for you that in HTTP routes, the same HTTP route that you would use to program traffic from your ingress controller to your back end applications, use that same resource, but you're going to change the parent ref of that resource. And instead of it being a gateway, we're going to say the parent ref is a type as a kind service. And so this is the one of the really big, you know, the big shifts is that what this is going to do is it's going to say, hey, for traffic destined to the service, we're going to route it to the following back-end refs. And you can have, you know, various different kinds of rules, but here's a very classic example of traffic splitting between two different versions of the through service. And so anything that's destined for traffic to service through, we're going to send 90% of traffic to that actual service through and then 10% of traffic to through V2 in order to, you know, get that the V2 version of the application up and running. You may notice here that you've got a back end, you've got the service resource kind of doing two jobs. The service, the service resource of the parent ref is kind of healing from the matching logic, but service is also a back-end ref for routing that traffic. John, what does this mean and, you know, how do I make sense of this? Yeah, it's, this exact topic was kind of the root of a lot of contention in kind of designing how gateway API could be used for mesh. If you look, I think last year at East2Con 2022, I had a talk on gateway API and I touched on mesh and I think I probably said something like mesh is experimental or something. And Keith just said mesh is now experimental as of this month. So what happened in that one year? Well, we iterated quite a bit and this is where we arrive, right? And this iteration involved this diagram times a thousand for every possible way we could possibly model how to represent service mesh traffic in the Kubernetes gateway API, right? So it may seem simple in the end, but this is like the result of years of it, well, one year of iteration and this kind of where we arrived. So the issue we have with service and remember East2 is a service mesh, so we generally are concerned with how we interact with services and how we kind of modify the behavior of services, right? That's largely what we're trying to do when we have a HTTP route or a virtual service that's kind of in the mesh mode, right? We're taking a service that was traditionally just a layer four TCP service has no kind of special routing rules and we're kind of upgrading it to an HTTP service that has all sorts of customizations that have added, right? But service is more than just one thing. It's one object, but it kind of has two rules. What we kind of call the service front end and the service back end. So the service front end is like how do I identify it calls the service or how does a client reach the service? So this is like the DNS name, the example.service.cluster.local or the cluster IP. But then it also is a kind of collection of back ends, a collection of pods or kind of the endpoints or endpoint slices. And in classical Kubernetes without a service mesh, those are tightly coupled, right? If you reach the front end, then you reach the back end directly. What gateway API or even virtual service allows us to do is say, I want to match on this front end, but then customize the behavior, right? So here I've attached a route to the service a front end. I'd be using like an attachment like this apparent rough here it's boo and the slide I think it's a. So I attach a route here. And now I'm overriding how I want to handle traffic to that service. So the client still calls service a but now I'm following this route. And this route may, for example, split between service AP one and service AV two. If you want to hear more about this, Tim Hawken gave a lightning talk all about service and kind of problems with it earlier this week. So feel free to check that out. So this is one of the core problems that we wanted to solve in the gateway API. We think we did a reasonable job solving it as long as you're okay with accepting that service is one object with two roles. And as you can see again in the example, we have the front end role here in parent ref and then the back end role here in back end refs a API in the ambient. So if you're if you're not familiar with ambient, you probably haven't been watching the other talks because I'm sure that over half them are about ambient. And same with all the used to blog posts, used to tweets, everything's all about ambient these days. But I'll give a quick summary. So used to ambient is kind of a new data plan mode that instead of using side cars, the traditional deployment model, we've kind of split the service mesh proxy into two layers. On each node, we have what we call the Z tunnel, which is kind of the node encryption layer. And it really doesn't do much. It's just augmenting the cluster networking stack to add encryption and a few other enhancements. So we can maintain the zero trust properties with mutual T loss that we want to use to. But the the core of it is really these waypoint proxies that run external to the application, typically in the cluster, but in theory, they could run anywhere. And these are standalone pods that kind of do the work that the service mesh sidecar proxies used to do. But now they're standalone. And the gateway API plays a key role in this right, the waypoint proxies are actually represented as gateways. You know, oftentimes in our docs, we're deploying them with an Easter cuddle helper command. I think it's used to cuddle waypoint apply or something similar. But under the hood, that's actually just creating a gateway object, just like we did in the past examples. And so it is a gateway, it has a few special properties, it has its own gateway class, which we touched upon, which is, you know, kind of a qualifier for what type of gateway it is. But ultimately, it's very similar and uses the same APIs as the you would for ingress. In fact, you can actually do I have a blog post about like, what would waypoint, what would it that architecture look like if there was an ambient, and how you could kind of do it the hard way. And you can check that out if you're interested. So just like a normal ingress gateway, we have routes that can attach. We have policies that can attach. So for example, we may want to apply an authorization policy. These will attach to the gateway, whether it's a waypoint or an ingress gateway. And yeah, so like, you know, this is kind of the, the two, I think main focuses and projects going on Easter is where the ambient mode and the gateway API and these two are also very tightly linked. I can wrap us up here. So like John was saying, gateway API is the encouraged ingress approach for Istio moving forward. Mesh support is currently experimental, but the Istio community is, you know, currently investing to pushing that spec forward. And we hope for it to one day be the out of the box default for Istio. Now our goal as we go through this process is to try to match the stability of the upstream gateway API. So we try, you know, through our, through our involvement in both communities, Istio and gateway API. Well, whenever gateway API, let's say milestone, we try to match that milestone relatively soon afterwards. And like John just said, ambient mesh utilizes gateway API for its waypoint proxies. And this, you really see the marrying of these two new innovations and these two concepts within Istio that we're putting a lot of focus in right now. This means, you know, this ambient mesh using gateway API means that policies are going to bind to the waypoints, which is a little bit different than, you know, what you might be used to in Istio, where you use workload selected about new workloads, you know, in ambience, policies will be binding to waypoints as in general. And we also see, we talked about two different roles of service, which might be your first time hearing about it. And so service, when you see service as a parent ref in the HTTP route or any kind of route and gateway API, it's going to refer to the front end role, which typically corresponds to the DNS name that is provision inside your cluster as well as the cluster IP. And when you see service being used as a backend ref, that refers to the service, that's a typo there, the service backend role. So the bag of endpoints that are provisioned by the Kubernetes API server, based on usually a selector of some sort. So that's the kind of Istio's journey with the gateway API. Hopefully, this was really informative. And we'd love for you to try out these features in Istio. Gateway API again is in beta support in ambience. Mesh is an alpha. And the gateway API mesh support is experimental. So various difference, you know, there's something for everybody, no matter what level of maturity that your organization is at, we've got something for you to try out and give us feedback. So really appreciate it. Thank you for your time. Yeah, like you said, thanks everyone. And we'll be around to answer any questions or you can reach us on Slack, there's a gateway API channel, we'd love to hear any questions or feedback. If you like it, you don't like it, you have issues, whatever, if you're back super useful. So thanks everyone. Appreciate it.