 All right, all right, all right, so we are starting again with our app lead on Developer advocate from data dog with the Kubernetes gateway API We are after our we're going to have a 30 minutes break and we're going to restart again at 330, but for now All right, will you join me give it up for our please? Thanks, thanks William Thank you, so yes, I'm out of leader Thanks, thanks for having me and and thanks for the organizers for this amazing conference. It's super. We'll run the venue It's super cool. It's like a club. Come on. This is very Huck Hucker club night is kind of feeling which is great But today I'm going to be talking about Kubernetes Gateway API, which I consider it to be the new way to travel north south so Just just some words about data dog is a platform that helps companies improve observability and security of their infrared applications and that of course includes Kubernetes as a platform But also the workloads the applications that you run on on top We actually have a brand new office in Amsterdam. They're very keen to host Community events so if you have a meetup that you want to have a space to run Just ping me and I'll put you in contact with the right people But today north-south traffic what is north-south traffic and I wanted to call this talk north-south and Also to explain with this term which not everybody knows and I didn't know and when the first time that I saw north-south Traffic, I was so confused about it What is north-south traffic is just External traffic into your cluster. I don't know we Why we come up with terms like that, but that's basically north-south As opposed to West East traffic, which basically means the tracking between the services into your cluster So this is more or less how it looks like north-south but because of the slice format most of my graphs are going to look like this but Always north-south Good, so how do we do north-south traffic in Kubernetes? So usually what we do we have to get a load balancer to get traffic in and If you're in a public cloud, so if you're running to key or a case a case and others There is all these clouds provide controllers So when you create a service and Salman is playing a little bit this morning All about this are the things thanks to that I can be a little bit faster on this If you do a type load load balancer service The cloud Internally it's going to have a controller that is going to provision a load an actual load balancer for you And that's how you get trafficking your class if you're not public cloud If you know if you're running your own infrastructure, you can actually write your own controller to do the same thing But what happens in reality is that you may have more than one service that you need to get traffic from from external and Having a single load balancer per service is not a great idea because they are Very expensive Because they are scars they actually give you an IP that is rotable on the internet and we know that there are not that many of those So they get pretty expensive So what we do in Kubernetes up until now is that we create these ingress objects and Basically an ingress object. It's an abstraction of things like reverse proxies. For example l7 reverse proxies So you can you are able to route traffic based on HTTP Application level so you can say things like the traffic is coming to corporate comm Route the traffic to my service called corporate, but it sits shop dot corporate comm route the traffic to service e-commerce and that's that's usually what we do and This is how the ingress object looks like It's basically that there are a couple of more things you can do things like TLS termination and put it there But it's very very simple. It's a very simple spec is part of the networking core Kubernetes API so very official is GA and But but the it's it's super simple is that basically you create rules based on the for example the host and you can do reroute space for example URL prefixes Again, you can do a little bit more than that with ingress, but that's that's more or less Which you what you can do In this example if the traffic goes to foobud.com slash foo It routes the traffic to service one on port 4200 if it does a slash bar goes to service to his poor 80 And that's very simple to understand. It's it's a very very good abstraction to be honest So we're good. Yeah, we're right. We are we can finish this talk today Um Not not quite if we step back a little bit We know that in Kubernetes there is this reconciliation loop We have a set of binary skull controllers that basically what they do this watching for changes on your cluster for specific resources and do something about it and There is a component Kubernetes called the controller manager that has a set of controllers You have controllers for replicas sets for deployments for all the things and those come From communities itself so from the communities distribution itself The ingress object is not like this the ingress is such is a core Kubernetes API, but it doesn't come with a default controller. You have to deploy it on your cluster Externally, so you only you only get the API, but no the controller with it So what happens is there are many options? I just put here four of them, but basically any open source project or Company that they are on the realm of I don't know API get ways or reverse proxies or all that area Probably are going to implement one of these ingress controllers and This should be fine like the the API Its core is there so you should be able to move from one to another and everything should be fine the problem is that the ingress of resource is pretty simple and You may want to do things very classic things that you do with reverse proxies like Shifting the traffic based on weight like if you want to do canaries or a be testing or things like that You may want to say okay send 90% of the traffic to the first version of my application and 10% of the traffic to the second version But the ingress object doesn't allow for this But because it feels like it should all these Implementations started to actually Accepting to do these things in several ways Again, the ingress object only allows for many like very small number of things But Here comes engine X and says okay my users wants to do canaries So if you want to do canaries using the ingress object You're able to hack it a little bit with annotations So we are going to provide you with annotations. There are ingress controller Understands and you're able to do these things that you want to do That's great, but then comes contour and said okay if With our ingress controller, you're able to do anything that you want to do with ingress But if you want to do something more You're going to use these crds that we came up with instead same with ambassador they came up with different crds and Con with a plug-in that is not even part of the open source release So you can start seeing the problem already And this is not only happens at a l7 reverse proxy level It this is where the problem is really really apparent But it also happens at an l4 so Because the spec of service in communities only allows to say type load balancer and nothing else Cloud providers also do these things because they say okay. I can provision for you a load balancer But you actually have three types of load balancers. Which one do you want? So because you cannot say that? You for example in this case is an example with G key You can create an annotation to get for example internal load balancer So we have a problem in Kubernetes and this is why They came up with with Gateway API so Gateway API to the rescue three about three years ago So it took a while until this was more or less usable There's a lot of people in the networking space in Kubernetes Coming from Google coming from contour with all the same people who created the problem I can knowledge that they had created a problem and they started trying to fix it So they decided that they wanted to build a set of new Kubernetes APIs To deploy l4 and l7 routing so both both levels not only l7 and From the very beginning they they had this this north star to focus on while designing it And this north star was like the Gateway API is going to be designed to be portable Meaning that if you have a resource that you have created in a controller You can move to a different controller and it's going to continue. It's very simple But it's clear that we need a little bit more So we are going to build it so you can express all your routing needs But it's also going to be extensible because we know that some point We cannot design everything for now on the future So we need to design it in a way that it can be extended in the in the future And and also role oriented with the idea that because we are going to create so many different Different resources each of those resources are going to be Designed for a specific persona in your cluster So not all your users all your the users of your cluster are going to be using the same type of resources Good so without further ado This is the most important resources that you're going to find on the Gateway API not the only ones But basically it's very simple Gateway classes gateways and routes And there are many types of routes again. This is L4 and L7 so We have TCP routes UDP routes year PC routes, but the most mature obviously and the Really the first one that was designed is the one that we are going to be seeing today in the talk Which is htp routes Which you can consider really the the replacement for for the ingress object So how does it look like? The gateway class and thinking about this role oriental model is going to be created by infra providers and Nobody else so if for example in this case if you're running In this example if you're running a key cluster with gateway API, which already you can do They are going to have this gateway classes for you So instead of having to create an annotation for the type of load balancer that you need They are going to have Those created for you You can see there is a typo external This is actually on gkey. So if you create a gkey cluster You can see that there is a typo on their definition of gateway class at least that's time I check Which I find it very funny But then once you have those gateway classes that you can use As a cluster operator or as an application developer if your policy allows for that again, this is The different resources allows for A very specific rback rules to control who can do what You're able to create those load balancers by creating gateways on your on your cluster And you have to specify Basically a gateway class if you do this in gkey again. I mentioned gkey a lot Because they have a very very mature implementation Not like other other class at this point But today we are going to do a lot of examples on htp routes Which I think are the most important ones for most people and most people are application developers I don't I didn't have time to do demos. I only have one demo for today and it's and it's recorded I have actually three examples I'm going to show two one of them with one demo. I didn't have time while I was rehearsing this talk I was already over the time so I decided to reduce a lot But you can run Everything all the examples on a kind cluster if you clone that reaper you have all the all the examples So you don't need anything else on those examples. I'm using contour as the controller And the reason why this control contour is because it's open source and also they They have a very very up-to-date implementation as well We are going to be using an application. So this is the app For the example, so it has a front end and a couple of of services behind discounts and and ads Backed up by a database This is how it looks like if you run the demo You can see it So this just an e-commerce example application on the left you see What the discount service is going to bring but which is a discount and on the right hand side You can see the the ads that you get and the reason why it's it's Just says one point something is to distinguish two versions because we are going to do routing of traffic So you will see that you cannot get version one in blue or version two in red and that way you're be you're going to be able Actual visually how the traffic is being rerouted And everything by the way, it's uh, if you clone the report all this application is already Instrumented with open telemetry. So if you use an open telemetry back end You can actually actually see the How the traffic is is actually being routed Without having to to do all the tests So you can use it. It's all open telemetry. You can use it with whatever back end Okay, so let's see a couple of examples The first one is something very simple that you Usually do with ingress is like you say with a particular host if The url is slash foo go here slash bar go there This already you can do with ingress. So there's nothing special here But the problem is that if you do that with the some frameworks Some web frameworks like rails, for example, they will get confused because they expect The application to be on the root url So what you do usually on On reverse proxies rewriting that url and that's something that all these Implementations can do but the ingress object doesn't have an abstraction for that and you want to do that Rewriting that url. So your application believes that it's running on the root So you can do this with the gateway api specifications. So the first thing what we need is a gateway And a listener in this case htp And one of the things that from a security model point of view in gateway api Is that Because gateways may be created by operators in a different namespace They need to say, okay I'm going to allow This gateway to be used by routes that are being created on specific namespaces Obviously, you can allow all your cluster if you want but you can specify Only certain namespaces in this case the ones that match this label Can use the gateway Then you need a couple of htp routes This is how it looks like this is very similar to ingress as I said You can do path prefix So anything a slash foo goes to front end on namespace one Anything a slash bar to front end on namespace two But this is the interesting bit the interesting bit is that things Interesting things like url rewrites now are part of the spec meaning that You write it the same way no matter the controller that you're using So once we do that, uh, you can see that if it's you go to a slash Food goes to version one slash bar goes to version two and The application continues working and the recent way it continues working if we check the trace that is being created You can see that the application thinks that that is coming from from the root url Okay, so The another example and we are going to see a a recorded demo for this one You can see in this case The example that we started with something that we want to do and ingress doing allow us to do it but the implementations did Which is routing traffic by weight So in this case, we want to route traffic 80 percent of the traffic to our first version 20 percent of the traffic to a second version and In this case, they have a new object called the reference grant because I'm saying that a route is going to Cross boundaries, uh, to the next to the next name is a space In order to do that, uh, you can do that with engine x and ingress already without any permission So unless you have network policies or things like that, uh It allows you to do that In this case, they thought okay If you want to do that using the gateway api as the owner of name space two You are going to accept, uh, traffic coming from routes So the way we are going to do that is first we create the htp route That has two back ends One in name space one one in name space two and you can see that Routing traffic by weight It's in the spec. So it's part of the spec something It's not an annotation. It's not Another object that we don't know what's coming from It's actually part part of the spec. So something that you can do in the spec And then we have the reference grant. So on name space two, we are going to create a reference grant that basically says I'm going to accept routes coming from name space one to send traffic to my backend services Okay, so let's see the demo Let's play this Um So basically this is the same thing that we saw so we are creating first the reference grant And uh, we are going to also create the routes In this case the route And once we do that, uh, if we start refreshing the page Uh, we are going to get 80 percent of the times version one and 20 percent of the time version two So I fast forward this a lot of times and After a while I can use these open telemetry traces to think about whether The gateway api and the controller are doing what i'm supposed to be doing So if we check the traces for the ad service We can see visually in purple is version 1.0 in blue is is 2.0 You can see visually more or less 80 percent of the traffic is going to the first version and 20 percent of the traffic is going to the second version And you can also see some latency issues on the second version that probably you need to to check out Okay, cool. Um, so that was uh, an example of what you can do, but I wanted to talk about as well On a little bit of of some of the design decisions on the gateway api that I found them very very cool So we mentioned at the beginning that uh, it's designed to be portable So you you can move things from controller to controller and they continue working as expected How do they do that how they? I as an implementator of one of these um controllers. How do I make sure that it's going to be portable so Basically, they offer support levels for features. They the gateway api have a set of core features and those core features mean that You if you want to be compliant You have because they have a set of compliance tests. You have to implement everything on the core level Um following the spec. So if you don't want to be compliant, that's fine. But if you want to That's how you do it Then there are a set of extender extended features meaning that it's optional for you Um as an as an implementation to implement this set of features, but if you do Um, you have to do so by following the spec. You cannot create annotations or tricks. You have to follow the spec But they understand as well that they might be things that are very implementation specific Because these things are very broad some not for example in the case of of gateway classes not All clouds are going to have the same the same set of resources So there are things that you can implement that are specific to your to to your implementation But you have to do so following also some rules And the other funny thing about the design of of the gateway api is that they have a different release model So we are used to apis and Kubernetes to be part of the release of communities in this case They decided early on that they were going to be released as crds That doesn't mean that it's not an official api. It's an official api. It's gateway networking kates.io But they decided early on that because there is not going to be a default controller Part of Kubernetes is going to be always external There is not that need of tight that with specific communities Release and also crds are so mature now that people know how to deploy them how to maintain them So they say that this is what's going to be the way to to release the gateway api But because they are official they have to have some rules And this is the way they manage those Those releases so first of all you have api versions In this case, we have v1 beta 1 some resources are already beta Some resources are still v1 alpha 2. We only saw three of them. There are many of those And once Nothing is ga yet, but it's going to be probably pretty soon at least for for three of of them Um, but inside those resources, they also have Standard features and experimental features and standard features meaning that they're mature enough That they believe that they're not going to change that much. Obviously it's a beta object So it still can't change a little bit, but they're they're pretty confident that they got it right But then they have experimental features things are you have to know That they are going to be changing and anything in alpha is everything is experimental So they get all of that And they they release versions of the gateway api The latest one is zero point zero six actually one But more or less zero six the only thing it changes a little bit of of compliance tests And they basically release a version based on what they have But then you have as a as a consumer of the gateway api You have two ways of getting two channels to get that because you it's not part of kubernetes release So you get it through these channels Depending on what you need and the level of maturity that you require for your clusters So if you get zero six zero from the standard channel, you're only going to get v1 beta one resources and only A standard features of those resources and actually on the demo if you if you clone that repo In the demo, we are using experimental feature url rewrite Is an experimental feature part of htp route, which is a v1 beta one So what I did is to download zero six zero from the Experimental channel in which you get everything you get v1 beta one resources also alpha alpha two resources And but you get experimental features as well Okay, so coming to the end So just a recap Gateway api is a new it's a new kubernetes api extension to extenderize vendor implementations for both l4 and l7 It's an official kubernetes api But it's based on crd and this may confuse people at the at the beginning But I believe that it's it's it's going to become a pattern So I they are the first ones, but I believe more apis will be will be written this way And if you use it watch out for two things support levels If you're choosing an implementation and and also the maturity level so what type of Experimentation you you allow in your in your cluster And and that's it. Thank you very much That is hiring So if you see anything on our careers page that looks interesting let let us know and that's that's a review in case you missed it Thanks So thank Thank you very much ara. That was brilliant. Do we have any questions for ara? Yes, we do Two questions actually the first one is is there a way to define the custom traffic split like based not on the weight But on the request itself like headers. Yes, and maybe some external decision logic Yes, everything that you can think at least the the the things that were all low already allowed to do With ingress on the hacky way on the All of that, uh, obviously they they had that as as the as the base to define So yes headers is definitely one one. Okay, and the second question is there like version compatibility metrics between gateway api versions and kubernetes cluster versions Again, it's a crd. So the it's if You can use whatever whatever version you you're in You have it's I think it's more important That to to think about whether that those implementations Have any problem with one version of the other? I noticed one thing regarding The crd that you mentioned basically the first time I saw the The first time I saw the api Was that In order to include it into the cluster you had to actually install this manifest to make the crd accessible And now you mentioned that there are actually no plans to introduce this into the standard kubernetes api And who is governing? This gateway api then is this cncf or it's the the sick It's a it's a very good question. This is part of sick networking. So the same people who are Managing the ingress for example api. So this is completely official part of the sick networking and and one of the reasons I think why it took a little bit longer Is because they had to come up with a good set of conformance tests a good set of release model Because they are a little bit pioneering on on how to release this but again, I really believe that They are going to be more Six creating creating new api extensions this way Because again if it there is no controller that is based that is part of of kubernetes like like gateway api in this case There's really no need to tighten that to To to a release model and it gives them a lot of flexibility. They They they can have a different pace of release if they if they need to One thing that is important is that once it becomes ga and probably the first resources that are going to be ga are the the same ones that are Beta right now, which are gateway gateway class and and htp routes Reference grant I think is also better at this point Once it gets to ga it's not it's not changing so That's why it's taking a while to to to get to that level because they want to make sure that They are not going to say a month later of my god. We are ga and we want to change it So they they they won't change the the resource Thank you very much ara Um, we are Um, we are going to have a little break now until 3 30 at 3 30. We are going to have Christina the vodka I don't know if I'm pronouncing it right pretty pretty sure not Uh, we'd manage services. We'd manage kubernetes service. So You're free for our fun