In ambient mode, the ztunnel secure overlay handles Layer 4 (L4) functions such as mTLS encryption and basic TCP routing. To apply Layer 7 (L7) traffic policies -- weighted routing, header-based matching, fault injection, or retries -- you need a Waypoint proxy. When you redirect traffic to a Waypoint, ztunnel forwards requests to it for L7 processing before they reach the destination service.
This topic walks through configuring a VirtualService that splits traffic between two versions of the reviews service in the Bookinfo application, routing 90% of requests to reviews-v1 and 10% to reviews-v2. This pattern is the foundation for canary deployments, where you gradually shift traffic to a new version while monitoring for errors.
Prerequisites
Before you begin, make sure that you have:
Completed all steps in Deploy sample applications and enable ambient for encrypted communication
Deployed a Waypoint proxy and configured labels to route traffic in the
defaultnamespace through the Waypoint proxy
Configure weighted traffic routing
The Bookinfo application includes three versions of the reviews service. The following steps create a VirtualService that distributes traffic between reviews-v1 and reviews-v2 at a 90:10 ratio.
Step 1: Apply the VirtualService
Run the following command to create a VirtualService that routes 90% of reviews traffic to reviews-v1 and 10% to reviews-v2:
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- name: route
route:
- destination:
host: reviews-v1
weight: 90
- destination:
host: reviews-v2
weight: 10
EOFThe following table describes the fields in this configuration:
| Field | Description |
|---|---|
hosts | The service this routing rule applies to. All requests targeting the reviews service are matched. |
destination.host | The target service for each route. reviews-v1 and reviews-v2 are Kubernetes services corresponding to different versions. |
weight | The percentage of traffic directed to each destination. Weights across all destinations must sum to 100. |
Step 2: Verify the traffic split
Send 100 requests from the sleep pod to the Bookinfo product page and count how many responses come from each version:
kubectl exec deploy/sleep -- sh -c "for i in \$(seq 1 100); do curl -s http://productpage:9080/productpage | grep reviews-v.-; done" | sort | uniq -c | sort -rnExpected output (approximate):
178 <...reviews-v1...>
22 <...reviews-v2...>The ratio of reviews-v1 to reviews-v2 responses is approximately 9:1, matching the weights in the VirtualService.
The Bookinfo product page renders two review entries per request, so 100 requests produce approximately 200 lines of output. The 9:1 traffic ratio still holds.
Adjust weights for canary deployments
VirtualService-based traffic splitting operates at the mesh layer, independent of Kubernetes Deployment scaling. Scaling reviews-v1 or reviews-v2 replicas does not change the traffic ratio -- the Waypoint proxy enforces the configured weights regardless of pod count.
This decoupling makes weighted routing well-suited for canary deployments:
Route 100% of traffic to the stable version.
Deploy the new version and shift a small percentage (for example, 10%) to it.
Monitor error rates and latency. If the new version performs well, gradually increase its weight (50%, then 100%).
Remove the old version after migration completes.
To adjust the split, update the weight values in the VirtualService and reapply the configuration.
Clean up
To remove the VirtualService and restore default round-robin routing:
kubectl delete virtualservice reviews