About

An ambient mesh is a service mesh that operates independently of the workloads that are enrolled in it.

Compared to traditional ("sidecar") service mesh, where a proxy server is embedded alongside each workload, an ambient mesh uses shared proxies which are operated separately from a user’s application.

In order to securely deliver this, functionality related to network routing and transport security (Layer 3 and Layer 4 of the OSI model, generally referred to as “L4”) and functionality relating to HTTP or other application protocols (Layer 7, or “L7”) is split. Layer 4 functionality is delivered by a shared proxy operating on every node, and Layer 7 functionality is provided by a proxy server shared within the security boundary of the application (traditionally, the Kubernetes namespace).

Ambient mesh was first built in 2022 by a team of engineers from Solo.io and Google Cloud. It is implemented in the Istio project, and by products that are derived from it.

How does it work?

Ambient mesh layers on top of a cloud native environment to transparently enable zero-trust security, observability, and advanced traffic management. Compared to traditional service mesh, the users deploying applications in an ambient mesh do not see, and are not responsible for, any of the infrastructure - it is provided by the environment upon which the application runs.

Consider a client pod wishing to connect to a server pod within a Kubernetes environment:

Application traffic without service mesh

Application traffic without service mesh

Ambient mesh is provided using two distinct layers. At the base, the secure overlay layer handles routing and zero trust security for traffic. Traffic is transparently routed through the ztunnel agents, which run on each node in the cluster.

The layer 4 view of the cluster, with routing performed by the node ztunnel proxy.

The layer 4 view of the cluster, with routing performed by the node ztunnel proxy.

Above that, when needed, users can enable L7 waypoint proxies to get access to the full range of service mesh features. The waypoint proxies, while heavier than the ztunnel overlay alone, still run as an ambient component of the infrastructure, requiring no modifications to application pods.

Users can add L7 features by deploying a waypoint proxy in a server’s namespace. Traffic appears to the waypoint as if from the client, but is actually routed through the ztunnel proxies.

Users can add L7 features by deploying a waypoint proxy in a server’s namespace. Traffic appears to the waypoint as if from the client, but is actually routed through the ztunnel proxies.

Traffic is routed through the ztunnel proxies to the waypoint associated with the service, entirely transparently to your application. Because the ztunnels are deployed on every node, enabling ambient mesh is as simple as applying a label to a namespace.

Like traditional service mesh, all you need to do is make a connection to a remote service. Unlike traditional service mesh, you don’t need proxy infrastructure co-located with your application pods.

Explore the following sections to learn about ambient mesh: