Red Hat OpenShift Service Mesh 3: Frequently asked questions

As recently announced, Red Hat OpenShift Service Mesh 3 is available for technology preview. To best prepare new and existing users for this change, this post aims to answer the most frequently asked questions we have received regarding OpenShift Service Mesh 3.

Why an OpenShift Service Mesh 3?

There are times when a large change is necessary to provide customers with significantly more value – not just for the next release, but for many years to come. OpenShift Service Mesh 3 represents such a change.

OpenShift Service Mesh was developed when Istio was a relatively new project. At the time, it wasn't yet part of the Cloud Native Computing Foundation. To best serve our customers, we needed a version of Istio that could be specialized 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 and enterprise users. Features under development, such as IPv4/IPv6 Dual Stack mode and multiple control planes, help address common use cases. Exciting new features, like Istio’s ambient mode and support for Kubernetes Gateway API, are building a promising future for the project as the backbone for security-oriented application networking.

To better serve our customers with support for the latest service mesh features, it's time to pivot. Red Hat OpenShift Service Mesh is becoming a Red Hat distribution of community Istio, and the Maistra.io project is no longer required. This benefits our customers as well as the whole Istio community, because innovation and code changes introduced by Red Hat are directly incorporated into upstream Istio.

For more details on the motivation for OpenShift Service Mesh 3, see the developer preview announcement.

When is OpenShift Service Mesh 3 generally available?

The general availability of OpenShift Service Mesh 3 is targeted for the end of year 2024 or early (Q1) of 2025. As always, forecasted dates are subject to change. Customers interested in participating in a high touch early access program prior to general availability should reach out to their account team.

How will users migrate from OpenShift Service Mesh 2?

The most common question we receive from our current users is how to upgrade from OpenShift Service Mesh 2.

The first step is to prepare your existing installation of OpenShift Service Mesh 2 for migration. To start, you will need to be on the latest and final version of OpenShift Service Mesh 2, version 2.6. Some features present in OpenShift Service Mesh 2 are not present in version 3. We've summarized these changes in a previous article, Preparing for OpenShift Service Mesh 3. Performing migrations in advance of the major upgrade makes for a smoother migration process with fewer components changing.

For observability, you must migrate to OpenShift’s user-workload monitoring for metrics, Tempo and OTEL for tracing and an explicitly created Kiali custom resource definition.

For ingress traffic, if automatic routes (also known as Istio OpenShift Routing or IOR) is enabled, the feature must be disabled in favor of explicit route management. If ingress and egress gateways are still managed by the ServiceMeshControlPlane, they must be disabled in favor of Gateway Injection or Kubernetes Gateway API.

With canary control plane upgrades natively supported by the OpenShift Service Mesh 3, this is the basis for upgrading to OpenShift Service Mesh 3. Both version 2 and 3 of the Service Mesh operators are usable in the same cluster in parallel, allowing corresponding Istio control planes to run in parallel such that workloads can be migrated between version 2 and version 3 control planes while maintaining application availability. This procedure allows you to move to OpenShift Service Mesh 3 incrementally, with confidence that the new control plane is operating as expected.

While OpenShift Service Mesh 3 is in technology preview, it's still not intended for production use and we don't recommend that you attempt to upgrade production workloads at this time. We will provide detailed migration instructions as we approach general availability of OpenShift Service Mesh 3.

How long will OpenShift Service Mesh 2.6 be supported? How long do I have to upgrade to Service Mesh 3 once it's available?

We aim to provide a minimum of 1 year of overlapping support between OpenShift Service Mesh 2.6 and 3.0 to ensure that you have ample time to plan and manage a migration in 2025.

In preparation for this migration, even before OpenShift Service Mesh 3 is generally available, read Preparing for OpenShift Service Mesh 3. 

What's the support lifecycle of OpenShift Service Mesh 3?

The lifecycle of OpenShift Service Mesh is dependent on the timing of future releases. For example, OpenShift Service Mesh 2.4 reaches its end of life when OpenShift Service Mesh 3.0 is released.

With OpenShift Service Mesh 3, we're aiming to increase our release cadence to three times a year. This aligns with OpenShift Container Platform releases. As this cadence increases, we will adjust the Service Mesh lifecycle to ensure that each release of OpenShift Service Mesh is supported for approximately 18 months.

Our long term goal is to continue extending the service mesh support cycle to align it with OpenShift Container Platform’s lifecycle, including Extended Update Support. 

In a nutshell, how does OpenShift Service Mesh 3 compare to Service Mesh 2?

While OpenShift Service Mesh 1 and 2 were based on the Maistra.io midstream project (which is based on Istio.io), OpenShift Service Mesh 3 is directly based on the Istio.io project. Installation and upgrades are managed by the sail-operator, which uses standard Istio community Helm chart values for configuration.

• Operator: The OpenShift Service Mesh 3 operator only manages Istio. Unlike the OpenShift Service Mesh 2 operator, it does not attempt to manage observability components such as metrics, distributed tracing, and Kiali
• Kiali: The OpenShift Service Mesh Console plugin, metrics, distributed tracing and additional observability capabilities are supported through the Kiali and OpenShift Observability operators
• Automatic routes: As detailed in Preparing for OpenShift Service Mesh 3, automatic routes (Istio OpenShift Routes) will no longer be available. Explicitly configuring OpenShift route resources is in line with the declarative configuration principles of Kubernetes and GitOps practices
• Multi-tenancy: OpenShift Service Mesh 3.0 defaults to a cluster-wide topology (the same as community Istio). Istio’s multiple control plane feature will be available as an optional configuration. Additional multi-tenant and scalability features are under development
• Federation: The Maistra.io federation feature is not present in OpenShift Service Mesh 3.0.  A new implementation is under development, which will be introduced in a later release to provide a migration path for existing federation users
• Notable Istio.io features that were not previously supported, will be supported in OpenShift Service Mesh 3.0:
  • To enable multi-cluster use cases: multi-primary, primary-remote and external control plane topologies will be supported
  • The istioctl command-line utility for select commands
  • Many configuration settings that were previously only accessible through the techPreview setting in ServiceMeshControlPlane is supported.

Does OpenShift Service Mesh 3 support Istio’s ambient mode?

We're excited about the advancements that Istio’s ambient mode is bringing to service mesh, and look forward to supporting our customers with it! While the OpenShift Service Mesh team is still actively monitoring and contributing to Istio’s ambient mode's development in the community, we arenot be ready to support Istio’s ambient mode as a generally available feature in time for OpenShift Service Mesh 3.0. We will look to provide it as a developer preview feature, and aim to provide it as a generally available feature as the feature matures.

Will OpenShift Service Mesh continue to use OpenSSL for encryption? What about FIPS compliance?

To enable FIPS readiness and compliance on OpenShift across the widest range of hardware platforms, OpenShift Service Mesh will continue to ship with a distribution of Envoy that uses OpenSSL for encryption rather than BoringSSL as used in community Envoy. OpenSSL is a RHEL core cryptographic library that Red Hat submits for FIPS validation by NIST’s Cryptographic Module Validation Program, it allows us to have full control of the validation process and provide transparent information on our FIPS compliance status for each release, which is valued by our public sector customers.

We have, however, created an OpenSSL/BoringSSL compatibility library to substantially reduce the effort of maintaining Envoy with OpenSSL. This was used for the first time in the recent release of OpenShift Service Mesh 2.6, and we plan to further incorporate this work into upstream Envoy.

Likewise, for ambient mode support, we will work to ensure that encryption is performed using OpenSSL.

How will OpenShift Service Mesh 3 compare to community Istio?

A service mesh does not live in isolation, and OpenShift Service Mesh is an integral part of Red Hat OpenShift - the leading hybrid cloud application platform. This provides OpenShift customers with support for a comprehensive set of tools and services that are used in combination with a service mesh, including: virtualization, networking, security, observability, CI/CD and much more. Each release of OpenShift Service Mesh is supported for approximately 18 months with Critical and Important Security Advisors (RSHAs) - a time frame that we plan to continue extending. In comparison, community Istio releases only receive security updates for 6-8 months.

At a nuts and bolts level, the primary difference between community Istio and OpenShift Service Mesh 3 is that OpenShift Service Mesh 3 is installed and managed by an operator that supports and automates the upgrade of a service mesh at scale. In the future, the operator may be used to provide enhanced support for multi-tenancy and other scalability features, multi-cluster topologies and other enhancements that complement the core Istio project.

While our goal with OpenShift Service Mesh 3 will be to provide complete support for Istio’s stable feature set, there are some features - such as experimental features or non-upgradable features (such as the use of Istio’s EnvoyFilter API) for which we will not be able to provide support guarantees. For general availability, OpenShift Service Mesh 3 will include a feature support matrix to indicate our support position across Istio’s feature set.

I am starting a new project, should I start with OpenShift Service Mesh 2 or 3?

As both OpenShift Service Mesh 2 and 3 are based on the Istio project, there will be little difference seen from an end user perspective. They both use the same APIs, such as VirtualServices, DestinationRules and AuthorizationPolicies for managing traffic. The primary differences between version 2 and 3 relate to the installation and administration of Istio - with version 3 using a completely different operator and administrative configuration.

As adopting a service mesh involves a significant learning curve, we encourage users to not wait for OpenShift Service Mesh 3 to start this journey. We have large customers using service mesh for thousands of critical workloads and will make every effort to provide a smooth migration path from OpenShift Service Mesh 2 to 3.

That said, if your timeline to production is no earlier than Q2 of 2025, we recommend starting with the technology preview edition of OpenShift Service Mesh 3. While the standard caveats of a technology preview feature apply, we are highly interested in feedback and will aim to ensure the product is ready for general availability.

Try the technology preview edition of OpenShift Service Mesh 3 today!