A canary release typically targets a single service. But when services form call chains, isolating one service is not enough -- canary traffic must stay isolated across the entire chain. If a request hits the canary version of Service A but routes to the stable version of Service B, the test results are unreliable.
Service Mesh (ASM) traffic lanes solve this by grouping a specific version or features of an application across a call chain into an isolated runtime environment. Lane rules route matching requests to the correct version of every service in the chain, keeping canary traffic separate from production traffic end to end. This makes it straightforward to build isolated environments for traffic from the gateway to services, release multiple services simultaneously, or develop multiple versions in parallel.
Traffic lanes operate in two modes -- strict and permissive -- that differ in how they handle services missing from a lane.
Key concepts
| Term | Definition |
|---|---|
| Traffic lane | An isolated runtime environment that groups a specific version or features of an application across a call chain. |
| Lane rule | A routing rule that directs matching requests to the target lane. |
| Baseline lane | The lane that contains all services in the call chain. In permissive mode, other lanes fall back to the baseline for missing services. |
| E2E pass-through request header | An HTTP header propagated across every service in a call chain. In permissive mode, this header identifies which lane a request belongs to. |
How it works
Strict mode
In strict mode, every lane contains all services in the call chain. ASM routes requests to the matching lane based on lane rules, with no fallback needed.
Because each lane is self-contained, strict mode requires no changes to your application code -- no header propagation is needed.
For setup instructions, see Use traffic lanes in strict mode to manage end-to-end traffic.
Permissive mode
In permissive mode, only the baseline lane must contain all services. Other lanes can contain a subset. When a request reaches a service that does not exist in the current lane, ASM forwards it to the baseline lane. When that service becomes available in the lane again, traffic automatically routes back.
This fallback mechanism requires your application to propagate an E2E pass-through request header across every service call in the chain. Each lane uses a distinct header value, so ASM can identify which lane a request belongs to throughout the call chain.
For setup instructions, see:
Choose a mode
| Strict mode | Permissive mode | |
|---|---|---|
| When to use | Canary releases that cover all services in a call chain. | Canary releases that target only some services in a call chain. |
| Application requirement | None. No code changes needed. | Propagate an E2E pass-through request header with a distinct value per lane across all service calls. |
| Lane composition | Every lane must contain all services in the call chain. | Only the baseline lane must contain all services. Other lanes contain only the services under test. |
| Flexibility | Lower -- every lane is a full replica of the call chain. | Higher -- test new versions of individual services without replicating the entire chain. |