Este conteúdo não está disponível no idioma selecionado.
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 Copiar o linkLink copiado para a área de transferência!
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 Copiar o linkLink copiado para a área de transferência!
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 Copiar o linkLink copiado para a área de transferência!
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 Copiar o linkLink copiado para a área de transferência!
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 Copiar o linkLink copiado para a área de transferência!
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 Copiar o linkLink copiado para a área de transferência!
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 Copiar o linkLink copiado para a área de transferência!
1.2.1. Ambient mode not supported on FIPS-enabled OpenShift clusters Copiar o linkLink copiado para a área de transferência!
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 Copiar o linkLink copiado para a área de transferência!
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.
1.2.3. Istio sidecars cannot reach Istiod on s390x and PowerPC when using TPROXY mode Copiar o linkLink copiado para a área de transferência!
Configuring Istio in sidecar mode with Transparent Proxy (TPROXY) on s390x and PowerPC hardware platforms causes the istio-proxy container to fail certificate signing and remain unready. As a consequence, the sidecar cannot reach the Istiod service and the connection times out. As a result, affected workloads cannot run successfully under these conditions.
1.2.4. Waypoint proxy emits incomplete telemetry on s390x platforms Copiar o linkLink copiado para a área de transferência!
Running Istio in ambient mode on the s390x hardware platform causes the waypoint proxy to emit incomplete telemetry after the namespace is enrolled. As a consequence, tools such as Kiali cannot generate accurate graphs or diagrams, resulting in missing edges, unknown fields, or no visualization data. As a result, telemetry-dependent observability features remain incomplete on affected clusters.