Tous les produits
Search
Centre de documentation

Alibaba Cloud Service Mesh:Improve stability with canary upgrades

Dernière mise à jour :Aug 11, 2026

Un déploiement canary vous permet de tester une nouvelle version d'une application en la déployant parallèlement à la version stable. Cette méthode vous aide à identifier et à corriger les problèmes tôt sans compromettre la stabilité de votre système. Cette rubrique explique comment utiliser une mise à niveau canary pour améliorer la stabilité de votre instance ASM.

Prérequis

Fonctionnement

Alibaba Cloud Service Mesh (ASM) prend en charge un modèle de mise à niveau basé sur des révisions utilisant des libellés. Cela vous permet d'effectuer une mise à niveau canary du plan de contrôle pour une meilleure stabilité et sécurité. Dans ce modèle, chaque proxy sidecar du plan de données est associé à une version spécifique du plan de contrôle, ou révision. Une nouvelle révision peut être déployée avec un risque minimal, car aucun proxy ne s'y connectera tant que vous n'aurez pas explicitement migré les charges de travail. Chaque plan de contrôle indépendant est appelé révision et identifié par le libellé istio.io/rev.

Pour prendre en charge les mises à niveau basées sur les révisions, Istio utilise un libellé istio.io/rev pour les namespaces. Ce libellé indique au plan de contrôle quelle révision utiliser pour injecter les proxys sidecar dans les charges de travail de ce namespace. Par exemple, le libellé istio.io/rev=1-23-6 instruit le plan de contrôle d'injecter le proxy sidecar de la version 1.23.6 pour les charges de travail du namespace.

Lors d'une mise à niveau canary, vous pouvez vérifier la version cible en mettant à niveau d'abord un petit sous-ensemble de services. Si la vérification échoue, vous pouvez rapidement revenir en arrière pour garantir la stabilité du service. Une fois la nouvelle version validée, vous pouvez promouvoir la version canary en tant que nouvelle version stable, mettre à niveau toutes les charges de travail via une mise à jour progressive, puis dépublier l'ancienne version pour terminer le processus de mise à niveau.

Préparatifs

Une mise à niveau canary nécessite de spécifier explicitement la version du proxy sidecar à injecter à l'aide de libellés de namespace. Vous devez donc vous assurer que votre politique d'injection est correctement configurée. Suivez ces étapes pour vérifier la configuration de votre politique d'injection.

  1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.

  2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez Data Plane Component Management > Sidecar Proxy injection.

  3. Sur la page Sidecar Proxy injection, sous Injection strategy configuration management, confirmez que The labels of the pod's namespace must meet the conditions. est défini sur Include istio-injection: enabled. Dans la section Select the pods that require sidecar injection de la page Injection policy configuration, la condition de libellé pour le namespace du pod est Contains istio-injection: enabled par défaut.

    Remarque

    Le libellé istio-injection: enabled est sémantiquement équivalent à istio.io/rev: stable. Lors d'une mise à niveau canary, le libellé istio.io/rev: stable injecte la révision stable du proxy sidecar pour les pods du namespace correspondant, tandis que le libellé istio.io/rev: canary injecte la révision canary.

    Après la mise à niveau, vous n'avez pas besoin de remplacer istio.io/rev:stable par istio-injection: enabled car ils sont sémantiquement identiques.

Étape 1 : Mettre à niveau le plan de contrôle

  1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.

  2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez ASM Instance > Upgrade Management.

  3. Sur la page Upgrade Management, cliquez sur l'onglet Canary Upgrade. Sous l'onglet Control Plane, sélectionnez une Canary version: et Create a new Server Load Balancer (CLB) instance, puis cliquez sur Confirm. Dans la boîte de dialogue Confirm upgrade?, cliquez sur OK.

    Une mise à niveau canary peut ignorer au maximum une version mineure. Dans cet exemple, l'instance ASM est en version 1.22, vous pouvez donc la mettre à niveau jusqu'à la version 1.23. Cette rubrique utilise la v1.23.6 comme exemple. Lors du déploiement de la version cible d'une mise à niveau canary, ASM crée et associe une instance Server Load Balancer (CLB) à la version cible. Si vous n'avez pas d'exigences particulières, vous pouvez utiliser les spécifications par défaut pour l'instance CLB. Pour plus d'informations sur la facturation de CLB, consultez Présentation de la facturation de CLB.

    Attendez le déploiement des composants. Une fois le déploiement terminé, la page se met à jour automatiquement.

    La barre de progression indique que le processus est à la deuxième étape, Deploy new version. Le statut de la version actuelle et de la version canary est Canary upgrading. La page indique que le nouveau plan de contrôle est déployé et vous invite à vérifier la nouvelle version. Vous pouvez cliquer sur Version switch pour poursuivre la mise à niveau ou sur Revoke upgrade pour revenir en arrière.

Étape 2 : Mettre à niveau le proxy sidecar reviews-v2****

Dans l'Étape 1, vous avez déployé un plan de contrôle Istio de version v1.23.6 à l'aide d'une mise à niveau canary. Les étapes suivantes décrivent comment vérifier cette version en mettant à jour le proxy sidecar injecté pour le service reviews-v2 de l'application Bookinfo vers la v1.23.

  1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.

  2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez ASM Instance > Global Namespace.

  3. Sur la page Global Namespace, dans la colonne Automatic Sidecar Injection, vérifiez si le libellé pour le namespace default est istio-injection: enabled.

    Si le libellé est istio-injection: enabled, cela indique que le proxy sidecar de la version 1.22 est injecté.

  4. Sur la page Global Namespace, localisez le namespace default. Dans la colonne Automatic Sidecar Injection, cliquez sur Switch to inject 1-23-6 version. Dans la boîte de dialogue Confirm, cliquez sur OK.

    Le libellé du namespace global default est modifié en istio.io/rev: canary, et le libellé du namespace default sur le plan de données est également synchronisé avec istio.io/rev: canary. La page Global Namespace indique que le proxy sidecar de la version 1.23 est injecté pour le namespace default. Les nouveaux pods créés dans le namespace default auront le proxy sidecar de la version 1.23 injecté. Les libellés des autres namespaces ne sont pas modifiés, ils continuent donc d'utiliser le proxy sidecar de la version 1.22.

    Remarque

    Les étapes précédentes décrivent comment changer la version du proxy sidecar pour un namespace dont l'injection automatique était activée avant la mise à niveau. Pour un namespace où l'injection automatique n'était pas activée, vous pouvez l'activer et sélectionner la version souhaitée du proxy sidecar. ASM ajoute le libellé istio.io/rev:stable ou istio.io/rev:canary au namespace en fonction de votre sélection.

  5. Effectuez une mise à jour progressive de la charge de travail reviews-v2.

    1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

    2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Workloads > Deployments.

    3. Sur la page Deployments, localisez reviews-v2. Dans la colonne Actions, sélectionnez More > Redeploy. Dans la boîte de dialogue Redeploy, cliquez sur OK.

  6. Sur la page Deployments, cliquez sur reviews-v2. Sous l'onglet Pods, vérifiez si le pod pour reviews-v2 a démarré avec succès après la mise à jour progressive et si le nouveau pod possède le proxy sidecar de la version 1.23 injecté.

    Le pod pour reviews-v2 démarre avec succès après la mise à jour progressive, et le proxy sidecar de la v1.23 est injecté dans le nouveau pod.

  7. Ouvrez un navigateur et accédez à la page Bookinfo pour vérifier si le trafic est routé comme prévu.

    Comme illustré dans la figure suivante, vous pouvez accéder au service reviews-v2 comme prévu. La page Bookinfo se charge correctement. La section Book Reviews affiche les avis sur les livres avec des évaluations en étoiles noires, et le coin inférieur droit de la page affiche Reviews served by: reviews-v2-5b5fdb5d7c-xxx. Cela indique que le pod reviews-v2 sert les avis et que le trafic est routé comme prévu.

Étape 3 : Revenir en arrière pour reviews-v2

Si la vérification de l'Étape 2 échoue, ou si vous devez revenir en arrière pour d'autres raisons, suivez ces étapes.

  1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.

  2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez ASM Instance > Global Namespace.

  3. Sur la page Global Namespace, localisez le namespace default. Dans la colonne Automatic Sidecar Injection, cliquez sur Switch to inject 1-22-6 version. Dans la boîte de dialogue Confirm, cliquez sur OK.

    Avant le retour en arrière, le libellé du namespace est istio.io/rev: canary, et le proxy sidecar de la version 1.23 est injecté pour le namespace default.

    Après le retour en arrière, le libellé est remplacé par istio.io/rev: stable, et le libellé du namespace default sur le plan de données est également mis à jour vers istio.io/rev: stable. Par conséquent, le proxy mesh de la version 1.22 est injecté dans le namespace default.

  4. Redéployez la charge de travail reviews-v2 dans la console ACK.

    1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

    2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Workloads > Deployments.

    3. Sur la page Deployments, sélectionnez default dans la liste déroulante Namespace. Localisez reviews-v2. Dans la colonne Actions, sélectionnez More > Redeploy. Dans la boîte de dialogue Redeploy, cliquez sur OK.

    4. Sur la page Deployments, cliquez sur reviews-v2. Sous l'onglet Pods, vérifiez si le pod pour reviews-v2 a démarré avec succès après la mise à jour progressive et si le nouveau pod possède le proxy sidecar de la version 1.22 injecté.

      Le pod pour reviews-v2 démarre avec succès après la mise à jour progressive, et le proxy sidecar de la version 1.22 est injecté dans le nouveau pod.

Étape 4 : Annuler la mise à niveau

Après un retour en arrière réussi, vous pouvez annuler la mise à niveau canary pour restaurer l'instance ASM à sa version initiale 1.22.

Important

Avant d'annuler la mise à niveau, assurez-vous que la version stable du proxy sidecar est injectée dans tous les namespaces. Sinon, l'annulation échouera.

  1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.

  2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez ASM Instance > Upgrade Management.

  3. Sur la page Upgrade Management, sous l'onglet Canary Upgrade, cliquez sur Undo upgrade. Dans la boîte de dialogue Confirm the cancellation of the upgrade?, cliquez sur OK.

    Après avoir cliqué sur Revoke upgrade, les composants du plan de contrôle canary (version 1.23 dans cet exemple) sont supprimés. Seuls les composants du plan de contrôle stable (version 1.22 dans cet exemple) sont conservés.

Étape 5 : Réessayer la mise à niveau et la vérification

À ce stade, l'instance ASM se trouve dans le même état qu'avant l'Étape 1. Cet exemple ne vérifie que les charges de travail reviews-v1, reviews-v2 et reviews-v3. Dans un scénario réel, vous devriez vérifier toutes les charges de travail nécessaires jusqu'à ce que la vérification soit réussie.

  1. Refaites l'Étape 1 pour déployer la version canary du plan de contrôle pour le cluster ASM.

  2. Refaites l'Étape 2 pour vérifier que le proxy sidecar injecté de la nouvelle version fonctionne comme prévu.

    Par exemple, redéployez les déploiements reviews-v1, reviews-v2 et reviews-v3 depuis la console ACK. Vous pouvez constater que le proxy sidecar de la version 1.23 est injecté dans les pods de reviews-v1, reviews-v2 et reviews-v3.

Étape 6 : Promouvoir la nouvelle version

Après avoir vérifié que reviews-v1, reviews-v2 et reviews-v3 fonctionnent comme prévu avec le nouveau proxy sidecar de la version 1.23, vous pouvez promouvoir la version 1.23 en tant que version stable.

Important
  • Une fois que vous avez promu la version, le processus de mise à niveau passe à l'étape de dépublication de l'ancienne version. Toutes les charges de travail doivent être basculées vers le nouveau proxy sidecar de la version 1.23, et vous ne pouvez plus annuler la mise à niveau. Assurez-vous de terminer toutes les vérifications pendant l'étape New version deployment.

  • Après avoir promu la version, ASM injectera le nouveau proxy sidecar de la version 1.23 dans les namespaces portant le libellé istio.io/rev: stable ou istio-injection: enabled. Le libellé istio.io/rev: canary ne sera plus effectif. Par conséquent, lorsque vous promouvez la version, ASM change automatiquement tous les libellés istio.io/rev: canary en istio.io/rev: stable. Confirmez ce changement lorsque vous cliquez sur Version switching sous l'onglet Canary Upgrade de la page Upgrade Management.

  1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.

  2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez ASM Instance > Upgrade Management.

  3. Sur la page Upgrade Management, sous l'onglet Canary Upgrade, cliquez sur Update Version. Dans la boîte de dialogue Confirm version switching?, lisez attentivement l'invite, puis cliquez sur OK.

    Après la promotion, les charges de travail existantes avec le proxy sidecar de la version 1.22 ne sont pas affectées. Cependant, tous les pods redéployés auront le proxy sidecar de la version 1.23 injecté. La page se met à jour une fois la promotion terminée.

    La barre de progression indique que le processus est à la troisième étape, Switch version. Le statut de la version actuelle et de la version canary est Canary upgrading. La page indique que le changement de version a réussi. Vous pouvez maintenant mettre à niveau le plan de données. À ce stade, vous pouvez cliquer sur Upgrade data plane pour continuer ou sur Unpublish old version pour finaliser la mise à niveau.

Étape 7 : Mettre à niveau le plan de données

À ce stade, la version ASM est 1.23.6. Les namespaces portant le libellé istio.io/rev=stable, istio.io/rev=1-23-6 ou istio-injection=enabled auront le proxy sidecar de la version 1.23 injecté. Vous pouvez terminer la mise à niveau du plan de données en effectuant une mise à jour progressive de vos charges de travail pour mettre à niveau leurs proxys sidecar injectés vers la nouvelle version 1.23.

  1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.

  2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez ASM Instance > Upgrade Management.

  3. Sur la page Upgrade Management, sous l'onglet Canary Upgrade, cliquez sur l'onglet Data plane pour mettre à niveau les passerelles ASM ou les charges de travail selon vos besoins.

    • Mettre à niveau une passerelle ASM : Dans la section ASM Gateways, localisez la passerelle cible. Dans la colonne Actions, cliquez sur Rolling Upgrade. Dans la boîte de dialogue Confirm to perform rolling upgrade?, cliquez sur OK pour mettre à niveau la passerelle ASM vers la nouvelle version 1.23.

    • Mettre à niveau une charge de travail : Dans la section Workload to be upgraded, sélectionnez un Namespace. Localisez la charge de travail cible. Dans la colonne Actions, cliquez sur Rolling Upgrade. Dans la boîte de dialogue Confirm to perform rolling upgrade?, cliquez sur OK pour mettre à niveau la charge de travail vers la nouvelle version 1.23.

      Remarque

      Les passerelles ASM ou les charges de travail qui ont été mises à niveau ne sont pas affichées dans la liste.

      Vous pouvez également cliquer sur Instances Status dans le volet de navigation de gauche pour afficher toutes les charges de travail ou instances de passerelle qui n'ont pas été mises à niveau.

Étape 8 : Dépublier l'ancienne version

Après avoir mis à niveau toutes les charges de travail du plan de données, vous pouvez dépublier l'ancienne version 1.22.

  1. Connectez-vous à la console ASM. Dans le volet de navigation de gauche, sélectionnez Service Mesh > Mesh Management.

  2. Sur la page Mesh Management, cliquez sur le nom de l'instance ASM. Dans le volet de navigation de gauche, sélectionnez ASM Instance > Upgrade Management.

  3. Sur la page Upgrade Management, sous l'onglet Canary Upgrade, cliquez sur Offline old version. Dans la boîte de dialogue Are you sure to offline the previous version of the Control Plane?, cliquez sur OK.