Implement Traffic Coloring in Service Mesh for Canary Releases & Multi-Version Deployments

1 What is Traffic Coloring

In complex production environments, multiple versions of the same service often need to coexist for extended periods. To direct different users to different versions without affecting others, requests are sampled and "colored" with distinct identifiers.

Supports staged releases, reducing the risk of large‑scale failures such as system crashes or user loss during full rollouts.

Enables colored experiments, allowing a subset of users to experience new versions or experimental features first.

Facilitates online QA analysis, verification, debugging, and even stress testing in isolated deployment zones, preventing impact on other live users.

Service Mesh traffic‑coloring capabilities allow multi‑version traffic distribution within a single service based on feature values. In large, intricate meshes, this can manage routing for ten or more parallel chains, making it essential for common patterns such as Canary Release, A/B Testing, and Diversified Version.

1. Canary Release

2. Diversified Version

2 Mesh Uses Tag Feature for Coloring

To achieve traffic coloring, Mesh must meet several conditions:

The request must carry identifiable features such as specific headers, cookies, or query parameters.

Multiple service versions must be deployed. Pods of a Kubernetes service (svc) need to be part of the Mesh and labeled with a version. Alternatively, create separate services and route traffic to the new service.

A policy in the Mesh must map request features (e.g., header UserID=12345678 ) to a specific version label (e.g., version=v1.7 ).

Requests that do not match any condition default to the default version.

Thus, Mesh coloring works by attaching feature data to traffic, which the Mesh uses to match routing rules and forward requests to the appropriate service instances; unmatched traffic goes to the default version, achieving isolation between multiple versions.

2.1 Mesh Coloring Flow Principle

2.1.1 Istio Supported Policy Model

Istio supports traffic features such as uri , scheme , method , headers , and queryParams for routing decisions.

Full reference: Istio VirtualService documentation

2.1.2 Traffic Forwarding Implementation

Based on the policy model, the following configuration routes requests whose header contains username=brand or department=A1025 to the v1 version; otherwise, traffic goes to the default version.

<code># VirtualService traffic coloring: route based on header conditions
apiVersion: networking.istio.io/beta
kind: VirtualService
metadata:
  name: router-test-vs
spec:
  hosts:
  - router-test-vs  # target router-test service
  exportTo:
  - "."
  http:
  - match:
    - headers:
        username:
          exact: brand
    - headers:
        department:
          exact: A1025
    route:
    - destination:
        # TODO: route matching traffic to the appropriate service, e.g., ServiceA-V1
    route:
    - destination:
        # TODO: route non‑matching traffic to another service, e.g., ServiceA-V2
</code>

3 Summary

This article described how to use traffic coloring in a Mesh environment to distribute requests based on distinct features. Traffic coloring provides several practical benefits:

Supports staged releases, mitigating risks of full rollouts.

Enables colored experiments, allowing selected users to access experimental environments.

Facilitates online QA analysis, verification, debugging, and stress testing.