Microservices Engine (MSE) fournit un outil de migration graphique qui transfère le trafic d'une passerelle NGINX Ingress autogérée vers une passerelle cloud-native MSE sans interruption de service.
Fonctionnement
La passerelle cloud-native MSE ne copie pas vos configurations Ingress : elle les écoute directement. Pendant la migration, NGINX Ingress Controller et la passerelle MSE Ingress surveillent simultanément les mêmes ressources Ingress en temps réel. Le trafic bascule progressivement selon des pondérations définies. Vous pouvez revenir en arrière à tout moment avant la fin de la migration.
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
Un cluster ACK, un cluster ACK Serverless ou un cluster ACS avec NGINX Ingress Controller déployé
Une passerelle cloud-native MSE en version V1.2.22 ou ultérieure. Consultez Créer une passerelle cloud-native
La passerelle cloud-native MSE et le cluster doivent se trouver dans le même Virtual Private Cloud (VPC)
Remarques d'utilisation
Après la migration, conservez toutes les configurations NGINX Ingress actuellement utilisées ; ne les supprimez pas. La passerelle MSE Ingress écoute et analyse ces configurations.
Une fois la migration terminée, toutes les configurations Ingress (existantes et nouvelles) doivent rester associées à la classe Ingress NGINX. Par exemple, si
ingressClassNameest défini surnginx, ce paramètre reste inchangé.
Choisir une méthode de basculement du trafic
Deux méthodes de basculement du trafic sont disponibles. Choisissez-en une avant de lancer la migration :
| Méthode | Fonctionnement | Cas d'usage recommandé |
|---|---|---|
| Réutiliser le SLB du cluster d'origine | Ajoutez la passerelle MSE au groupe de serveurs virtuels backend de l'instance SLB. L'instance SLB répartit le trafic entre NGINX et MSE selon des pondérations. | Clusters dont l'instance SLB est gérée par le service Kubernetes |
| Résolution DNS vers le SLB | Mettez à jour les enregistrements DNS pour mapper les noms de domaine à l'adresse IP du SLB de la passerelle MSE. Transférez le trafic progressivement via des pondérations DNS. | Scénarios privilégiant un contrôle du trafic au niveau DNS |
Flux de travail de migration
La migration comprend cinq étapes :
Migrer les règles de routage
Vérifier la compatibilité des routes
Sélectionner une méthode de basculement du trafic
Basculer le trafic
Terminer la migration
Étape 1 : Migrer les règles de routage
Connectez-vous à la console MSE. Dans la barre de navigation supérieure, sélectionnez une région.
Dans le volet de navigation de gauche, choisissez Cloud-native Gateway > Migration to Cloud.
Sur la page Migration to Cloud, cliquez sur Add Task.
-
Dans le panneau Create Migration Configuration, configurez les paramètres.
ImportantSi la passerelle cloud-native MSE est déjà associée au cluster et que l'écoute Ingress est activée, la classe Ingress source configurée ici doit correspondre à la classe Ingress existante de ce cluster. Toute incompatibilité bloque la migration.
Paramètre Description Cloud-native Gateway Passerelle cloud-native MSE cible de la migration. La version doit être V1.2.22 ou ultérieure. ACK Managed Cluster/ACK Serverless Cluster/ACS Cluster Cluster où NGINX Ingress Controller est déployé. La passerelle MSE et ce cluster doivent se trouver dans le même VPC. Source Ingress class Classe Ingress associée aux ressources Ingress à migrer. Une seule classe Ingress est prise en charge. Si ce champ est laissé vide, la passerelle MSE écoute toutes les ressources Ingress du cluster. 
Cliquez sur Next.
Après avoir cliqué sur Next, la passerelle cloud-native MSE écoute automatiquement toutes les ressources Ingress associées à la classe Ingress source configurée. Les noms de domaine et les routes de ces ressources Ingress sont synchronisés vers la passerelle. Vérifiez dans la console MSE que vos ressources Ingress apparaissent bien et que leurs noms de domaine ainsi que leurs routes sont générés correctement.
Étape 2 : Vérifier la compatibilité des routes
La console MSE vérifie si les annotations de vos ressources Ingress sont compatibles avec la passerelle cloud-native.
-
Si toutes les annotations sont compatibles, passez à l'étape 3.
Si une annotation est incompatible, soumettez un ticket pour obtenir de l'aide.
L'annotationnginx.ingress.kubernetes.io/service-weightayant une valeur de chaîne vide ("") peut être ignorée. Elle est ajoutée par défaut dans les anciennes versions de la console ACK et n'a aucun effet.
Ne supprimez pas les annotations incompatibles pendant la migration. NGINX Ingress Controller continue d'analyser ces annotations et de les appliquer à votre trafic. Pour reproduire le même comportement sur la passerelle MSE Ingress, ajoutez les annotations étendues MSE équivalentes à vos ressources Ingress. Une fois tout le trafic dirigé vers la passerelle MSE, retirez les annotations incompatibles selon vos besoins.
Étape 3 : Sélectionner une méthode de basculement du trafic
Avant de basculer le trafic, testez la passerelle MSE localement :
Modifiez votre fichier hosts local pour mapper l'adresse IP de l'instance SLB (associée à la passerelle cloud-native MSE) aux noms de domaine concernés.
Utilisez curl ou Postman pour vérifier que le trafic est routé comme prévu.
Sélectionnez ensuite l'une des deux méthodes de basculement du trafic décrites dans Choisir une méthode de basculement du trafic.
Si vous choisissez Reuse original cluster SLB, configurez les paramètres suivants :
| Paramètre | Description |
|---|---|
| ACK Cluster Namespace | Namespace du service Kubernetes correspondant à l'instance SLB associée à la passerelle NGINX Ingress. |
| ACK Cluster SLB Service | Nom du service Kubernetes correspondant à l'instance SLB associée à la passerelle NGINX Ingress. |
| SLB ID | ID de l'instance SLB dont vous souhaitez basculer le trafic. |
| Ports and Backend Servers | Port d'écoute de l'instance SLB et protocole de la passerelle (HTTP ou HTTPS). Après avoir sélectionné le port et le protocole, le groupe de serveurs virtuels s'affiche automatiquement. Assurez-vous que le port et le protocole choisis sont valides, faute de quoi une perte de trafic peut survenir. |
Étape 4 : Basculer le trafic
Réutiliser le SLB du cluster d'origine
La méthode basée sur le SLB transfère le trafic en ajustant les pondérations du groupe de serveurs virtuels de l'instance SLB. Suivez ces quatre sous-étapes dans l'ordre.
Sous-étape 1 : Modifier la configuration du SLB
Cliquez sur Change SLB. Cette action retire l'instance SLB de la gestion du cluster et remplace l'algorithme de planification de l'écouteur par un round-robin pondéré.
Après avoir cliqué sur Change SLB, l'instance SLB ne détecte plus les changements d'adresse IP des pods dans NGINX Ingress Controller. Exécutez immédiatement la sous-étape 2 pour réassocier le service Kubernetes à l'instance SLB.
Sous-étape 2 : Remplacer les annotations du service
Connectez-vous à la console ACK.
Localisez le service Kubernetes spécifié lors de la sélection de Reuse Original Cluster SLB.
Supprimez toutes les annotations existantes de ce service.
Copiez les annotations générées automatiquement dans l'onglet Switch Traffic et appliquez-les au service Kubernetes. Cette étape réassocie le service à l'instance SLB.
Cliquez sur Pre-check. Attendez que la vérification réussisse avant de continuer.
Si des pods du même cluster accèdent à la passerelle NGINX Ingress, ajoutez l'annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname: mse-ingress-migration au service Kubernetes. Avant d'ajouter cette annotation, assurez-vous que le contrôle d'accès basé sur l'adresse IP n'est pas activé sur l'instance SLB. Cela force les pods du cluster à accéder à la passerelle NGINX Ingress via l'instance SLB et désactive le contournement de l'instance SLB par kube-proxy.
Sous-étape 3 : Transférer le trafic par pondération
Définissez la pondération pour le trafic routé vers la passerelle cloud-native MSE. La plage valide est de 1 à 100.
Fonctionnement des pondérations :
La pondération définie correspond au poids total réparti sur tous les nœuds de la passerelle MSE. Le poids total par défaut de tous les nœuds de la passerelle NGINX Ingress est de 100. L'instance SLB répartit le trafic proportionnellement :
| Pondération de la passerelle MSE | Trafic vers la passerelle MSE |
|---|---|
| 100 | 50 % (100 sur un total de 200) |
| 50 | 33 % (50 sur un total de 150) |
| 0 | 0 % (retour arrière) |
Commencez avec une valeur comprise entre 1 et 10 pour le transfert initial.
Surveillance et ajustement des pondérations :
Surveillez l'état de santé et les métriques métier de la passerelle MSE sur le tableau de bord de la console MSE.
Si les métriques correspondent aux attentes, augmentez progressivement la pondération. Les modifications de pondération prennent effet de manière asynchrone ; patientez au moins 3 minutes entre chaque ajustement.
Si les métriques ne correspondent pas aux attentes, ramenez la pondération à 0 pour empêcher le trafic d'atteindre la passerelle MSE.
Pour augmenter le trafic vers la passerelle MSE, diminuez également la valeur de l'annotation
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weightsur le service Kubernetes. Définir cette annotation à 0 route tout le trafic du SLB vers la passerelle MSE.
Le SLB fonctionne au niveau de la couche 4 en utilisant une limitation au niveau des connexions. Les pondérations contrôlent la répartition des connexions, et non celle des requêtes individuelles ; les proportions sont donc approximatives.
Restez à cette étape jusqu'à confirmation du bon comportement du trafic et tant qu'un retour arrière peut être nécessaire. Une fois que vous avez cliqué sur Complete Traffic Verification, vous ne pouvez plus modifier les pondérations.
Sous-étape 4 : Basculer tout le trafic vers la passerelle MSE
Dans la console ACK, définissez l'annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight du service Kubernetes sur 0, ou supprimez entièrement le service Kubernetes. NGINX Ingress Controller est alors automatiquement retiré de l'instance SLB, et tout le trafic est routé vers la passerelle cloud-native MSE.
Cliquez sur Complete Migration pour terminer.
Résolution DNS vers le SLB
Dans la console de gestion de votre fournisseur DNS, ajoutez des enregistrements mappant tous les noms de domaine concernés par la migration à l'adresse IP de l'instance SLB associée à la passerelle cloud-native MSE. Transférez le trafic progressivement en ajustant les valeurs de pondération DNS.
Retour arrière
Si le trafic présente un comportement inattendu, revenez immédiatement en arrière :
Réutiliser le SLB du cluster d'origine : Définissez la pondération de la passerelle MSE sur
0.Résolution DNS vers le SLB : Supprimez les enregistrements DNS qui mappent les noms de domaine métier à l'adresse IP du SLB de la passerelle MSE.
Étape 5 : Terminer la migration
Réutiliser le SLB du cluster d'origine
Assurez-vous que tout le trafic du SLB est routé vers la passerelle cloud-native MSE. Ensuite, selon vos besoins, supprimez le service Kubernetes et NGINX Ingress Controller.
Résolution DNS vers le SLB
Vérifiez que tous les noms de domaine sont résolus vers l'adresse IP du SLB associée à la passerelle cloud-native MSE. Ensuite, selon vos besoins, supprimez le service Kubernetes et NGINX Ingress Controller.
FAQ
Je vois l'erreur mse.backend.gw.MIGRATE_INGRESS_CLASS_CONFLICT. Comment la corriger ?
Cette erreur indique que la passerelle cloud-native MSE est déjà associée à votre cluster et que l'écoute Ingress est activée, mais la classe Ingress configurée pour l'écoute ne correspond pas à la classe Ingress source que vous tentez de migrer.
Pour résoudre ce problème, mettez à jour la configuration de la classe Ingress :
Si vous utilisez la ressource
MseIngressConfigpour gérer les MSE Ingresses, suivez les étapes décrites dans Utiliser les MSE Ingresses pour accéder aux applications dans les clusters ACK.Sinon, mettez à jour les paramètres d'écoute Ingress du cluster directement dans la console MSE.
Je vois l'erreur mse.backend.gw.MIGRATE_SERVICE_ANNOTATION_NOT_MATCH [annotation is not expected]. Comment la corriger ?
Ce problème survient lorsque l'annotation du service Kubernetes ne correspond pas à la valeur attendue.
Je vois l'erreur mse.backend.gw.MIGRATE_SERVICE_NOT_MATCH [weight hasn't be 0 or service hasn't been deleted]. Comment la corriger ?
La migration ne peut pas se terminer car le service Kubernetes reçoit encore du trafic. Dans la console ACK, définissez l'annotation service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight du service Kubernetes sur 0, ou supprimez le service Kubernetes.