That Envoy Proxy The project is being expanded with the goal of establishing a standardized, simplified set of APIs for working with Kubernetes itself.
This week at KubeCon+CloudNativeCon EUthe open source project revealed that it was working on an extension, Envoy Gateway, which would make the Envoy reverse proxy a network gateway, allowing it to not only route internal microservices traffic, but also manage external traffic entering the network. Kubernetes is the initial target.
Originally developed for Lyft, Envoy was released as open source in 2016 and was primarily used to create service meshes (often using Istio, another CNCF project) that help cloud-native apps talk to each other via sidecars.
Interestingly, Lyft itself initially used the software as an API gateway/edge proxy, meaning it could easily serve as a reverse proxy for internal routing of external traffic, while providing the same level of observability and zero-trust security.
The Envoy Proxy project was inherited from the Cloud Native Computing Foundation is 2017 and has reached the Graduated project maturity level. Envoy Gateway is also hosted by CNCF as a spin-off project.
Kubernetes Gateway API
According to Klein, you can think of the API gateway “as a wrapper around the Envoy Proxy core” that would not make any significant changes to the core itself. It can manage L4/L7 traffic in a variety of use cases.
For administrators, the software should offer an easier way to set up Kubernetes Service Mesh. Envoy itself is not that easy to administer, admits Klein himself. A little ease of use could help attract more users, especially those with smaller networks who are now more prone to deployment HAProxy or nginx instead for Kubernetes ingress duties.
Perhaps more importantly, the project aims to engage developers and third-party tools to use 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 use “the Kubernetes Gateway API with some Envoy-specific extensions,” Klein explained.
“This API was chosen because deploying to Kubernetes as the ingress controller is the initial focus of the project and because the API has broad industry adoption,” he said.
Using the Kubernetes Gateway for configuration would “decouple routing from management in its API,” it goes on to explain Ambassador Labs CEO Richard Liin one blog entry. Ambassador is a sponsor of the project along with Fidelity. tetrats, and VMware. The API would hide the low-level configurations that developers and administrators would otherwise have to deal with.
The project will “focus on making the experience incredibly simple and easy for individual application developers or teams to incorporate and deploy Envoy into their infrastructure.” Tweeted Zack Butcher, Istio contributor and steering committee member.
Butcher also noted that convergence on the Kubernetes Gateway API would reduce the amount of duplication of work now being done to create competing control planes.
“Control planes are boring! They’re also expensive to make and hard to get right,” Butcher noted.
If the Kubernetes user base all agreed to provide these APIs, it would allow their vendors “to easily provide alternative SaaS implementations that may be preferable if a user grows beyond the reference implementation, wants additional support and features, etc.” , Klein argued.
Third-party software developers can then move up the stack and work to develop advanced functionality based on the standardized, vendor-neutral Kubernetes Gateway API.
The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Ambassador Labs.