Envoy Gateway Offers to Standardize Kubernetes Ingress
The Envoy Proxy project is expanding, with the aim of establishing a standardized, simplified set of APIs for working with Kubernetes itself.
This week, at the KubeCon+CloudNativeCon EU, the open source project revealed that is has been working on an extension, Envoy Gateway, that would equip the Envoy reverse proxy to be a network gateway, allowing it to not only direct internal microservices traffic, but also to manage external traffic coming into the network. Kubernetes is the initial target.
The idea behind the Envoy Gateway is to provide “a simplified deployment model and API layer aimed at lighter use cases,” explained Envoy creator Mat Klein, in a blog post.
Originally created for Lyft, Envoy was released as open source in 2016 and has been primarily used to build service meshes (often with Istio, another CNCF project) that help cloud native apps communicate with one another by way of sidecars.
Interestingly, Lyft itself first used the software as an API gateway/edge proxy, meaning it could easily serve as a reverse proxy for internally routing outside traffic as well, offering the same level of observability and zero trust security.
The Envoy Proxy project was adopted by the Cloud Native Computing Foundation is 2017 and has reached the Graduated project maturity level. Envoy Gateway will be hosted by CNCF as well, as a spin-off project.
Kubernetes Gateway API
According to Klein, the API Gateway can be thought of “as a wrapper around the Envoy Proxy core,” one that would not make any significant changes to the core itself. It can manage L4/L7 traffic in a variety of use cases.
For admins, the software aims to provide an easier way to set up Kubernetes service mesh. Envoy itself is not so easy to administer, Klein himself admits. A bit of ease-of-use might help attract more users, namely those with smaller networks who now tend to deploy HAProxy or Nginx for Kubernetes ingress duties instead.
Perhaps more importantly, the project would like to see developers and third-party tool vendors settle on using the Envoy Gateway to access Kubernetes, by providing a reference implementation to run Envoy as an ingress controller for a K8s cluster. This API will be “the Kubernetes Gateway API with some Envoy-specific extensions,” Klein explained.
“This API was chosen because deployment on Kubernetes as an ingress controller is the initial focus for the project and because the API has broad industry buy-in,” he said.
Use of the Kubernetes Gateway for configuration would decouple “routing from management in its API,” further explained Ambassador Labs CEO Richard Li, in a blog post. Ambassador is a sponsor of the project, along with Fidelity, Tetrate, and VMware. The API would hide the low-level configurations that developers and admins would otherwise have to tangle with.
The project will “focus on making the experience incredibly simple and easy for individual application devs or teams to take and deploy Envoy in their infrastructure,” Tweeted Zack Butcher, who is an Istio contributor and steering committee member.
Butcher also noted that converging on the Kubernetes Gateway API would reduce the amount of duplicate work now being undertaken to build competing control planes.
“Control planes are boring! They’re also expensive to build and hard to get right,” Butcher noted.
If the Kubernetes user base were to all agree to deploy these APIs, it will allow their vendors “to easily provide alternate SaaS implementations that may be preferable if a user outgrows the reference implementation, wants additional support and features, etc,” Klein argued.
Third-party software developers can then move up the stack, and work on building advanced features atop the standardized, vendor-neutral, Kubernetes Gateway API.
This is not the first CNCF to tackle the API gateway. But the best bits of Contour and Ambassador’s Emissary will be merged into this new effort, CNCF said.
