Traffic Management
Traffic management is one of the most commonly used Istio features. It lets you control how requests flow between services without changing application code or redeploying workloads.
What it Gives You
- Request routing - send requests to specific service versions based on weight, HTTP headers, path, method, or source workload.
- Traffic splitting - shift a percentage of traffic between versions to support canary releases and blue/green deployments.
- Fault injection - deliberately inject delays or errors to test how services behave under failure.
- Mirroring - send a copy of live traffic to a new version without affecting the response the user receives.
How it Works
Istio decouples traffic routing from the number of running pods. Instead of relying on Kubernetes service load balancing, you describe the desired routing behaviour in Istio resources and the data plane proxies enforce it.
| Resource | Purpose |
|---|---|
VirtualService | Defines routing rules - which requests go where, with what weights and match conditions |
DestinationRule | Defines subsets (for example v1 and v2) and policies such as load balancing applied after routing |
A typical pattern is a DestinationRule that defines version subsets based on pod labels, and a VirtualService that splits traffic across those subsets.
Info
Traffic management between services inside the mesh does not require an Istio ingress gateway. A gateway is only needed when traffic enters the mesh from outside the cluster. East-west (service-to-service) routing works with VirtualService and DestinationRule alone.
When to Use It
- Gradually rolling out a new version with a canary deployment
- A/B testing based on request headers
- Testing resilience with fault injection before an incident happens
- Decoupling release (deploying code) from rollout (sending it traffic)
You will use traffic management directly in Lab 4 .