La migration d'Istio vers Anthos Service Mesh nécessite une certaine planification. Cette page fournit des informations pour vous aider à préparer votre migration.
Examiner les profils
Les profils de configuration fournis par Anthos Service Mesh sont différents de ceux d'Istio Open Source. Lorsque vous installez Anthos Service Mesh, vous utilisez un profil de configuration adapté à votre environnement :
asm-gcp: utilisez ce profil pour les installations sur GKE pour un maillage contenant un seul cluster ou plusieurs clusters se trouvant dans le même projet Google Cloud.asm-gcp-multiprojectbêta: utilisez ce profil pour les installations sur GKE avec des clusters dans différents projets Google Cloud.asm-multicloud: utilisez ce profil pour les installations dans les environnements suivants :- GKE sur VMware
- GKE sur AWS
- Amazon Elastic Kubernetes Service (Amazon EKS)
- Microsoft Azure Kubernetes Service (Microsoft AKS)
Les fonctionnalités Anthos Service Mesh compatibles diffèrent selon les profils. Consultez les fonctionnalités compatibles pour le profil qui correspond à votre configuration.
Comparer des profils
Vous pouvez comparer le profil de configuration que vous avez utilisé pour installer Istio avec le profil Anthos Service Mesh que vous prévoyez d'utiliser :
Suivez les étapes de la section Télécharger le fichier d'installation pour télécharger les fichiers d'installation et de signature, extraire le contenu et définir le chemin d'accès à la version de
istioctlà partir du fichier de téléchargement.Générez un fichier manifeste pour le profil Anthos Service Mesh que vous prévoyez d'utiliser :
istioctl manifest generate -f manifests/profiles/ASM_PROFLE > a.yaml
Recherchez le profil que vous avez utilisé pour installer Istio. Étant donné que les profils peuvent changer entre les versions d'Istio, vous devez disposer du profil du package d'installation correspondant à votre version d'Istio.
Générez un fichier manifeste pour le profil que vous avez utilisé pour installer Istio :
istioctl manifest generate -f ISTIO_PROFILE > b.yaml
Comparez les fichiers manifestes :
istioctl manifest diff a.yaml b.yaml
Préparer les fichiers de configuration
Si vous avez personnalisé l'installation d'Istio, vous avez besoin des mêmes personnalisations lors de la migration vers Anthos Service Mesh. Si vous avez personnalisé l'installation en ajoutant l'option --set values, nous vous recommandons d'ajouter ces paramètres à un fichier de configuration IstioOperator. Vous spécifiez le fichier de configuration à l'aide de l'option -f avec le fichier de configuration lorsque vous exécutez la commande istioctl install.
Choisir une autorité de certification
Vous pouvez continuer à utiliser Citadel (désormais intégré dans istiod) en tant qu'autorité de certification (CA) pour émettre des certificats TLS mutuel (mTLS), ou vous pouvez choisir de migrer vers l'autorité de certification Anthos Service Mesh (CA).
Nous vous recommandons généralement d'utiliser Mesh CA pour les raisons suivantes :
- Mesh CA est un service hautement fiable et évolutif, optimisé pour les charges de travail à scaling dynamique sur Google Cloud.
- Avec Mesh CA, Google gère la sécurité et la disponibilité du backend CA.
- Mesh CA vous permet de dépendre d'une seule racine de confiance dans les clusters.
Vous pouvez cependant envisager d'utiliser Citadel dans certains cas :
- Si vous disposez d'une autorité de certification personnalisée.
- Vous ne pouvez pas planifier un temps d'arrêt pour la migration vers l'autorité de certification Mesh. Même si nous vous recommandons d'utiliser l'autorité de certification Mesh, vous devez planifier le temps d'arrêt de la migration, car le trafic mTLS échoue jusqu'à ce que tous les pods soient redémarrés dans tous les espaces de noms.
Vérifier le processus de migration
Pour effectuer une migration depuis Istio, suivez le processus de mise à niveau du plan de contrôle double (appelé "mises à niveau Canary" dans la documentation d'Istio). Avec une mise à niveau du plan de contrôle double, vous installez une nouvelle version du plan de contrôle à côté du plan de contrôle existant. Lors de l'installation de la nouvelle version, vous incluez le libellé revision qui identifie la version du nouveau plan de contrôle. Chaque révision est une mise en œuvre complète du plan de contrôle d'Anthos Service Mesh avec ses propres déploiement et service.
Vous effectuez ensuite une migration vers la nouvelle version en définissant le même libellé revision sur vos charges de travail de sorte qu'il pointe vers le nouveau plan de contrôle et en effectuant un redémarrage progressif pour réinjecter les proxys avec la nouvelle version d'Anthos Service Mesh. Avec cette approche, vous pouvez surveiller l'effet de la mise à niveau sur un petit pourcentage de vos charges de travail. Après avoir testé votre application, vous pouvez migrer tout le trafic vers la nouvelle version. Cette approche est beaucoup plus sûre qu'une mise à niveau sur place, où un nouveau plan de contrôle remplace immédiatement la version précédente.
À moins que vous n'ayez configuré un équilibreur de charge ou un routeur pour les déploiements bleu-vert, nous vous recommandons de tester la migration et le redémarrage des pods dans un environnement de préproduction pour vérifier que vos services peut gérer toute interruption de trafic potentielle.