Alibaba Cloud Service Mesh:Integrar o ASM ao Argo Rollouts para implementar canary releases

Criar o Rollout

1. Crie um arquivo rollout.yaml com o seguinte conteúdo:

   Show rollout.yaml

   apiVersion: argoproj.io/v1alpha1
   kind: Rollout
   metadata:
     name: istio-rollout
   spec:
     revisionHistoryLimit: 2               # Number of old ReplicaSets to retain
     selector:
       matchLabels:
         app: istio-rollout
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true"  # Enable Istio sidecar injection
         labels:
           app: istio-rollout
       spec:
         containers:
         - name: istio-rollout
           image: argoproj/rollouts-demo:blue  # Initial stable version
           ports:
           - name: http
             containerPort: 8080
             protocol: TCP
           resources:
             requests:
               memory: 32Mi
               cpu: 5m
     strategy:
       canary:
         canaryService: istio-rollout-canary   # Service that targets canary pods
         stableService: istio-rollout-stable   # Service that targets stable pods
         trafficRouting:
           istio:
             virtualService:
               name: istio-rollout-vsvc        # VirtualService whose weights the controller updates
               routes:
               - primary                       # Route name inside the VirtualService
         steps:
         - setWeight: 10          # Route 10% of traffic to canary
         - pause: {}              # Wait for manual approval (kubectl argo rollouts promote)
         - setWeight: 20          # Route 20% of traffic to canary
         - pause: {duration: 20s} # Wait 20 seconds, then auto-advance
         - 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}

   Campos principais em strategy.canary:

   Campo	Descrição
   setWeight	Porcentagem de tráfego roteada para a versão canary nesta etapa
   pause: {}	Pausa indefinida até a execução de kubectl argo rollouts promote
   pause: {duration: 20s}	Pausa de 20 segundos e avanço automático para a próxima etapa

2. Implante o Rollout no cluster adicionado à sua instância do ASM:

   kubectl apply -f rollout.yaml

Criar os Services

1. Crie um arquivo service.yaml com o seguinte conteúdo:

   Ambos os Services usam o mesmo seletor ( app: istio-rollout ). O Argo Rollouts gerencia quais pods cada Service direciona durante o canary release.

   apiVersion: v1
   kind: Service
   metadata:
     name: istio-rollout-canary    # Canary Service -- Argo Rollouts maps this to canary pods
   spec:
     ports:
     - port: 80
       targetPort: http
       protocol: TCP
       name: http
     selector:
       app: istio-rollout
   
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: istio-rollout-stable    # Stable Service -- Argo Rollouts maps this to stable pods
   spec:
     ports:
     - port: 80
       targetPort: http
       protocol: TCP
       name: http
     selector:
       app: istio-rollout

2. Implante os Services:

   kubectl apply -f service.yaml

Criar o VirtualService

1. Crie um arquivo istio-rollout-vsvc.yaml com o seguinte conteúdo:

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
     name: istio-rollout-vsvc
   spec:
     gateways:
       - istio-rollout-gateway
     hosts:
       - '*'
     http:
       - match:
           - uri:
               prefix: /
         name: primary                   # Must match the route name in the Rollout
         route:
           - destination:
               host: istio-rollout-stable # All traffic goes to stable initially
             weight: 100
           - destination:
               host: istio-rollout-canary # Canary destination -- weight starts at 0

2. Implante o VirtualService:

   kubectl apply -f istio-rollout-vsvc.yaml

Criar o Gateway

1. Crie um arquivo istio-rollout-gateway.yaml com o seguinte conteúdo:

   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: istio-rollout-gateway
   spec:
     selector:
       istio: ingressgateway            # Binds to the ASM ingress gateway
     servers:
       - hosts:
           - '*'
         port:
           name: http
           number: 80                   # Accept HTTP traffic on port 80
           protocol: HTTP

2. Implante o Gateway:

   kubectl apply -f istio-rollout-gateway.yaml

kubectl argo rollouts get rollout istio-rollout

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

Atualizar a imagem do Rollout

1. Defina a nova versão da imagem:

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

2. Verifique se ambas as versões dos pods estão em execução:

   1. Faça logon no console do ACK e clique em Clusters no painel de navegação à esquerda.

   2. Clique em nome do cluster e escolha Workloads > Pods.

   3. Na coluna Name, confirme que existem pods tanto para a versão azul (estável) quanto para a amarela (canary).

   

Observar a primeira mudança de tráfego

Abra http://<ingress-gateway-ip>/ em um navegador. Cerca de 10% das grades agora exibem amarelo. O controlador do Argo Rollouts atualizou os pesos do VirtualService: o estável (azul) caiu de 100 para 90, e o canary (amarelo) aumentou de 0 para 10.

A primeira etapa especifica pause: {} sem duração, portanto, o Rollout aguarda aprovação manual antes de prosseguir.

Continuar a liberação

1. Aprove o Rollout para avançar além da pausa manual:

   kubectl argo rollouts promote istio-rollout

2. Abra http://<ingress-gateway-ip>/ em um navegador. Os pesos do VirtualService continuam a se ajustar automaticamente nas etapas restantes (20%, 30%, ... 90%), com pausas de 20 segundos entre cada etapa.

   

Verificar a liberação concluída

1. Após a conclusão de todas as etapas, abra http://<ingress-gateway-ip>/ em um navegador. Todas as grades agora exibem amarelo, confirmando que a versão canary substituiu totalmente a versão estável.

   

2. Verifique o status do Rollout: Saída esperada: A imagem agora mostra argoproj/rollouts-demo:yellow (stable), confirmando que a versão canary foi promovida.

   kubectl argo rollouts get rollout istio-rollout --watch

   Name:            istio-rollout
   Namespace:       default
   Status:           Healthy
   Strategy:        Canary
     Step:          18/18
     SetWeight:     100
     ActualWeight:  100
   Images:          argoproj/rollouts-demo:yellow (stable)
   Replicas:
     Desired:       1
     Current:       1
     Updated:       1
     Ready:         1
     Available:     1
   
   NAME                                       KIND        STATUS        AGE  INFO
   ⟳ istio-rollout                            Rollout      Healthy     48m
   ├──# revision:4
   │  └──⧉ istio-rollout-5fcf5864c4           ReplicaSet   Healthy     27m  stable
   │     └──□ istio-rollout-5fcf5864c4-vw6kh  Pod          Running     26m  ready:2/2
   ├──# revision:3
   │  └──⧉ istio-rollout-897cb5b6d            ReplicaSet  ScaledDown  27m
   └──# revision:1
      └──⧉ istio-rollout-7f96d86486           ReplicaSet  ScaledDown  48m