Gateway API Charla con Peter Kelly (Tigera / Calico)

Hello. Okay, Peter, how are you? Very good. How are you doing? Well, so tell me a little bit about yourself. What do you do? Where do you work for? Sure. So, my name is Peter Kelly. I'm the VP of engineering at Tigera. We're the company behind project Kico. Nice. The most widely used adopted CNI in Kubernetes. Mhm. Um, prior to Tiger, I worked at EngineX. I have a particular interest in Ingress Technologies. Nice. So, your company, so I I joined as a media whatever media analyst here for CubeCon and I got a lot of emails from different companies. Um, your company contacted me because they wanted to talk a little bit about the whole thing that is happening right now, which is API gateway, right? Uh, versus ingress. So you have experience in both sides. We were talking a little bit about that earlier that basically you because you work for engine X you know the side and also there is a lot going on right now. So can you explain a little bit what is the difference between ingress and API gateway and why is it a big thing now? Absolutely. And it's very confusing. Yeah. At the moment even the terminology around I was about to say because it's also gateway API as well. Correct. API gateway. Ah sorry I actually misspoke. I said API gateway not gateway API. Okay. So maybe you can explain better. Absolutely. So it is confusing. Uh you know naming things is hard in computing. This is the perfect example of why naming things is hard. Um an API gateway is a you know a general uh you know term for something that controls access to your APIs in terms of rate limiting in terms of routing and things like that. So you could argue that gateway API is a you know a subset or a version of an API gateway in some ways. Um so the difference really is uh ingress is a resource an old resource in Kubernetes. It's old resource it's still supported. Okay. Uh but we're definitely the community is definitely encouraging people to uh move towards the gateway API. Okay. So you even see that in the Kubernetes documentation if you go to the ingress uh resource it encourages people instead to look at gateway API. So basically gateway API is a way to interact. So basically a open source or basically standardized version of ingress. So we don't want to call it ingress anymore. So, so yeah, the way it works is um both of these concepts uh essentially boil down to getting external traffic, yeah, routed to services that are running inside your cluster. And they both do that. Both the ingress API and the gateway API, they provide a spec for how you can do that. Yes. Um there are many implementations of both specs and many implementations use different underlying technologies which I can talk about in a second but essentially they both uh ultimately get external traffic routed into internal services. Okay, the gateway API actually started in SIG network as ingress v2. Okay, so just to give you an idea, it's essentially the next generation of ingress. Um but they're very different. So So, ingress is a very simple resource, a very simple API. Um, but it's quite limited. So, simple can be good. It's very easy to get started. It's one resource. Um, gateway API is a little bit more complex. Okay. Initially, uh, to get your head around and to understand how everything interacts. There are multiple resources. Supports like an orback model with multiple personas. So, it's a little bit more complex to get started. Okay. but it's a much more powerful expressive API. Um, so just to give you a bit of history about the ingress, uh, it's a very simple API. It does some very basic things for routing external traffic internally. Um, but people want more customizations. They want more power than that. Um, the most popular ingress was implementation was based on engine X uh, ingress engine X. So what a lot of users did is they wanted access to the fine grained pieces of configuration of the engine X proxy to do like more advanced routing and load balancing and header manipulation and things like that. Uh so the way that people got around the limited API in ingress that doesn't provide you access to such things is to do custom annotations. Yeah. Custom annotations are basically just string train string regular key values. Mhm. they're not validated. They're not part of a CRD. Um, you're relying on the implementation to validate whatever input uh goes into custom annotations, which can be a big security hole. And there was recently a CP that right in a few days ago. Just Exactly. So what happened? Uh, so engine X ingress or ingress engine X has 118 custom

annotations. Okay. on top of the ingress spec just to control engine X the way users wanted. So this is kind of getting out of control. It's getting very complex and it means you can't really uh port your underlying because obviously those annotations are not compatible with another solution. If I change engine X to another one like I don't know Apachi API 6 or something like that they are not compatible. That's exactly right. So it's not portable at all. Right. So the effort then in the community and the steering group was to get gateway API um to kind of solve some of the problems that were introduced with the evolution of ingress to a richer specification in gateway API. Okay. So basically it's not like EngineX is going out of business or they're not going to be running anymore. They're going to now be interpreting the interpreting this manifests better. So instead of reading for example the annotations they're going to be reading some parts of the spec and basically doing the same thing at the end they're going to be generating engineext coffee files right yeah ultimately whatever the implementation is whether it's envoy or engine x or some other proxy the proxy that's running doesn't know it's part of an ingress solution or gateway API solution or even that it's running in kubernetes the gateway or the other controller that's running is essentially programming or updating that configuration Yeah, exactly. So, um there are multiple implementations of ingress and game API. The engine X ingress um there's a project called uh ingate. There was a talk about it here at CubeCon and the uh the concept there is to take as much of the custom annotations and see if they can form part of the game AI spec officially. Okay. uh that will help a lot of engine X andress users move and migrate to gateway API. The migration is a big kind of pain point at the moment. Yeah. Of course, because obviously you need to translate all of those annotations to actual things inside the spec, but hopefully that will have much more support and people will be able to do everything. That's the idea. So like getting started today, start with the gateway and I speced today. If you're already on an ingress, there are some migration tools to help you move over. There's ingress to gateway, which is an open source tool. Converts your old ingress yl to uh to gateway API specific ones. Okay. Um Calico, if I can talk about Calico for a second. So, we just announced uh support for an ingress gateway. Calico ingress gateway and it's based on envoy. Uh it's in our open source solution and our commercial solutions. Um it's 100% upstream Envoy Gateway. Okay. So Envoy Gateway is a open source project. It's a sub project of Envoy. Uh it's a fantastic project. It fully supports and implements the gateway API spec. Mhm. And it offers additional capabilities beyond that as well. Okay. Um which is one of the kind of flexible things kind of like annotations in the old ingress. There's ways of extending the gateway API. Okay. But it's done through CRDs. is done through like something called policy attachment which is a much more kind of flexible approach. Interesting. So we're going to need a B V B V B V B3 in the future really once we don't repeat the same mistakes. Yeah. And what are the things? So I'm really like there are a few things that are important about the gateway API, right? Which is uh well you mentioned that before you have like a one ingress like it's one thing, right? One ingress for one service. Maybe you can combine them but the idea is to maybe have again one ingress per service but you mentioned that now maybe you can have a single gateway API. What is the best uh practice here? Should we have only one manifest or should we have one manifest per service? What is the best way to do it? Yeah, it depends. So the one of the powerful things about gateway API is it introduces different uh resources based on the persona based on the person that should be interacting with them. Okay. So previously everything was in the ingress. Yes. So the orback was not really uh you know an option. Ah right. So in gateway API it's broken into something called a gateway class which is like the they kind of think of it like a an interface in programming language. So it defines like the spec of what a gateway can be in the cluster and typically the kind of uh infrastructure provider the infrastructure operator will define what that is and then you'll have like a cluster operator a different role actually instantiating a version of that gateway. So that's the gateway resource. So you have gateway class and then a gateway and then finally you have the application developer. So the person deploying a micros service they can uh configure something like a HTTP route so they can actually define how traffic gets from the gateway to their applications right

and that's all they have access to and all they have control I was going to say you can be more granular right now before it was just you have permissions or not to modify the ingress and that can break a lot of things. Absolutely. Yeah. So that was one of the key kind of concepts with the gateway API which makes it slightly trickier to get started with. You know there's a little bit more to learn about how the hierarchy of these resources work and different personas. So it's not as easy to get going but it's much more powerful. So in the previous world of ingress uh we had a lot of great integrations with providers right so we were able to create a load balancer have the ingress controller whatever it's called the load balancer controller that creates all of that. So how is it going to work right now with the new way the gateway with gateway API? Yeah. So gateway API is it's a you know a mature API now in terms of it's a v1. 2 I think maybe 1. 3 right now. Um so it's a you know uh a stable uh API. So it's definitely production ready. Uh you can start using it. There's over 30 implementations of gateway API. So you know name your favorite proxy and there's probably like a you know a handful of implementations available. So there are many based on envoy, there is many based on engineext, haroxy, enrock. There's so many implementations of gateway API. There's almost too many to choose from. Okay. Uh there was a great talk again here at CubeCon this week, yesterday, a panel discussion about like which gateway API implementation is right for you and there's multiple options. Isto is another one. Selium have one as well of course and now Calico is announcing our gateway. So there's many different options to choose from. Uh it may come down to feature parity. You know, some implement all of the spec, some of these might only implement some of the spec. Some of them support ingress and gateway API. Some of them only focus on gateway API. And then you want to look at the extensions like what extensions do they provide if I want something beyond the gateway API. And then maybe you know depending on your company, you might already use envoy for example. So then you're obviously going to go for an onboard based uh gateway API. How about monitoring also relatively is something that was before it was just engine exting or whatever proxy it's like a different implementation now is it integrated uh not so much no so the observability that's a great uh point actually so when you're coming down to choose like which implementation of gateway API you should um uh you should choose observability and what metrics are available is kind of underlying that like what's the underlying prox proxy implementation Okay. So, uh it's still the same way. It is. It is. Exactly. Interesting. Okay. Thank you very much, Peter, for your knowledge. Now, we have to start working on more things and always after going to a conference, I realize that I need to do more work. Yeah. So, I don't like going to these things. Okay. Yeah. Thank you very much for everything. Thanks for opportunity. Yeah. Thank you. Great to talk. Cheers.