An ambient mesh removes the requirement of running a sidecar alongside each app in your mesh. Instead, you use node-level ztunnels to route Layer 4 traffic between apps, and waypoint proxies to enforce Layer 7 traffic policies whenever needed.

Check out the following video to see ambient mesh in action.

What is ambient mesh?

Solo collaborated with Google to develop ambient mesh, a new “sidecarless” architecture for the Istio service mesh. This architecture reduces the complexity of adopting a service mesh. You no longer have to inject a sidecar into your apps. But, you still get the benefits of Istio, such as secure mutual TLS (mTLS) for pod-to-pod communication.

Ambient mesh removes the sidecar from each pod for your apps. Instead, Istio uses node-level ztunnels to route Layer 4 traffic between apps. Waypoint proxies enforce Layer 7 traffic policies whenever needed. To onboard apps into the mesh, you simply label the namespace the app belongs to. Because no sidecar must be injected, you don’t need to worry about restarting or reconfiguring your apps. Your apps automatically become part of the ambient mesh.

What is the difference between a sidecarless and sidecar architecture?

You might wonder if you should use a sidecar or sidecarless architecture. Your approach depends on the requirements that your apps need to meet. These requirements include security, visibility, and lifecycle operations. Let’s take a look at the benefits each architecture offers.

For detailed information about ambient mesh, see this Istio blog. For an example of how routing works in a sidecarless vs. sidecar service mesh architecture, see the Ambient architecture guide in the Gloo Mesh Enterprise docs.

Sidecarless architecture

The sidecarless architecture means that you do not need a sidecar in the same pod as your app. Communication between pods is still secured via mutual TLS (mTLS). This approach reduces your lifecycle operations in several ways, including:

  • Fewer cluster resources to run your workloads
  • Easier onboarding with no app configuration changes
  • Simpler lifecycle operations by not having to restart the app

By default, ambient mesh routes traffic over Layer 4 of the OSI networking stack. Waypoint proxies are used for Layer 7 only when needed. This networking approach also reduces complexity, including:

  • Simpler service mesh architecture
  • Smaller risk of CVEs on Layer 4 vs. Layer 7
  • Greater network performance in the service mesh

Sidecar architecture

A sidecar architecture, on the other hand, uses sidecars that run in each app’s pod. This approach gives several security benefits, such as:

  • Stronger pod identity that enforces mTLS encryption per pod
  • Reduced vulnerability surface, because any compromise impacts only that app

Network traffic is always on Layer 7 of the OSI networking stack. This way, you get greater visibility into the service mesh to help with things such as:

  • Detecting bottlenecks
  • Troubleshooting issues
  • Improving workload parameters, such as resource requests and limits

Why ambient and Gloo Mesh Core?

Running ambient workloads in Gloo Mesh Core provides the following benefits:

  • Observability with the Gloo UI and built-in Prometheus: Get instant access to L4 and L7 metrics for ambient workloads and visualize them with the Gloo UI. Metrics are automatically collected by the ztunnels and waypoint proxies, and are scraped by the built-in Prometheus server. You can run PromQL queries in Prometheus to analyze the metrics and monitor the traffic in your ambient mesh.
  • Support for any CNI: You can run Gloo Mesh Core in ambient mode on any CNI, such as Cilium, Calico, or cloud provider-specific CNIs.
  • Ambient insights: Gloo Mesh Core comes with an insights engine that automatically analyzes your Istio and Cilium setups for health issues. Then, Gloo shares these issues along with recommendations to harden your Istio and Cilium setups. The insights give you a checklist to address issues that might otherwise be hard to detect across your environment. For more information, see Insights.

Components

Review the key components that make up the ambient mesh architecture.

ztunnel

The ztunnel is a zero trust, lightweight proxy that handles only Layer 4 traffic in the ambient mesh. It is deployed as a daemon set on every node of the cluster. 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.

Waypoint proxy

The waypoint proxy is a Layer 7 proxy that is shared between apps in the same service account.To enforce a Layer 7 policy for an app, you must manually deploy a waypoint proxy to the cluster. Then, when a request is sent to a target app that has L7 policies applied, the request is forwarded from the ztunnel to the waypoint proxy of the target app. The waypoint proxy enforces the L7 policy and collects L7 metrics before the request is forwarded to the ztunnel that runs on the same node as the target app. Traffic between the ztunnel and the waypoint proxy is secured via mTLS by default.

Istio CNI plug-in

The Istio CNI plug-in is deployed as a daemon set on every node of the cluster and monitors all pods that are created or removed from the ambient mesh. For all pods that participate in the ambient mesh, the CNI plug-in configures the redirect from the app to the ztunnel.

Istio control plane

The Istio control plane istiod rolls out the ambient mesh configuration to the ztunnels and waypoint proxies in the cluster and keeps this configuration up-to-date. To enable mTLS connections between ztunnels and waypoint proxies, the control plane generates the TLS certificates. At the same time, the control plane acts as a Certificate Authority (CA) to sign the certificates. The certificates are used by the ztunnels and waypoint proxies to do mutual TLS authentication.

More resources for ambient mesh

Check out the following resources for more information about ambient mesh.

  • Reduce cloud costs: Explore how Istio Ambient Mesh cuts the service mesh costs typically associated with sidecars.
  • Demo video: Watch Solo’s Christian Posta explain key ambient mesh features in a demo video.