Explore an Istio service mesh without sidecars by running Gloo Mesh Core in ambient mode.
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.
Ambient is a beta feature. Beta features might change and are not supported for production. For more information, see Gloo feature maturity
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.
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
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:
- 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.
- 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.
- Central management with Gloo: Ambient mesh is fully integrated into the Gloo stack. With the Gloo management server, you can manage resources in multiple clusters in a single place. This significantly reduces management overhead and simplifies troubleshooting resources across clusters.
Review the key components that make up the ambient mesh architecture.
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.
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.
Want to automate waypoint proxy creation? Check out Gloo Mesh Enterprise in ambient mode. Gloo Mesh Enterprise manages the entire lifecycle of the waypoint proxy for you. If you create a policy or routing rule that requires a waypoint proxy, the proxy is automatically created for you and tied to the service account of your app.
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.