Chapter 5. Coexistence of ambient and sidecar modes
Red Hat OpenShift Service Mesh supports running sidecar and ambient workloads in the same Istio mesh. Use this capability to migrate workloads to ambient mode in increments. You can keep specific workloads in sidecar mode if they depend on features that ambient mode does not yet support.
5.1. Overview of sidecar and ambient interoperability Copy linkLink copied to clipboard!
Coexisting sidecar and ambient workloads operate under a single Istio control plane that uses the ambient profile. With this configuration, you can enforce policies and route traffic across both deployment types. Review the following capabilities, limitations, and operational guidelines for managing this architecture.
5.1.1. Supported features Copy linkLink copied to clipboard!
Ambient and sidecar coexistence requires Red Hat OpenShift Service Mesh version 3.2 or later.
The following features work when sidecar and ambient workloads coexist.
| Category | Functionality | Description |
|---|---|---|
| Connectivity | East-west traffic | Sidecar pods and ambient pods communicate bidirectionally across namespace boundaries. |
| Security | mTLS | Sidecar proxies automatically detect HBONE (HTTP-Based Overlay Network Environment) endpoints and use HBONE for outbound connections to ambient pods. Ztunnel uses HBONE to reach sidecar proxies. Traffic between both modes is encrypted with mutual TLS. |
| Security |
L4 | The mesh enforces authorization policies based on principals, source IPs, and ports in both directions across modes. |
| Security |
|
A |
| Gateways | Egress gateways | Ambient pods interoperate with egress gateways. |
| Gateways | Ingress gateways | Ingress gateways deployed in non-ambient namespaces expose services in both sidecar and ambient namespaces. |
| Observability | L4 TCP metrics | Basic Layer 4 TCP metrics and telemetry are available for traffic between sidecar and ambient workloads. |
5.1.2. Limitations Copy linkLink copied to clipboard!
Unsupported
VirtualServicefeatures: Ambient mode does not support a gateway API required by the following features. Workloads that rely on these features must remain in sidecar mode:-
HTTPFaultInjection - JWT claim-based routing
- Delegate rules
- Rate limiting
-
ignoreCasefor path matching
-
One-Way L7 policy bypass (sidecar to ambient): Traffic from a sidecar pod to an ambient pod bypasses the waypoint proxy of the destination.
As a result, the mesh enforces only L4 authorization policies on this path; L7 policies (such as HTTP routing or rules) do not apply.
NoteTraffic in the opposite direction (ambient to sidecar) works without this limitation. The destination sidecar proxy enforces L7 policies normally.
Ingress gateway waypoint bypass: By default, traffic from an ingress gateway to an ambient service bypasses the waypoint proxy. To force traffic through the waypoint for L7 enforcement, you must:
-
Set the environment variable
ENABLE_INGRESS_WAYPOINT_ROUTINGtotruein the Istio CR. -
Label the target service or namespace with
istio.io/ingress-use-waypoint: "true".
-
Set the environment variable
5.1.3. Best practices Copy linkLink copied to clipboard!
- Keep ambient and sidecar workloads in separate namespaces to make the data plane mode of each workload explicit and to avoid label conflicts.
-
Do not label a namespace or pod with both
istio-injection: enabledandistio.io/dataplane-mode: ambient. If both labels are present, sidecar injection takes precedence, but the resulting configuration is ambiguous and difficult to maintain.
5.2. Enable ambient mode on an existing sidecar mesh Copy linkLink copied to clipboard!
Add ambient workloads to an existing sidecar-mode OpenShift Service Mesh installation by updating the control plane configuration and deploying the ztunnel proxy. After you complete this procedure, you can run sidecar and ambient workloads in separate namespaces within the same mesh.
Prerequisites
- You have an existing OpenShift Service Mesh installation (version 3.2 or later) in sidecar mode on OpenShift Container Platform.
-
You are logged in to the OpenShift Container Platform cluster as a user with the
cluster-adminrole.
Procedure
Update the existing
IstioCR to setprofile: ambientand to configure the trustedztunnelnamespace, as shown in the following example. Save the configuration to a file namedistio_ambient.yaml.apiVersion: sailoperator.io/v1 kind: Istio metadata: name: default spec: namespace: istio-system profile: ambient values: pilot: trustedZtunnelNamespace: ztunnelImportantYou must set
spec.profiletoambientand setspec.values.pilot.trustedZtunnelNamespacetoztunnel. This is the namespace in which you install theZTunnelresource.Apply the updated
IstioCR by running the following command:$ oc apply -f istio_ambient.yamlUpdate the
IstioCNIresource to enable the ambient profile, as shown in the following example. Save the configuration to a file namedistiocni_ambient.yaml.apiVersion: sailoperator.io/v1 kind: IstioCNI metadata: name: default spec: profile: ambientApply the updated
IstioCNIresource by running the following command:$ oc apply -f istiocni_ambient.yamlConfirm that the
IstioCNIresource is ready by running the following command:$ oc wait --for=condition=Ready istiocnis/default --timeout=3mCreate the
ztunnelnamespace by running the following command:$ oc create namespace ztunnelCreate a file named
ztunnel.yamlthat has theZTunnelresource. For example:apiVersion: sailoperator.io/v1 kind: ZTunnel metadata: name: default spec: namespace: ztunnel targetRef: kind: Istio name: defaultNoteThe
spec.targetReffield associates theZTunnelinstance with an Istio control plane. When you set this field, the system automatically copies values relevant toZTunnel, such asglobal,meshConfig, andrevision, from the referencedIstioorIstioRevisionresource. Values that you set in theZTunnelspec.valuesfield override inherited values.Apply the
ZTunnelCR by running the following command:$ oc apply -f ztunnel.yamlConfirm that the
ZTunnelresource is ready by running the following command:$ oc wait --for=condition=Ready ztunnels/default --timeout=3mConfirm that the Istio control plane is ready by running the following command:
$ oc wait --for=condition=Ready istios/default --timeout=3mRestart existing sidecar pods in each namespace that has sidecar workloads. Run the following command for each namespace:
$ oc rollout restart deployment -n <sidecar_namespace>The restart re-injects the pods with
ISTIO_META_ENABLE_HBONEset totrue. Without this setting, the sidecar proxies cannot communicate with workloads in the ambient data plane. If you have a large number of sidecar pods, consider restarting them in small batches or one at a time to avoid disruption.Create a namespace for your ambient workloads by running the following command:
$ oc create namespace <ambient_namespace>Label the namespace to enable ambient mode by running the following command:
$ oc label namespace <ambient_namespace> istio.io/dataplane-mode=ambientDeploy your application workloads to
<ambient_namespace>.The mesh uses the ztunnel proxy to intercept traffic for pods in this namespace. You do not need to change your workload manifests.
Verification
Verify that your ambient workloads run without a sidecar proxy:
$ oc get pods -n <ambient_namespace>Example output:
NAME READY STATUS RESTARTS AGE my-app-6d8f94b7c9-xk2pj 1/1 Running 0 45sPods in an ambient namespace show
1/1containers in theREADYcolumn. This output confirms that the mesh did not inject a sidecar proxy into the pod.Verify that ztunnel registered your ambient workloads and configured HBONE. Run the following command:
$ istioctl ztunnel-config workloads --namespace ztunnel --workload-namespace <ambient_namespace>The output lists the mesh workloads:
NAMESPACE POD NAME IP NODE WAYPOINT PROTOCOL example example-gateway-istio-59dd7c96db-q9k6v 10.244.1.11 ambient-worker None TCP example example-app-cf74bb974-5sqkp 10.244.1.5 ambient-worker None HBONEConfirm that the PROTOCOL column displays HBONE for your new ambient pods. This protocol value indicates that ztunnel configured HBONE.
When a sidecar pod sends traffic to an ambient pod, the traffic bypasses the waypoint proxy of the destination. As a result, the mesh enforces only L4 authorization policies on this path; L7 policies do not apply.
5.3. Enable sidecar mode on an existing ambient mesh Copy linkLink copied to clipboard!
Add sidecar workloads to an existing ambient-mode OpenShift Service Mesh installation by configuring automatic sidecar injection for a dedicated namespace. After you complete this procedure, you can run sidecar and ambient workloads in separate namespaces within the same mesh.
Prerequisites
- You have an existing OpenShift Service Mesh installation (version 3.2 or later) in ambient mode on OpenShift Container Platform.
-
You are logged in to the OpenShift Container Platform cluster as a user with the
cluster-adminrole.
Procedure
Follow the procedure Enabling sidecar injection with namespace labels in this guide.
ImportantDo not apply the
istio.io/dataplane-mode: ambientlabel to sidecar namespaces. If you apply both labels, sidecar injection takes precedence, but the resulting configuration is ambiguous and difficult to maintain.
Verification
Confirm that the namespace does not have the ambient label:
$ oc get namespace <sidecar_namespace> --show-labelsThe output displays the active labels. Verify that the string
istio.io/dataplane-mode=ambientdoes not appear.