How does this project differ from Envoy Gateway?

[stevehipwell]

I'd like to understand how kgateway is different from the Envoy Gateway project? IIRC Envoy Gateway was kicked off as a cross company CNCF initiative to simplify the ecosystem and Tetrate were mentioned in the original announcement.

[linsun]

Hi Steve (@stevehipwell)!

Thank you for your great question! At KubeCon NA 2024, Solo.io announced its intention to donate the Gloo Gateway open source project as kgateway to the CNCF, to enrich the broader cloud native ecosystem. In case you are not familiar with Gloo Gateway, it is the most mature and widely deployed Envoy-based gateway in the market today. Built on open source and open standards, Gloo Gateway is Kubernetes-native and implements the Kubernetes Gateway API.

Kgateway is being donated to CNCF as a standalone project - a rebrand of a very mature open source gateway project that has been around since 2018. Envoy Gateway is a subproject of Envoy. Envoy became a CNCF graduated project in 2018 before Envoy Gateway was created. CNCF is known as a vendor neutral home for cloud native projects so it is common to have more than 1 API gateway projects within CNCF.

The following are key differences between Gloo/kgateway and Envoy Gateway:

Adopters: Based on both projects’ websites (https://kgateway.dev/ & https://gateway.envoyproxy.io/), Gloo/kgateway has a much larger list of adopters with many brand names such as T-Mobile, SAP, OfficeDepot, Carfax, ADP, BMW, and so on, handling large scale, mission critical enterprise systems API calls.

Features: Envoy gateway is primarily Kubernetes based while Gloo/kgateway supports not only Kubernetes but also other environments such as AWS Lambda. Gloo/kgateway supports rich API gateway features such as request transformation, CSRF or CORS or local rate limiting, Istio sidecar and ambient integration.

Maintainers: Kgateway currently has over 20 maintainers including 4 maintainers outside of solo.io. Envoy gateway has 5 active maintainers, with 6 emeritus maintainers. Gloo/kgateway was initially created in 2018 releasing over 1200 artifacts, while Envoy gateway was first established in 2022, releasing over 30 artifacts.

Architecture & Scale: Kgateway is the newest evolution of Gloo Gateway, taking ~7 years of lessons learned and refining our battle-proven Envoy control-plane to be able to handle enormous scale.

To learn more about kgateway and its future roadmap, read our blog that was published very recently. Feel free to let us know if you have any future questions or join one of our upcoming community meetings.

[stevehipwell]

Thanks for the reply @linsun. I guess I didn't quite word my question right (and I got the Gloo vendor wrong so apologies). What I really want to know is why is there a new single vendor (or close) Envoy gateway added to the CNCF landscape instead of a new collaborator to the existing multi vendor Envoy gateway project? This isn't intended to be a hostile question, but I'd like to understand the context.

[linsun]

Hi @stevehipwell, kgateway/Gloo actually predates Envoy Gateway by four years. It was first released (as Gloo) in 2018 with the 1.0 release in 2019. EG was proposed in 2022 and went 1.0 in 2024. It wasn’t a “CNCF initiative” per se, but a joint project by some existing Envoy ingress vendors. Like I mentioned, it is very common for CNCF to host multiple API Gateway (or mesh or CNI or anything) projects where projects may have different architecture, governance, goals etc.

From technical perspective, kgateway has different architectures and extensibility. We plan to publish a technical blog to elaborate how kgateway is designed for massive scale and extensibility leveraging our 7 years' expertise building Envoy based API gateways. Will keep you posted!

[stevehipwell]

OK, I'm familiar with the history and I'm not saying one project is better than the other. But given the current size of the CNCF landscape and the general sense of end-user (and maintainer) fatigue I was interested in why kgateway was a new project rather than a way to level up the existing project (which was backed by the Envoy project as well as the vendors). Having incompatible architecture and goals would be a good reason for there to be a new project, but without supporting documentation explaining "why" there is no way to validate this.

[linsun]

One addition point I wanted to add is a key principal of CNCF is no kingmakers and one size doesn't fit all, except Kubernetes. In this case, it would be odd for kgateway to join force with Envoy Gateway when kgateway is 4 years ahead on adoption, stability and have different architecture & extensibility. The goal of kgateway is to provide our users the best Envoy based API gateway in CNCF leveraging all 7 years' expertise building Envoy based API gateways and I look forward to seeing you in the kgateway community!