Alibaba Cloud Service Mesh:Integrate ASM with Argo Rollouts to implement canary releases

Step 1: Create the Rollout and Services

Step 2: Create the Istio resources

With data-plane KubeAPI access enabled, use kubectl from the data-plane cluster to create Istio resources directly. Alternatively, use the ASM console or the control-plane kubeconfig.

Step 3: Deploy an ingress gateway

Create an ASM ingress gateway with port 80 enabled for service access.

1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.

2. On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.

3. On the Ingress Gateway page, click Create and configure the following parameters: For other parameters, see Create an ingress gateway.

   Parameter	Value
   Name	ingressgateway
   Gateway types	North-South IngressGateway
   Port Mapping	Protocol: HTTP, Service Port: 80

4. Click Create.

Step 4: Verify the initial Rollout status

Run the following command to verify that the Rollout is healthy:

kubectl argo rollouts get rollout istio-rollout

Expected output:

Name:            istio-rollout
Namespace:       default
Status:           Healthy
Strategy:        Canary
  Step:          18/18
  SetWeight:     100
  ActualWeight:  100
Images:          argoproj/rollouts-demo:blue (stable)
Replicas:
  Desired:       1
  Current:       1
  Updated:       1
  Ready:         1
  Available:     1

NAME                                       KIND        STATUS     AGE  INFO
⟳ istio-rollout                            Rollout      Healthy  52s
└──# revision:1
└──⧉ istio-rollout-7f96d86486           ReplicaSet   Healthy  52s  stable
   └──□ istio-rollout-7f96d86486-vpqvb  Pod         Running  52s  ready:2/2

A Healthy status with image argoproj/rollouts-demo:blue (stable) confirms the initial deployment succeeded.

Step 5: Test the initial deployment

1. Get the ingress gateway IP address:

   1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.

   2. Click the ASM instance name. In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.

   3. Copy the Service address of the ingress gateway.

2. Open http://<ingress-gateway-ip>/ in a browser. The page makes concurrent calls to /color and fills the grid with the returned color. Because the stable version uses the blue image and no canary is running, all grids display blue.

   

Step 6: Perform the canary release

In this example, yellow represents the canary version. As the release progresses, the grid gradually transitions from blue to yellow.

Observe the first traffic shift

Open http://<ingress-gateway-ip>/ in a browser. About 10% of the grids now display yellow. The Argo Rollouts controller updated the VirtualService weights: stable (blue) dropped from 100 to 90, and canary (yellow) increased from 0 to 10.

The first step specifies pause: {} with no duration, so the Rollout waits for manual approval before proceeding.

Step 1: Enable Prometheus in ASM

Enable Prometheus monitoring for the ASM instance. For more information, see:

• Integrate Managed Service for Prometheus to monitor ASM instances

• Monitor ASM instances by using a self-managed Prometheus instance

Step 2: Create an AnalysisTemplate

The AnalysisTemplate defines a Prometheus query that calculates the request success rate for the canary version. If the success rate drops to 0.90 or below (meaning more than 10% of requests return 5xx errors), the Rollout is marked as Degraded and automatically rolled back.

1. Create an istio-success-rate.yaml file with the following content: Replace <your-prometheus-endpoint> with the actual endpoint of your Prometheus instance connected to ASM.

   apiVersion: argoproj.io/v1alpha1
   kind: AnalysisTemplate
   metadata:
     name: istio-success-rate
   spec:
     args:
     - name: service                       # Service name, passed from the Rollout
     - name: namespace                     # Namespace, auto-resolved from the Rollout
     metrics:
     - name: success-rate
       initialDelay: 60s                   # Wait 60s for traffic to flow before first check
       interval: 20s                       # Re-evaluate every 20 seconds
       successCondition: result[0] > 0.90  # Pass if success rate > 90%; fail otherwise
       provider:
         prometheus:
           address: http://<your-prometheus-endpoint>:9090/api/v1/prometheus/
           query: >+
             sum(irate(istio_requests_total{
               reporter="source",
               destination_service=~"{{args.service}}.{{args.namespace}}.svc.cluster.local",
               response_code!~"5.*"}[40s])
             )
             /
             sum(irate(istio_requests_total{
               reporter="source",
               destination_service=~"{{args.service}}.{{args.namespace}}.svc.cluster.local"}[40s])
             )

2. Deploy the AnalysisTemplate:

   kubectl apply -f istio-success-rate.yaml

Step 3: Associate the AnalysisTemplate with the Rollout

Update the Rollout to include an analysis section that references the AnalysisTemplate. The analysis starts from the second step (startingStep: 1), giving the canary version time to receive traffic before metrics are evaluated.

1. Create a new rollout.yaml file with the following content:

   Show rollout.yaml

   apiVersion: argoproj.io/v1alpha1
   kind: Rollout
   metadata:
     name: istio-rollout
   spec:
     revisionHistoryLimit: 2
     selector:
       matchLabels:
         app: istio-rollout
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true"
         labels:
           app: istio-rollout
       spec:
         containers:
         - name: istio-rollout
           image: argoproj/rollouts-demo:yellow   # Current stable version
           ports:
           - name: http
             containerPort: 8080
             protocol: TCP
           resources:
             requests:
               memory: 32Mi
               cpu: 5m
     strategy:
       canary:
         canaryService: istio-rollout-canary
         stableService: istio-rollout-stable
         analysis:
           startingStep: 1                        # Start analysis from the second step
           templates:
           - templateName: istio-success-rate     # Reference the AnalysisTemplate
           args:
           - name: service
             value: canary
           - name: namespace
             valueFrom:
               fieldRef:
                 fieldPath: metadata.namespace    # Auto-resolve namespace
         trafficRouting:
           istio:
             virtualService:
               name: istio-rollout-vsvc
               routes:
               - primary
         steps:
         - setWeight: 10
         - pause: {}              # Wait for manual approval
         - setWeight: 20
         - pause: {duration: 20s}
         - setWeight: 30
         - pause: {duration: 20s}
         - setWeight: 40
         - pause: {duration: 20s}
         - setWeight: 50
         - pause: {duration: 20s}
         - setWeight: 60
         - pause: {duration: 20s}
         - setWeight: 70
         - pause: {duration: 20s}
         - setWeight: 80
         - pause: {duration: 20s}
         - setWeight: 90
         - pause: {duration: 20s}

2. Update the Rollout:

   kubectl apply -f rollout.yaml

Step 4: Trigger a canary release with analysis

1. Update the image to start a new canary release: Open http://<ingress-gateway-ip>/ in a browser. Orange grids begin appearing as canary traffic flows.

   kubectl argo rollouts set image istio-rollout "*=argoproj/rollouts-demo:orange"

   

2. Approve the Rollout to start the automatic canary progression with Prometheus monitoring:

   kubectl argo rollouts promote istio-rollout

3. Monitor the Rollout status:

   kubectl argo rollouts get rollout istio-rollout --watch

   

Step 5: Test automatic rollback

To test rollback behavior, increase the error rate for the canary version using the error rate slider on the demo application page. When the error rate exceeds 10% (success rate drops below 0.90), the AnalysisTemplate marks the Rollout as Degraded, and the controller automatically rolls back to the stable version (yellow).

After a short delay, all traffic returns to the stable version: