← Kubernetes Podcast from Google
Kubernetes Podcast from Google
Kubernetes Ingress & Gateway API Updates, with Lior Lieberman
00:45:15
is a software engineer lead at Google Cloud focusing on GCE, Kubernetes, and Service Mesh. He is a leading contributor to Gateway API and the maintainer of Ingress2gateway. Do you have something cool to share? Some questions? Let us know: -...
Loading summary
Transcript76 lines
- [00:00]
Mofi Rahman
Hi and welcome to the Kubernetes podcast from Google. I'm your host Mofi Rahman.
- [00:05]
Kazan Fields
And I'm Kazan Fields.
- [00:16]
Mofi Rahman
This week we spoke to Lear Liberman. The main goal of the conversation was to learn about Investor gateway tool, but we touch on all things Gateway, API and the future of it. But first, let's get to the news.
- [00:30]
Kazan Fields
A new NFTables mode for Kube Proxy was introduced as an alpha feature in Kubernetes 1.29. Currently in beta, it is expected to be ga as of 1.33. The new mode fixes long standing performance problems with the iptables mode in Kubernetes 1.31 and later you can pass a flag to Kube Proxy to enable the feature. If you're running a newer Linux kernel, you're encouraged to try it out and share feedback.
- [00:56]
Mofi Rahman
The CNCF has announced a new incubating project, Cubescape. Cubescape joined the Cloud Native Computing Foundation Sandbox in November 2022 and has achieved a number of milestones since then. The open Source Kubernetes Security project is designed to offer comprehensive security coverage through the entire development and deployment lifecycle. It provides posture and vulnerability management and automatic hardening policies. The Cubescape operator is a set of microservices that monitor Kubernetes clusters From within the OpenTelemetry community.
- [01:27]
Kazan Fields
Announced the beta release of the OpenTelemetry Go Auto instrumentation project. OpenTelemetry Go Auto instrumentation allows developers to collect traces from their GO applications without requiring manual code modifications or rebuilding binaries. By dynamically instrumenting applications at runtime using ebpf, this project hopes to lower the barrier to adopting observability best practices and provide deep insights into your application's behavior.
- [01:54]
Mofi Rahman
The CNCF has introduced new guidelines for creating Phippy and Friends books. Phippy, the Giraffe PHP app, is the main character of the Children's Illustrated Guide to Kubernetes, a fun children's book styled introduction to Kubernetes. Originally produced by Deis, Deis was acquired by Microsoft in 2017 and the book and its characters were donated to the CNCF a year later in 2018. With the donation, the CNCF licensed the characters under the Creative Commons license, making them available for use in a variety of community related spinoff books about other open source projects, cool new use cases and more. The new guidelines separate Phippi books into two types, Project Related Books and Kids Day Books. Maintainers who create project related books will now also have book signings at Kubecon events coordinated by the CNCF and that's the news.
- [02:49]
Lior Liberman
Lior is a software engineer lead at Google Cloud focusing on gce, Kubernetes and Service Mesh. He's a leading contributor to Gateway API and the maintainer of Ingress to Gateway. Welcome to the show Lior.
- [03:01]
Hey, I'm excited to be here. Thank you Mophie.
- [03:03]
So other than what I have said about your background in the intro, anything else you'd like to add for the audience?
- [03:09]
No, yeah, I'm doing service mesh at Google. Been doing a lot of Kubernetes work recently, mainly in sync networking and yeah, as I said, excited to be here and talking about Gateway API.
- [03:21]
So you said you've been working in the Kubernetes networking sig. How did you get involved with the Kubernetes open source project itself?
- [03:29]
Well, actually fun fact actually back in the day I used to avoid companies that relied on Kubernetes because I found it frustrating and overcomplicated learning all these obstructions, especially when debugging and knowledge sharing with others. So it was a real pain and not even talk about companies that weren't even containerized. So then I remember starting working for a gaming company and I experienced some of these painful challenges which Kubernetes happened to solve. For example, I think I remember we the DevOps team had to be very involved in the rollout process and there were some custom fragile scripts anywhere, taking EC2 from the load balancer, running tests, sending requests, bringing it back. So everything was really fragile. And I also remember the whole idea of self filling wasn't there. So I remember like many nights waking up to just run nginx reload to just fix out some web servers. I still remember the pager tone and basically I was reading and all of these were just happened to be solved in Kubernetes so it was really exciting and fast forward when I started working at Riskified we really doubled down on Kubernetes and we had a strong support from R&D SVP back then. So I went for a journey to just migrating 400 services to Kubernetes, some of which we of course were split out of a giant monolith and that's where I really got to learn the ins and outs of the system and how powerful it was. And I even think that most importantly I got to learn the power of that community. We had issues, we posted there, whether it's GitHub, whether it's Slack, we saw so many people eager to just solve it or contribute their view of how they get a workaround or something. And I remember actually one thing in particular. We were a relatively early adopter of Argo CD, I think it was back in 2020 and really wanted to streamline an automated process of creating Argo applications. And this basically wasn't exist but it was some project called Argo CD Application Controller which basically was used to streamline this process and remove bottlenecks from the DevOps teams. And we didn't have what we need. So we just develop something internally and we just say okay, maybe we'll just put it back to the community. And since then I like, you know, I got the whole view of how it works and how smooth it was and yeah and when Google came out gave me the opportunity to work here, I figured it could be a good opportunity to actually being one of these people who more frequently work on kubernetes who solves users pains and that's what led me to what I'm here today.
- [06:12]
Yeah, I mean Kubernetes itself is a fairly big project in itself but even within this project I feel like networking is probably one of the more complex because it just touches so much surface area of the project and it is so much of that actually needs to happen outside the kubernetes core. What has that experience been like working in the networking side of Kubernetes?
- [06:35]
Yeah, I think not just like I really resonate with it and I wouldn't say it's just complex. It's even sometimes very intimidating to just go to the whole Kubernetes code base and understanding where should you put your contribution, where should you look for it without the really expertise and people that were there for a long time. So yeah, I think that's where we can see more and more projects like two of which come to my mind right now is on the Gateway API obviously and network policy API that kind of started to being developed outside like what we call out of three. So outside of kubernetes like Kubernetes and you know, it provides values such as like, you know, you could fastly iterate on it, you could have more contributors who easily, you know, can contribute without trying to learn the whole, you know, code base, ecosystem, testing machinery, everything and yeah, yeah.
- [07:29]
And for our audience that are listening what Lior mentioned about like in tree and out of tree Kubernetes being a project of the size it is contributing everything to the like the core of kubernetes requires so much, I mean for good reason, red tape at times for like getting new things into the actual core of Kubernetes. Developing things out of tree oftentimes is the easier way to actually get mind share not only but also velocity that a lot of projects need to show that the idea that there is it is actually going to work. Not rather than just like trying to go through the. What is the word like red tapes of merging something into the core of Kubernetes. So we have seen some really great projects that came out like even from within the core. A lot of the things like a lot of the vendor stuff have been taken out of tree over the last two years. I remember one of the commits that had like 1.2 million lines of deletion from the core that took out all the vendor related specific codes out of the tree to like in the in tree to out of tree. So that has been great. But we are here to talk about some of the network specific things and most of our viewers and listeners probably already know about some of these words. If not but just for folks in case they wouldn't know in Kubernetes, tell me a little bit about the Ingress API and why we're here talking about Ingress to something else, right?
- [08:49]
Well yeah, I mean the Ingress API I think is very, very widely known and it basically provides a capability to expose and control how external traffic from application access services in your cluster. So you know, the Ingress lets you define rules like HPE and HBS traffic. It can handle things like host based routing, pass based routing, SSL termination. So pretty useful. And it was designed to be simple so I guess it was definitely a win back then. While Ingress is was and is useful still it's a bit limited and basically you know, that's why Gateway API was created. And yeah, we could talk to our talk a little bit more about limitations but yeah, I think people need more things other than what Ingress provides.
- [09:34]
So what would be some of these key limitations of the Ingress API that you mentioned?
- [09:39]
Well, as I said, Ingress lacked a lot of core features. You could do useful things but pretty simple things which led to a lot of providers implementations put custom extensions everywhere which were usually in form of annotations which you know, we all know to happen to be very, very, very messy. And those extensions were not portable because you know you had like for example you could set up your AWS load balancer config is annotation. But anyone tomorrow you want to start using gke, you want to start using, you know, istio other projects, you cannot really port it and just use the same Ingress. And it also had lack of protocol diversity. As I mentioned, you could do HTTP and HTTPs, but for example TCP wasn't there, not at all. GRPC and things like that. And lastly, I think it also had insufficient permission model. When we talk about Gateway API, we probably can address like why the permission model is better. But yeah, I mean it was so many different things that different Personas should manage. Kind of being managed in the same resource. Yeah, so it was just very hard to delegate proper permissions for teams and organizations.
- [10:50]
So you mentioned that we have now a newer API. Well, new in comparison, over a couple of years already, the Gateway API. So tell me a little bit more about the Gateway API and maybe some of the design philosophy of the Gateway API and why it was built the way it was.
- [11:04]
Yeah, I mean if I need to maybe put it in one sentence, I'd say that Gateway API is the newer generation of Kubernetes, ingress, load balancing and service mesh APIs. That's only if I need to kind of capture it in one sentence. But I think the real value of Gateway is the composability of different pieces in the API. And as we mentioned above, the Persona Focus model, which addresses the insufficient permission model that Ingress had. And I think I don't want to go too deep into the structure. There are a lot of good Kubecon talks, podcasts, blog posts before on Gateway. Who are the Personas we focus on what's the API structure, but the different pieces, the different resources that combine the API lets us use it much more efficiently.
- [11:47]
And we actually had Rob Scott talk to us about the Gateway API when it was in beta in episode 186 of the podcast. So if anyone wants to hear about maybe an earlier iteration or one of the beta iteration of the Gateway API, they could go listen to episode 186 where Rob Scott actually talked to us about the. And even that was about two to three years after the initial announcement of the Gateway API that we're going to work on. So Gateway API have been in works actually for a while. In 2019 is one of the first time in one of the kubecons they announced the whole Gateway API. So we are already looking at like five, six years in the making.
- [12:26]
Yeah, like if I may, which by the way was initially started as the Services API. So. So for the people that were around for a while, they probably heard the announcement of Services API and then Rob was one of the people kind of also led the renaming and all that.
- [12:40]
Yeah, I mean, again, I think naming is probably one of the hardest problem of our tech because in the beginning days when I was personally looking up things about Gateway, I was running into things like API Gateway, because again, Gateway API and API Gateway are so close to each other. So I would run into things like, oh, if you have APIs, this is how you create an API gateway. I was like, that doesn't sound right. So as of now, after a couple of years of it, and with enough Kubecon talks published on the Gateway API topic, if you Google Gateway API today, you'll probably get a pretty close to the right answer rather than just getting a bunch of different API gateways. So you mentioned also that now Gateway API takes some different approach of how to design your external traffic coming into your cluster. But for a lot of our users and a lot of the people using Kubernetes for a long time, obviously they always had to have some ways to have people access their application. So a lot of that application might already have pretty robust ingress with a number of annotations, as you mentioned, for different services and things. What would be the process then to think, okay, I think this whole Gateway API thing sounds cool. A lot of new services and features that are coming with it. I like the ability to have this permission control system that comes with it as well. What does the migration path look like for users?
- [14:02]
I think even before we jump to talk on demarcation, there's also one additional thing I'd like to mention is that Gateway API has also this very impressive conformance test system which we've built. And we also, I think, have close to 30 implementations. So not even like the advantages we kind of touched before. It's also very, very well tested, widely used. And for those who have this ingress configurations, which are, I guess, a lot of the audience, a lot of the listeners, I think there's this tool called Ingress to Gateway, if you haven't heard of it, which was designed to, at least initially provide a good starting point to migrate. It's not designed to provide you a comprehensive, you know, magic tool to just go and read all your ingress configurations and get the Gateway API resources, But it is designed to give you a good starting point, making the migration less intimidate. So as I said, it started with addressing all these simple ingress configurations, taking all them output Gateway API configs. But as we all know, and as you said, Moffi, a lot of people have custom annotations, a lot of people have CRDs, some implementations going to Say, oh, annotations is weird, are weird, let's do a CRD that will be an addition to Gatwi. So some implementations had a TCP ingress crd, right? Because we mentioned Ingress didn't support TCP for example. So we actually added to Ingress to Gateway this extensibility kind of continue over in the spirit of Gateway API being extensible and implementations. You know, providers can just plug their conversion logic in the tool which would convert annotations, custom annotations and CRDs to those core features we support in gateway in core APIs, which I think is pretty useful. And I just wanted to highlight that we already have some major implementation supports the tool. Obviously not all of their metrics of possible features that it can have. But you know, we have istio, we have gke, we have Cilium, we have Kong, and like we're seeing more implementations kind of coming on board and you know, putting the time to implement that which is obviously driven by user requests. So if you do have some use case like that, make sure the implementation you're using is aware that you are looking to migrate your configs to Gateway API.
- [16:20]
We will make sure to link the ingress to Gateway repo in our show notes. So if you have any use cases or just want to check it out, what are the implementation and more information about the ingress to Gateway that would be in the show notes below.
- [16:33]
Yeah, that's great. And I think one of the other things that the tool gives you, which I wanted to highlight, is it gives you a kind of comprehensive notifications table that basically attempts to let you know what was the conversion logic. So like what was converted to what and and warns you from things that it skipped, whether it's a feature not supported in Gateway, whether it's just a feature that the implementation didn't implement yet in the conversion. So you have your Gateway API resources equivalent for the ingress resources that you had and you also have some kind of a notification that attempts to say hey, what was converted, what not and what you should go ahead and kind of complete yourself.
- [17:09]
Yeah, so I feel like the out of the box ingress that comes with Kubernetes for the most part probably will have full coverage in the Gateway API. But as you mentioned, people have been using annotations, some other CRDS extension, other things on top of ingress that may or may not be fully implemented in Gateway. Can you think of any kind of like major use cases of that nature that people are saying or people are finding any challenge with Moving to Gateway. Other than the actual task of moving your like configurations onto Gateway, is there any use case where Gateway just wouldn't support the things people have been using Ingress for?
- [17:48]
I think if we do want to go and dig up those cases, we'll probably need to go to things other than the Gateway API repo, which by the way is some kind of like a misconception kind of thing where people would find these issues opening up on Gateway. Because if I'm a user and I'm going to have a case that a Gateway API implementation of my implementation is not supported, what I need for Ingress, I'll probably go to my implementation page and, and put it there. And one of the things we've been seeing is, you know, Ingress NGINX kind of positioned in the center of it. Ingress nginx I think I could confidently say it's like, in my opinion, like the far most adopted implementation for Ingress on Kubernetes and I think there's a majority. I can't say the majority, I don't know. But like, I think like a lot of users are using Ingress Nginx, like definitely a lot. And Ingress nginx has a lot of annotations for everything and we're going to see a lot of examples there, that's for sure. But I know Gateway does not support all of these annotations partly because I kind of implemented some of the logic to migrate from Ingress Nginx to Gateway implementation. But there are some good news if we missed it. So Ingress Nginx project actually announced their intention to actually start a repository for a new implementation of Gateway API and it's called In Gate and, and it was announced, I think the community meetings as well kind of move to kind of work on the ingate. I know there has been Kubecon talks and will be more Kubecon talks in London soon about in Gate. So I think we are in the good direction of addressing all the cases for Ingress Nginx users, which again I think is a very big portion of the use cases you mentioned that are not yet supported in Gateway.
- [19:29]
So this is awesome that the community is kind of slowly building out all these Gateway implementations for pretty much all the use cases. People would be needing gateways that people are using ingresses for now they would be using hopefully Gateway for. But I did hear that Gateway have more features than just routing, like just getting your application traffic from outside into your cluster. What else is Gateway doing in terms of routing cloud native Application.
- [19:59]
I think you got it right. Gateway is definitely more than an ingress replacement. Gateway also supports Service Mesh APIs, which some of our audience probably may know as Gamma or Gateway for Mesh. You basically achieve that by attaching your routes, the same exact HTTP routes or whatever other routes, GRPC routes that are used to be attached to Gateway, but you attach them to services. So this initiative, GAM initiative started a while ago and kind of addressed this as a primary case. Because imagine we have a lot of features that are basically kind of the same, whether it's L7 like L7 ingress or L7 in the mesh. So features like pass based writing, right? Like why would it be unique for a request coming from a gateway request viewing all that, we do see a lot of similarities between the traffic patterns. Obviously there are some needs where it's not the case. But yeah, Gateway is definitely more than an ingress replacement. And in fact there are some implementations that only support Gateway, the Gamma, the gateway for mesh APIs for their implementation. So if I'm sure a lot of the listeners are kind of, you know, going with the ISTIO ambient right now hearing about it. And just to confirm, S2ambient does not support other APIs than the gamma APIs for many cases when we have more implementations again. So I think we're definitely going to see more Mesh implementers, Mesh projects just supporting the Gamma APIs.
- [21:25]
So seems like Gateway API and Service Meshes seem to have like a number of overlaps in terms of features they can provide. What would be like a reason to have a Service Mesh at this point with Gateway API evolving to do a lot of the Service Mesh like things, right?
- [21:39]
So like, and just to clarify, right, the Service Mesh is here the implementation would be like either using like today's implementations, which I can't say today, right, like, but previous implementations were we had custom APIs like custom CRDs, but now they all can support the Gateway APIs. And obviously we need to evolve more and more use cases in. But I mean in a high level, why even having a Service mesh? That's a good question and probably a broader question, but I think Service Mesh kind of starts to be very handy when you start having a decent amount of microservices in your cluster and when you start having some needs for advanced networking capabilities, you know, you want to do canary traffic splitting, you want to do some other L7 networking functions, percentage based request mirroring or you know, you want to do rate limiting a lot like, you know, and all that without even needing to change your application code. So this is where it becomes useful. It becomes useful when you want to understand what happens to the requests that come to your cluster. So telemetry and observability is a key here. And also when you start care about security and we start care about identity based authorization and not IP authorization. Right. It's not network policy, it's identity based authorization because you have identity for every workload running in your mesh. So yeah, I think this is mainly where Service Mesh would be very useful for you to deploy.
- [22:59]
Yeah, so I think that I had some of the my ideas about service meshes where the additional things you mentioned like metrics and observability that Service Mesh kind of gives out of the box for microservices based application. Having been part of this, I would say almost like a journey of converting or working in the networking sig for Kubernetes. What are probably some of the misconceptions you have seen about the Gateway API in the community that you would like to use this moment to help clarify?
- [23:33]
Well, a common one I hear a lot is people think that Gateway API is not core Kubernetes, partly because it's not installed by default or other reasons. But I want to clarify that Gateway API is a core Kubernetes API. I mean it depends what you call core, but it's a Kubernetes API and it's just stuck to decision to be installed and managed in a CRD way out of tree as we touched in the beginning, partly for faster iteration, for flexibility, for having easier contributions. Again, people don't need to learn the whole Kubernetes repository structure. And by the way, there are some discussions in Flyte right now whether we can include those CRTs as parts of the default Kubernetes installation. So, you know, assuming those land from newer Kubernetes versions, depends on those land, you're going to have this Gateway API installed by default. Like Gateway PI CRDs. Again not in implementation, but the CRDS would be there so you can just start using them assuming you have the implementation installed. I think the other misconception I could think of is I'm talking to people on Kubecon, I'm talking to friends, colleagues, and they say it's just too complicated for what I need. And I think we often think that our specific case is simple enough, but it often evolves and there is a very high chance that this one additional feature that we're going to need is not supported with ingress. And that's where you start having ingress in all your environment. But then you say, oh, now I need to do all the migration because I did not pick Gateway to begin with.
- [25:03]
Yeah. So I think the follow up question to that for me would be then at this point in 2025 when we're recording this, would you recommend anybody who's starting a new application on Kubernetes and they have networking needs for external traffic, should they reach for a gateway as a default?
- [25:23]
I would say definitely yes. And now are there any distinct use cases where Ingress is better recommended? I would say that if you absolutely believe that ingress is all you need and you 100% confident and sure about it, just stay with ingress. But I think there's an increasing number of features that are already supported only with Gateway and not with Ingress. Increasing number of implementation that only supports Gateway and not Ingress. And by the way, if there is something that's missing from Gateway API and you would use Gateway only if this feature would exist in Gateway API. So let us know and definitely going to work on this.
- [25:59]
So what you are saying is, and I don't want to put words in your mouth, I'll let you answer that. What you're saying is Gateway API is ready for Primetime.
- [26:08]
Well, I'd say Primetime is already here. I can say that many thousands of users already use Gateway in production, so definitely Primetime is here. And I'll also add that this is only the beginning. I believe if some of the short term contributions gonna land like the one that installing CRDs by default that we talked about, this would even grow these thousands an even bigger number.
- [26:29]
And there have been some work, especially in the. I forget the name of the sig, but SIG Serving, I think.
- [26:36]
Yeah. W. Working Group Serving.
- [26:38]
Yes, yeah, working Group serving. And there have been some discussion about things like Gateway API Inference extension. And again, I probably have changed my mind on this quite a bit, but I had a thought about like serving large language models and AI models on Kubernetes, which was just another type of application. But since then, seeing how much of a challenge some of the accelerated workload are, I have probably changed my mind much on that particular heel, I would say. So the Gateway API inference extension. Tell me a little bit about it.
- [27:10]
Oh yeah, I anticipate that it will come. So just to clarify, the Gateway API inference extension was starting off a kind of collaboration between WGserv and Signetwork and I think it's formerly owned by think that we're now. I'm not sure it's not that interesting. As well, like who owns it. But I think what it gives is it's basically it is one of the way of extensing the Gateway API, which the Gateway API claims to be very extensible, and it basically come and address those people with inference needs on Kubernetes. So assuming you're a company, you're running your models on Kubernetes and more specifically without getting too deep for our ML audience, right? Like you're running with Lora adapters, so you're using Lora adapters to tailor your model for specific tasks. Now for people who are using some frameworks like VLLM that is basically kind of tailored for all these, for working with Lora and everything. So you get a request through the gateway, right? Like let's say a user put a request, it gets to the gateway and needs to find the right model server to get to. Right. So traditional load balancing algorithms would just do like, you know, round robin or like list requests, whatever load balancing you've been using. But apparently if you're basically, you know, you get a request, the request is requesting a specific Lora adapter. If we're able to get this to the POD with a Lora adapter already loaded, and basically save the time that our framework is kind of reloading the adapter to memory, this appeared to be very, very efficient. It increases the throughput significantly, introduces latency as well. So this is what the kind of project kind of come to address. And then this extension would probably let you, for the people who are familiar with the gateway API structure. So this project would let you target this new inference pool API from an HTTP route. So assuming you get a request for completion, right, and you want to attach to the gateway, but instead of just routing it to a service, you're going to route it to this inverse pool special API special object, which is going to do this selection for you and have a basically more smooth and more efficient part selection.
- [29:15]
Yeah, that definitely would be super useful for that kind of like Lora use cases and maybe even more. As more LLM based things come about, more research happens in terms of how do you do very specific tasks or even like maybe again, this is probably not even in the feature catalog. But like as agents become more prevalent, you probably would even be able to route to specific agents and things of that nature. So this is going to be the final question and this is a bit of like a future prediction. So in a couple of years, in a future episode of the podcast, we'll come back and see how much of the prediction Lior got right, so this is for all the marbles. Where do you see the Kubernetes networking evolve in the next few years? And again, more focus on where do you see kind of the Gateway API fitting in the future iterations of the Kubernetes networking?
- [30:04]
Well, what do you think of Kubernetes networking? Right, you're thinking about services, you're thinking about ingresses, you're thinking about mesh networking. So this is like when you say Kubernetes networking, that's what I'm thinking about. Now to clarify, that's where Gateway API is today and therefore I expect a huge portion of signetwork bandwidth would be invested in Gateway in the coming five years. There are also people who started working on cluster IP gateways and I'm going to refer to this lightning talk from Tim Hawkins back in Kubecon Chicago, which kind of indicated why Service API is kind of flawed and all the mistakes that were with service. But basically this cluster IP gateway is a replacement of service and obviously don't quote me on name, right, the name's probably going to evolve as we all know, but this would likely be developed as part of Gateway. We have already issues opened in Gateway API and this would unlock a lot of limitations exposed by the service API today.
- [30:58]
Well, I think yeah, that was a very solid prediction and more than prediction, I feel like having been involved in the project and seen the trajectory, working with insider information, so to speak with what is going to happen. But I am super excited for the usage of the Gateway API and the thing you mentioned about CIDs being installed as part of the Kubernetes distribution with the base installation of Kubernetes and Gateway becoming almost like the default thing people reach for. That would be exciting. Having used Gateway API for certain use cases, it just like the user level permission boundary. It's awesome to have kind of the responsibility segregated in the right way with cluster level permission versus user level permission. So not even with all the features, just that as an application developer I can just think about my routes and not having to think about all the other permission for the actual service entry and all that things. That itself is like worth the price of admission for me. So all the other things almost feels like a bonus. So super excited for the evolution of Gateway and seeing more adoption and hopefully in a couple of years we'll come and say that Gateway API is feature complete and you have no reason to not use Gateway for anything.
- [32:11]
Yeah, I mean it's mostly feature complete now I guess. I mean it's feature complete, definitely. But you cannot address. I mean people are creative out there like in the community, they're getting a lot of creativity, which is by the way some of the main driver for Kubernetes and everything. But addressing all the features and standardizing it and one thing it's just like not feasible and probably not encouraged. And as I said, if there's a feature that you would like to have in Gateway and that's the only thing that would brought you to use Gateway, definitely open an issue, definitely reach the stack and then we'll make sure to have it supported.
- [32:44]
And I think that's a good place to end this conversation as any. So thank you so much Lior for spending your precious time talking with us and letting us learn a bit more. I surely learned a bunch of things that I did not know, which I'll go back and research a bit more to learn and understand a bit more. So thank you so much.
- [33:02]
Thank you Mophie. I'm happy to be here.
- [33:06]
Kazan Fields
Thank you so much Mophie and Lior for that interview. The Gateway API is always something really interesting to talk about. The sessions at Kubecons are always packed. It can be hard to get into the rooms. I was actually moderating one of those sessions one time and they almost didn't let me into the room because the room was full and I was like I have to do things in this session. Luckily they did let me in, but those sessions are often full, so always excited to hear more stuff about the Gateway. Ingress is such an important feature of any workload that you're running in Kubernetes, so it's always good to learn more about it. And networking, as you said at the beginning of the episode, is so critical to everything that Kubernetes does. It's quite complex because it underlies everything. So I've been out for the last couple of weeks. Mophie, tell me about what you talked about.
- [33:57]
Mofi Rahman
Well, before I do, I would say like one quick life hack. If you're struggling to get into the ingress or like the Gateway talks, you can just like reach out to the maintainers and ask them for an interview and they would. They will tell you all about it. So that's just like one life hack from me.
- [34:11]
Kazan Fields
That is true.
- [34:12]
Mofi Rahman
If you do a podcast with them, they'll tell you in person. Like not in person that is over GVC but over video call. But they will just tell you everything you want to know. So this interview again, my initial plan was to talk about The Ingress to Gateway tool that was that released to help people convert their ingress manifest into Gateway manifests, but having the access to one of the maintainers of the project and someone who contributes to Kubernetes networking, I just kept asking more questions and we kind of kept going into a lot of the Gateway things and Lior was gracious enough to answer all my questions. So that's the episode we got and I think that was better for it because we kind of got like a much nicer wrapped picture of the entire story of what Gateway actually looks like. And the other bit of question I wanted to ask and just to get his opinions on albeit could be a little bit biased because he works on the project, but I just wanted to get his thoughts on whether or not how is the community feeling about Gateway being quote unquote, production ready? Right. So that's another bit of questions we talked about in the chatter.
- [35:21]
Kazan Fields
So I liked at the beginning you all actually talked about the Kubernetes history is one of my favorite things. You know, very big Kubernetes history buff here. And you all talked about the removal of all the cloud provider code, those like million lines of code that were removed from Kubernetes last year, and how the Gateway API kind of relates to all of that. It's within the same vein as this trend in Kubernetes of moving anything provider specific outside of Kubernetes itself, so that it's not tied to the Kubernetes release cycle, which is, I think, a really good pattern. And Gateway also does that. So it's always interesting to talk about that.
- [35:57]
Mofi Rahman
Yeah, it is a great pattern, but I think one of the challenges with that also is that as of now at least, Gateway does not come pre installed as part of your Kubernetes distribution. So for many people it seems like you are pulling in something like an external something that may not feel like, quote unquote, like original Kubernetes. So that's something actually also talked about that in the future releases of Kubernetes we're going to figure out a way to set a bunch of CIDs as part of the installation as well. Because Gateway is part of core Kubernetes. It's just a decision being made to make Kubernetes more extensible by having these extension points instead of having everything in tree, so to speak.
- [36:37]
Kazan Fields
That is something that's come up in open source conversations quite a bit lately and I like the idea of including CRDs with the installation, but not including them In Kubernetes itself, that's been one of the sticking points in the conversation because one of the reasons that all the provider code was moved out of tree to begin with is, you know, the more people you have to coordinate for a release, the more difficult it is. So keeping them as separate release processes but then installing them together, that could be good.
- [37:08]
Mofi Rahman
And also like the, I think not just the release process, but also testing it takes longer because all the vendor code needs to be tested, all the code that is in the main trunk.
- [37:18]
Kazan Fields
Needs to be tested, which costs more money.
- [37:21]
Lior Liberman
Yeah.
- [37:22]
Mofi Rahman
So one thing I think people tend to forget is that Kubernetes is an open source project that kind of runs on donation and not just money of also time from people that works in various companies, but there is also a ton of just individual contributors that does not have like a big company association. They're just donating their time and making this project survive and work. Right. So like making the project more sustainable long term in the next decade that we are already in of Kubernetes. So that is going to be crucial to make sure that people can continue to build and add new things and being able to add things in a faster speed until it needs to be merged into the main path. It is extremely crucial. I think Gateway API is already like from idea to now about 5 to 6 years old, but I can imagine if they tried to build it as part of the main path, it probably would have taken like three to four years more for the API to get to the point it has.
- [38:18]
Lior Liberman
Right.
- [38:18]
Mofi Rahman
Because they could have their own release cycle build much quicker. And I think overall that is the correct decision, although at times can create some friction because things are moving separately from each other.
- [38:29]
Kazan Fields
Some interesting conversations in open source about that. Any other highlights that you want to call out from your interview?
- [38:36]
Mofi Rahman
Yeah, I think the couple of big ones and we talked about in the interview is that the Ingress to Gateway tools tool kind of is adding a lot more features to help you move any types of ingress configuration that you have to move it to Gateway. And the maintainers, lior included, are open to your feedback. If you try to take your existing ingress and the Ingress to Gateway does not do exactly what you need it to do. And if that's the use case a lot of people are having, they're open to having the discussion. We'll link the basically the GitHub project in our show notes. So if you want to go there and post issues is going to make the tool that much easier and Move the migration over to Gateway that much smoother for everybody. So that's kind of like the one big one. The other one is that if you're building any new application in 2025 today, choosing Gateway as the first choice is probably the way to go. There are very few use cases where Gateway would not be the one that does your networking coverage. And on top of that, if you're looking for ways to handle any other traffic other than tcp, Gateway is probably the way you should go anyway. Because people try to make ingress work using like extensions, some other external CRDs that makes it extremely unportable. What is the not portable, right. That is the opposite of portable because these CRDs are tied to a specific installation of the Ingress software or your cloud provider. But Gateway makes everything very extensible. So Gateway already supports like UDP and TCP and GRPC all out of the box. So again 2025, any new application you're building probably look at Gateway and if that doesn't cover everything you need, that is a good time to actually bring it up with the Gateway maintainers that this is my use case. I'm seeing this not being supported on Gateway. What can we do? So over the last few years they have been talking to the community and adding more and more features. So we are getting to the point where almost feature complete, we'll never get to 100% because nothing ever is. But for majority of the people, Gateway is probably the right first call.
- [40:40]
Kazan Fields
And we talked about how Gateway involves some provider code, but we didn't talk about why that is in past episodes about the Gateway API. We have talked about it. So there was the Ingress API built into Kubernetes. But realistically, if you're talking about traffic that's coming into your applications it and the networking underlying it, then you're going to have to interact with whatever creates that networking for you in order to implement things as effectively and robustly as possible.
- [41:13]
Mofi Rahman
Yeah, so Gateway API mostly provides almost like an interface that anybody that can implement. For example on Google Cloud we have our multiple implementation of the Gateway API. But there are a number of providers that can do that. There are Kong, there's Traefik, they all have implemented their own version of like the Gateway API. And one big one we also talked about in the conversation is that nginx is actually have announced that they're going to build out their own Gateway. So nginx easily is the biggest ingress provider in the community space right now. And a lot of the users A lot of the missing links of what people think about Gateway are features from nginx. So if nginx folks actually implement the Gateway API, that actually lowers the barrier even more and make it even easier for people to adopt Gateway. So the gateway was by design, in a sense that every gateway is implementing an API that anybody with the resources to build out can build out.
- [42:12]
Kazan Fields
You'd call it the same way. Just it's using the things that your thing is built on. Yeah, yeah. And so you have to install things for that.
- [42:22]
Lior Liberman
Yeah.
- [42:22]
Mofi Rahman
Which kind of has been kind of design philosophy. And again, like let's say on Google Cloud or your cloud provider, if they're providing a gateway API that can be kind of bundled in as part of the cluster creation process, you only need to decide on a unique gateway if you're manually installing kubernetes on your own data center. Even then you could probably bundle in as part of the cluster creation process instead of having to install a new gateway. Because the percent of people that needs a different gateway within the same cluster, it's actually not probably not that high. Like your company or your team or your organization. Whatever cluster you're creating, you probably want to be on the same style of Gateway anyway.
- [43:02]
Kazan Fields
Yeah. Having both Ingress and Gateway would just confuse things. But the barrier to entry is really not that high now for a Gateway.
- [43:10]
Lior Liberman
Yeah.
- [43:10]
Mofi Rahman
And that's kind of the gist of the conversation. I think last time we had a Gateway episode in the show was I think 2022, one of the very older episode, and that was kind of some of the beta features that was being talked about. So it's been a while. I think Gateway has evolved quite a bit in the time and the community itself, there's a lot more options for people to use Gateway now. And so I'm excited to see where gateway goes in 2025 and beyond and.
- [43:37]
Lior Liberman
How we can have more and more.
- [43:38]
Mofi Rahman
People kind of starting off as like when I first started Kubernetes. Right. Ingest was the only way to have networking. And in the middle for a couple of years, people had to kind of, oh, I see a lot of information about Ingress, but there's this new Gateway thing. Which one should I choose in a couple of years? I hope anybody that is coming to kubernetes sees the Gateway API as being the first choice for building these things out.
- [44:03]
Kazan Fields
So if you out there listening are in that migration path right now where you know that Gateway is cool, or you've just found out that Gateway is really cool, but you're using Ingress right now and you you need to transition over. Look forward in 1.33 to new tools to help you make that migration from Ingress to the Gateway API. Thank you so much Mophie, and we'll catch you next time.
- [44:26]
Mofi Rahman
Thank you. That brings us to the end of another episode. If you enjoyed this show, please help us spread the word and tell a friend. If you have any feedback for us, you can find us on social media ubernetespod or reach us by email at kubernetes podcastoogle.com you can also check out the website at kubernetespodcast.com where you will find transcripts and show notes and links to subscribe. Please consider rating us on your podcast player so we can help more people find and enjoy the show. Thanks for listening and we'll see you next time.