An Overview of the Kubernetes Gateway API and Envoy Gateway

Last May, Ambassador Labs introduced the Envoy Gateway project. With the project about to release version 0.3.0, I want to talk about why I’m so excited about Envoy Gateway, the Kubernetes Gateway API that it implements, and why I think they are the future of Kubernetes ingress.

Kubernetes Ingress: A Look Back

In early 2018 I was on a team tasked with moving a startup from a Platform-as-a-Service (PaaS) that we had operationally outgrown to a platform we controlled and could scale based on Kubernetes. Ingress into the cluster was a critical piece of the new infrastructure we were building and one of the first challenges we had to address.

The native Ingress object was too restrictive; in the words of the Gateway API project “Ingress primarily targets exposing HTTP applications with a simple, declarative syntax.” Additionally, Ingress objects and their configuration all had to live in one namespace, making it harder to split the responsibilities of the Ingress itself (my ops team) and the routing configuration (dev teams).

We decided that Emissary-Ingress (at that time “Ambassador API Gateway”) was the best solution for our needs. It was based on the cutting-edge Envoy Proxy project. Even in those early days, it could handle protocols beyond HTTP, like gRPC and Websockets. It also had a decentralized configuration model that was perfect for how our teams were working. My team deployed Emissary-Ingress into a namespace we controlled, and dev teams could deploy Mappings (Emissary-Ingress’ routing resource) whenever they needed to along with their application and get instant routing, along with control of timeouts, retries, load balancing, etc.

Kubernetes Gateway API

Looking back, the ideas that Ambassador Labs put into Emissary-Ingress had a huge influence on the direction of the cloud-native API Gateway space, and that’s obvious in the design of the Kubernetes Gateway API. The Gateway API, to me, represents the wide adoption of a philosophy and feature set that has been critical to my Kubernetes experience. That’s why I’m so excited about it!

The Gateway API is a spec and set of Custom Resource Definitions representing the next evolution in handling traffic ingress in a cluster. There are a few key concepts that I want to highlight.

Role-oriented

This is the concept that I feel has the strongest line drawn from Emissary-Ingress to the Gateway API. In fact, it’s such an important difference from the Ingress concepts that the Gateway API documentation has a long section dedicated to it right in the introduction. Structuring your gateway so that the ownership and management of different resources can be split across teams and responsibilities has always felt like an integral feature to me, and it’s one that has been adopted over time by other projects. I love seeing it have such a huge focus in the new standard. This is also reflected in the Gateway API’s support for shared gateways and cross-namespace support.

Expressiveness and Extensibility

Ingress objects required custom annotations to support things like header-based matching and traffic weighting. The Gateway API supports these in the core spec. It also supports typed routes like HTTP and gRPC routes. For features that are not in the core spec (or aren’t yet, see below), custom resources can be linked in at various levels of ownership.

Clear levels of feature support

Gateway API is a spec, not a Gateway itself, similar to how the Ingress object was a spec that needed to be implemented by an Ingress Controller. One of its main features is portability; there can be many different implementations and you should generally be able to take your resources from one to another, picking the best implementation for your needs. But if every implementation was held strictly to the spec, that could block progress and experimentation, and even features that some teams may require now (for example, WebSocket upgrade support is not in the current spec). Gateway API specifies support levels of Core, Extended, and Implementation Specific so that implementation projects can move ahead of the spec and users always know where they stand.

Implementations

There are a lot of implementations of the Kubernetes Gateway API! Maybe the thing I’m most excited about with the Gateway API is that it appears to be a standard that people are actually coming together on, rather than being a “universal standard” that’s just another competing standard. I’m rather excited about Envoy Gateway.

Envoy Gateway

Envoy Gateway is an implementation of the Kubernetes Gateway API based on the famous Envoy Proxy project. The goal of Envoy Gateway is to provide an easily-deployable version of Envoy that can be configured using the Gateway API.

Why am I excited about this implementation in particular? For one, Ambassador Labs is on the steering committee. We join Matt Klein, Tetrate, VMware, and Fidelity Investments, in stewarding the project. But we decided to join this project because we deeply believe in Envoy, which is also the underlying technology of Emissary-Ingress. It’s a natural evolution for us. The Gateway API represents the broad adoption of ideas Ambassador Labs brought to the table, and Emissary-Ingress itself was based on Envoy; the Envoy implementation of the Gateway API is the perfect project for us to be involved in.

The main strength of basing the implementation on Envoy is that it is already feature-rich, it just needs to be configurable via the Gateway API. WebSockets, gRPC, retries, advanced load balancing, observability…anything that Emissary-Ingress can do today will eventually be available in Envoy Gateway. And the underlying capabilities will expand and be maintained in the larger Envoy project, which has fantastic velocity and diverse backing.

The Future of K8s Gateways

I’ve never been more excited about the future of traffic management in Kubernetes. Both the Kubernetes Gateway API and Envoy Gateway are young projects. Gateway API is at v0.6.0, and Envoy Gateway is about to release v0.3.0.

As each project releases new versions we will provide updates on the new features and why they matter. Keep checking back!