Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
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.
1.1. Red Hat OpenShift Service Mesh version 3.3.1 Link kopierenLink in die Zwischenablage kopiert!
This release of Red Hat OpenShift Service Mesh is included with the Red Hat OpenShift Service Mesh Operator 3.3.1 and is supported on OpenShift Container Platform 4.18-4.21. This release addresses enhancements, fixed issues, and Common Vulnerabilities and Exposures (CVEs).
For supported component versions for 3.3.1, see "Service Mesh version support tables".
1.1.1. Fixed issues Link kopierenLink in die Zwischenablage kopiert!
- Smart load balancing issue in OpenShift AI and llm-d resolved
Before this update, a bug in Istio caused a smart load balancing issue in OpenShift AI and llm-d on OpenShift Container Platform 4.20 and possibly 4.21. As a consequence, improper load distribution affected user experience. With this release, the update fixes the smart load balancing issue. As a result, sharing a Gateway now provides greater stability for many models.
- Increased xDS keepalive timeout for FIPS-enabled clusters
Before this update, the proxy in Red Hat OpenShift Service Mesh processed a high volume of clusters with Transport Layer Security (TLS) contexts on a FIPS-enabled cluster. As a consequence, the Envoy main thread missed keepalive signals due to the additional cryptographic checks, which caused the xDS proxy downstream to stop with the following error:
xdsproxy downstream terminated with unexpected error … rpc error: code = Unavailable desc = transport is closingWith this release, the new default configuration extends the keepalive timeout to 2 minutes from 30 seconds. As a result, the proxy maintains a stable connection even during intensive configuration processing in FIPS environments.
1.2. Red Hat OpenShift Service Mesh version 3.3 new features and enhancements Link kopierenLink in die Zwischenablage kopiert!
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
X25519MLKEM768with both Istio gateways and in-mesh traffic (for both sidecar and ambient modes).NoteThe PQC
X25519MLKEM768algorithm is not available in FIPS-enabled clusters.- 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
ztunnelandIstiodto communicate. As a result, the ambient mode functions correctly on FIPS-enabled clusters, ensuring a secure and compliant environment for end users.- 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.
- 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
Kialicustom 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.)
-
- 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
KialiCR by setting thespec.kiali_internal.traffic_cache.enabledfield tofalse.
1.3. Red Hat OpenShift Service Mesh version 3.3 Technology Preview features Link kopierenLink in die Zwischenablage kopiert!
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.
1.4. Red Hat OpenShift Service Mesh version 3.3 fixed issues Link kopierenLink in die Zwischenablage kopiert!
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.
- 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
GetRootNamespacedetermination. 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.
1.5. Red Hat OpenShift Service Mesh 3.3 known issues Link kopierenLink in die Zwischenablage kopiert!
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.
- 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_MUTUALTLS 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.