Alibaba Cloud Service Mesh:Migration progressive depuis Istio vers ASM

Étape 1 : Ajoutez le cluster à migrer à ASM

Suivez les instructions de la rubrique Add a cluster to an ASM instance. Lors de l'ajout du cluster, cochez l'option « Ignorer la vérification du namespace istio-system » pour ajouter à ASM un cluster ACK sur lequel Istio est déjà installé, ou un cluster enregistré dans ACK. Si le cluster à migrer n'est pas encore enregistré dans ACK, utilisez la fonctionnalité d'enregistrement de cluster d'ACK One pour l'enregistrer, puis ajoutez-le à ASM via la console ASM.

Une fois le cluster ajouté à ASM, la ressource ASMMigrateFromIstio est automatiquement créée dans l'instance ASM. Cette ressource pilote l'ensemble du processus de migration. Exécutez la commande suivante pour afficher son contenu.

kubectl --kubeconfig=${ASM_KUBECONFIG} get asmmigratefromistio

Résultat attendu :

apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMMigrateFromIstio
metadata:
  name: default
spec:
  desiredState: Init
  retryCounter: 0
  advancedOptions:
    stopIstioSystemInjectionDisabling: false
status:
  message: ""
  retryCounter: 0
  state: Init

Le tableau ci-dessous décrit certains champs de configuration de cette ressource.

Changement d'état de ASMMigrateFromIstio

Lorsque la préparation de la migration permet de passer à l'étape suivante, changez manuellement l'état de la ressource ASMMigrateFromIstio. Par exemple, si l'état actuel est Init, passez à SetupIstioForMigrate pour avancer dans le processus.

Voici des exemples de commandes pour passer à chaque état.

• SetupIstioForMigrate

  kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"desiredState":"SetupIstioForMigrate"}}'

• Migrating

  kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"desiredState":"Migrating"}}'

• Finished

  kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"desiredState":"Finished"}}'

Prenons l'exemple du passage à l'état SetupIstioForMigrate. Vérifiez la réussite du changement d'état comme suit.

kubectl get asmigratefromistio default -o yaml

Résultat attendu :

apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMMigrateFromIstio
metadata:
  name: default
spec:
  desiredState: SetupIstioForMigrate
  retryCounter: 0
status:
  message: ""
  retryCounter: 0
  state: SetupIstioForMigrate

Si la valeur de status.state est SetupIstioForMigrate, le changement d'état a réussi.

Configuration supplémentaire requise pour les clusters avec un gateway east-west Istio activé

Par défaut, ASM désactive l'injection automatique dans le namespace istio-system. Toutefois, les Pods du gateway east-west Istio nécessitent le remplacement manuel de leur image via MutatingWebhook, ce qui exige que l'injection ne soit pas explicitement interdite dans ce namespace. Si votre cluster utilise un gateway east-west, exécutez la commande suivante pour empêcher le plan de contrôle ASM d'interdire l'injection dans le namespace istio-system.

kubectl --kubeconfig=${ASM_KUBECONFIG} patch asmmigratefromistio default --type='merge' -p '{"spec":{"advancedOptions":{"disableIstioSystemLabelReconciliation": true}}}' 

Supprimez ensuite manuellement les labels synchronisés par ASM dans le namespace istio-system :

1. Modifiez la configuration du namespace istio-system.

   kubectl --kubeconfig=${ACK实例kubeconfig文件路径} edit ns istio-system

2. Supprimez manuellement le label istio-injection: disable, puis enregistrez et quittez.

Étape 2 : Configurez Istio pour préparer la migration

1. Passez à l'état SetupIstioForMigrate.

   Important

   Après l'exécution de cette commande, Istiod redémarre progressivement (rolling restart) pour appliquer la configuration requise par ASM en vue de la migration.

2. Pour garantir une communication mTLS correcte entre les Sidecars Istio et ASM durant la migration, ASM ajoute la configuration suivante à Istio lorsque vous entrez dans cette phase :

   defaultConfig:
     proxyMetadata:
       PROXY_CONFIG_XDS_AGENT："true"

   Redémarrez également manuellement toutes les charges de travail injectées avec un Sidecar Istio afin que cette configuration prenne effet. Utilisez la commande suivante pour vérifier si un Pod donné satisfait aux conditions requises :

   kubectl get pod ${POD名称} -o yaml|grep PROXY_CONFIG_XDS_AGENT

   Si la sortie n'est pas vide, la charge de travail est prête. Une fois que toutes les charges de travail injectées avec un Sidecar Istio du cluster satisfont à cette condition, vous pouvez passer à l'état Migrating.

Étape 3 : Démarrez la migration

Cette étape vous fait entrer dans la phase Migrating. Durant cette phase, choisissez librement d'injecter un Sidecar Istio ou un proxy de maillage ASM pour vos charges de travail, jusqu'à ce que tous les Sidecars Istio soient remplacés par des proxys ASM.

1. Passez à l'état Migrating. Une fois l'état Migrating atteint, appliquez d'abord toutes les API Istio à ASM, puis migrez séparément les Sidecars Istio, les gateways d'entrée, les gateways de sortie et les gateways east-west vers leurs composants ASM correspondants, en suivant les étapes ci-dessous.

2. (Facultatif) Déployez un gateway inter-cluster ASM.

   Dans ASM, les charges de travail injectées avec un proxy de maillage utilisent automatiquement le gateway inter-cluster ASM pour la communication inter-clusters, correspondant au gateway east-west d'Istio. Par conséquent, si vous avez activé un gateway east-west, déployez le gateway inter-cluster ASM avant d'injecter un proxy de maillage ASM dans toute charge de travail, afin de garantir la continuité de la communication inter-clusters après le remplacement des Sidecars Istio.

   Selon la configuration réseau actuelle d'Istio, définissez le nom de réseau approprié pour chaque cluster dans la console ASM et activez le gateway inter-cluster pour les clusters disposant déjà d'un gateway east-west Istio. Pour plus d'informations, consultez la rubrique Spécifier la configuration réseau d'un cluster et activer le proxy de maillage inter-cluster.

   L'activation du proxy de maillage inter-cluster entraîne la création automatique d'un service de type LoadBalancer et la facturation associée à l'instance CLB. Cliquez sur OK une fois la configuration terminée.

   Remarque

   Cette configuration doit correspondre à celle d'Istio. Par exemple, si Istio attribue network-1 au cluster a et network-2 au cluster b, ASM doit utiliser les mêmes noms.

3. Migrez les Sidecars Istio vers les proxys de maillage ASM.

   $ kubectl --kubeconfig=${K8s集群kubeconfig文件路径} -n ${命名空间} patch ${Deployment名称} --type='merge' -p '{"spec":{"template":{"metadata":{"labels":{"sidecar.asm.aliyun.com/inject":"true"}}}}}'

   Important

   Cette commande modifie les labels de la charge de travail, ce qui provoque un redémarrage progressif (rolling restart). L'impact sur le trafic dépend de la prise en charge de l'arrêt gracieux par le protocole applicatif (HTTP/HTTP2/gRPC), de la configuration correcte de l'arrêt gracieux du Sidecar Istio, et du respect par l'application des exigences d'arrêt gracieux (toutes les requêtes doivent retourner dans le délai d'attente défini). Effectuez cette opération de préférence pendant les heures creuses.

4. Migrez le gateway d'entrée Istio vers le gateway d'entrée ASM.

   Effectuez une migration sans interruption du gateway d'entrée Istio vers le gateway d'entrée ASM. Pour plus d'informations, consultez la rubrique Migrate traffic from a self-managed Istio ingress gateway to an ASM ingress gateway.

5. Migrez le gateway de sortie Istio vers le gateway de sortie ASM. Si le cluster à migrer utilise un gateway de sortie, suivez la procédure ci-dessous.

   1. Créez un gateway de sortie dans ASM. Pour plus d'informations, consultez la rubrique Create an egress gateway. Créez également les autres ressources nécessaires, telles que ServiceEntry pour enregistrer les services externes, Gateway pour activer les ports de transfert du gateway de sortie, et VirtualService pour diriger le trafic vers le gateway de sortie. Pour plus d'informations, consultez la rubrique Manage egress traffic to external services.

   2. Modifiez le VirtualService associé au service externe à migrer pour qu'il pointe vers le gateway de sortie ASM, et définissez le poids souhaité.

      Voici un exemple de configuration pour ce VirtualService. Pour l'exemple complet, consultez la page Egress gateway for HTTP traffic.

      apiVersion: networking.istio.io/v1
      kind: VirtualService
      metadata:
        name: direct-cnn-through-egress-gateway
      spec:
        hosts:
        - edition.cnn.com
        gateways:
        - istio-egressgateway
        - mesh
        http:
        - match:
          - gateways:
            - mesh
            port: 80
          route:
          - destination:
              host: istio-egressgateway.istio-system.svc.cluster.local
              port:
                number: 80
            weight: 99
          - destination: # 新增一个destination，指向出口网关，并根据需要调整其权重
              host: asm-egressgateway.istio-system.svc.cluster.local # 假设您的ASM出口网关叫asm-egressgateway
              port:
                number: 80
            weight: 1

      Dans ce YAML, le trafic destiné à edition.cnn.com est réparti selon un ratio de 99:1 entre le Ingressgateway Istio et le Egressgateway ASM. Ajustez progressivement ce ratio jusqu'à ce que tout le trafic soit migré vers le gateway de sortie ASM. Consultez les journaux d'accès du gateway de sortie Istio pour vérifier s'il reste du trafic transitant par celui-ci.

Étape 4 : Finalisez la migration

Assurez-vous que toutes les tâches suivantes sont terminées avant de passer à l'étape suivante de la migration.

• Tous les Sidecars Istio ont été entièrement supprimés.

• Aucun trafic ne transite plus par les gateways east-west, d'entrée ou de sortie Istio.

• Toutes les configurations API Istio ont été importées dans ASM.

• Le comportement des charges de travail injectées avec un proxy de maillage ASM est conforme aux attentes.

Une fois ces vérifications effectuées, désinstallez Istio du cluster à l'aide de la commande istioctl correspondant à votre version :

$ istioctl --kubeconfig=${K8s集群kubeconfig文件路径} uninstall --purge

Une fois la désinstallation terminée, passez à l'état Finished. Si le changement d'état échoue, supprimez les ressources résiduelles d'Istio selon les indications de status.message, incrémentez la valeur de spec.retryCounter de 1 pour réessayer, et répétez l'opération jusqu'à ce que status.state affiche l'état Finished. La migration est alors terminée.