Introducing OpenShift Service Mesh 3.1

Red Hat OpenShift Service Mesh 3.1 has been released and is included with the Red Hat OpenShift Container Platform and Red Hat OpenShift Platform Plus. Based on the Istio, Envoy, and Kiali projects, this release updates the version of Istio to 1.26 and Kiali to 2.11, and is supported on OpenShift Container Platform 4.16 and above.

This is the first minor release following Red Hat OpenShift Service Mesh 3.0, a major update to converge OpenShift Service Mesh with the community Istio project, with installation and management using the Sail operator. This change helps ensure that OpenShift Service Mesh can offer the latest stable Istio features with Red Hat support.

Upgrading to OpenShift Service Mesh 3.1

If you are running OpenShift Service Mesh 2.6 or earlier releases, you must upgrade to OpenShift Service Mesh 3.0 before upgrading to 3.1. We recommend migrating to OpenShift Service Mesh 3.0 promptly, because version 2.6 reaches its end of life on 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.  

We've also recently published an article that describes how to use the Kiali console for migrating between OpenShift Service Mesh 2.6 and 3.0.

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

Kubernetes Gateway API support in OCP 4.19+

Kubernetes Gateway API is the next generation of Kubernetes Ingress, load balancer, and service mesh APIs. Istio plans to make it the default set of APIs for creating and managing traffic using a service mesh, and it is required for using Istio's ambient mode. Note that there are no plans to remove the stable Istio APIs, such as VirtualService, DestinationRule, and others. It may at times be necessary to use those APIs to take advantage of features that have not yet been added to Kubernetes Gateway API.

While OpenShift Service Mesh 3.0 included support for Kubernetes Gateway API, it required users to install unsupported custom resource definitions (CRD) to take advantage of the feature. This has changed as of OpenShift Container Platform 4.19 and beyond, with the required CRDs now available by default in OpenShift. You no longer need to install these CRDs separately. The Gateway API CRDs included with OpenShift are fully supported by Red Hat.

As we look to provide optimized support for generative AI workloads and traffic patterns, we have included Technology Preview support for the Gateway API Inference Extension by backporting this feature to OpenShift Service Mesh 3.1.

Generally available dual-stack support for x86 clusters

This release makes support for dual-stack IPv4 and IPv6 workloads with OpenShift Service Mesh generally available for OpenShift clusters running x86 hardware. To enable dual-stack support in OpenShift Service Mesh, you need to set the ISTIO_DUAL_STACK flag to true in your Istio customer resource. This is demonstrated in the upstream sail-operator documentation for dual-stack, as well as the community Istio dual-stack documentation, with OpenShift Service Mesh product documentation to follow.

Moving to UBI Micro containers

This release moves most of the containers, including the key istiod and proxy (Enovy) containers to use UBI Micro base images. UBI Micro is the smallest possible Universal Base Image (UBI) image of Red Hat Enterprise Linux, obtained by excluding a package manager and all of its dependencies, which are normally included in a container image. Adopting UBI Micro helps minimize the attack surface of container images that are delivered as part of OpenShift Service Mesh.

Toward a sidecar-less service mesh: Istio's ambient mode

OpenShift Service Mesh 3.1 is based on Istio 1.26 and includes mostly incremental updates compared to OpenShift Service Mesh 3.0, which was based on Istio 1.24. This is because the Istio community and Red Hat are very focused on the next generation of service mesh data plane: Istio's ambient mode.

We've seen steady growth in service mesh usage over the past few years, but the need for sidecar proxies is often an impediment to adoption due to the extra resources (memory and CPU, primarily) required to run sidecar containers beside each application container. This complicates service mesh adoption, because sidecar proxies must be added and updated as part of the pod's lifecycle. This means that applications must be restarted to introduce an update of the service mesh.

Istio's ambient mode aims to address these concerns by removing the need for sidecar proxies and splitting the Istio dataplane into two separate layers. This allows for incremental adoption of service mesh features with less complexity for application owners.

This split architecture results in significantly fewer proxies deployed to enable service mesh, significantly reducing the resources required to run a service mesh. Because Istio's ambient mode does not require side car proxies, applications can be added and removed from the mesh without the need to modify or restart application pods.

The two separate layers of Istio's ambient mode are:

• Ztunnel: A lightweight, layer 4 node-level proxy (run as a Daemonset in Kubernetes) that creates a listening socket inside the application pod's network namespace to transparently upgrade pod-level traffic with mTLS encryption. Ztunnel also takes care of certificate and identity management for pods on the node (and only the pods on the node). With Ztunnel alone, you can achieve automatic mTLS encryption, layer 4 telemetry and policy management.
• Waypoint: An optional Envoy proxy, similar to a gateway, deployed for a set of applications (namespace-scoped by default) to provide layer 7 mesh features, such as application level security and traffic policies, application-level telemetry, and mesh resiliency features. Unlike sidecars, waypoint proxies can be added as needed and scaled independently of application containers.

For more details on the Istio ambient mode architecture and trade offs, read Try Istio ambient mode on Red Hat OpenShift.

OpenShift Service Mesh 3.1 updates the status of Istio's ambient mode to Technology Preview, with a Ztunnel proxy, fully supported by Red Hat, that uses OpenSSL for encryption to ensure it's designed for FIPS. OpenShift Service Mesh 3.1 includes documentation for getting started with Istio's ambient mode on OpenShift as part of the installation guide. This will be built up in the coming months as we move toward general availability.

Note that Istio's ambient mode requires Kubernetes Gateway API, so use it on OpenShift Container Platform 4.19 or later, which includes supported Gateway API CRDs, installed by default. If you wish to experiment with Istio's ambient mode on earlier releases of OpenShift, you must install unsupported Kubernetes Gateway API CRDs, as described in the community Istio documentation. Note that upgrading to the supported Kubernetes Gateway API CRDs in OCP 4.19 may incur downtime.

We also recommend experimenting with Istio ambient mode on clusters that don't already have OpenShift Service Mesh installed to reduce the probability of interfering with existing service mesh deployments. In the future, we'll provide documentation on running an ambient mode data plane alongside a sidecar mode dataplane, as well as guidance on migrating applications from sidecar mode to ambient mode.

Note that as of Istio 1.26, not all sidecar mode features are supported in ambient mode, and some features remain "Alpha" in upstream Istio . Ambient mode may not be appropriate for all service mesh use cases. The most notable gaps are multiple network multiple cluster setups and interoperability between ambient and sidecar mode data planes. These features and more are under development in the Istio community.

Kiali updates

Kiali is the console for Istio service mesh included with OpenShift Service Mesh. This release updates it to 2.11, which includes many updates and enhancements (such as Istio's ambient mode).

Mesh Page Updates

The mesh page continues to receive enhancements as the primary dashboard for monitoring the status of Istio's infrastructure, covering the Istio control plane itself, data plane components, and observability addons such as Prometheus and Tempo. This release includes several updates including Istio gateways and the ambient mode data plane components: Ztunnel and Waypoint. From the mesh page, you can examine components to reveal key status information, including metrics and configuration dumps relevant to each component.

Performance and scalability with large meshes

A common concern with Kiali is performance as the number of workloads in the service mesh grows. In the past, Kiali would have struggled to remain responsive with very large service meshes. The Kiali project FAQ now includes a new section on performance that provides guidance for using Kiali with large mesh deployments. This release includes updates to improve performance, including updates to better manage large meshes.

For example, by default Kiali immediately attempts to render a page and automatically updates most pages based on the setting in the Refresh Interval drop-down. For very large meshes, even initial rendering can be slow, delaying your ability to use the console. Kiali now offers a Manual refresh setting, which only updates a page when the Refresh button is manually clicked. This can be set with the spec.kiali_feature_flags.ui_defaults.refresh_interval: manual in the Kiali custom resource definition (CRD). 

You can also now disable validations to improve performance and responsiveness with large meshes. You can do this by setting the Kiali operator configuration spec.external_services.istio.validation_reconcile_interval to 0.

Get started with OpenShift Service Mesh

If you're new to OpenShift Service Mesh, start with our introduction to OpenShift Service Mesh and our day 1 installation instructions. For a complete working example, check out the Optimizing Traffic and Observability with OpenShift Service Mesh 3 solution pattern.

If you're coming from OpenShift Service Mesh 3.0, review the upgrade documentation for different approaches to updating the OpenShift Service Mesh 3 operator, Istio control planes, Istio CNI resource, and the proxies that make up the data plane.

If you're coming from OpenShift Service Mesh 2.6 or earlier, review the differences between OpenShift Service Mesh 2 and 3, and our extensive migration documentation. There is also a blog post that describes the procedure using Kiali.