Loose mode traffic lanes work with custom routing resources, such as virtual services and destination rules, to provide unified end-to-end traffic ingress, fine-grained routing, and plugin-based traffic processing.
Function Introduction
Loose mode traffic lanes let you isolate application versions. Traffic is routed to different lanes based on pass-through request headers and traffic-guiding request headers. When services in a lane call each other, if the target service does not exist in the current lane, traffic is forwarded to the baseline lane. This ensures link integrity and simplifies traffic management.
Before you use loose mode traffic lanes, understand the following concepts.
Methods for passing through call chain context
Passing through call chain context is a prerequisite for loose mode traffic lanes. For a single call chain, all requests must share the same request header.
Loose mode traffic lanes support common methods for passing through call chain context. Choose the scenario that matches your application.
Scenario 1: Pass through a trace ID
A trace ID is a request header with the following features:
-
The request header is passed through the entire call chain.
-
The request header is unique for each call chain.
A trace ID uniquely identifies a complete call chain. Its value is usually a random string. If your application is integrated with a tracing system, it likely passes through a trace ID. Common tracing standards use unique request headers for trace IDs, such as x-b3-trace-id and x-datadog-trace-id.
Scenario 2: Pass through a custom request header
Your application code may already pass through request headers with business meaning, such as version or env. These headers often identify the version and environment of the call chain. In this scenario, you must use the passed-through custom request header as the traffic-guiding request header.
Scenario 3: Pass through a baggage request header
Baggage is a standard OpenTelemetry mechanism that passes context information across processes in distributed call chains by adding a Baggage field to the HTTP header. The field value is a set of key-value pairs that can carry context data such as tenant IDs, trace IDs, and security credentials, enabling tracing and log correlation without code changes. For example:
baggage: userId=alice,serverNode=DF%2028,isProduction=falseBaggage is the recommended method for configuring loose mode traffic lanes because it is the standard OpenTelemetry mechanism for passing through call chain context.
For Scenarios 1 and 3: If your application is not integrated with a tracing system or does not pass through baggage in its code, you can use automatic instrumentation. You can use the OpenTelemetry Operator to inject automatic instrumentation capabilities into your application. This enables the pass-through of trace ID request headers without changing your application code. To set up automatic instrumentation, follow the steps in the community document. You must install the OpenTelemetry Operator, configure automatic instrumentation, and add annotations to your application Pods. OpenTelemetry automatic instrumentation supports many common standards for passing through distributed call chain context, such as W3C Baggage and B3. The community document provides examples for passing through W3C TraceContext and W3C Baggage. For more information, see Automatic Instrumentation.
Traffic-guiding request header
Loose mode traffic lanes use a traffic-guiding request header to tag the request chain. You can specify any request header that does not conflict with your application's existing business-related headers. Based on your chosen method for passing through call chain context, loose mode traffic lanes ensure that the traffic-guiding request header is included at every step of the call chain. The header value is the name of the traffic lane. For example, if you specify x-asm-prefer-tag as the traffic-guiding request header, when a request is sent to a service in a lane named s1, subsequent requests in the call chain always carry the x-asm-prefer-tag: s1 request header. Traffic lanes use the lane tag in the request header to create isolated environments for different application versions.
If you choose to pass through a custom request header, you must use that same header as the traffic-guiding request header.
Scenario overview
The following scenarios show how to route traffic to lanes using three different methods for passing through request headers, and how to configure custom virtual services to guide traffic into loose mode lanes.
References
-
Traffic lanes have two modes: Strict and Loose. For more information about the modes and their differences, see Overview of traffic lanes.
-
To use the same header for both pass-through and traffic-guiding to manage end-to-end traffic, see Scenario 2: Pass through a custom request header in the chain.
-
You can implement traffic lanes using traffic rules such as VirtualService and DestinationRule. You can also configure traffic fallback. If an application with a specific version or feature is unavailable, traffic is sent to a designated fallback version. For more information, see Implement traffic lanes and traffic fallback based on traffic rules.
-
Traffic-guiding rules for traffic lanes include rules that match request headers and the URI of the request. To implement more complex matching rules or custom routing, you can use a custom virtual service. For configuration details, see Guide traffic to loose mode lanes using a custom virtual service.