Location>code7788 >text

ServiceMesh 4: Enabling Traffic Coloring and Hierarchical Distribution

Popularity：899 ℃/2024-11-13 08:14:59

★ ServiceMesh Series

1 What is flow coloring

In complex production scenarios, there is often a need for multiple versions of the same service to coexist over time. In order to allow different users in different versions, it is necessary to sample and color the user requests with different markings.
This serves several purposes:

  1. Supports hierarchical release to avoid large-scale risks that may be encountered when releasing the full volume, such as system crash and user loss.
  2. Support coloring experiments to give some people priority in experiencing new releases or experimental features
  3. QA's online problem analysis, verification, debugging, and even pressure testing can be placed in the dye deployment area to do, because it is a strong isolation mode, you can avoid the impact on other users on the line!

Using the traffic coloring capability of Service Mesh, it is possible to distribute multiple versions of traffic in a single service based on feature values. This capability is especially important in giant meshes with cumbersome links, where the ability to manage up to 10 or more link diversion schedules is important. The common Canary Release, ABTesting, and Diversified Version are all based on such algorithms. This side describes how the mesh can realize traffic coloring without intruding into the business.

1. Canary Release
image

2. Diversified Version
image

3. Diversified Version
image

2 Mesh Coloring Using Label Features

Mesh needs to have several conditions if it wants to achieve traffic coloring:

  • Certain features need to be attached to the requested traffic, such as the Header, Cookies, queryParams, etc. of the traffic's request, which carry certain information.
  • Deploying multi-version services
    • Instances (pods) of services (svc) deployed on kubernetes need to be connected to the mesh and labeled with a version
    • Or create a different service (svc) and later bring traffic to this new service
  • The corresponding service on the mesh platform is paired with a policy: when the requested traffic has certain characteristics (e.g., UserID=12345678 in the header), the traffic is routed to the service instance with the corresponding label (e.g., version = v1.7).
  • Routes that do not meet the conditions go to the default version by default (e.g. version = default).

So, mesh coloring is essentially done by carrying some features (e.g., Header, Cookies, queryParams, etc. of the request of the flow) in the flow, and the mesh will route and match based on the features of these requests and forward to the corresponding service instances with certain features.
Traffic that is not successfully matched goes to the default version, thus achieving the goal of isolating multiple versions and services from the default version.

image

2.1 Mesh coloring flow principle

2.1.1 Strategy models supported by Istio

That is, Istio supports traffic features including conditions such as uri, scheme, method, headers, queryParams, etc., which can be routed and forwarded based on these features:
image

image

Refer to the official documentation for full details:/latest/docs/reference/config/networking/virtual-service/

2.1.2 Traffic forwarding implementation

Based on the above policy model, if you want to configure the following: if the header of the request has username=brand or dep=A1025, the traffic will be forwarded to the v1 version of the service, otherwise it will be forwarded to the default version.
Then the strategy code is as follows:

# Description: VirtualService traffic coloring, according to different conditions will be sent to different characteristics of the version of the traffic, assuming that this side of the default, V1, V2 versions
apiVersion: /beta
kind: VirtualService
metadata.
  name: router-test-vs
spec.
  hosts: router-test-vs # Schedule traffic to the router-test service.
  - router-test-vs # scheduling traffic for router-test service
exportTo.
- "."
http: # add various routing conditions, such as matching people and departments for routing
- match # when user matches brand and department matches A1025
  - headers.
    username.
      exact: brand
  - headers: username: exact: brand
    exact: A1025
      exact: A1025
  route.
    destination.
    # todo Matching traffic is routed to the corresponding service, e.g., ServiceA-V1.
route.
  destination.
  # todo Traffic that does not match the criteria is routed to other services, such as ServiceA-V2.

3 Summary

This paper describes the implementation of how to use traffic coloring to distribute traffic with different characteristics in a mesh scenario. Traffic coloring can have many benefits and values in our real production environment:

  1. Supports hierarchical publishing to avoid problems when publishing in full volume
  2. Support coloring experiments and get some people into the experimental environment
  3. QA's online problem analysis, validation, debugging, and even pressure testing
<Previous Next>