Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 1. OpenShift Service Mesh release notes

Review new features, compatibility updates, fixed issues, and known issues for Red Hat OpenShift Service Mesh to stay informed about changes across different product versions.

This release makes Red Hat OpenShift Service Mesh 3.3 generally available, adds new features, addresses Common Vulnerabilities and Exposures (CVEs), and is supported on OpenShift Container Platform 4.18 and later.

For a list of supported component versions and support features, see "Service Mesh feature support tables".

When upgrading from OpenShift Service Mesh 2.x, first you must migrate to version 3.0. Then, you can upgrade to version 3.1 and incrementally to version 3.3. For more information see, Migrating from Service Mesh 2 to Service Mesh 3 in the OpenShift Service Mesh 3.0 documentation and Updating in the OpenShift Service Mesh 3.3 documentation.

Support for post-quantum cryptography (PQC)

With this update, Red Hat OpenShift Service Mesh adds support for post-quantum cryptography (PQC) encryption algorithm 

X25519MLKEM768
with both Istio gateways and in-mesh traffic (for both sidecar and ambient modes).

Note

The PQC 

X25519MLKEM768
algorithm is not available in FIPS-enabled clusters.

OSSM-11488

Support for FIPS 140-2 Compliance for ztunnel in ambient mode

With this release, ztunnel supports FIPS 140-2 compliant clusters in ambient mode. This release adds TLS 1.2 support for secure communications with the existing TLS 1.3 support that enables 

ztunnel
and 
Istiod
to communicate. As a result, the ambient mode functions correctly on FIPS-enabled clusters, ensuring a secure and compliant environment for end users.

OSSM-11068

Support for Gateway API 1.4.0 and Gateway API Inference Extensions 1.1

This update introduces support for Gateway API 1.4.0 and Gateway API Inference Extensions 1.1 to provide users with the latest networking standards and advanced traffic management capabilities.

OSSM-10819

Health status pre-compute and caching in Kiali

Kiali now features health status pre-compute and caching by default to optimize performance as production mesh sizes grow. This enhancement shifts health status calculations from an on-demand model to a background process that pre-calculates data by using a configurable duration (five minutes by default).

As a result, users experience significantly faster render times and increased responsiveness on the Overview and List pages, where the Duration dropdown selector is now removed. Other pages, such as the Traffic graph and Detail pages continue to calculate health status on-demand, and based on the user’s selected duration.

Kiali introduces a background health status pre-compute and caching mechanism that functions independently of user sessions. The 

Kiali
custom resource (CR) now includes the following new fields: 

  • spec.health_config.compute.duration
     
  • spec.health_config.compute.refresh_interval
     
  • spec.health_config.compute.TIMEOUT
     
  • spec.kiali_internal.health_cache.enabled
    (Keep the health cache enabled as not all the features fall back to on-demand calculation.)

OSSM-12036

Kiali traffic graph caching

Kiali now introduces traffic graph caching enabled by default to optimize the performance of the Service Mesh visualization. This enhancement allows Kiali to periodically regenerate and cache the traffic graph in the background based on the UI’s refresh interval. As a result, users experience significantly faster re-render times when navigating back to the traffic graph or during automatic refreshes, particularly within large and complex meshes.

The backend resource utilization might get affected, although it does not change significantly. The caching can be disabled in the 

Kiali
CR by setting the 
spec.kiali_internal.traffic_cache.enabled
field to 
false
.

OSSM-12035

This release includes some features that are currently in Technology Preview. These experimental features are not intended for production use.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Technology Preview for multi-cluster support in Istio ambient mode

Red Hat OpenShift Service Mesh introduces the Technology Preview (TP) of multi-cluster support for Istio’s ambient mode. The multi-cluster support provides the capability to manage and deploy applications across multiple clusters, focusing on multi-primary topologies. It is designed for testing and feedback to help identify potential limitations in experimental settings. Use the feature only in non-production environments. This feature is only available as a Technology Preview.

OSSM-11236

This release addresses the following fixed issues:

Halting unnecessary OpenShift Service Mesh Console pod redeployments

Before this update, Kiali Operator provided by Red Hat was incorrectly reconciling OpenShift Service Mesh Console every ten hours due to a misconfigured watches setup. As a consequence, Kiali operator triggered unnecessary pod redeployment for OpenShift Service Mesh Console, affecting application stability in production. With this release, the Kiali Operator reconciliation period is changed to zero, halting periodic console pod redeployment. As a result, the Kiali Operator no longer triggers console pod redeployment every 10 hours, improving production environment stability.

OSSM-12420

Removed false warnings for unmanaged namespaces in Kiali logs

Before this update, Kiali logged warnings for namespaces without the required sidecar label. As a consequence, users experienced excessive warnings in Kiali logs for namespaces not managed by the Istio control plane due to incorrect 

GetRootNamespace
determination. With this release, the false warnings in Kiali logs for namespaces not managed by the Istio control plane are removed. As a result, user experience is improved by reducing unnecessary log messages.

OSSM-12581

This release has the following known issues:

Performance issues when applying configuration changes in large FIPS clusters

There is currently a known issue where applying configuration changes takes longer than expected in environments with a large number of services and pods when FIPS mode is enabled. This delay occurs because Envoy performs additional certificate checks to maintain FIPS compliance.

There is currently no workaround for this issue. Wait for the configuration changes to complete; the process eventually succeeds.

OSSM-12930

Increased Envoy validation time impacts OSSM proxy readiness

In the Red Hat OpenShift Service Mesh 3.3 FIPS release, a known issue arises due to extended validation time for 

ISTIO_MUTUAL
TLS keys within Envoy, leading to a delay. The issue particularly affects the readiness time of Envoy proxies in Red Hat OpenShift Service Mesh 3.3 FIPS clusters, potentially increasing performance impact on the affected cluster.

There is currently no workaround for this issue.

OSSM-12929

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top