layout: post
title: "Highlights of Envoy Gateway v1.1.0: What’s New and Improved" subtitle: "" description: 'Envoy Gateway (EG) released its latest version, 1.1.0, on July 22. This update marks the first feature release since the 1.0 GA (General Availability) version and includes multiple new features and improvements. In this article, I will highlight some of the most important new features.' author: "" date: 2024-07-22 image: "https://www.zhaohuabing.com/img/travel/PXL_20240525_032754131.jpeg" published: true tags: [Envoy, Envoy Gateway] categories: [Tech,Open Source]
Envoy Gateway (EG) released its latest version, 1.1.0, on July 22. This update marks the first feature release since the 1.0 GA (General Availability) version and includes multiple new features and improvements. In this article, I will highlight some of the most important new features.
In 1.1.0, EG introduces support for Wasm extensions in OCI image format through the EnvoyExtensionPolicy CRD. OCI images facilitate easier management of different versions of Wasm extension plugins and support private images for enhanced access control and security.
Below is an example of configuring a Wasm extension in OCI image format using the EnvoyExtensionPolicy CRD:
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: oci-wasm-source-test
spec:
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: http-with-oci-wasm-source
wasm:
- name: wasm-filter
code:
type: Image
image:
url: "zhaohuabing/testwasm:v0.0.1"
sha256: cdb37a856ae7dae208cdcb19378022cc81dbcae30859f58b89ae259a9575a49d
For private images, configure imagePullSecrets for credentials and pullPolicy to specify the pull strategy.
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: oci-wasm-source-test
spec:
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: http-with-oci-wasm-source
wasm:
- name: wasm-filter
rootID: my_root_id
code:
type: Image
image:
url: oci://my-private-registry/wasm-filter-2:v1.0.0
pullSecretRef:
name: my-pull-secret
pullPolicy: Always
EnvoyExtensionPolicy also supports Wasm extensions via HTTP download.
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: http-wasm-source-test
spec:
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: http-with-http-wasm-source
wasm:
- name: wasm-filter
rootID: my_root_id
code:
type: HTTP
http:
url: https://raw.githubusercontent.com/envoyproxy/envoy/main/examples/wasm-cc/lib/envoy_filter_http_wasm_example.wasm
sha256: 79c9f85128bb0177b6511afa85d587224efded376ac0ef76df56595f1e6315c0
In addition to Wasm, EG 1.1.0 also introduces External Process extensions, allowing custom logic implementation via an independent process.
The primary advantage of the External Process extension is its flexibility. Except the requirement of gRPC API communication between Envoy and the External Process, users have full control over the extension's internal implementation, including the choice of programming language and external services interaction.
Below is an example configuration of an External Process extension:
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: ext-proc-example
spec:
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: myapp
extProc:
- backendRefs:
- name: grpc-ext-proc
port: 9002
processingMode:
request: {}
response:
body: Streamed
In version 1.0.0, Envoy Gateway (EG) supported Service and ServiceImport as two native Kubernetes backend service definitions. For services outside the Kubernetes cluster, EG recommended creating EndpointSlice objects for indirect support.
With the release of version 1.1.0, EG introduces a new API called Backend, which directly supports defining non-Kubernetes services. This API not only covers IP addresses and FQDNs (Fully Qualified Domain Names) previously supported via EndpointSlice but also adds support for Unix Domain Socket addresses. IP addresses and FQDNs are used to access services outside the cluster, while Unix Domain Sockets can be used to access services within the same Pod as Envoy. For example, an External Process extension process can be deployed as a sidecar within the Envoy Pod, communicating with Envoy via Unix Domain Sockets to avoid network communication overhead.
In version 1.1.0, the Backend API is supported as a BackendReference for both HTTPRoute and ExtensionPolicy. Future versions will gradually extend this support to other resources based on user demand. Additionally, BackendTLSPolicy can be associated with a Backend to configure TLS for non-Kubernetes services.
Below is an example of defining a Backend object and using it as the backend service for an HTTPRoute to access the external service httpbin.org:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: backend
spec:
parentRefs:
- name: eg
hostnames:
- "www.example.com"
rules:
- backendRefs:
- group: gateway.envoyproxy.io
kind: Backend
name: httpbin
matches:
- path:
type: PathPrefix
value: /
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: Backend
metadata:
name: httpbin
spec:
endpoints:
- fqdn:
hostname: httpbin.org
port: 80
IP allow and deny list are common security control measures that restrict the range of client IP addresses allowed to access a service. In version 1.1.0, Envoy Gateway (EG) supports configuring IP whitelists and blacklists through the SecurityPolicy CRD.
For example, the following SecurityPolicy enforces access control for requests to the http-with-authorization-client-ip HTTPRoute. The default access policy is set to Deny, meaning only the specified IP ranges 10.0.1.0/24 and 10.0.2.0/24 are allowed to access this HTTPRoute.
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
name: authorization-client-ip
spec:
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: http-with-authorization-client-ip
authorization:
defaultAction: Deny
rules:
- action: Allow
principal:
clientCIDRs:
- 10.0.1.0/24
- 10.0.2.0/24
Please note that EG uses the original client IP address for IP allow and deny list, you can configure how to detect the client IP address using the ClientTrafficPolicy CRD.
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: ClientTrafficPolicy
metadata:
name: enable-client-ip-detection
spec:
clientIPDetection:
xForwardedFor:
numTrustedHops: 1
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: http-with-authorization-client-ip
For stateful services, session persistence allows routing HTTP requests from the same client to the same backend instance. EG 1.1.0 supports session persistence with consistent hash load balancing, based on client IP addresses, HTTP headers, or cookies.
Note: Consistent hashing load balancing achieves soft session affinity, meaning that a client’s requests are routed to the same backend service instance for a certain period. However, if the backend instances change (e.g., scaling in or out), session persistence may be lost. In future versions, EG will support strong session affinity, ensuring that a client’s requests are always routed to the same backend instance, regardless of any changes to the backend service instances.
Below is an example of using client IP addresses for session persistence:
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
name: policy-for-route-1
spec:
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: httproute-1
loadBalancer:
type: ConsistentHash
consistentHash:
type: SourceIP
In EG, we offer flexible policies like BackendTrafficPolicy and SecurityPolicy to manage requests. Under the hood,these policies are implemented using Envoy’s HTTP Filters. The execution order of these filters, as set by EG, is fixed and generally works well. However, there are cases where users might want to customize this order. For example, you might want the Rate Limit Filter to run first, so you can immediately limit incoming requests and reduce the processing load on subsequent filters.
Starting from version 1.1.0, EG includes a new field called filterOrder in the EnvoyProxy CRD. This field allows users to define the execution order of filters.
Below is an example of a custom filter order where the Wasm Filter runs before the JWT Filter, and the CORS Filter runs after the Basic Auth Filter.
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
name: custom-proxy-config
namespace: envoy-gateway-system
spec:
filterOrder:
- name: envoy.filters.http.wasm
before: envoy.filters.http.jwt_authn
- name: envoy.filters.http.cors
after: envoy.filters.http.basic_authn
Envoy Gateway (EG) version 1.1.0 introduces multiple new features and enhancements, including support for Wasm extension with OCI images, External Process extensions, direct support for non-Kubernetes services, IP Allow and Deny list, session persistence, and custom filter order. These updates enhance EG’s versatility and customizability, making it more effective in various scenarios. Additionally, version 1.1.0 includes bug fixes that improve stability and performance.
We encourage everyone to download and try EG version 1.1.0, and to share your experiences and suggestions with the community.
For detailed release notes and a complete list of updates, please refer to the release changelog.