Introducing Aeraki Mesh: Extending Istio Service Mesh to Manage Any L7 Protocol

Aeraki Mesh (named after the Greek word for "breeze") is an open‑source CNCF sandbox project that enhances Istio by enabling support for arbitrary layer‑7 protocols beyond HTTP and gRPC.

Service Mesh Lacks Protocol Support

Current service meshes, such as Istio, have limited support for protocols other than HTTP/gRPC. Envoy's RDS is HTTP‑centric, proprietary protocols require custom Envoy filters, and managing widely used L7 protocols (e.g., Dubbo, Thrift, Redis, Kafka) becomes difficult.

Typical protocols include:

RPC: HTTP, gRPC, Thrift, Dubbo, custom RPCs

Messaging: Kafka, RabbitMQ

Cache: Redis, Memcached

Database: MySQL, PostgreSQL, MongoDB

Aeraki's Approach

Aeraki Mesh provides a non‑intrusive, extensible way to manage any L7 traffic within an Istio service mesh.

Key components:

Aeraki : Translates high‑level traffic‑management rules into Envoy filter configurations and pushes them via Istio's EnvoyFilter API. It also acts as an RDS server for MetaProtocol proxies.

MetaProtocol Proxy : Implements common L7 functions (load balancing, circuit breaking, routing, rate limiting, fault injection, authentication). Adding a new protocol only requires implementing a codec interface and minimal configuration; custom filters can be added for special needs.

Dubbo and Thrift are already supported via MetaProtocol, with more protocols under development. Aeraki can also manage proprietary protocols by writing a MetaProtocol codec.

While most stateless request/response protocols can be handled, some (e.g., Redis slot‑based routing) need special handling; Aeraki currently supports Redis and Kafka for such cases.

Deep Dive into MetaProtocol

Before MetaProtocol, adding a new protocol required writing a full Envoy filter to handle routing, header manipulation, fault injection, etc. MetaProtocol centralizes these common functions, reducing the effort to just implementing a codec.

The control plane monitors services and traffic rules, generating configurations for sidecar proxies and delivering them via EnvoyFilterMetaProtocol RDS.

Two important data structures in MetaProtocol Proxy:

Metadata : Used for routing decisions.

Mutation : Holds header modifications.

During request processing, the decoder populates Metadata, which the router uses to select an upstream cluster. If mutations are needed, they are filled into the Mutation structure and applied by the encoder before sending the request downstream. The response path mirrors this flow in reverse.

An Example (Thrift)

Data Plane

Implement the codec interface to encode/decode Thrift packets (refer to existing Dubbo/Thrift codecs for guidance).

Define the protocol via an Aeraki ApplicationProtocolCRD YAML snippet.

Control Plane

No custom control‑plane code is needed; Aeraki watches services and traffic rules, generates sidecar configurations, and pushes them via EnvoyFilterMetaProtocol RDS.

Protocol Selection

Protocol identification follows Istio’s convention: name the service port with the pattern tcp-metaprotocol-<protocol>-xxx (e.g., tcp-metaprotocol-thrift ).

Traffic Management

Use Aeraki CRDs to define routing rules, such as sending 20% of traffic to version v1 and 80% to version v2.

For further reading, see the announcement "Aeraki Mesh officially enters CNCF sandbox".