About
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
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.
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.
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: