Architecture

Learn more about how ambient mesh works under the covers.

Overview

An ambient mesh is logically split into a data plane and a control plane.

• The data plane is composed of a set of programmable proxy servers, also referred to as ztunnels and waypoint proxies. These proxies mediate and control all network communication, and collect and report telemetry on all mesh traffic. Compared to traditional service mesh architectures, where the proxy servers are deployed as “sidecars” next to every workload, ambient mesh uses proxy servers that are operated by the cluster administrator.

• The control plane manages and configures the proxies in the data plane.

Components

There are three main components that comprise an ambient mesh:

Istiod

The Istio control plane istiod provides service discovery, configuration, and certificate management for your ambient mesh. When new configuration becomes available, istiod rolls out this configuration to the ztunnels and waypoint proxies in the cluster at runtime.

To enable mTLS connections between ztunnels and waypoint proxies, istiod acts as a Certificate Authority (CA) to sign TLS certificates. The certificates are used by the ztunnels and waypoint proxies to do mutual TLS authentication.

Deployment: Istiod is typically deployed as a single instance per mesh. However, you can also operate istiod in high availability mode.

ztunnel

The ztunnel (Zero Trust tunnel) component is a lightweight, purpose-built, per-node proxy that powers ambient mesh.

Ztunnel is responsible for securely connecting and authenticating workloads within the mesh. The ztunnel proxy is written in Rust and is intentionally scoped to handle L3 and L4 functions such as mTLS, authentication, L4 authorization, and telemetry. All traffic to and from an app that is part of the ambient mesh is always redirected to the ztunnel that runs on the same node as the app itself.

The ztunnel collects L4 metrics, such as the number of request or response bytes, and then forwards the request to the target app. If the target app is located on a different node, the ztunnel first forwards the request to the ztunnel that runs on the same node as the target app. Communication between ztunnel instances is secured via mutual TLS (mTLS) by default. However, traffic from the app to the ztunnel and vice versa is sent via plain text. Ztunnel can also efficiently and securely transport traffic to workloads directly or to waypoint proxies.

Keep in mind that ztunnel does not terminate workload HTTP traffic or parse workload HTTP headers. You must create waypoint proxies to handle L7 HTTP traffic.

Deployment: Ztunnel is deployed as a DaemonSet with one instance per cluster node.

Gateways and waypoints

A gateway is a proxy server deployed at the edge of the mesh, used to route traffic into or out of the mesh. A waypoint proxy is a proxy server deployed inside the mesh, used to add HTTP or other L7 features to traffic between services.

Both gateways and waypoints are deployments of the Envoy proxy, a high-performance L7 proxy server.

Gateways and waypoints run outside of application pods. They are installed, upgraded, and scaled independently from applications. Waypoint proxies are shared between applications in the same namespace or service account. They enforce L7 policies and collect L7 telemetry before forwarding requests to the ztunnel of the target destination. Traffic between the ztunnel and the waypoint proxy is secured via mTLS by default.

Many ambient mesh use cases can be addressed solely with ztunnel, and will not require a waypoint proxy. Ambient mesh is designed so that you can transparently add and remove waypoint proxies as required by your use case.

Deployment: You typically have one ingress Gateway per mesh, and one waypoint proxy per namespace (or other security boundary).