Alibaba Cloud Service Mesh:Use Argo CD to implement end-to-end canary releases of application services

Create an orchestration YAML file for each application service and submit the file to GitHub. Argo CD synchronizes the orchestration YAML files in GitHub to the configured Kubernetes cluster. The following figure shows the orchestration files of the v1 and v2 versions of Service A, Service B, and Service C. For more information, see swimeline.

• The v1 folder contains the configurations of Service A, Service B, and Service C of the v1 version, routing rules for an ASM gateway, and virtual services and destination rules of these services.

• The v2 folder contains the orchestration YAML files of Deployments of Service A, Service B, and Service C of the v2 version.

The following code shows a sample YAML file in the v1 folder:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mocka-v1
  labels:
    app: mocka
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mocka
      version: v1
      ASM_TRAFFIC_TAG: v1
  template:
    metadata:
      labels:
        app: mocka
        version: v1
        ASM_TRAFFIC_TAG: v1
    spec:
      containers:
      - name: default
        image: docker.io/vifoggy/gobin:1.0.0
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mocka
        - name: upstream_url
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000

Service A, Service B, and Service C mock the same image. You can set the environment variables in Deployments to specify the content to be returned. For example, you can specify that Service A of v1 returns -> mocka(version: v1, ip: 172.30.96.123). The following information describes some parameters in the sample YAML file:

• app: the name of the application.

• version: the version number.

• upstream_url: indicates whether to send a request to an upstream service in a synchronous manner. You can leave this parameter empty or set this parameter to the URL used in the request. The preceding configuration indicates that the 8000 port of the mockb service is to be accessed.

• ASM_TRAFFIC_TAG: the name of the lane.

  Note

  The services whose YAML files are stored in the v1 folder are of the v1 version, and the ASM_TRAFFIC_TAG: v1 tag is added to template.metadata.labels in the Deployments of the services.

The Traffic labeling and label-based routing topic describes how an end-to-end canary release is implemented. The getContext method is supported in the Spec parameter of the TrafficLabel CRD. The following code shows the content of a sample YAML file:

apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
  name: example2
  namespace: workshop
spec:
  workloadSelector:
    labels:
      app: test
  rules:
  - labels:
      - name: userdefinelabel1
        valueFrom:
        - $getContext(x-request-id)
        - $localLabel
    attachTo:
    - opentracing
    protocols: "*"
  hosts:
  - "*"

If the application service is not connected to a tracing system or you do not consider connecting to a tracing system by using SDKs, you can make use of the built-in header propagation logic in the code. In this case, you need to only make sure that the x-request-id header is propagated. This logic is also used by the Bookinfo application released by the Istio community. The Bookinfo application contains the following code snippet. For more information about the source code of the Bookinfo application, see Source code of Bookinfo on GitHub.

def getForwardHeaders(request):
    headers = {}

    # x-b3-*** headers can be populated using the opentracing span
    span = get_current_span()
    carrier = {}
    tracer.inject(
        span_context=span.context,
        format=Format.HTTP_HEADERS,
        carrier=carrier)

    headers.update(carrier)

    # We handle other (non x-b3-***) headers manually
    if 'user' in session:
        headers['end-user'] = session['user']

        # Keep this in sync with the headers in details and reviews.
        incoming_headers = [
            # All applications should propagate x-request-id. This header is
            # included in access log statements and is used for consistent trace
            # sampling and log sampling decisions in Istio.
            'x-request-id',

            # Lightstep tracing header. Propagate this if you use lightstep tracing
            # in Istio (see
            # https://istio.io/latest/docs/tasks/observability/distributed-tracing/lightstep/)
            # Note: this should probably be changed to use B3 or W3C TRACE_CONTEXT.
            # Lightstep recommends using B3 or TRACE_CONTEXT and most application
            # libraries from lightstep do not support x-ot-span-context.
            'x-ot-span-context',

            # Datadog tracing header. Propagate these headers if you use Datadog
            # tracing.
            'x-datadog-trace-id',
            'x-datadog-parent-id',
            'x-datadog-sampling-priority',

            # W3C Trace Context. Compatible with OpenCensusAgent and Stackdriver Istio
            # configurations.
            'traceparent',
            'tracestate',

            # Cloud trace context. Compatible with OpenCensusAgent and Stackdriver Istio
            # configurations.
            'x-cloud-trace-context',

            # Grpc binary trace context. Compatible with OpenCensusAgent nad
            # Stackdriver Istio configurations.
            'grpc-trace-bin',

            # b3 trace headers. Compatible with Zipkin, OpenCensusAgent, and
            # Stackdriver Istio configurations. Commented out since they are
            # propagated by the OpenTracing tracer above.
            # 'x-b3-traceid',
            # 'x-b3-spanid',
            # 'x-b3-parentspanid',
            # 'x-b3-sampled',
            # 'x-b3-flags',

            # Application-specific headers to forward.
            'user-agent',

            # Context and session specific headers
            'cookie',
            'authorization',
            'jwt',
        ]
        # For Zipkin, always propagate b3 headers.
        # For Lightstep, always propagate the x-ot-span-context header.
        # For Datadog, propagate the corresponding datadog headers.
        # For OpenCensusAgent and Stackdriver configurations, you can choose any
        # set of compatible headers to propagate within your application. For
        # example, you can propagate b3 headers or W3C trace context headers with
        # the same result. This can also allow you to translate between context
        # propagation mechanisms between different applications.

        for ihdr in incoming_headers:
            val = request.headers.get(ihdr)
            if val is not None:
                headers[ihdr] = val

    return