Introducing OpenShift Service Mesh 3.2 with Istio’s ambient mode

We are thrilled to announce the general availability of Red Hat OpenShift Service Mesh 3.2. This release includes the general availability of Istio’s ambient mode—a new way of deploying service mesh without sidecars that significantly lowers the resource costs of using service mesh. This provides a low overhead solution for zero trust networking with lightweight pod-to-pod mTLS encryption and authorization policies based on workload identities, with the ability to add more advanced features as required.

Based on the Istio, Envoy, and Kiali projects, this release updates the version of Istio to 1.27 and Kiali to 2.17, and is supported on Red Hat OpenShift 4.18 and above.

Upgrading to OpenShift Service Mesh 3.2

If you are running OpenShift Service Mesh 2.6 or earlier releases, you must upgrade to OpenShift Service Mesh 3.0, 3.1, and then 3.2. We recommend migrating to OpenShift Service Mesh 3.0 promptly, because version 2.6 reaches its end of life (EOL) on June 30, 2026 (recently extended from March 12, 2026). An in-depth migration guide is provided in the OpenShift Service Mesh 3.0 documentation, including an analysis of the differences between OpenShift Service Mesh 2.6 and 3.0. This blog post describes using the Kiali console for migrating between OpenShift Service Mesh 2.6 and 3.0.

For an example of OpenShift Service Mesh 3 in action, with fully configured metrics and the Kiali console, see this solution pattern.

Sidecar-less service mesh: Istio’s ambient mode

This release brings generally available support for Istio’s ambient mode to OpenShift Service Mesh. Istio’s ambient mode is a significant new feature that enables service mesh features on workloads without the need for sidecar proxies.

With Istio’s traditional dataplane architecture, known as “sidecar mode,” each application pod requires a sidecar proxy container to enable service mesh features. While this makes for a simple architecture, it introduces additional overhead when running a service mesh as a proxy container is required for every application workload container. This also complicates service mesh adoption, because sidecar proxies must be added and updated as part of both the application and service mesh’s lifecycle. This means that applications must be restarted when the service mesh is both introduced and updated.

With Istio’s ambient mode architecture, the data plane is split up into 2 levels of proxy: ztunnels and waypoints that fulfill different roles.

Ztunnel proxy

Ztunnel is a lightweight shared node-level proxy that intercepts traffic at Layer 4 providing security (the “Z” stands for “zero trust”) in the form of mutual transport layer security (mTLS) encryption, authentication, telemetry, and simple L4 authorization policies based on application identities. It also provides basic layer 4 (e.g., TCP) level logs and metrics, which like all service mesh metrics, can be viewed using the Kiali console.

The fact that ztunnel is written in Rust for this specialized purpose allows it to achieve high performance proxying with minimal additional overhead.

Though ztunnel runs as a node level proxy, a Kubernetes DaemonSet, it implements traffic redirection within each pod’s network namespace. This means that from a network isolation perspective, traffic redirection and encryption actually occurs within the pod and thus pod-to-pod traffic isolation and encryption is maintained. This is discussed in more detail, along with how the Istio CNI agent configures this traffic redirection, in the Istio documentation on ZTunnel traffic redirection.

With Istio’s ambient mode, if you only require the features provided by ztunnel, then it is the only proxy you are required to run, resulting in a very resource-efficient service mesh.

Waypoint proxy

If users desire application-level (layer 7) service mesh features, such as HTTP or gRPC related telemetry, traffic management, and authorization policies, they may introduce additional proxies called “waypoints”. These are typically deployed per namespace, with a group of closely related application workloads.

In addition to the features already provided by ztunnel, a waypoint proxy adds features such as:

• HTTP routing and load balancing, retries, timeouts, circuit breaking, rate limiting, and fault injection
• Rich authorization policies based on L7 primitives, such as request type or HTTP header
• HTTP metrics, access logging, and tracing

Waypoint proxies are managed similarly to ingress gateways, as standalone Envoy proxies and similarly are likely to be lifecycled with your application workloads rather than with the service mesh control plane or the per-node ztunnel.

**Is Istio’s ambient mode right for you? What are the benefits and trade offs? **

Istio’s ambient mode is still evolving in the Istio community, and at this time, is ideal for new service mesh installations since there are some limitations when migrating or combining with sidecar mode (more on this topic below).

OpenShift 4.19 or later should be used for the supported Kubernetes Gateway API custom resource definitions (CRDs), which are recommended to configure ingress gateways and are required to configure ambient’s waypoint proxies. OpenShift Service Mesh 4.18 and earlier releases do not include or provide support for these CRDs.

Some of the benefits and tradeoffs of adopting ambient mode include:

Significantly reduced resource costs

With sidecars no longer necessary, Istio’s ambient mode significantly reduces the resource footprint, both in memory and CPU required to adopt service mesh features such as mTLS encryption. We have seen memory use reductions of over 90% and CPU reductions of over 50% compared to sidecar mode. An even greater reduction in resource usage is seen when only ztunnel is used.

Lightweight zero trust networking

We believe the biggest motivation for Istio’s ambient mode is lightweight pod-to-pod mTLS encryption. As zero trust networking becomes a higher priority, we are seeing more customers mandate service mesh to enforce mTLS encryption across a large number of applications. Istio’s ambient mode with ztunnel alone provides this, including identity and certificate management, while minimizing resource overhead and the impact on running workloads. As requirements expand, waypoints can be added to introduce application-level policies and telemetry, such as those based on HTTP request types (e.g., /GET) or headers.

**Improved scalability **

With fewer proxies to manage and a significantly smaller footprint, the scalability potential of Istio’s ambient mode is significantly greater than traditional sidecar mode. While we have seen customers scale meshes to support thousands of workloads using Istio’s scoping and scaling features, ambient mode’s architecture offers the potential to scale to tens or even hundreds of thousands of workloads with fewer optimizations needed.

Potential performance characteristics

Though there have been promising early performance measurements in the Istio community, we are still evaluating Istio ambient mode’s performance in an enterprise-like setup comparable to that of our customers. To date, we have seen performance comparable to sidecar mode, with potential for improvement in future releases. The performance characteristics will be different with ztunnel alone compared with ztunnel and a waypoint, with a waypoint adding greater overhead depending on the setup. We have also encountered a performance known bottleneck that limited the vertical scalability of ztunnel, which will take time to resolve. We believe that Istio’s ambient architecture shows potential for performance improvements in future releases.

Easier adoption

Istio’s ambient mode also makes service mesh easier to adopt, with workloads no longer needing to be modified to add sidecar containers. In fact, they do not even need to be restarted to be added to the mesh or when the mesh is upgraded. The 2 level architecture also enables Istio features to be adopted incrementally, without incurring the resource costs of layer 7 proxying when it is not needed.

Feature support levels

Note that the level of support for Istio features with ambient mode may differ from the traditional sidecar mode. For the list of supported features, see the Service Mesh feature support table. Advanced features such as multicluster and multimesh are very much still under development, while mixing workloads with sidecar and ambient mode has limitations, in particular, for using waypoint proxies with sidecars. For the Istio community perspective on ambient versus sidecar, see this page.

Upgrade considerations

Istio’s ambient mode offers the benefit that Istio’s data plane may be updated without restarting workload pods, which is required with sidecar proxies. The trade off is that ztunnels are shared node-level agents that are part of the datapath for multiple applications. Thus, ztunnel must be upgraded with care. We recommend upgrading during a maintenance window or a lower traffic period, which will result in long-lived TCP connections being reset on that node. Revision-based (canary) upgrades are also not yet supported as of this release. This will be an area of development in future releases.

Getting started with Istio’s ambient mode

To get started with Istio’s ambient mode, OpenShift Service Mesh provides the “Ztunnel” resource to install and manage the ztunnel as a daemonset. This is installed alongside the “Istio” and “IstioCNI” resources, which must be configured with the “ambient” profile even if some workloads have sidecars.

As with traditional sidecar mode, it is also important to configure Istio “discovery selectors” to ensure that the Istio control plane is able to monitor the namespaces that are to be part of the mesh and no more. For ambient mode, the label “istio.io/dataplane-mode=ambient” is used to indicate that a namespace or workload should be included in the mesh. For more information on adding workloads, see the Istio community documentation.

When a new workload is added to the mesh, the Istio CNI agent will work with the node-local ztunnel proxy to configure traffic redirection, so that all traffic is intercepted and upgraded to use mTLS using Istio’s HBONE tunneling protocol. Ztunnel also handles the fetching and management of certificates for all pods on the same node.

If a waypoint proxy is desired, it can be added in a similar way that an ingress or egress gateway would be added using the Kubernetes “Gateway” resource from Kubernetes Gateway API, included with OpenShift 4.19+. More information on installing waypoints can be found here, and using waypoints for L7 features here.

For a detailed procedure on getting started with Istio’s ambient mode, see the OpenShift Service Mesh documentation.

If I am already using service mesh, can I migrate to ambient mode?

While ambient mode is ideal for new service mesh users, it can also be introduced to existing service mesh deployments and combined with sidecar mode workloads with certain caveats. We also anticipate that sidecar mode will continue to be the preferred use case when the full feature set of a dedicated Envoy proxy per pod is needed.

To introduce ambient mode into an existing mesh, the mesh (Istio and Istio CNI) must be updated with the “ambient” profile and all workloads with sidecars must be restarted so that they can communicate with ztunnels using the HBONE tunnelling protocol.

A current limitation of this coexistence is that traffic between sidecar proxies and ambient workloads will usually bypass waypoint proxies, thus layer 7 policies will not be applied for the ambient workload.

Given these limitations, we recommend that namespaces, and groups of applications, use either ambient mode or sidecar mode and not mix modes within tightly coupled application workloads. It is also important to avoid mixing sidecar and ambient mode pod labels.

Kiali with Istio’s ambient

Kiali, the console for Istio included with OpenShift Service Mesh, provides many features for configuring, visualizing, and validating Istio’s ambient mode. With the potential for workloads to be in several possible states—in mesh with ztunnel, in mesh with waypoints, sidecar mode or not part of the mesh—Kiali becomes even more important for understanding the state of your mesh and troubleshooting when distributed applications are not behaving as expected.

Kiali provides clear confirmations at every level that ambient mode has been successfully configured. This starts with the Istio control plane running with the ambient profile enabled and that namespaces and workloads have been labelled, so that workload traffic will be captured by ztunnel and/or waypoint as expected. Finally, at the pod level, you can check that traffic is being secured using Istio’s HBONE protocol rather than unencrypted TCP.

Kiali also provides correlated logs between ztunnel and waypoint so that you can understand and troubleshoot how traffic moves from the workload through each proxy.

While waypoint proxies are similar to other proxies, Kiali has a specific tab to show which services and workloads have been enrolled.

Finally, the topology graphs for ambient mode look different compared to sidecar mode. As there are now 2 levels of proxy, there may be 2 independent sets of telemetry reported per workload: L4 (TCP) metrics shown with blue edges from ztunnels and L7 (HTTP) metrics shown with green edges where a waypoint has been configured. Kiali provides the ability to select the type of traffic shown.

As waypoint proxies are likely to represent groups of tightly coupled workloads (perhaps making up a common distributed application), the waypoint view will provide a higher-level overview of your mesh in what could be a very large mesh.

For more information on all of Kiali’s features for ambient mode, see the Kiali community documentation.

Istio 1.27 updates

This release includes all of the updates noted in the Istio 1.27 change notes. These are some of the highlights.

Gateway API Inference Extensions (GIE)

This release includes support for Gateway API Inference Extensions. To better support customers on Red Hat OpenShift AI 3, we have backported the generally available implementation (version 1.0) of the API into this release. Note that this feature is only supported with Red Hat OpenShift AI 3, and is considered a technology preview feature for OpenShift Service Mesh 3.2.

Multicluster with ambient mode

This release introduces initial support for Istio ambient mode in a multiprimary, multicluster topology. Because this feature is still under development upstream, we have designated it as “developer preview” for OpenShift Service Mesh 3.2.

Native nftables support in sidecar mode

In preparation for Red Hat Enterprise Linux (RHEL) 10, Red Hat has contributed support for nftables to the Istio project, with support for sidecar mode introduced in Istio 1.27. The nftable framework is the modern successor to iptables, the Linux feature that is used by Istio to configure network redirection rules. It aims to provide better performance, maintainability, and more flexible rules management for traffic redirection to and from the Envoy sidecar. As of RHEL 10, nftables will be the default tool for managing networking rules. Support for RHEL 10 will come in a future release of OpenShift.

Cert-manager Istio-CSR is generally available

The cert-manager Operator is supported for use with OpenShift Service Mesh, though the istio-csr agent is required for cert-manager to sign, deliver, and renew certificates for workloads. With the release of the cert-manager Operator version 1.18, this agent is now generally available and may be used with all supported versions of OpenShift Service Mesh. For more information on how cert-manager and OpenShift Service Mesh work together to enable zero trust, read this blog post. For the procedure that outlines how to use cert-manager with OpenShift Service Mesh, view the documentation.

Getting started with OpenShift Service Mesh

To learn more about Red Hat OpenShift Service Mesh, read this blog post as well as the follow-up on multicluster service mesh.

To get started with service mesh, you must first install the Red Hat OpenShift Service Mesh 3 Operator. If you are new to service mesh, you’ll want to consider Istio’s ambient mode. It will provide a significantly more resource-efficient service mesh architecture than the traditional side car mode. To get started with Istio’s ambient mode, read the documentation here.

For an end-to-end example of using OpenShift Service Mesh with OpenShift user-workload monitoring, distributed tracing, and Kiali, see this solution pattern.