Cette page fait partie d'un guide de plusieurs pages qui explique comment migrer d'Istio vers la version 1.7.8 d'Anthos Service Mesh sur un cluster GKE pour un maillage contenant plusieurs clusters qui se trouvent dans des projets Google Cloud différents. Pour les migrations sur un réseau maillé à un seul cluster ou pour un maillage contenant plusieurs clusters dans le même projet Google Cloud, consultez la page Installation, migration et mise à niveau pour GKE.
Avant de commencer
Avant d'installer Anthos Service Mesh, assurez-vous de disposer des éléments suivants :
- Configurez votre environnement pour installer les outils dont vous avez besoin.
- Configurez votre projet pour activer les API requises et définir les autorisations.
- Configurez votre cluster pour activer les options de cluster requises.
- Consultez la page Préparer la migration depuis Istio.
Définir des identifiants et des autorisations
Initialisez votre projet afin de le préparer pour l'installation. Cette commande crée, entre autres, un compte de service pour permettre aux composants du plan de contrôle, tels que le proxy side-car, d'accéder en toute sécurité aux données et aux ressources du projet :
curl --request POST \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --data '' \ "https://meshconfig.googleapis.com/v1alpha1/projects/${PROJECT_ID}:initialize"
La commande renvoie des accolades vides :
{}
.Obtenez des identifiants d'authentification pour interagir avec le cluster : Cette commande définit également le contexte actuel de
kubectl
sur le cluster.gcloud container clusters get-credentials ${CLUSTER_NAME} \ --project=${PROJECT_ID}
Accordez des autorisations d'administrateur de cluster à l'utilisateur actuel. Vous avez besoin de ces autorisations pour créer les règles de contrôle d'accès basé sur les rôles (RBAC) nécessaires pour Anthos Service Mesh :
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole=cluster-admin \ --user="$(gcloud config get-value core/account)"
Si l'erreur "cluster-admin-binding" already exists
s'affiche, vous pouvez l'ignorer en toute sécurité et poursuivre avec le cluster-admin-binding existant.
Télécharger le fichier d'installation
-
Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-linux-amd64.tar.gz
-
Téléchargez le fichier de signature et utilisez
openssl
pour valider la signature :curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-linux-amd64.tar.gz.1.sig openssl dgst -verify /dev/stdin -signature istio-1.7.8-asm.10-linux-amd64.tar.gz.1.sig istio-1.7.8-asm.10-linux-amd64.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
Extrayez le contenu du fichier vers n’importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
tar xzf istio-1.7.8-asm.10-linux-amd64.tar.gz
La commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé
istio-1.7.8-asm.10
, et qui contient les éléments suivants:- Des exemples d'applications dans le répertoire
samples
- L'outil de ligne de commande
istioctl
que vous utilisez pour installer Anthos Service Mesh se trouve dans le répertoirebin
. - Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire
manifests/profiles
- Des exemples d'applications dans le répertoire
-
Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-osx.tar.gz
-
Téléchargez le fichier de signature et utilisez
openssl
pour valider la signature :curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-osx.tar.gz.1.sig openssl dgst -sha256 -verify /dev/stdin -signature istio-1.7.8-asm.10-osx.tar.gz.1.sig istio-1.7.8-asm.10-osx.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
Extrayez le contenu du fichier vers n’importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
tar xzf istio-1.7.8-asm.10-osx.tar.gz
La commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé
istio-1.7.8-asm.10
, et qui contient les éléments suivants:- Des exemples d'applications dans le répertoire
samples
- L'outil de ligne de commande
istioctl
que vous utilisez pour installer Anthos Service Mesh se trouve dans le répertoirebin
. - Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire
manifests/profiles
- Des exemples d'applications dans le répertoire
-
Téléchargez le fichier d'installation d'Anthos Service Mesh dans votre répertoire de travail actuel :
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-win.zip
-
Téléchargez le fichier de signature et utilisez
openssl
pour valider la signature :curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.7.8-asm.10-win.zip.1.sig openssl dgst -verify - -signature istio-1.7.8-asm.10-win.zip.1.sig istio-1.7.8-asm.10-win.zip <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
La sortie attendue est
Verified OK
. -
Extrayez le contenu du fichier vers n’importe quel emplacement de votre système de fichiers. Par exemple, pour extraire le contenu vers le répertoire de travail actuel :
tar xzf istio-1.7.8-asm.10-win.zip
La commande crée un répertoire d'installation dans votre répertoire de travail actuel, nommé
istio-1.7.8-asm.10
, et qui contient les éléments suivants:- Des exemples d'applications dans le répertoire
samples
- L'outil de ligne de commande
istioctl
que vous utilisez pour installer Anthos Service Mesh se trouve dans le répertoirebin
. - Les profils de configuration d'Anthos Service Mesh qui se trouvent dans le répertoire
manifests/profiles
- Des exemples d'applications dans le répertoire
-
Assurez-vous d'être dans le répertoire racine de l'installation Anthos Service Mesh.
cd istio-1.7.8-asm.10
-
Pour plus de commodité, ajoutez les outils du répertoire
/bin
à votre variable PATH :export PATH=$PWD/bin:$PATH
Linux
macOS
Windows
Préparer les fichiers de configuration des ressources
Lorsque vous exécutez la commande istioctl install
, vous spécifiez -f istio-operator.yaml
sur la ligne de commande. Ce fichier contient des informations sur le projet et le cluster requis par Anthos Service Mesh. Vous devez télécharger un package contenant istio-operator.yaml
et d'autres fichiers de configuration des ressources afin de pouvoir définir les informations sur le projet et le cluster.
Pour préparer les fichiers de configuration des ressources, procédez comme suit :
Mesh CA
Créez un répertoire pour les fichiers de configuration des ressources du package Anthos Service Mesh. Nous vous recommandons d'utiliser le nom du cluster comme nom de répertoire.
Accédez au répertoire dans lequel vous souhaitez télécharger le package Anthos Service Mesh.
Téléchargez le package :
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.7-asm asm
Définissez l'ID du projet dans lequel le cluster a été créé :
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
Définissez le numéro de projet du projet hôte du parc :
kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
Définissez le nom du cluster :
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
Définissez la zone ou la région par défaut :
kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
Définissez le tag sur la version d'Anthos Service Mesh que vous installez :
kpt cfg set asm anthos.servicemesh.tag 1.7.8-asm.10
Définissez le webhook de validation pour utiliser un libellé de révision :
kpt cfg set asm anthos.servicemesh.rev asm-178-10
Lorsque vous installez Anthos Service Mesh, vous définissez un libellé de révision sur
istiod
. Vous devez définir la même révision sur le webhook de validation.Comme les clusters de votre configuration multicluster se trouvent dans différents projets, vous devez configurer les alias de domaine de confiance pour les autres projets qui forment les maillages de services multi-clusters/multiprojets.
Obtenez l'ID de projet de tous les clusters qui se trouveront dans le maillage multicluster/multiprojet.
Pour l'ID de projet de chaque cluster, définissez les alias de domaine de confiance. Par exemple, si vous avez des clusters dans trois projets, exécutez la commande suivante en remplaçant
PROJECT_ID_1
,PROJECT_ID_2
etPROJECT_ID_3
par l'ID de projet de chaque cluster.kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog
Lorsque vous configurez les clusters dans les autres projets, vous pouvez exécuter la même commande.
Les alias de domaine de confiance permettent à Mesh CA d'authentifier les charges de travail sur les clusters d'autres projets. En plus de définir les alias de domaine de confiance, vous devez activer l'équilibrage de charge interclusters après avoir installé Anthos Service Mesh.
Affichez les valeurs des setters
kpt
:kpt cfg list-setters asm
La sortie de la commande ressemble à ceci :
NAME VALUE anthos.servicemesh.canonicalServiceHub gcr.io/gke-release/asm/canonical-service-controller:1.7.8-asm.10 anthos.servicemesh.controlplane.monitoring.enabled true anthos.servicemesh.hub gcr.io/gke-release/asm anthos.servicemesh.hubMembershipID MEMBERSHIP_ID anthos.servicemesh.tag 1.7.8-asm.10 anthos.servicemesh.trustDomainAliases [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog] base-dir base gcloud.compute.location us-central gcloud.compute.network default gcloud.compute.subnetwork default gcloud.container.cluster example-cluster-1 gcloud.container.cluster.clusterSecondaryRange gcloud.container.cluster.releaseChannel REGULAR gcloud.container.cluster.servicesSecondaryRange gcloud.container.nodepool.max-nodes 4 gcloud.core.project example-project-12345 gcloud.project.environProjectID FLEET_PROJECT_ID gcloud.project.environProjectNumber 1234567890123 gcloud.project.projectNumber 9876543210987
Vérifiez que les valeurs pour les setters suivantes sont correctes :
- anthos.servicemesh.rev
- anthos.servicemesh.tag
- anthos.servicemesh.trustDomainAliases
- gcloud.compute.location
- gcloud.container.cluster
- gcloud.core.project
- gcloud.project.environProjectNumber
Vous pouvez ignorer les valeurs des autres setters.
Citadel
Créez un répertoire pour les fichiers de configuration des ressources du package Anthos Service Mesh. Nous vous recommandons d'utiliser le nom du cluster comme nom de répertoire.
Accédez au répertoire dans lequel vous souhaitez télécharger le package Anthos Service Mesh.
Téléchargez le package :
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.7-asm asm
Définissez l'ID du projet dans lequel le cluster a été créé :
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
Définissez le numéro de projet du projet hôte du parc :
kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
Définissez le nom du cluster :
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
Définissez la zone ou la région par défaut :
kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
Définissez le tag sur la version d'Anthos Service Mesh que vous installez :
kpt cfg set asm anthos.servicemesh.tag 1.7.8-asm.10
Définissez le webhook de validation pour utiliser un libellé de révision :
kpt cfg set asm anthos.servicemesh.rev asm-178-10
Affichez les valeurs des setters
kpt
:kpt cfg list-setters asm
La sortie de la commande ressemble à ceci :
NAME VALUE anthos.servicemesh.canonicalServiceHub gcr.io/gke-release/asm/canonical-service-controller:1.7.8-asm.10 anthos.servicemesh.controlplane.monitoring.enabled true anthos.servicemesh.hub gcr.io/gke-release/asm anthos.servicemesh.hubMembershipID MEMBERSHIP_ID anthos.servicemesh.tag 1.7.8-asm.10 anthos.servicemesh.trustDomainAliases base-dir base gcloud.compute.location us-central gcloud.compute.network default gcloud.compute.subnetwork default gcloud.container.cluster example-cluster-1 gcloud.container.cluster.clusterSecondaryRange gcloud.container.cluster.releaseChannel REGULAR gcloud.container.cluster.servicesSecondaryRange gcloud.container.nodepool.max-nodes 4 gcloud.core.project example-project-12345 gcloud.project.environProjectID FLEET_PROJECT_ID gcloud.project.environProjectNumber 1234567890123 gcloud.project.projectNumber 9876543210987
Vérifiez que les valeurs pour les setters suivantes sont correctes :
- anthos.servicemesh.rev
- anthos.servicemesh.tag
- gcloud.compute.location
- gcloud.container.cluster
- gcloud.core.project
- gcloud.project.environProjectNumber
Vous pouvez ignorer les valeurs des autres setters.
Migrer vers Anthos Service Mesh
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.
Mettre à jour le plan de contrôle
Mesh CA
Vérifiez que le contexte
kubeconfig
actuel pointe vers le cluster sur lequel vous souhaitez installer Anthos Service Mesh :kubectl config current-context
Le résultat est au format suivant :
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
Le contexte
kubeconfig
et les valeurs des Setterskpt
doivent correspondre. Si nécessaire, exécutez la commandegcloud container clusters get-credentials
pour définir le contextekubeconfig
actuel.Exécutez la commande suivante pour déployer le nouveau plan de contrôle avec le profil
asm-gcp-multiproject
. Si vous souhaitez activer une fonctionnalité facultative compatible, incluez-f
et le nom de fichier YAML dans la ligne de commande suivante. Pour plus d'informations, consultez la page Activer les fonctionnalités facultatives.istioctl install \ -f asm/istio/istio-operator.yaml \ -f asm/istio/options/multiproject.yaml \ -f asm/istio/options/multicluster.yaml\ --revision=asm-178-10
L'argument
--revision
ajoute un libellé de révision au formatistio.io/rev=asm-178-10
àistiod
. Le libellé de révision est utilisé par le webhook d'injecteur side-car automatique pour associer les side-cars injectés à une révisionistiod
particulière. Pour activer l'injection side-car automatique sur un espace de noms, vous devez lui attribuer un libellé associé à une révision correspondant à un déploiementistiod
.Les fichiers suivants remplacent les paramètres du fichier
istio-operator.yaml
:Le fichier
multiproject.yaml
définit le profilasm-gcp-multiproject
.Le fichier
multicluster.yaml
configure les paramètres dont Anthos Service Mesh a besoin pour une configuration multicluster.
Vérifiez que les pods du plan de contrôle dans
istio-system
sont opérationnels :kubectl get pods -n istio-system
Exemple de résultat :
NAME READY STATUS RESTARTS AGE istio-ingressgateway-c56675fcd-86zdn 1/1 Running 0 2m9s istio-ingressgateway-c56675fcd-vn4nv 1/1 Running 0 2m21s istiod-asm-178-10-6d5cfd4b89-xztlr 1/1 Running 0 3m44s istiod-fb7f746f4-wcntn 1/1 Running 0 50m
Deux services et déploiements de plan de contrôle s'exécutent côte à côte.
Déployez le contrôleur de service canonique sur votre cluster :
kubectl apply -f asm/canonical-service/controller.yaml
Le contrôleur de service canonique regroupe les charges de travail appartenant au même service logique. Pour en savoir plus sur les services canoniques, consultez la présentation du Service canonique.
Citadel
Vérifiez que le contexte
kubeconfig
actuel pointe vers le cluster sur lequel vous souhaitez installer Anthos Service Mesh :kubectl config current-context
Le résultat est au format suivant :
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
Le contexte
kubeconfig
et les valeurs des Setterskpt
doivent correspondre. Si nécessaire, exécutez la commandegcloud container clusters get-credentials
pour définir le contextekubeconfig
actuel.Exécutez la commande suivante pour déployer le nouveau plan de contrôle avec le profil
asm-gcp-multiproject
. Si vous souhaitez activer une fonctionnalité facultative compatible, incluez-f
et le nom de fichier YAML dans la ligne de commande suivante. Pour plus d'informations, consultez la page Activer les fonctionnalités facultatives.istioctl install \ -f asm/istio/istio-operator.yaml \ -f asm/istio/options/citadel-ca.yaml \ -f asm/istio/options/multiproject.yaml \ -f asm/istio/options/multicluster.yaml\ --revision=asm-178-10
L'argument
--revision
ajoute un libellé de révision au formatistio.io/rev=asm-178-10
àistiod
. Le libellé de révision est utilisé par le webhook d'injecteur side-car automatique pour associer les side-cars injectés à une révisionistiod
particulière. Pour activer l'injection side-car automatique sur un espace de noms, vous devez lui attribuer un libellé associé à une révision correspondant à un déploiementistiod
.Les fichiers suivants remplacent les paramètres du fichier
istio-operator.yaml
:Le fichier
citadel-ca.yaml
configure la Citadel en tant qu'autorité de certification.Le fichier
multiproject.yaml
définit le profilasm-gcp-multiproject
.Le fichier
multicluster.yaml
configure les paramètres dont Anthos Service Mesh a besoin pour une configuration multicluster.
Vérifiez que les pods du plan de contrôle dans
istio-system
sont opérationnels :kubectl get pods -n istio-system
Exemple de résultat :
NAME READY STATUS RESTARTS AGE istio-ingressgateway-c56675fcd-86zdn 1/1 Running 0 2m9s istio-ingressgateway-c56675fcd-vn4nv 1/1 Running 0 2m21s istiod-asm-178-10-6d5cfd4b89-xztlr 1/1 Running 0 3m44s istiod-fb7f746f4-wcntn 1/1 Running 0 50m
Deux services et déploiements de plan de contrôle s'exécutent côte à côte.
Déployez le contrôleur de service canonique sur votre cluster :
kubectl apply -f asm/canonical-service/controller.yaml
Le contrôleur de service canonique regroupe les charges de travail appartenant au même service logique. Pour en savoir plus sur les services canoniques, consultez la présentation du Service canonique.
Redéployer des charges de travail
L'installation de la nouvelle révision n'a aucune incidence sur les proxys side-car existants. Pour les mettre à niveau, vous devez les configurer de sorte qu'ils pointent vers le nouveau plan de contrôle. Cette opération est contrôlée lors de l'injection side-car en fonction du libellé d'espace de noms istio.io/rev
.
Mettez à jour les charges de travail à injecter avec la nouvelle version d'Anthos Service Mesh :
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-178-10 --overwrite
Le libellé
istio-injection
doit être supprimé, car il est prioritaire sur le libelléistio.io/rev
.Redémarrez les pods pour déclencher la réinjection :
kubectl rollout restart deployment -n NAMESPACE
Vérifiez que les pods sont configurés de sorte qu'ils pointent vers le plan de contrôle
istiod-asm-178-10
:kubectl get pods -n NAMESPACE -l istio.io/rev=asm-178-10
Testez votre application pour vérifier que les charges de travail fonctionnent correctement.
Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes précédentes pour chaque espace de noms.
Si vous êtes sûr que votre application fonctionne comme prévu, passez à la section Terminer la migration. Sinon, procédez comme suit pour effectuer un rollback vers la version précédente :
Pour effectuer un rollback :
Mettez à jour les charges de travail à injecter avec la version précédente du plan de contrôle :
kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
Redémarrez les pods pour déclencher une réinjection afin que les proxys disposent de la version précédente :
kubectl rollout restart deployment -n NAMESPACE
Redéployez la version précédente du fichier
istio-ingressgateway
:kubectl -n istio-system rollout undo deploy istio-ingressgateway
Supprimez le nouveau plan de contrôle :
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-asm-178-10 -n istio-system --ignore-not-found=true
Terminer la migration
Si vous êtes sûr que votre application fonctionne comme prévu, procédez comme suit pour terminer la migration vers Anthos Service Mesh :
Supprimez l'ancien plan de contrôle :
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
Enregistrer votre cluster
Vous devez enregistrer votre cluster auprès de l'Environ du projet pour accéder à l'interface utilisateur unifiée dans la console Google Cloud. Un parc constitue un moyen unifié d'afficher et de gérer les clusters et leurs charges de travail, y compris les clusters extérieurs à Google Cloud.
Consultez la section Enregistrer des clusters dans la Fleet pour en savoir plus sur l'enregistrement de votre cluster.