Introducing Red Hat OpenShift Service Mesh 3.0

We are thrilled to announce the general availability of Red Hat OpenShift Service Mesh 3.0. OpenShift Service Mesh is based on the Istio, Envoy and Kiali projects, and is included with the Red Hat OpenShift Container Platform and Red Hat OpenShift Platform Plus. 

This article provides an overview of Red Hat OpenShift Service Mesh 3.0, including information for existing OpenShift Service Mesh users on how to migrate.

OpenShift Service Mesh 3.0 is based on Istio 1.24 and Kiali 2.4. This release is a major update, using a new operator based on the community sail-operator for managing Istio and deploying a Red Hat-maintained distribution of the Istio.io project rather than Maistra.io. This will help ensure that OpenShift Service Mesh is able to offer the latest stable Istio features with Red Hat support.

The road to OpenShift Service Mesh 3

This is the third major release of Red Hat OpenShift Service Mesh since it was first made generally available in 2019. This update kicked off in 2023 with the release of a new operator for Istio, followed by a project update and a technology preview release in the Fall of 2024. It incorporates many of the lessons learned in versions 1 and 2, simplifying how we deliver Istio on OpenShift while improving support for Istio’s stable features. After multiple customer trials with a lot of helpful feedback, Red Hat OpenShift Service Mesh 3.0 is now generally available. 

A major update to OpenShift Service Mesh

Major releases require a significant effort to deliver and often require more time and effort for customers to upgrade than minor releases. For these reasons, we avoid major releases whenever possible. That said, there are times when a large change is necessary to provide a significantly improved offering—not just for the next release, but for many years to come. OpenShift Service Mesh 3 represents such a change.

OpenShift Service Mesh was first released when Istio was a relatively new project. At the time, it wasn't yet part of the Cloud Native Computing Foundation (CNCF). To serve our customers, we needed a version of Istio customized for enterprise use cases and concerns of Red Hat customers, which was not a priority for the fast-moving Istio project during that period. This became the Maistra.io project, the basis for OpenShift Service Mesh 1 and 2.

Istio has since become a graduated CNCF project and has obtained broad industry adoption with a diverse community made up of multiple large vendors. Recent features such as IPv4/IPv6 Dual Stack mode, multiple control planes and multicluster help address enterprise use cases. Exciting new features, like Istio’s “sidecar-less” ambient mode and support for Kubernetes Gateway API, are building a promising future for the project as the backbone for security-oriented application networking. 

Meanwhile, the cost to maintain Maistra.io as an independent project based on Istio is significant and meant the OpenShift Service Mesh offering was often several releases behind the Istio project.

To ensure Red Hat OpenShift has the best possible service mesh going forward, the time to migrate is now. OpenShift Service Mesh 3.0 is based on a Red Hat distribution of community Istio, rather than the Maistra.io project. This change benefits not only our customers, but also Istio, Envoy and Kiali communities, as innovation and code changes introduced by Red Hat are now directly contributed to the Istio and Envoy communities.

A new operator for Istio 

OpenShift Service Mesh 3 is built on a new operator for Istio that is maintained as part of the istio ecosystem organization as the sail operator project. This operator differs significantly from the OpenShift Service Mesh 2.6 operator and is not based on the deprecated and now removed Istio in-cluster operator. Instead, the sail operator is based on Istio’s Helm chart APIs, which are the source of truth for community-maintained Istio configuration. 

The operator includes the following custom resource definitions (CRDs) to manage service mesh components: 

• Istio - manages the Istio control plane, which manages the Istio data plane. The majority of Istio’s configuration can be specified here using the “values” field.
• IstioCNI - manages the Istio CNI daemonset, which is responsible for configuring traffic redirection for pods in the mesh.
• ZTunnel - manages the ambient mode Ztunnel daemonset. 

Note: Istio’s ambient mode is a Developer Preview feature in OpenShift Service Mesh 3.0.

The operator manages the lifecycle of the Istio control plane through either InPlace or RevisionBased upgrades. 

• With InPlace upgrades, the existing Istio control plane is replaced and workload sidecar proxies immediately connect to the new control plane. The proxies must then be restarted to complete the upgrade. InPlace was the only supported upgrade mechanism in OpenShift Service Mesh 2.6 and earlier releases.
• With RevisionBased upgrades, a new Istio control plane is created alongside the existing one. Workloads are then migrated to the new Istio control plane using “revision” labels or tags. The operator includes the IstioRevision and IstioRevisionTag CRDs which help to manage upgrades.

Scoping a service mesh

To align with the community Istio project, all instances of OpenShift Service Mesh 3.0 are cluster-scoped. This means that each instance of the Istio resource must have a unique name within the same cluster. It also means that appropriately scoping the service mesh becomes critical on clusters that are shared with other workloads or that may contain multiple service meshes. Appropriate scoping ensures that multiple meshes, if present, do not conflict, while also reducing the resources used by both the Istio control plane and proxies.

The top-level mechanism for scoping an Istio control plane is the Istio DiscoverySelector feature, which determines that namespaces of the cluster will be monitored by the Istio control plane, while other namespaces will be ignored. 

We recommend that all service meshes configure Istio DiscoverySelectors to ensure that the Istio control plane only watches the namespaces that will make up the service mesh. 

Scaling a service mesh

In addition to discovery selectors, scoping features, such as the Sidecar resource and exportTo, are important for larger service meshes to ensure the mesh is able to scale without excessive resource consumption. These features can also be used to implement lightweight multitenancy within a mesh and can be combined with Istio’s AuthorizationPolicies to create zones of isolation. This approach will often be preferable to multiple control planes for a scaled, “soft,” multitenant deployment, where there is a single administrator.

Multicluster service mesh

OpenShift Service Mesh 3.0 includes support for Istio’s multicluster topologies, specifically, multiprimary, primary-remote and external control planes. These topologies enable a single service mesh to be deployed across multiple OpenShift clusters. While there may be multiple Istio control planes (in the case of “multiprimary”), they support high-availability and have a shared view of the world. These topologies are ideal for implementing high-availability for services located on different clusters, different availability zones or even different regions where all clusters share the same zone of trust and are managed by the same administrator. In this model, all services are shared by default, according to the concept of namespace sameness, and traffic management rules can be added for fine-grained control.

Federation is another model for multicluster service mesh, where stronger boundaries are maintained between the clusters that make up the mesh. With federation, each cluster maintains its own independent Istio control plane with services only shared between clusters as needed. This topology is most appropriate when there is a desire to selectively share services across clusters  and manage those services with Istio policies, without the need to expose them externally. OpenShift Service Mesh 2.6 provided support for service mesh federation, but since the feature was not part of the core Istio project, it needed to be reimplemented for OpenShift Service Mesh 3.0 and beyond. 

The new service mesh federation implementation, which treats federation as an extension to community Istio, is currently available for developer preview, with the goal of re-introducing it as a supported feature in a later release of OpenShift Service Mesh 3. We are looking for feedback from both customers and the community while this feature is under active development. 

Istioctl - Istio’s command-line utility

While the installation and lifecycle management of Istio on OpenShift is performed by the OpenShift Service Mesh 3 operator, based on the upstream Sail operator for Istio, the istioctl command-line utility is an invaluable tool for diagnostics and debugging of the Istio control plane and data plane along with the Kiali and OpenShift Service Mesh Console dashboards. 

OpenShift Service Mesh 3.0 includes support for Istioctl, with a downloadable command-line utility tailored for OpenShift Service Mesh. The istioctl command-line utility can be downloaded from the OpenShift Console’s CLI tools menu once the OpenShift Service Mesh 3.0 operator has been installed. 

Introducing Kiali version 2

The Kiali console for Istio service mesh provides an invaluable console for visualizing, validating and troubleshooting a service mesh. It is deployed alongside Istio using the Kiali operator provided by Red Hat, integrating with your service mesh as well as metrics, traces and logs to provide a comprehensive user interface for observing and managing both the Istio control plane and data plane. 

OpenShift Service Mesh 3.0 includes support for Kiali 2.4, which is a significant version upgrade from OpenShift Service Mesh 2.6, which included Kiali 1.73. Kiali version 2 includes some important changes.

First, Kiali now also uses discovery selectors for scoping namespaces access. Like Istio, by default, Kiali will watch all namespaces available in the cluster. Kiali allows discovery selectors to be configured (which are independent from Istio’s discovery selectors) to restrict Kiali so that it can only access a specific set of namespaces.

Second, the traffic graph has gotten a major update with Patternfly Topology graph, which provides a more modern appearance, dark theme support and converges with other Red Hat topologies both in and outside of the OpenShift console. 

Third, Kiali 2.4 introduces the new mesh page. While the traffic graph visualizes requests flowing through the mesh, the mesh page visualizes mesh infrastructure. It gives users quick access to configuration, version and health information for control planes, data planes and add-on components, such as metrics and tracing. 

Finally, Kiali 2.4 also includes several updates to better support multicluster deployments and Istio’s ambient mode.

OpenShift Service Mesh Console Plug-in

The OpenShift Service Mesh Console Plug-in incorporates service mesh telemetry into the OpenShift Console, adding a Service Mesh menu to the OpenShift console that provides quick access to the Kiali topology graph along with additional Istio diagnostics. The plug-in also incorporates service mesh telemetry into other pages, such as the workload and networking pages.

OpenShift Service Mesh Console is installed with the OSSMConsole CRD, which is included with the Kiali operator provided by Red Hat. Once Kiali has been installed and configured, the OSSMConsole CRD can be created to add the OpenShift Service Mesh Console to the OpenShift console.

Service mesh integrations

A service mesh does not live on its own, which is why OpenShift Service Mesh is part of the comprehensive Red Hat OpenShift Container Platform. This includes the following supported integrations:

• Red Hat OpenShift observability for logs, metrics, traces, visualization and analysis.
• The cert-manager operator for Red Hat OpenShift, including the istio-csr component (technology preview) for use with OpenShift Service Mesh.
• Red Hat OpenShift GitOps, with Argo Rollouts to automate progressive delivery.
• Red Hat OpenShift Serverless operator.

The supported integrations are always growing as new combinations and use cases are uncovered. It is important to note that customers are not locked into these integrations - Red Hat OpenShift is “batteries included, but swappable”. OpenShift Service Mesh 3 provides improved flexibility and can be integrated with a wide range of partner and community solutions.

IPv4/IPv6 Dual Stack with service mesh

This release includes IPv4/IPv6 Dual Stack support as a technology preview feature, which has reached an “Alpha” level of maturity in the upstream Istio project and is complete for Istio with sidecars. As of OpenShift Service Mesh 3.0, dual-stack is disabled by default and must be enabled with the “ISTIO_DUAL_STACK” flag. As this is a maturing feature, we are actively seeking feedback from users and we aim to make this feature generally available later this year.

Istio’s “sidecar-less” ambient mode: now available for developer preview

The update of OpenShift Service Mesh 3.0 is not about a single release, but about enabling the future of service mesh on OpenShift. For Istio, that is a future where sidecars are optional.

While a traditional sidecar-based service mesh enables a wide range of features for securing, managing and observing application networks, those features come with the added overhead of sidecar proxies. For some applications, this additional overhead is too much, particularly when only a single feature, often pod-to-pod mTLS encryption, is desired. Istio’s ambient mode targets these use cases.

Istio’s ambient mode uses a different data plane architecture that splits traffic processing between a per-node layer 4 (L4) proxy and an optional layer 7 (L7) proxy, removing the need for sidecar proxies. The lightweight L4 Ztunnel(“Zero-Trust” Tunnel) proxy manages pod-to-pod mTLS encryption with cryptographic identities, simple L4 authorization policies and telemetry. The L7 proxies, called Waypoints, implement the remaining L7 functions, such as traffic routing, rich authorization policies and L7 telemetry. Waypoints run outside of application deployments and can be scaled horizontally to handle traffic demands. Read more about Istio ambient mode’s architecture in the Istio community documentation.

This split topology enables users who only want mTLS encryption and simple authorization policies to start with lightweight Rust-based Ztunnel node proxies. Because these do not require sidecar proxies, mTLS encryption can be introduced without restarting application workloads, adding minimal overhead.

If additional service mesh features are required later, such as application-level traffic management and telemetry, Waypoint proxies, implemented using Envoy proxies similar to Istio Gateways, can be introduced and scaled independently as your application's needs evolve.

OpenShift Service Mesh 3.0 includes Istio’s ambient mode as a developer preview feature for experimentation purposes only. Kiali 2.4 includes features for visualizing components and traffic with Istio’s ambient mode.

Developer preview features, Istio’s Ambient mode and the ZTunnel custom resource definitions, should not be used on clusters containing production workloads and should not be used with an existing sidecar-based service mesh installation. 

Getting started with OpenShift Service Mesh 3.0

For those getting started with OpenShift Service Mesh, we recommend starting with our documentation about OpenShift Service Mesh and Understanding Service Mesh before proceeding to Install OpenShift Service Mesh and sidecar injection. 

While more advanced deployments of OpenShift Service Mesh may involve multiple service meshes or multicluster topologies, we recommend starting with a single mesh deployment for simplicity. A single service mesh can scale to include thousands of pods using the Istio scoping features.

While the OpenShift Service Mesh 3 operator manages the installation and upgrades of Istio, the broad set of features included with Istio, such as security, traffic management and observability are covered thoroughly in the community Istio documentation. For very specific use cases, the Istio tasks documentation provides even deeper level resources.

Migrating from OpenShift Service Mesh 2.6

OpenShift Service Mesh 3.0 is a major update with significant changes compared to earlier releases. We strongly recommend that current users of OpenShift Service Mesh carefully review the list of differences between the two releases before migrating to OpenShift Service Mesh 3.0. 

Migrating to OpenShift Service Mesh 3.0 is only supported from OpenShift Service Mesh 2.6. Users should ensure that they are on the latest version of OpenShift Service Mesh 2.6 before beginning the migration procedure. It is possible that fixes relating to the 3.0 migration procedure have been incorporated into a recent patch release of OpenShift Service Mesh 2.6. 

A pre-migration checklist has been provided that includes steps for OpenShift Service Mesh 2.6 users to take before beginning the migration procedure. Some features and settings in OpenShift Service Mesh 2.6 are no longer supported, or supported in a different manner in OpenShift Service Mesh 3.0. These must be reconfigured prior to the migration to avoid disruptions.

OpenShift Service 3.0 is deployed with a new operator called Red Hat OpenShift Service Mesh 3 that can be deployed alongside the existing Red Hat OpenShift Service Mesh operator. Migrating to Red Hat OpenShift 3.0 follows a similar procedure to the RevisionBased upgrade procedure(which uses Istio’s canary upgrades feature). The migration involves using the new operator to create a Service Mesh 3.0 Istio control plane in parallel with the existing Service Mesh 2.6 control plane, and then moving existing workloads to the 3.0 control plane while maintaining application service traffic. Once all workloads have been moved to the 3.0 control plane, the 2.6 control plane and operator must be removed.

While OpenShift Service 2.6 service mesh(es) may live alongside OpenShift Service 3.0 service mesh(es), this side-by-side setup should be maintained during the migration period only. Upgrading the OpenShift Service 2.6 once the migration procedure has commenced may introduce conflicts, thus we recommend minimizing this migration period as much as possible.

Once the pre-migration checklist has been completed, there are separate migration paths depending on the OpenShift Service Mesh 2.6 deployment model (mode) used. In multitenant mode (default), a service mesh is isolated to a defined set of namespaces and there may be multiple service meshes within a cluster. In cluster-wide mode, there is only a single service mesh per cluster that by default is cluster-wide. 

In OpenShift Service Mesh 3.0, all meshes are considered “cluster-wide,” even where there are multiple service meshes deployed within the same cluster. The Istio DiscoverySelector feature must be used to scope each Istio control plane to the required set of namespaces. This is strongly recommended when there is a single service mesh per cluster and is required when there will be multiple service meshes per cluster to avoid conflicts.

As with all Istio upgrades, workloads will need to be restarted for their sidecar proxies to be updated, and in this case, to be moved to the updated Istio control plane managed by the Service Mesh 3.0 operator. 

Before beginning the migration process, we strongly recommend reading the migration documentation from end to end to ensure that the process is fully understood. While the migration procedure aims to maintain service traffic, there may be other workload specific or environmental factors to consider. Therefore, we recommend performing the upgrade during lower traffic periods or maintenance windows, particularly when the upgrade involves critical production workloads. 

Finally, we understand that this migration will take time and planning. While we encourage users to start the migration to take full advantage of the new features in OpenShift Service Mesh 3.0 and subsequent 3.x releases, OpenShift Service Mesh 2.6 will continue to be supported for a full year (until March 2026) to ensure that users have enough time to plan for and implement the migration. For full lifecycle details including specific dates, see the OpenShift Operator Lifecycle page.

Learn more about OpenShift Service Mesh.