Uploaded image for project: 'OpenShift Service Mesh'
  1. OpenShift Service Mesh
  2. OSSM-9381

Istio Ambient Mode - GA

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Blocker Blocker
    • None
    • None
    • Istio, Kiali, Sail Operator
    • None
    • Istio Ambient Mode - GA
    • False
    • Hide

      None

      Show
      None
    • False
    • Documentation (Ref Guide, User Guide, etc.), Release Notes
    • Done
    • 21% To Do, 15% In Progress, 64% Done
    • Hide
      This release brings the core features (Ztunnel, Waypoint) of Istio's ambient mode to general availability. Istio's ambient mode significantly reduces the resource costs of running service mesh with an architecture that removes the need for sidecar proxies.

      Not all features of sidecar mode are supported with ambient mode. For a detailed list of feature support levels with Istio's ambient mode, see the feature support table (link if possible).

      Istio's ambient mode is not yet supported on OpenShift clusters running in FIPS mode.

      While Istio's ambient mode's performance should be comparable to that of sidecar mode, a known concurrency issue in ztunnel (https://github.com/istio/ztunnel/issues/1174) will limit the potential to scale throughput performance.

      Istio's ambient mode's L4 overlay (ztunnel) will tunnel traffic between pods over port 15008. If there is a pre-existing Kubernetes NetworkPolicy that blocks inbound TCP traffic on this port, you will have to add an exception to that NetworkPolicy for TCP port 15008 to allow traffic to pods that are part of the ambient mesh. Sidecar workloads will also need to allow inbound traffic on port 15008 for them to communicate with ambient workloads. (More information: https://istio.io/latest/docs/ambient/usage/networkpolicy/)

      To ensure that pod liveness and readiness probes continue to function correctly for workloads that use Istio ambient mode, enable OVN-Kubernetes `local` gateway mode by setting `routingViaHost: true` in the `gatewayConfig` spec. Full documentation on this can be found here: https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/ovn-kubernetes_network_plugin/configuring-gateway.
      Show
      This release brings the core features (Ztunnel, Waypoint) of Istio's ambient mode to general availability. Istio's ambient mode significantly reduces the resource costs of running service mesh with an architecture that removes the need for sidecar proxies. Not all features of sidecar mode are supported with ambient mode. For a detailed list of feature support levels with Istio's ambient mode, see the feature support table (link if possible). Istio's ambient mode is not yet supported on OpenShift clusters running in FIPS mode. While Istio's ambient mode's performance should be comparable to that of sidecar mode, a known concurrency issue in ztunnel ( https://github.com/istio/ztunnel/issues/1174 ) will limit the potential to scale throughput performance. Istio's ambient mode's L4 overlay (ztunnel) will tunnel traffic between pods over port 15008. If there is a pre-existing Kubernetes NetworkPolicy that blocks inbound TCP traffic on this port, you will have to add an exception to that NetworkPolicy for TCP port 15008 to allow traffic to pods that are part of the ambient mesh. Sidecar workloads will also need to allow inbound traffic on port 15008 for them to communicate with ambient workloads. (More information: https://istio.io/latest/docs/ambient/usage/networkpolicy/) To ensure that pod liveness and readiness probes continue to function correctly for workloads that use Istio ambient mode, enable OVN-Kubernetes `local` gateway mode by setting `routingViaHost: true` in the `gatewayConfig` spec. Full documentation on this can be found here: https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/ovn-kubernetes_network_plugin/configuring-gateway .

      This is an epic to capture work to bring Istio's ambient mode to GA. To take a user-first approach, we will use the official documentation as a guide to GA readiness. 

      This will include:

      • Identifying the feature status of ambient features, particularly any features that we do not wish to declare GA yet, which will need to be noted in our product feature table. We may need to note additional features not noted in the upstream feature support table.
      • Istio upstream integration tests
        • Ensure we have adequate automated testing for regression across later OSSM releases - in particular, for all GA supported features.
      • Knowledge sharing within the team. We need bring everybody up to speed on the differences between ambient and sidecar meshes.
      • Documentation changes needed are captured here: https://docs.google.com/document/d/1mCzK4qBdYQVoj-Ir-FATIJpTv2xhx6bDGhoXocbt_8o/edit?usp=sharing
      • API Review in the Sail Operator before declaring GA.
        • Currently ZTunnel is a separate CRD because it has a separate lifecycle from istiod and can't be upgraded using the revision-based upgrade mechanism. If we're going to invest in this (or anyone else implements it), we might want to revisit the Istio/ZTunnel split.
      • Add more integration/e2e tests for Ambient Mesh in Sail Operator
        • Control Plane upgrades with ZTunnel are not covered right now
        • Co-existence of sidecars and ambient mesh
      • Work with Kiali team to make sure feature support is matched
      • Identify and implement required Konflux changes to move from TP to GA

      Note: The outcome of https://issues.redhat.com/browse/OSSM-9855 will have a big impact on the above, thus that spike should be carried out first.

              jlongmui@redhat.com Jamie Longmuir
              jlongmui@redhat.com Jamie Longmuir
              Cameron Garrison, Gaddam Sridhar, Josune Cordoba Torrecilla, Matej Kralik, Maxim Babushkin, Mikhail Abramov, Praneeth Bajjuri, Zuzana Miklánková
              Votes:
              3 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated:
                Resolved: