About ambient mesh
Ambient mesh is an experimental feature that is offered as a private alpha to gather feedback from users and continue testing. Alpha features are likely to change, are not fully tested, and are not supported for production. For more information, see Gloo feature maturity. If you are interested in trying out ambient mesh, contact a Solo account representative.
Check out the following video to see ambient mesh in action.
Get started
Gloo Mesh Enterprise offers support for ambient workloads as an experimental feature that you can try out in your Kubernetes clusters at no additional cost. Simply install Istio with the ambient profile and start onboarding workloads to an ambient mesh. For more information, see the Get Started with Istio Ambient Mesh blog.
What is ambient mesh?
Ambient mesh was initially developed by Solo engineers in collaboration with Google and introduces a new sidecarless architecture that you can leverage in your Istio service mesh. It was developed with the intention to reduce the complexity of adopting a service mesh and remove the risk of injecting sidecars into workloads without losing secure, mutual TLS (mTLS) pod-to-pod communication.
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. To onboard workloads into the ambient mesh, you simply label the namespace the workload belongs to. Because no sidecar must be injected, workloads do not need to be restarted or changed in order to participate in the ambient mesh.
What is the difference between a sidecarless and sidecar architecture?
Deciding between a sidecar and sidecarless architecture for your service mesh is highly dependent on the workloads that are part of the service mesh, and the security, visibility, operational, and management requirements that you have. Istio offers the flexibility to mix different service mesh architectures within the same service mesh so that you can decide what architecture best meets the needs of your app. To understand what architecture fits your workload, 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 Architecture.
Sidecarless architecture
With a sidecarless architecture, you secure communication between services via mutual TLS (mTLS) without the need to inject a sidecar into each workload. This approach significantly reduces operational cost and the cluster resources that are required for your workloads, and simplifies the onboarding process of apps into the service mesh as they do not need to be changed or restarted. Furthermore, traffic is routed over Layer 4 of the OSI networking stack by default, and Layer 7 waypoint proxies are used only when needed which can further simplify the service mesh architecture and improve performance in the service mesh.
Sidecar architecture
A sidecar architecture, on the other hand, uses sidecars that run alongside each workload to provide strong pod identity and mTLS encryption to secure the communication between microservices in the mesh. This approach reduces the surface of vulnerability, as compromising a sidecar affects only the app the sidecar belongs to. Because sidecars always operate on Layer 7 of the OSI networking stack, you get L7 visibility into the service mesh traffic. You can use the metrics to detect bottlenecks, troubleshoot issues, or improve workload parameters, such as resource requests and limits.
Why ambient and Gloo Mesh Enterprise?
Running ambient workloads in Gloo Mesh provides the following benefits:
- Waypoint proxy lifecycle management: Gloo Mesh 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.
- Waypoint proxy customization: You can optionally override the default waypoint proxy specification in Gloo Mesh to create multiple waypoint proxy instances by default. Running multiple waypoint proxy instances can be useful if you have multiple apps that share the same service account.
- Multitenancy and zero trust with Gloo workspaces: Organize cluster resources for different teams and tenants with Gloo workspaces. You can enable service isolation for ambient workloads so that services in one workspace cannot communicate with services in another workspace.
- 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.
- Protect ambient workloads with Gloo traffic policies: Apply advanced traffic policies, such as fault injection, outlier detection, failover, rate limiting, and more to ambient workloads in your cluster. Gloo automatically translates these policies into Istio resources so that they can be enforced via the waypoint proxies.
- Central management with Gloo: Ambient mesh is fully integrated into the Gloo Platform 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.
For a full list of supported features, see Supported features.