Ambient Mode Traffic Management Demo

This guide demonstrates how common Istio traffic-management features behave in Ambient Mode. You’ll learn which control-plane primitives still work, which require Kubernetes-native APIs (for example, HTTPRoute), and how the waypoint proxy fits into request flows. Note: Ambient Mode is typically a small part of the ICA exam objectives. Practically, you should know how to install Ambient Mode and label namespaces. This article is a hands-on demo to illustrate Ambient Mode behavior and how to implement L7 features using a waypoint proxy.

Ambient Mode uses the ztunnel DaemonSet for L4 routing and an optional waypoint (Envoy) proxy for L7 behaviors. Some Istio features (for example, split traffic using VirtualService subsets or mirroring) require different Kubernetes-native APIs in Ambient Mode.

Table: Sidecar vs Ambient — API/Behavior mapping

Feature	Sidecar mode (classic)	Ambient mode (ztunnel + waypoint)
L4 routing	iptables + sidecar	`ztunnel` DaemonSet (L4)
L7 routing / weights	`VirtualService` + `DestinationRule` subsets	`HTTPRoute` + waypoint; `VirtualService` may work when waypoint handles L7
Fault injection (delay/abort)	`VirtualService` fault rules	Often via waypoint + `VirtualService` (depends on setup)
Mirroring	`VirtualService` mirror	Not supported / limited in Ambient Mode

References:

Verify Ambient components

Assuming Istio Ambient Mode has been installed, confirm the core control-plane components are running in the istio-system namespace:

kubectl get pods -n istio-system

Example (trimmed):

NAME                        READY   STATUS    RESTARTS   AGE
istio-cni-node-vdt82        1/1     Running   0          3m
istiod-6b85468cc-nnfk4      1/1     Running   0          3m
ztunnel-qgtj5               1/1     Running   0          3m

Check namespaces and labels. Ambient Mode commonly uses:

istio.io/dataplane-mode=ambient
istio.io/use-waypoint=waypoint (for namespaces that need L7 capabilities)

Inspect your namespaces:

kubectl get ns --show-labels

Sample output:

NAME           STATUS   AGE     LABELS
hello          Active   5m      kubernetes.io/metadata.name=hello
test           Active   6m      kubernetes.io/metadata.name=test
istio-system   Active   8m      kubernetes.io/metadata.name=istio-system
# ...

If you plan to enable L7 features in a namespace, add the labels:

kubectl label namespace hello istio.io/dataplane-mode=ambient istio.io/use-waypoint=waypoint

Deploy the HelloWorld app (example)

This demo uses a simple Hello World app with two versions (v1 and v2). The repository contains helloworld.yaml which creates two deployments and a catch-all service. Deploy into the hello namespace:

kubectl apply -f helloworld.yaml -n hello

Verify deployments and services:

kubectl get deployments.apps -n hello
kubectl get svc -n hello

Example output:

NAME            READY   UP-TO-DATE   AVAILABLE   AGE
helloworld-v1   1/1     1            1           2m
helloworld-v2   1/1     1            1           2m
waypoint        1/1     1            1           30s

NAME        TYPE        CLUSTER-IP       PORT(S)
helloworld  ClusterIP   10.109.201.209   5000/TCP
waypoint    ClusterIP   10.108.208.214   15021/TCP,15008/TCP

Attempt: split traffic using DestinationRule + VirtualService (sidecar-style)

In sidecar-based deployments, you typically split traffic using a DestinationRule with subsets and a VirtualService with weighted routes. Example sidecar-style VirtualService:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: hello-world-vs
  namespace: hello
spec:
  hosts:
    - helloworld
  http:
    - match:
        - uri:
            prefix: /
      route:
        - destination:
            host: helloworld.default.svc.cluster.local
            port:
              number: 5000
            subset: v1
          weight: 95
        - destination:
            host: helloworld.default.svc.cluster.local
            port:
              number: 5000
            subset: v2
          weight: 5

And matching DestinationRule:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: hello-world-dr
  namespace: hello
spec:
  host: helloworld
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Apply:

kubectl apply -f hello-dr.yaml
kubectl apply -f hello-vs.yaml

However, in Ambient Mode this approach does not reliably split traffic. ztunnel handles L4 routing and does not support VirtualService subset routing in the same way sidecars do. Results may appear random or not follow the configured weights.

Correct approach for split traffic in Ambient Mode: HTTPRoute + waypoint

To implement weighted HTTP split routing in Ambient Mode, use the Kubernetes Gateway API HTTPRoute (gateway.networking.k8s.io/v1) and configure a waypoint proxy that performs L7 processing. High-level steps:

Create a waypoint proxy for the namespace (generates the waypoint Envoy).
Remove the sidecar-style VirtualService/DestinationRule.
Create per-version Kubernetes Services and an HTTPRoute that references those services with weights.
Test traffic distribution via the waypoint proxy.

Step-by-step:

Create the waypoint for the hello namespace:

istioctl waypoint apply -n hello

Verify the waypoint pod is running:

kubectl get pods -n hello

Remove the sidecar-style rules that do not provide the expected split semantics in Ambient Mode:

kubectl delete -f hello-vs.yaml
kubectl delete -f hello-dr.yaml

Create an HTTPRoute that attaches to the catch-all helloworld Service (port 5000) and splits traffic using backendRefs. Save as hello-httproute-split-traffic.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: hello-http-split-traffic
  namespace: hello
spec:
  parentRefs:
    - group: ""
      kind: Service
      name: helloworld
      port: 5000
  rules:
    - backendRefs:
        - name: helloworld-v1
          port: 5000
          weight: 95
        - name: helloworld-v2
          port: 5000
          weight: 5

Apply:

kubectl apply -f hello-httproute-split-traffic.yaml

Important: backendRefs must reference Kubernetes Services. Create two per-version services (one per deployment) in addition to the catch-all helloworld service. Example per-version Service YAML (can be added to helloworld.yaml or a separate file):

apiVersion: v1
kind: Service
metadata:
  name: helloworld-v1
  namespace: hello
  labels:
    app: helloworld
    version: v1
spec:
  ports:
    - port: 5000
      name: http
  selector:
    app: helloworld
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: helloworld-v2
  namespace: hello
  labels:
    app: helloworld
    version: v2
spec:
  ports:
    - port: 5000
      name: http
  selector:
    app: helloworld
    version: v2

Apply the services (and any updated helloworld manifests):

kubectl apply -f helloworld.yaml -n hello

Now confirm you have the catch-all and the per-version services:

kubectl get svc -n hello

Example output:

NAME             TYPE        CLUSTER-IP       PORT(S)
helloworld       ClusterIP   10.109.201.209   5000/TCP
helloworld-v1    ClusterIP   10.109.201.210   5000/TCP
helloworld-v2    ClusterIP   10.106.142.114   5000/TCP
waypoint         ClusterIP   10.108.208.214   15021/TCP,15008/TCP

Test the split behavior from a test pod:

kubectl exec -n test curl -- curl helloworld.hello.svc.cluster.local:5000/hello

You should observe routing according to the configured weights (95% → v1, 5% → v2). Small sample sizes can hide the distribution — issue many requests to validate the split.

Notes: features not fully supported (yet)

Mirroring is not supported in Ambient Mode (as of this writing).
Some features like certain timeouts and retries may not behave identically under Ambient Mode L7 processing. Always check release notes and the Istio roadmap for current support.
HTTPRoute + waypoint is the recommended Kubernetes-native pattern for L7 behavior (weights) in Ambient Mode.

Ambient Mode behavior is evolving. If a feature behaves differently than sidecar mode, consult the Istio Ambient Mode documentation and Istio release notes for current status and supported APIs.

Example: httpbin with delay and abort fault injection (waypoint + VirtualService)

For L7 fault injection (delay/abort) you can often use VirtualService APIs when a waypoint proxy is handling L7. This example deploys httpbin into a waypoint-enabled namespace and applies VirtualService fault rules.

Label the namespace and create a waypoint for httpbin:

kubectl label namespace httpbin istio.io/dataplane-mode=ambient istio.io/use-waypoint=waypoint
istioctl waypoint apply -n httpbin

Deploy httpbin:

kubectl apply -f httpbin.yaml -n httpbin

Verify pods and services:

kubectl get pods -n httpbin
kubectl get svc -n httpbin

Test the basic GET route from the test pod:

kubectl exec -n test curl -- curl httpbin.httpbin.svc.cluster.local:8000/get

You should receive a normal httpbin JSON response.

Inject a delay (VirtualService fault injection). Save as httpbin-vs-delay.yaml:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs-delay
  namespace: httpbin
spec:
  hosts:
    - httpbin.httpbin.svc.cluster.local
  http:
    - fault:
        delay:
          percentage:
            value: 100.0
          fixedDelay: 3s
      route:
        - destination:
            host: httpbin.httpbin.svc.cluster.local
            port:
              number: 8000

Apply:

kubectl apply -f httpbin-vs-delay.yaml

Test and observe the delay (~3 seconds):

kubectl exec -n test curl -- curl httpbin.httpbin.svc.cluster.local:8000/get

Sample curl timing should show the request takes ~3s.

Inject an abort (500). Save as httpbin-vs-abort.yaml:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs-abort
  namespace: httpbin
spec:
  hosts:
    - httpbin.httpbin.svc.cluster.local
  http:
    - fault:
        abort:
          percentage:
            value: 100.0
          httpStatus: 500
      route:
        - destination:
            host: httpbin.httpbin.svc.cluster.local
            port:
              number: 8000

Apply and test with a HEAD request to inspect the HTTP status:

kubectl apply -f httpbin-vs-abort.yaml
kubectl exec -n test curl -- curl --head httpbin.httpbin.svc.cluster.local:8000/get

Expected response header (example):

HTTP/1.1 500 Internal Server Error
content-length: 18
content-type: text/plain
server: istio-envoy
x-envoy-decorator-operation: httpbin.httpbin.svc.cluster.local:8000/*

You can change httpStatus (for example, to 404) and reapply to modify abort behavior.

Summary / Best practices

Ambient Mode uses ztunnel for L4 routing and a waypoint Envoy proxy for L7 features.
Sidecar-mode primitives (VirtualService subsets + DestinationRules) do not reliably provide the same split semantics in Ambient Mode.
For HTTP request splitting in Ambient Mode, prefer the Kubernetes Gateway API HTTPRoute attached to the catch-all service, with backendRef services (one service per deployment/version).
For L7 fault injection (delay/abort), the waypoint proxy combined with VirtualService often works — but confirm support per Istio release.
Ambient Mode is evolving; always consult the Istio docs and release notes for current API support and recommended patterns.

Introduction

Installation & Configuration

Traffic Management

Securing Workloads

Troubleshooting

Conclusion

Ambient Mode Traffic Management Demo

Table: Sidecar vs Ambient — API/Behavior mapping

Verify Ambient components

Deploy the HelloWorld app (example)

Attempt: split traffic using DestinationRule + VirtualService (sidecar-style)

Correct approach for split traffic in Ambient Mode: HTTPRoute + waypoint

Notes: features not fully supported (yet)

Example: httpbin with delay and abort fault injection (waypoint + VirtualService)

Summary / Best practices

Watch Video

Practice Lab

​Table: Sidecar vs Ambient — API/Behavior mapping

​Verify Ambient components

​Deploy the HelloWorld app (example)

​Attempt: split traffic using DestinationRule + VirtualService (sidecar-style)

​Correct approach for split traffic in Ambient Mode: HTTPRoute + waypoint

​Notes: features not fully supported (yet)

​Example: httpbin with delay and abort fault injection (waypoint + VirtualService)

​Summary / Best practices

Watch Video

Practice Lab

Table: Sidecar vs Ambient — API/Behavior mapping

Verify Ambient components

Deploy the HelloWorld app (example)

Attempt: split traffic using DestinationRule + VirtualService (sidecar-style)

Correct approach for split traffic in Ambient Mode: HTTPRoute + waypoint

Notes: features not fully supported (yet)

Example: httpbin with delay and abort fault injection (waypoint + VirtualService)

Summary / Best practices