Implement blue-green and canary release with ASM - Alibaba Cloud Service Mesh

Service Mesh (ASM) découple le routage du trafic de la mise à l'échelle des pods. Vous contrôlez ainsi la répartition du trafic vers chaque version d'application par pourcentage, indépendamment du nombre de réplicas.

Ce guide présente trois stratégies de déploiement à l'aide de services virtuels et de règles de destination, avec l'application exemple Bookinfo :

Déploiement blue-green : basculez l'intégralité du trafic d'une version vers une autre en une seule étape.
Déploiement canary pondéré : répartissez le trafic entre deux versions selon un pourcentage défini.
Déploiement canary basé sur les en-têtes : acheminez des utilisateurs spécifiques vers une nouvelle version en fonction des en-têtes de requête.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

Une instance ASM. Pour plus d'informations, consultez la rubrique Créer une instance ASM
Au moins un cluster Container Service for Kubernetes (ACK) ajouté à l'instance ASM. Pour plus d'informations, consultez la rubrique Ajouter un cluster à une instance ASM
L'application Bookinfo déployée dans le cluster ACK. Pour plus d'informations, consultez la rubrique Déployer une application dans une instance ASM
Une passerelle d'entrée déployée pour le cluster ACK. Pour plus d'informations, consultez la rubrique Créer un service de passerelle d'entrée

Fonctionnement

Les règles de destination définissent des sous-ensembles nommés qui correspondent aux libellés de version de vos pods. Les services virtuels font référence à ces sous-ensembles pour contrôler la version destinataire du trafic et sa proportion.

Ce guide suit une progression réaliste :

Définissez des sous-ensembles pour toutes les versions des microservices Bookinfo (règles de destination).
Acheminez tout le trafic vers v1 (référence de base).
Déploiement blue-green : basculez le service reviews de v1 vers v2.
Déploiement canary pondéré : répartissez le trafic entre reviews v2 et v3.
Déploiement canary basé sur les en-têtes : acheminez un utilisateur spécifique vers reviews v3.

Étape 1 : Créer des règles de destination

Définissez des sous-ensembles pour chaque microservice Bookinfo afin que les services virtuels puissent y faire référence par leur nom. Pour plus d'informations, consultez la rubrique Gérer les règles de destination.

Appliquez les règles de destination suivantes à votre instance ASM :

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  subsets:
  - name: v1
    labels:
      version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ratings
spec:
  host: ratings
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v2-mysql
    labels:
      version: v2-mysql
  - name: v2-mysql-vm
    labels:
      version: v2-mysql-vm
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details
spec:
  host: details
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Vérifiez la création des règles de destination :

kubectl get destinationrules -o name

Résultat attendu :

destinationrule.networking.istio.io/productpage
destinationrule.networking.istio.io/reviews
destinationrule.networking.istio.io/ratings
destinationrule.networking.istio.io/details

Étape 2 : Acheminer tout le trafic vers v1 (référence de base)

Créez des services virtuels pour acheminer tout le trafic vers le sous-ensemble v1 de chaque microservice Bookinfo. Cela établit une référence stable avant de modifier le routage du trafic. Pour plus d'informations, consultez la rubrique Gérer les services virtuels.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage
spec:
  hosts:
  - productpage
  http:
  - route:
    - destination:
        host: productpage
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: details
spec:
  hosts:
  - details
  http:
  - route:
    - destination:
        host: details
        subset: v1

Vérifier la référence de base

Actualisez la page produit Bookinfo dans votre navigateur. La section des avis s'affiche sans notation par étoiles, car reviews v1 n'appelle pas le service ratings.

Confirmez la règle de routage :

kubectl get virtualservice reviews -o yaml

Le résultat doit afficher subset: v1 comme seule destination pour le service reviews.

À ce stade, les pods pour reviews v2 et v3 sont en cours d'exécution mais ne reçoivent aucun trafic.

Étape 3 : Déploiement blue-green — bascule vers reviews v2

Le déploiement blue-green transfère l'intégralité du trafic d'une version vers une autre en une seule étape. Mettez à jour le service virtuel reviews pour acheminer 100 % du trafic vers le sous-ensemble v2 :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2

Vérifier le déploiement blue-green

Actualisez la page produit Bookinfo. La section des avis affiche désormais des étoiles noires, confirmant que tout le trafic atteint reviews v2.

Confirmez la règle de routage :

kubectl get virtualservice reviews -o yaml

Le résultat doit afficher subset: v2 comme seule destination.

Remarque : Pour revenir en arrière, réappliquez le service virtuel de l'étape 2 qui achemine le trafic vers le sous-ensemble v1.

Étape 4 : Déploiement canary pondéré — répartition du trafic entre v2 et v3

Au lieu de basculer tout le trafic d'un coup, transférez progressivement un pourcentage vers la nouvelle version. Le service virtuel suivant répartit le trafic à parts égales (50/50) entre reviews v2 et v3 :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v2
      weight: 50
    - destination:
        host: reviews
        subset: v3
      weight: 50

Les valeurs weight contrôlent le pourcentage de trafic pour chaque version. La somme des poids doit être égale à 100.

Vérifier le déploiement canary

Actualisez plusieurs fois la page produit Bookinfo. La section des avis alterne entre des étoiles noires (v2) et des étoiles rouges (v3) avec une fréquence approximativement égale.

Remarque : Pour revenir en arrière, définissez weight: 100 sur la destination v2 et weight: 0 sur v3, ou supprimez entièrement la destination v3.

Étape 5 : Déploiement canary basé sur les en-têtes — routage par identité utilisateur

Acheminez des utilisateurs spécifiques vers la nouvelle version en fonction des en-têtes HTTP, tandis que tous les autres utilisateurs restent sur la version actuelle. Cette approche est utile pour les tests internes avant un déploiement plus large.

L'application Bookinfo transmet le nom d'utilisateur connecté via l'en-tête HTTP end-user. Le service virtuel suivant achemine l'utilisateur jason vers reviews v3 et tous les autres utilisateurs vers reviews v2 :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v3
  - route:
    - destination:
        host: reviews
        subset: v2

Vérifier le déploiement basé sur les en-têtes

Sans vous connecter, actualisez la page produit Bookinfo. La section des avis affiche des étoiles noires (v2).
Cliquez sur Sign in dans le coin supérieur droit. Saisissez jason comme nom d'utilisateur. Aucun mot de passe n'est requis.
Une fois connecté, actualisez la page. La section des avis affiche désormais des étoiles rouges (v3).

Cela fonctionne car la page produit Bookinfo inclut un en-tête end-user dans les requêtes adressées aux microservices backend. Lorsque end-user correspond à jason, le service virtuel achemine la requête vers reviews v3.

Nettoyage

Pour supprimer les règles de routage créées dans ce guide, supprimez les services virtuels et les règles de destination :

kubectl delete virtualservice productpage reviews ratings details
kubectl delete destinationrule productpage reviews ratings details

Étapes suivantes

Gérer les services virtuels : explorez les options de routage telles que l'injection de pannes et les délais d'expiration.
Gérer les règles de destination : configurez les politiques d'équilibrage de charge et les paramètres de pool de connexions pour les sous-ensembles.