Canary upgrade for an ASM gateway - Alibaba Cloud Service Mesh

Les passerelles ASM prennent en charge les mises à niveau Canary pour garantir une transition fluide. Cette rubrique illustre la procédure via une mise à niveau sur place d’une instance ASM : un pod est déployé avec la nouvelle version afin de valider le trafic avant la mise à niveau de l’ensemble des pods de la passerelle.

Prérequis

Instance et version ASM — Assurez-vous d’avoir ajouté un cluster à une instance ASM et que la version ASM est 1.20 ou ultérieure. Pour mettre à niveau une instance ASM, consultez la rubrique Mettre à niveau une instance ASM.
Passerelle Ingress — Assurez-vous d’avoir créé une passerelle Ingress.
Arrêt gracieux — Activez l’arrêt gracieux de la passerelle avant la mise à niveau afin de minimiser les risques de perte de trafic. Pour plus d’informations, consultez la rubrique Activer l'arrêt gracieux pour éviter la perte de trafic.
Absence de conflit de nom avec le déploiement Canary — Vérifiez qu’aucun Deployment n’existe dans le namespace de la passerelle avec un nom correspondant au nom du Deployment de la passerelle suivi du suffixe -canary. Par exemple, si la passerelle se nomme ingressgateway, assurez-vous qu’aucun Deployment nommé istio-ingressgateway-canary n’existe dans le namespace istio-system.
Accès au plan de données — Récupérez le fichier KubeConfig du plan de données pour exécuter des commandes kubectl sur le cluster du plan de données.

Fonctionnement d’une mise à niveau Canary d’une passerelle

Point d’entrée et de sortie unique du trafic des services, la passerelle doit respecter des exigences strictes de disponibilité. La mise à niveau Canary préserve la continuité des activités. Vous modifiez la configuration de la passerelle pour démarrer d’abord un pod exécutant la nouvelle version, puis vous validez le trafic sur ce pod. La mise à niveau complète de la passerelle n’intervient qu’après validation réussie. En cas de problème lors de la vérification, vous pouvez supprimer ce nouveau pod à tout moment et reprendre la mise à niveau une fois le problème résolu.

Remarque

Ne confondez pas la mise à niveau Canary d’une passerelle ASM avec celle d’une instance ASM. La mise à niveau Canary d’une passerelle ASM est disponible, que vous effectuiez une mise à niveau sur place ou une mise à niveau Canary de l’instance ASM.

Dans ASM, la mise à niveau du plan de contrôle et celle du plan de données sont distinctes. Le plan de données peut être mis à niveau une fois celle du plan de contrôle terminée.

Une mise à niveau Canary de passerelle crée un Deployment à réplica unique correspondant à la version actuelle du plan de contrôle. Ce Deployment, appelé « Canary Deployment », gère un seul pod, le « pod canary ». Le Canary Deployment appartient au même Service que le Deployment d’origine de la passerelle. La seule différence réside dans son nom, qui correspond au nom du Deployment d’origine suivi du suffixe -canary.

Important

Si un Deployment portant le même nom et le suffixe -canary existe déjà dans le namespace de la passerelle, il n’est pas écrasé.

Les deux chemins de mise à niveau d’instance ASM suivants prennent en charge la mise à niveau Canary d’une passerelle. Identifiez votre scénario avant de commencer :

Mise à niveau sur place d’une instance ASM — Une fois la mise à niveau du plan de contrôle terminée, la passerelle continue d’exécuter l’ancienne version. Suivez les étapes 1 à 4 de cette rubrique.
Mise à niveau Canary d’une instance ASM — L’étape 1 de cette rubrique ne s’applique pas. Lors de la mise à niveau Canary d’une instance ASM, après avoir basculé la nouvelle version vers le plan de contrôle par défaut, la passerelle reste en attente de mise à niveau. Passez directement à l’étape 2 pour déployer un pod canary, vérifier le trafic et mettre à niveau la passerelle une fois la validation réussie.

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

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l’instance ASM. Dans le volet de navigation de gauche, choisissez Instance Information > Upgrade Management.
Sur la page Upgrade Management, sous l’onglet In-place Upgrades, cliquez sur Perform Upgrade Precheck. Dans la boîte de dialogue Note, cliquez sur OK.

Remarque
Si la page affiche le message Currently, it is the latest version and does not need to be upgraded., le maillage de services est déjà à jour et aucune mise à niveau n’est nécessaire.
Une fois la pré-vérification réussie, cliquez sur Upgrade. Dans la boîte de dialogue Note, cliquez sur OK.

Étape 2 : Déployer un pod canary pour la passerelle ASM

Pour déployer un pod canary pour une passerelle ASM, ajoutez l’annotation asm.alibabacloud.com/enable-canary-deployment: "true" au champ annotations sous le champ metadata dans le fichier YAML de la passerelle ASM. Utilisez la console ASM ou la ligne de commande kubectl.

Méthode 1 : Utiliser la console ASM

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l’instance ASM. Dans le volet de navigation de gauche, choisissez ASM Gateways > Ingress Gateway.
Sur la page Ingress Gateway, cliquez sur View YAML à droite de la passerelle cible. Dans la boîte de dialogue Edit, ajoutez l’annotation, puis cliquez sur OK.

Méthode 2 : Utiliser la commande kubectl

Exécutez la commande suivante pour ouvrir le fichier YAML de la passerelle ASM.
```
kubectl edit IstioGateway <YOUR-INGRESSGATEWAY-NAME> -n istio-system
```
Modifiez le fichier YAML pour ajouter l’annotation, puis enregistrez-le.

L’extrait YAML suivant présente une configuration de passerelle ASM avec l’annotation ajoutée. Le résultat est identique quelle que soit la méthode utilisée.

apiVersion: istio.alibabacloud.com/v1beta1
kind: IstioGateway
metadata:
  labels:
    asm-gateway-type: ingress
  annotations:
    asm.alibabacloud.com/enable-canary-deployment: "true"  # Add this annotation.
  name: ingressgateway
  namespace: istio-system
spec:
  clusterIds:
    - xxxxxxxxxxxxxx
  disableContainerPortExposed: true
  dnsPolicy: ClusterFirst
  externalTrafficPolicy: Local
  gatewayType: ingress
  ports:
    - name: http-0
      port: 80
      protocol: HTTP
      targetPort: 80
  replicaCount: 1
  resources:
    limits:
      cpu: '2'
      memory: 4G
    requests:
      cpu: 200m
      memory: 256Mi
  rollingMaxSurge: 25%
  rollingMaxUnavailable: 25%
  serviceAnnotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain: 'on'
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-connection-drain-timeout: '10'
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-instance-charge-type: PayByCLCU
    service.beta.kubernetes.io/alicloud-loadbalancer-address-type: internet
  serviceType: LoadBalancer

Vérifier le pod canary et son trafic

Suivez les étapes ci-dessous, quelle que soit la méthode utilisée pour ajouter l’annotation.

Utilisez le fichier KubeConfig du plan de données pour exécuter la commande suivante et afficher le Canary Deployment déployé. Dans cet exemple, le nom de la passerelle est ingressgateway. Adaptez-le à votre environnement.
```
kubectl -n istio-system get deployment | grep ingressgateway
```
Sortie attendue :
```
istio-ingressgateway                1/1     1            1           10m
istio-ingressgateway-canary         1/1     1            1           55s
```
Le Deployment avec le suffixe -canary est le Canary Deployment. Attendez que le nombre de réplicas prêts atteigne 1/1, comme indiqué dans la sortie précédente.
Une fois le pod canary prêt, une partie du trafic est acheminée vers celui-ci. Vérifiez que le trafic atteignant la passerelle est normal.

Si le trafic est normal, passez à l’étape 3 pour mettre à niveau la passerelle. Sinon, effectuez un rollback du pod canary comme décrit dans la section suivante.

Effectuer un rollback en cas d’échec de la vérification

Si le trafic atteignant la passerelle est anormal, procédez comme suit :

Sauvegardez les journaux de la passerelle.
Supprimez l’annotation asm.alibabacloud.com/enable-canary-deployment: "true" que vous avez configurée. Le pod canary est supprimé et tout le trafic est acheminé vers les pods de la passerelle exécutant l’ancienne version.
Une fois le problème résolu, ajoutez à nouveau l’annotation pour redéployer le pod canary, puis vérifiez à nouveau le trafic.

Étape 3 : Mettre à niveau la passerelle après la réussite de la vérification

Connectez-vous à la console ASM. Dans le volet de navigation de gauche, choisissez Service Mesh > Mesh Management.
Sur la page Mesh Management, cliquez sur le nom de l’instance ASM. Dans le volet de navigation de gauche, choisissez Instance Information > Upgrade Management.
Dans la section Data Plane, dans la colonne Upgrade, sélectionnez la passerelle cible et cliquez sur Upgrade Gateway. Dans la boîte de dialogue Note, cliquez sur OK et attendez la fin de la mise à niveau de la passerelle.

Étape 4 : Supprimer le pod canary

Une fois la mise à niveau de la passerelle terminée, supprimez l’annotation ajoutée à l’étape 2. Le pod canary est automatiquement supprimé. Pour confirmer le résultat, affichez à nouveau les Deployments dans le namespace de la passerelle et vérifiez que le Deployment avec le suffixe -canary n’existe plus.

Important

Le pod canary suit toujours la version du plan de contrôle. Si vous ne le supprimez pas, il sera mis à niveau conjointement avec le plan de contrôle lors de la prochaine mise à niveau de ce dernier.