Project announcement by Istio Maintainers
The upcoming 1.22 version of Istio brings the Layer 4 features of the sidecar-less service mesh architecture to production readiness
Istio, the most widely adopted service mesh, proudly announces the upcoming beta release of ambient mode in version 1.22.
Istio’s ambient mode is designed for simplified operations without requiring changes or restarts to your application. It introduces lightweight, shared node proxies and optional Layer 7 (L7) per-workload proxies, thus removing the need for traditional sidecars from the data plane. Compared with sidecars, ambient mode reduces memory overhead and CPU usage by over 90% in many cases. Under development since 2022, the beta release status indicates Istio’s ambient mode features and stability are ready for production workloads with appropriate cautions.
Ambient mode features promoted to Beta in 1.22 include; a secure overlay layer with mutual TLS, enhanced metrics and Layer 4 (L4) authorization policies, and integration between the L4 secure overlay with L7 waypoint proxies. Istio’s implementation of L7 waypoints is currently in Alpha phase and is on track to upgrade to Beta in the near future.
Why would I want to use ambient mode?
In the past, we have observed users want some of the mesh functions for their applications but walked away from service mesh due to complexity and overhead of sidecars. Ambient mode greatly simplifies the operational life cycle of your application deployment onto Istio by using a lightweight node proxy called the zero-trust tunnel, or ztunnel.
Ztunnel drastically reduces the overhead needed to run a mesh by removing the need to potentially overprovision memory and CPU within a cluster to handle expected loads. In some use cases, the savings can exceed 90% or more, while still providing zero-trust security using mutual TLS with cryptographic identity, enhanced metrics, and L4 authorization policies. In addition, users can optionally deploy per-workload L7 proxies called waypoints for functions such as traffic routing, rich authorization policy enforcement, and enterprise-grade resilience.
But what about all those sidecars I have?
Sidecars are not going away and remain first-class citizens in Istio. You can continue to use sidecars and they will remain fully supported. Some use cases, such as custom policy enforcement or destination services with highly granular service configurations, will continue to be best implemented using the sidecar pattern. We believe most use cases will be better served with a mesh in ambient mode, and the Istio project remains committed to ongoing sidecar mode support.
How does ambient mode make deployment and adoption easier?
We refer to the mode as ambient because it is designed to be transparent to your application, meaning that no additional configuration is necessary to adopt it; no restart is required – meaning zero downtime. Ambient mode works without any modification of your existing Kubernetes deployments. Just label a namespace to add all of its workloads to ambient, or opt-out of certain deployments as needed. By enabling ambient mode, many troubling restrictions of the sidecar model have been eliminated: server send-first protocols now work, reserved ports are removed, and the ability of containers to bypass the sidecar – either maliciously or not – is no longer possible.
The separation between the L4 secure overlay layer and L7 processing layer allows incremental adoption of the ambient mode data plane in contrast to the earlier binary “all in” injection of sidecars. Users can start with the secure overlay layer which offers mTLS with cryptographic identity, simple L4 authorization policy, and telemetry. Even without any L7 processing, the secure overlay layer dramatically reduces the attack surface. Later on, complex L7 handling such as retries, traffic splitting, complex load balancing, and observability collection can be enabled on a case-by-case basis.
Why else might I want to run in ambient mode?
In addition to the run-time benefits outlined above, ambient mode also allows true lifecycle management of the data plane, and eliminates the potential for race conditions and orphaned containers. The ztunnel node proxy is always available, removing the potential for workloads to be ready before the sidecar proxy was ready. In addition, users of Kubernetes Jobs which may inject a sidecar, will not orphan those pods, mitigating the resource consumption and security risks exposed by those scenarios.
What else can ambient mode do?
Ambient mode is designed to be invisible to your applications in Kubernetes or VMs for L4 functions such as mTLS, simple authorization policy and telemetry. The separate L4 and L7 proxies enable easier extension of the mesh to targets that may have been traditionally difficult to integrate such as serverless functions, additional VM-based nodes, or even directly into core libraries available for many application ecosystems. Istio’s ambient mode realizes the vision and answers the requirements of modern service meshes everywhere!
Try Istio today!
With the upcoming 1.22 release of Istio and the beta release of ambient mode, it will be easier than ever to try out Istio on your own workloads. More information on installing Istio and setting up a mesh in ambient mode on 1.21 or 1.22 nightly builds is available at https://istio.io/latest/docs/ops/ambient/. Stable binary releases are and will always remain freely available at https://istio.io.