Chapter 1. OpenShift Service Mesh release notes

This release introduces support for Kubernetes Gateway API custom resource definitions (CRDs). You can now use these CRDs to configure OpenShift Service Mesh with the Kubernetes Gateway API. This feature is available with Red Hat OpenShift Service Mesh 4.19.

This release introduces support for OpenShift Service Mesh on x86 dual-stack clusters. This feature remains a technology preview on all other platforms.

This release introduces support for the Kubernetes traffic distribution feature, part of the Kubernetes Service API, within OpenShift Service Mesh. As of Red Hat OpenShift Service Mesh 4.19, this is a Beta feature and requires enabling the ServiceTrafficDistribution parameter in the Istio Custom Resources (CRs).

This release introduces developer preview support for the experimental Kubernetes ClusterTrustBundle feature. This feature provides a new way of distributing X.509 trust anchors (root certificates) to workloads within the cluster. As of Red Hat OpenShift Service Mesh 4.19, this is an Alpha feature and requires enabling the ClusterTrustBundle feature.

This release updates OpenShift Service Mesh to use UBI-micro base containers for most container images. The UBI-micro image is the smallest possible Universal Base Image (UBI), which excludes a package manager and all of its dependencies normally included in a container image. This change minimizes the attack surface of container images that use the UBI-micro base.

This release updates the status of Istio ambient mode to Technology Preview. Istio ambient mode provides a sidecar-less alternative data plane to the traditional sidecar-based data plane. By default, ambient mode splits the data plane into node-level L4 ZTunnels and namespace-scoped L7 Waypoint proxies.

Istio ambient mode requires Kubernetes Gateway API custom resource definitions (CRDs). Use OpenShift Service Mesh 4.19 or later, which includes the CRDs by default.

To avoid potential conflicts, you must install Istio ambient mode only on clusters that do not have an existing Red Hat OpenShift Service Mesh installation. Istio ambient mode is not compatible with clusters that use Red Hat OpenShift Service Mesh 2.6 or earlier.

When you use Istio ambient mode, pods that rely on liveness or readiness probes require you to set the OVN-Kubernetes gateway mode to local instead of the default shared mode. In local mode, traffic routes through the host and the host processes it using the routing table, ensuring that probes function correctly. For more information, see the "Configuring gateway mode" section in the OVN-Kubernetes documentation.

To start using Istio ambient mode, see the "Istio ambient mode" section in the OpenShift Service Mesh 3 installation documentation.

This release provides technology preview support for Kubernetes Gateway API Inference Extensions. These extensions build on Kubernetes Gateway API to provide inference-specific routing capabilities that optimize for self-hosted generative-AI workloads. This implementation was backported to OpenShift Service Mesh 3.1 from Istio 1.27.

There is currently a known issue that prevents OpenShift Container Platform nodes from upgrading. The podDisruptionBudget resource prevents the draining of the node where the istiod pod is running, unless there are multiple replicas of the istiod pod.

Workaround: Set the .spec.values.global.defaultPodDisruptionBudget.enabled field in the Istio CR to false. Alternatively, you can temporarily increase the number of replicas for the istiod deployment. OSSM-9392

This release removes the use of ISTIO_META_DNS_AUTO_ALLOCATE option in the proxyMetadata configuration. You can use the DNS auto-allocation label in the ServiceEntry resource instead. A future release will remove support for the ISTIO_META_DNS_AUTO_ALLOCATE option.

For more information about using the DNS auto-allocation label in the ServiceEntry resource, see the "Address auto-collection" section in the Istio documentation.

This release adds a set of checklists and migration guides to help you migrate from OpenShift Service Mesh 2 to OpenShift Service Mesh 3.0.

You must complete the checklists first. The checklists help you set up and configure OpenShift Service Mesh 2 and the ServiceMeshControlPlane resource to migrate to OpenShift Service Mesh 3.0 and the Istio control plane resource.

Your migration depends on your deployment model:

You can also migrate gateways. For more information, see "Migrating from Service Mesh 2 to Service Mesh 3".

OpenShift Service Mesh 3.0 is based on a Red Hat distribution of the Istio project and is deployed with a new Operator for Istio based on the Sail Operator project that is part of the istio-ecosystem organization on GitHub. The Sail Operator includes a new set of custom resource definitions (CRDs) for managing Istio. For example, the Istio CRD replaces the ServiceMeshControlPlane CRD in previous releases of OpenShift Service Mesh.

This release adds support for select platforms and commands for Istioctl, the command line utility for the Istio project that includes many diagnostic and debugging utilities. For more information, see "Support for Istioctl".

This release introduces support for the following Istio multi-cluster deployment models:

The federation feature introduced in OpenShift Service Mesh 2.1 is not available in OpenShift Service Mesh 3.0.

This release adds support for the Istio feature of multiple control planes in a single cluster. This replaces the MultiTenant deployment model (mode) in OpenShift Service Mesh 2.

This release adds support for canary-style updates of the Istio control plane using the Istio revision feature. This enables a new Istio control plane to be created alongside the existing Istio control plane so that workloads can be migrated incrementally. The update strategy is configured using the spec.updateStrategy parameter of the Istio resource.

For more information, see "About RevisionBased strategy".

This release introduces the IstioCNI custom resource definition (CRD), which is used to manage the lifecycle of the Istio Container Network Interface (CNI) daemon set. A single instance of this resource must be created per cluster to configure traffic redirection for pods in the mesh. The Istio CNI lifecycle is independent of the Istio control plane or planes.

This release includes IPv4/IPv6 dual-stack support as a technology preview feature. This aligns with the Alpha status of the Istio upstream project, and is feature-complete for Istio when using sidecars. Dual-stack helps organizations smoothly transition to IPv6, while still maintaining compatibility with their existing IPv4 setup.

In OpenShift Service Mesh 3.0, dual-stack is disabled by default in the Istio resource. You can enable it with specific configuration changes, such as the one shown in the following example:

apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
spec:
  values:
    meshConfig:
      defaultConfig:
        proxyMetadata:
          ISTIO_DUAL_STACK: "true"
    pilot:
      ipFamilyPolicy: RequireDualStack
      env:
        ISTIO_DUAL_STACK: "true"
  namespace: istio-system

apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
spec:
  values:
    meshConfig:
      defaultConfig:
        proxyMetadata:
          ISTIO_DUAL_STACK: "true"
    pilot:
      ipFamilyPolicy: RequireDualStack
      env:
        ISTIO_DUAL_STACK: "true"
  namespace: istio-system

Istio Ambient mode provides a sidecarless service mesh architecture that reduces resource overhead, simplifies operations, and allows incremental adoption without application changes. It maintains security and observability through a layered security model with mTLS and authorization. The OpenShift Service Mesh 3 Operator includes deploying the Ambient profile as a developer preview feature using the community Ztunnel image. However, the Ambient profile should not be used on clusters with production workloads or for multi-control plane use cases.

The community Ztunnel image is unavailable on the following platforms:

This release removes the Istio OpenShift Route (IOR) for automatically creating and managing OpenShift Route resources with Istio Gateway resources. Istio Gateways are managed independent of the Istio control plane using either Gateway injection or Kubernetes Gateway API.

OpenShift Service Mesh 3.0 no longer includes Prometheus and Grafana, and it does not manage the configuration of Jaeger and Elasticsearch. Both Jaeger and Elasticsearch are deprecated and will be removed in a future release.

Supported integrations are provided with Red Hat OpenShift Observability, including user-workload monitoring and distributed tracing. For more information, see "Red Hat OpenShift Observability and Service Mesh". Support is also provided for the Kiali Operator provided by Red Hat. For more information, see "Using Kiali Operator provided by Red Hat".