Chapter 1. OpenShift Service Mesh release notes
Red Hat OpenShift Service Mesh release notes contain information about new features and enhancements, and known issues. They contain a set of tables for supported component versions and Istio features, and are organized by OpenShift Service Mesh version.
For additional information about the Red Hat OpenShift Service Mesh life cycle and supported platforms, refer to the OpenShift Operator Life Cycles.
1.1. Red Hat OpenShift Service Mesh version 3.2 new features and enhancements Copy linkLink copied to clipboard!
This release makes Red Hat OpenShift Service Mesh 3.2 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 3.2 feature support tables".
When upgrading from OpenShift Service Mesh 2.x, you must first migrate to version 3.0 and then to version 3.1. Then, you can upgrade to version 3.2. For more information, see "Migrating from Service Mesh 2 to Service Mesh 3".
1.1.1. General availability of Istio ambient mode Copy linkLink copied to clipboard!
This enhancement brings the core features of Istio ambient mode, ztunnel, and waypoint, to general availability. Ambient mode reduces the resource costs of running a service mesh by removing the need for sidecar proxies with a new data plane architecture that consists of the following two levels of proxy:
- The layer 4 node level ztunnel proxy
- The layer 7 application level waypoint proxy
1.1.2. Updated feature support matrix for ambient mode Copy linkLink copied to clipboard!
This enhancement provides an updated feature support matrix for Istio ambient mode. Not all sidecar mode features are supported in ambient mode. For detailed information about supported and unsupported features, see "Service Mesh feature support tables".
1.1.3. Network policy updates may be required for ambient mode traffic Copy linkLink copied to clipboard!
Istio ambient mode uses an application-layer tunnel (L7) called HBONE to carry TCP traffic (L4) securely between workloads. The ztunnel component tunnels pod traffic over TCP port 15008. If existing Kubernetes NetworkPolicy configurations block inbound traffic on this port, update them to allow inbound TCP traffic on port 15008 for ambient workloads. Sidecar workloads must also allow inbound traffic on this port to communicate with ambient workloads. For more information, see "Configuring network policies for ambient mode".
1.1.4. Ensuring probe reliability with OVN-Kubernetes local gateway mode Copy linkLink copied to clipboard!
To ensure liveness and readiness probes continue to function correctly for workloads running in Istio ambient mode, you must enable OVN-Kubernetes local gateway mode by setting routingViaHost: true in the gatewayConfig specification. For more information, see the "OVN-Kubernetes documentation"
1.1.6. Enhanced NetworkPolicy Coverage for Ambient Mode Components Copy linkLink copied to clipboard!
With the 3.2 release, enabling the global networkPolicy setting now extends NetworkPolicy creation to include istio-cni and ztunnel resources, in addition to the previously supported istiod and gateway resources.
1.2. Red Hat OpenShift Service Mesh 3.2 known issues Copy linkLink copied to clipboard!
1.2.1. Ambient mode not supported on FIPS-enabled OpenShift clusters Copy linkLink copied to clipboard!
Istio ambient mode does not currently support OpenShift clusters running in Federal Information Processing Standards (FIPS) mode. Deployments that require FIPS compliance must continue using sidecar mode until support becomes available in a future release.
1.2.2. Limitation due to ztunnel concurrency issue Copy linkLink copied to clipboard!
A concurrency issue in ztunnel limits throughput scalability in Istio ambient mode. Performance remains comparable to sidecar mode in most scenarios, but the issue can limit the potential to scale throughput performance.