Envoy Gateway 0.3.0 Release

New features and Kubernetes Gateway API 0.6 compatibility

Welcome to the first article in our series on Envoy Gateway releases, covering the February 2023 release of v0.3.0. Our goal with this series is not just to rehash the release notes or cover them in full but to highlight major and minor changes we think are important and provide context. This release includes

• Compatibility with Kubernetes Gateway API v0.6.1
• Support for extended Gateway API fields
• Support for experimental Gateway APIs, including GRPCRoute and UDPRoute
• Global Rate Limiting
• Authentication
• WebSocket support
• Separate scaling of the control plane and Envoy Proxy

What is Envoy Gateway?

Envoy Gateway is an implementation of the Kubernetes Gateway API based on Envoy Proxy. The goal is to leverage Envoy Proxy's capabilities as a gateway, just like Ambassador Labs’ Emissary-Ingress project, but by following the new common standard of the Gateway API. Ambassador Labs is on the steering committee for Envoy Gateway along with Tetrate, VMWare, Fidelity Investments, and Tencent.

Ambassador Labs’ goal is to get Envoy Gateway to the point of maturity and capability that it can be seamlessly dropped into any environment currently using Emissary-Ingress or Ambassador Edge Stack as an API gateway.

Key Envoy Gateway Updates

To avoid overcrowding this article, if you need an overview of what “extended” and “experimental” fields and APIs mean, check out my previous post on the Gateway API 0.6.0 release, where we discuss the various release channels of that project.

Extended Gateway API fields

Filters in the Gateway API are ways to do additional processing on a request, like modifying the request or response, doing authentication (see below!), etc. The 0.3.0 release of Envoy Gateway adds support for three new filters on HTTPRoutes:

• URLRewrite — changes the upstream request hostname and/or path
• RequestMirror — allows a request to be mirrored to a separate backend from the original target
• ResponseHeaderModifier — allows modification of response headers. Request header modification was introduced in Envoy Gateway v0.2.0.

Experimental Gateway APIs

In addition to the HTTPRoute and TLSRoute resources that are in the Gateway API Standard release channel, Envoy Gateway now supports three experimental APIs:

• TCPRoute
• UDPRoute
• GRPCRoute

These additions continue to bring Envoy Gateway closer to feature parity with Edge Stack, and in some ways, go beyond it! Certain use cases require L4 protocol usage. Edge Stack provides the TCPMapping but does not have any UDP support. Envoy Gateway now supports both. I covered GRPCRoute in depth in my Gateway API post, but it’s basically a nicer interface for configuring gRPC routing than using the standard HTTPRoute, and it’s cool to see it land so quickly in Envoy Gateway.

New custom filters

The Gateway API defines three levels of conformance:

• Core
• Extended
• Implementation-specific

These levels allow the API to define common standards while allowing each implementation to add features that may not work in all the implementations. Envoy Gateway adds two implementation-specific filters in this release to provide two key pieces of functionality for an API gateway.

Rate limiting

The new RateLimitFilter allows for global rate limiting on a given route. While global rate limiting is…limited in its value, this early implementation sets the stage for more complex forms of rate limiting and acts as an example of how to use the API.

Authentication

Similarly, the new AuthenticationFilter is currently limited to JWT authentication, but that’s a great place to start, as it’s one of the most commonly used authentication methods. It allows the user to point Envoy Gateway at a remote key set endpoint to validate encryption keys, check the token issuer, and list the audiences allowed to access the route.

WebSocket support

This is one of the most exciting features to me because I’ve done a lot of work with WebSockets, and supporting that protocol feels like table stakes for an API gateway. However, in the Gateway API, support for Websockets is stuck in a Gateway Enhancement Proposal (GEP) that states the need for creating a standard to simply describe things like Websockets, re-encryption, or HTTP/2 support. So to see Envoy Gateway add support for WebSocket upgrades ahead of the Gateway API and make those upgrades automatic is awesome! It makes the experience more seamless for users and would have saved me a few Mappings in my previous roles.

Scaling

Another new addition is the ability to separately scale the pods in the Envoy Gateway control plane and the Envoy Proxy pods that actually do the traffic routing. The process is somewhat obtuse right now as it’s done in a config map:

apiVersion: v1
kind: ConfigMap
metadata:
  name: envoy-gateway-config
  namespace: envoy-gateway-system
data:
  envoy-gateway.yaml: |
    apiVersion: config.gateway.envoyproxy.io/v1alpha1
    kind: EnvoyGateway
    provider:
      type: Kubernetes
    gateway:
      controllerName: gateway.envoyproxy.io/gatewayclass-controller
    ---
    apiVersion: config.gateway.envoyproxy.io/v1alpha1
    kind: EnvoyProxy
    metadata:
      name: envoyproxy-sample
    spec:
      provider:
        type: Kubernetes
        kubernetes:
          envoyDeployment:
            replicas: 2

However, as the project matures and ease-of-use features like a Helm chart are created, I’m sure this interface will improve.

The Next Envoy Gateway Release

The next release of Kubernetes Gateway API will be v0.4.0 with a theme of “Manageability and Scale.” The majority of work being done is visible in the 0.4.0-rc.1 milestone on GitHub. We’ll provide an update when that release is available!