Migrer d'Istio sur GKE vers Cloud Service Mesh
Ce guide explique comment mettre à niveau un cluster Google Kubernetes Engine (GKE) avec Istio sur Google Kubernetes Engine (Istio sur GKE) version 1.4 ou 1.6 (bêta) vers Cloud Service Mesh géré avec le plan de contrôle géré par Google et l'autorité de certification Cloud Service Mesh.
Prérequis
Les conditions préalables suivantes sont requises pour suivre ce guide :
Un cluster GKE avec Istio sur GKE activé Si vous disposez de plusieurs clusters GKE, suivez la même procédure pour tous les clusters.
Istio sur GKE doit être de la version 1.4 ou 1.6.
Assurez-vous d'exécuter la version 1.17.17-gke.3100+ de GKE 1.18.16-gke.1600+, 1.19.8-gke.1600+ ou ultérieure.
Le cluster GKE doit s'exécuter dans l'un de ces emplacements.
L'utilisateur ou le compte de service qui exécute ce script doit disposer des autorisations IAM décrites dans la section Configurer votre projet.
Ce guide étant testé sur Cloud Shell, nous vous recommandons d'utiliser Cloud Shell pour effectuer les étapes décrites dans ce guide.
Objectifs
- Déployez le plan de contrôle géré par Google de Cloud Service Mesh dans le canal standard. Ce guide est spécifique au canal standard. Les canaux stables ou rapides nécessitent des instructions légèrement modifiées. Pour en savoir plus sur les canaux de publication, cliquez ici.
- Migrez les configurations Istio vers Cloud Service Mesh.
- Configurez l'autorité de certification Cloud Service Mesh.
- Migrez des applications vers Cloud Service Mesh.
- Mettez à niveau
istio-ingressgatewayde Istio sur GKE vers Cloud Service Mesh. - Finalisez la migration Cloud Service Mesh ou effectuez un rollback vers Istio sur GKE.
Configurer votre environnement
Pour configurer votre environnement, procédez comme suit :
Dans la console Google Cloud, activez Cloud Shell.
En bas de la page de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI et Google Cloud CLI sont déjà installés, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Créez les variables d'environnement utilisées dans ce guide:
# Enter your project ID export PROJECT_ID=PROJECT_ID # Copy and paste the following gcloud config set project ${PROJECT_ID} export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)') export CLUSTER_1=GKE_CLUSTER_NAME export CLUSTER_1_LOCATION=GKE_CLUSTER_REGION_OR_ZONE export SHELL_IP=$(curl ifconfig.me) # This is required for private clusters with `master-authorized-networks` enabled.Créer un dossier
WORKDIR. Tous les fichiers associés à ce guide se trouvent dansWORKDIRafin que vous puissiez supprimerWORKDIRlorsque vous avez terminé.mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`Créez un fichier
KUBECONFIGpour ce guide : Vous pouvez également utiliser votre fichierKUBECONFIGexistant contenant le contexte du cluster pour le cluster GKE à migrer vers Cloud Service Mesh.touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfigObtenez des identifiants pour le cluster GKE et stockez le contexte dans une variable:
Cluster zonal
gcloud container clusters get-credentials ${CLUSTER_1} \ --zone=${CLUSTER_1_LOCATION} export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}Clusters régionaux
gcloud container clusters get-credentials ${CLUSTER_1} \ --region=${CLUSTER_1_LOCATION} export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}Les clusters doivent être enregistrés sur un parc. Vous pouvez effectuer cette opération séparément avant l'installation ou pendant l'installation en transmettant l'option --fleet-id et l'une des options --enable-all ou --enable-registration.
La fonctionnalité Service Mesh doit être activée sur votre projet. Vous pouvez l'activer pendant l'installation en transmettant l'une des options --enable-all ou --enable-registration, ou en exécutant la commande suivante avant l'installation:
gcloud container hub mesh enable --project=FLEET_PROJECT_IDoù FLEET_PROJECT_ID est l'ID du projet hôte du parc.
Étape facultative
Si le cluster est un cluster privé (avec master-authorized-networks activé), ajoutez votre $SHELL_IP à la liste d'autorisation master-authorized-networks.
Si vous avez déjà accès à votre cluster, cette étape peut ne pas être nécessaire.
Cluster zonal
export SHELL_IP=$(curl ifconfig.me)
gcloud container clusters update ${CLUSTER_1} \
--zone=${CLUSTER_1_LOCATION} \
--enable-master-authorized-networks \
--master-authorized-networks ${SHELL_IP}/32
Clusters régionaux
export SHELL_IP=$(curl ifconfig.me)
gcloud container clusters update ${CLUSTER_1} \
--region=${CLUSTER_1_LOCATION} \
--enable-master-authorized-networks \
--master-authorized-networks ${SHELL_IP}/32
Installer Cloud Service Mesh
Dans cette section, vous allez déployer Cloud Service Mesh avec le plan de contrôle géré par Google du canal standard sur le cluster GKE. Ce plan de contrôle est initialement déployé en même temps qu'Istio, en tant que deuxième plan de contrôle (ou Canary).
Téléchargez la dernière version du script qui installe Cloud Service Mesh dans le répertoire de travail actuel et rendez le script exécutable:
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli chmod +x asmcliPour configurer le cluster GKE, exécutez le script d'installation permettant d'installer Cloud Service Mesh avec le plan de contrôle géré par Google du canal standard:
./asmcli install \ -p ${PROJECT_ID} \ -l ${CLUSTER_1_LOCATION} \ -n ${CLUSTER_1} \ --fleet_id ${FLEET_PROJECT_ID} \ --managed \ --verbose \ --output_dir ${CLUSTER_1} \ --enable-all \ --channel regularCette étape peut prendre quelques minutes.
Copiez
istioctldans le dossierWORKDIR:cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
Dans la section suivante, vous téléchargez et exécutez le script migrate_addon pour vous aider dans la migration vers Cloud Service Mesh. L'utilitaire de ligne de commande istioctl doit se trouver dans le même dossier que le script migrate_addon. Vous utilisez le dossier WORKDIR pour l'utilitaire de ligne de commande istioctl et le script migrate_addon.
Migrer des configurations vers Cloud Service Mesh
Dans cette section, vous migrez des configurations Istio sur GKE vers Cloud Service Mesh. Le script guidé identifie les configurations pouvant ou non être migrées.
Téléchargez l'outil de migration et rendez-le exécutable:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon chmod +x ${WORKDIR}/migrate_addonDésactivez le webhook de validation Galley. Cette étape est nécessaire pour migrer certaines des configurations 1.4 vers Cloud Service Mesh. Répondez
Yaux deux questions:${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhookLe résultat ressemble à ce qui suit :
tmpdir directory not present. Create directory? Continue? [Y/n] Y Disabling the Istio validation webhook... Continue? [Y/n] Y Running: kubectl get clusterrole istio-galley-istio-system -n istio-system -o yaml Running: kubectl patch clusterrole -n istio-system istio-galley-istio-system --type=json -p=[{"op": "replace", "path": "/rules/2/verbs/0", "value": "get"}] clusterrole.rbac.authorization.k8s.io/istio-galley-istio-system patched Running: kubectl get ValidatingWebhookConfiguration istio-galley --ignore-not-found Running: kubectl delete ValidatingWebhookConfiguration istio-galley --ignore-not-found validatingwebhookconfiguration.admissionregistration.k8s.io "istio-galley" deletedVérifiez et configurez manuellement la configuration. Cette étape permet d'identifier certaines des configurations devant être migrées manuellement avant de migrer des charges de travail vers le plan de contrôle géré par Google.
${WORKDIR}/migrate_addon -d tmpdir --command config-checkLe résultat ressemble à ce qui suit :
Installing the authentication CR migration tool... OK Checking for configurations that will need to be explicitly migrated... No resources found
Migrer des configurations personnalisées
Vous devrez peut-être migrer manuellement les configurations personnalisées avant de migrer vers Cloud Service Mesh. Le script précédent identifie les configurations personnalisées et imprime les informations requises. Ces personnalisations sont les suivantes:
Les filtres Envoy personnalisés détectés ne sont pas compatibles avec Cloud Service Mesh. Si possible, supprimez-les. Les filtres Envoy ne sont actuellement pas disponibles dans le plan de contrôle géré par Google.
Certificat de plug-in personnalisé détecté. Les certificats de plug-in ne seront pas migrés vers Cloud Service Mesh. Si des certificats de plug-ins sont utilisés avec Istio sur GKE, ils ne sont pas utilisés après la migration des charges de travail vers le plan de contrôle géré par Google. Toutes les charges de travail utilisent des certificats signés par l'autorité de certification Google Cloud Service Mesh. Les certificats de plug-in ne sont pas compatibles avec l'autorité de certification Cloud Service Mesh. Ce message est informatif et aucune action n'est requise.
Les règles de sécurité n'ont pas pu être migrées. <Motif de l'erreur>. Cette erreur se produit généralement en raison de règles alpha AuthZ qui doivent être migrées manuellement. Pour obtenir plus de contexte et d'informations sur la migration des règles, consultez la section Migrer la règle de sécurité alpha d'Istio 1.4 vers les API actuelles. Pour en savoir plus sur le message d'erreur, consultez la page security-policy-migrate.
Détection d'une configuration VirtualService potentiellement incompatible. <Configuration spécifique obsolète. Vous devez mettre à jour les configurations
VirtualServicesuivantes:- L'utilisation de
appendHeadersn'est pas acceptée. Utilisez plutôtspec.http.headers. - L'utilisation de
websocketUpgraden'est pas nécessaire. Il est activé par défaut. - Remplacez le champ
abort.percentparabort.percentage.
- L'utilisation de
Détection d'installation personnalisée des ressources Mixer qui n'ont pas pu être migrées. Nécessite une migration manuelle vers Telemetryv2. Si les règles de Mixer personnalisées sont configurées en plus de l'installation par défaut d'Istio sur GKE, vous devez migrer manuellement ces règles vers la télémétrie v2. Pour en savoir plus, consultez la page Personnaliser les métriques Istio.
Deployment <deploymentName> peut être une passerelle personnalisée. Effectuez la migration manuellement. Vous devez migrer manuellement tous les déploiements de passerelles autres que
istio-ingressgateway(qui est installé par défaut). Pour en savoir plus sur la mise à niveau des passerelles du plan de contrôle géré par Google, consultez la page Configurer le plan de contrôle géré par Google.
Pour migrer les configurations, procédez comme suit:
Migrez manuellement toutes les configurations personnalisées (à l'exception de la dernière configuration répertoriée) avant de passer à l'étape 2.
Utilisez l'outil de migration pour migrer les configurations pouvant être migrées automatiquement (ou ignorées).
${WORKDIR}/migrate_addon -d tmpdir --command migrate-configsLe résultat ressemble à ce qui suit :
Converting authentication CRs... 2021/06/25 20:44:58 found root namespace: istio-system 2021/06/25 20:44:59 SUCCESS converting policy /default Running: kubectl apply --dry-run=client -f beta-policy.yaml peerauthentication.security.istio.io/default created (dry run) Applying converted security policies in tmpdir/beta-policy.yaml... Continue? [Y/n] Y Running: kubectl apply -f beta-policy.yaml peerauthentication.security.istio.io/default created OK
Appliquez la racine de confiance de l'autorité de certification Cloud Service Mesh. Cela vous permet de migrer de l'autorité de certification Citadel actuelle vers l'autorité de certification Cloud Service Mesh sans aucun temps d'arrêt pour vos applications.
${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-caLe résultat ressemble à ce qui suit :
Configuring Istio on GKE to trust Anthos Service Mesh... Continue? [Y/n] Y Running: kubectl get cm -n istio-system istio-asm-managed -oyaml Running: kubectl -n istio-system apply -f - secret/meshca-root created Running: kubectl get cm istio -n istio-system -o yaml Running: kubectl get cm istio -n istio-system -o yaml Running: kubectl replace -f - configmap/istio replaced Running: kubectl get deploy istio-pilot -n istio-system -o yaml Running: kubectl patch deploy istio-pilot -n istio-system -p={"spec":{"template":{"spec":{"containers":[{ "name":"discovery", "image":"gcr.io/gke-release/istio/pilot:1.4.10-gke.12", "env":[{"name":"PILOT_SKIP_VALIDATE_TRUST_DOMAIN","value":"true"}] }]}}}} deployment.apps/istio-pilot patched Running: kubectl get deploy istio-citadel -n istio-system -o yaml Running: kubectl patch deploy istio-citadel -n istio-system -p={"spec":{"template":{"spec":{ "containers":[{ "name":"citadel", "args": ["--append-dns-names=true", "--grpc-port=8060", "--citadel-storage-namespace=istio-system", "--custom-dns-names=istio-pilot-service-account.istio-system:istio-pilot.istio-system", "--monitoring-port=15014", "--self-signed-ca=true", "--workload-cert-ttl=2160h", "--root-cert=/var/run/root-certs/meshca-root.pem"], "volumeMounts": [{"mountPath": "/var/run/root-certs", "name": "meshca-root", "readOnly": true}] }], "volumes": [{"name": "meshca-root", "secret":{"secretName": "meshca-root"}}] }}}} deployment.apps/istio-citadel patched OK Waiting for root certificate to distribute to all pods. This will take a few minutes... ASM root certificate not distributed to asm-system, trying again later ASM root certificate not distributed to asm-system, trying again later ASM root certificate distributed to namespace asm-system ASM root certificate distributed to namespace default ASM root certificate distributed to namespace istio-operator ASM root certificate not distributed to istio-system, trying again later ASM root certificate not distributed to istio-system, trying again later ASM root certificate distributed to namespace istio-system ASM root certificate distributed to namespace kube-node-lease ASM root certificate distributed to namespace kube-public ASM root certificate distributed to namespace kube-system ASM root certificate distributed to namespace online-boutique Waiting for proxies to pick up the new root certificate... OK Configuring Istio Addon 1.6 to trust Anthos Service Mesh... Running: kubectl get cm -n istio-system env-asm-managed -ojsonpath={.data.TRUST_DOMAIN} --ignore-not-found Running: kubectl get cm istio-istio-1611 -n istio-system -o yaml Running: kubectl replace -f - configmap/istio-istio-1611 replaced Running: kubectl patch -n istio-system istiooperators.install.istio.io istio-1-6-11-gke-0 --type=merge istiooperator.install.istio.io/istio-1-6-11-gke-0 patched Running: kubectl -n istio-system get secret istio-ca-secret -ojsonpath={.data.ca-cert\.pem} Running: kubectl -n istio-system patch secret istio-ca-secret secret/istio-ca-secret patched Running: kubectl patch deploy istiod-istio-1611 -n istio-system deployment.apps/istiod-istio-1611 patched Running: kubectl rollout status -w deployment/istiod-istio-1611 -n istio-system Waiting for deployment "istiod-istio-1611" rollout to finish: 1 old replicas are pending termination... deployment "istiod-istio-1611" successfully rolled out Running: kubectl apply -f - -n istio-system envoyfilter.networking.istio.io/trigger-root-cert created Waiting for proxies to pick up the new root certificate... Running: kubectl delete envoyfilter trigger-root-cert -n istio-system OKCette étape prend quelques minutes pour que le certificat racine Cloud Service Mesh soit distribué à tous les espaces de noms. Attendez la fin de l'exécution du script avec le message
OK.
L'étape précédente effectue les opérations suivantes:
- Installe la racine de confiance de l'autorité de certification Cloud Service Mesh pour toutes les charges de travail du cluster.
Modifie les configurations des déploiements du plan de contrôle
istio-pilot,istiodetistio-citadel. Les modifications incluent les suivantes:- Mise à niveau des images vers les dernières compilations
- Désactivez la validation
trust-domainen définissantPILOT_SKIP_VALIDATE_TRUST_DOMAIN=true. - Ajouter la racine de confiance de l'autorité de certification Cloud Service Mesh à
istio-citadelpour distribuer leConfigMapà tous les espaces de noms - Ajouter la racine de confiance de l'autorité de certification Cloud Service Mesh à
istio-ca-secretpour distribuer le certificat racine.
Il stocke les anciens fichiers manifestes de configuration dans
tmpdir.Fournit des étapes concernant la fonction de rollback (décrite plus loin).
Migrer des charges de travail vers Cloud Service Mesh
Dans cette section, vous migrez des charges de travail exécutées sur Istio sur GKE vers Cloud Service Mesh. Après la migration, vérifiez que les proxys side-car appropriés (Cloud Service Mesh) sont injectés dans chaque pod et que l'application fonctionne comme prévu.
Si vous effectuez cette procédure sur un cluster existant, sélectionnez un espace de noms à migrer.
Définissez l'espace de noms en tant que variable. Cet espace de noms est migré vers Cloud Service Mesh:
export NAMESPACE=NAMESPACE_NAME
Pour migrer des charges de travail vers Cloud Service Mesh, vous devez modifier les étiquettes de l'espace de noms pour Cloud Service Mesh. L'ajout d'un libellé à l'espace de noms permet à Cloud Service Mesh d'injecter automatiquement des side-cars à toutes les charges de travail. Pour ajouter un libellé à l'espace de noms, exécutez la commande suivante en définissant le libellé sur
asm-managed:kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwriteRedémarrez progressivement tous les objets Deployment présents dans l'espace de noms:
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}Le résultat ressemble à ce qui suit :
deployment.apps/deploymentName1 restarted deployment.apps/deploymentName2 restarted ...
Assurez-vous que tous les pods sont redémarrés et s'exécutent avec deux conteneurs par pod:
kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get podsLe résultat ressemble à ce qui suit :
NAME READY STATUS RESTARTS AGE deploymentName1-PodName 2/2 Running 0 101s deploymentName2-PodName 2/2 Running 2 100s ...
Un bon moyen de vérifier cette étape consiste à examiner
AGEdes pods. Assurez-vous que la valeur est courte (par exemple, quelques minutes).Vérifiez la version du proxy Envoy side-car de l'un des pods depuis un déploiement de l'espace de noms pour vérifier que vous avez maintenant déployé les proxys Envoy de Cloud Service Mesh:
export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'Le résultat ressemble à ce qui suit :
"gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3" "appContainerImage"
Vérifiez et testez vos applications après le redémarrage.
kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'(Facultatif) Si vous souhaitez que Google gère les mises à niveau des proxys, activez le plan de données géré par Google.
Afficher l'état de la migration
Exécutez la commande suivante pour afficher l'état de la migration:
kubectl get cm/asm-addon-migration-state -n istio-system -ojsonpath={.data}
Le résultat indique si les migrations sont terminées, en attente ou ayant échoué:
{"migrationStatus":"SUCCESS"}
{"migrationStatus":"PENDING"}
{"migrationStatus":"MIGRATION_CONFIG_ERROR"}
{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}
Si migrationStatus génère SUCCESS, le plan de contrôle a bien été mis à niveau vers Cloud Service Mesh. Pour mettre à jour manuellement le plan de données, suivez la procédure décrite dans Migrer des charges de travail.
Si migrationStatus renvoie un état autre que SUCCESS, vous pouvez choisir l'une des options suivantes:
- Ne prenez aucune mesure supplémentaire si l'erreur de migration n'a aucun impact sur vos charges de travail Istio sur GKE existantes. Sinon, effectuez un rollback si nécessaire.
- Mettez à jour les configurations personnalisées dans le cluster et relancez manuellement la migration si
migrationStatusafficheMIGRATION_CONFIG_ERROR.
Vous pouvez afficher les métriques du plan de contrôle dans l'explorateur de métriques une fois la migration terminée. Pour en savoir plus, consultez verify_control_plane_metrics.
Accéder aux tableaux de bord Cloud Service Mesh
Dans cette section, accédez aux tableaux de bord Cloud Service Mesh et assurez-vous que vous recevez les signaux clés pour tous les services. Vous devriez également pouvoir voir la topologie de votre application.
Dans la console Google Cloud, accédez à la page Cloud Service Mesh.
Vous devriez pouvoir afficher les métriques et la topologie de vos services.
Pour en savoir plus sur les tableaux de bord Cloud Service Mesh, consultez la page Explorer Cloud Service Mesh dans la console Google Cloud.
Effectuer une migration réussie
Dans cette section, vous allez finaliser votre migration Istio sur GKE vers Cloud Service Mesh. Avant de poursuivre cette section, assurez-vous de vouloir continuer avec Cloud Service Mesh. Cette section vous aide également à nettoyer vos artefacts Istio sur GKE. Si vous souhaitez effectuer un rollback vers Istio sur GKE, passez à la section suivante.
Remplacez
istio-ingressgateway(une partie d'Istio sur GKE standard) par la passerelle avec versions gérées du plan de contrôle géré par Google:${WORKDIR}/migrate_addon -d tmpdir --command replace-gatewayLe résultat ressemble à ce qui suit :
Replacing the ingress gateway with an Anthos Service Mesh gateway... Continue? [Y/n] Y Running: kubectl label namespace istio-system istio-injection- istio.io/rev- --overwrite label "istio.io/rev" not found. namespace/istio-system labeled Running: kubectl apply -f - serviceaccount/asm-ingressgateway created deployment.apps/asm-ingressgateway created role.rbac.authorization.k8s.io/asm-ingressgateway created rolebinding.rbac.authorization.k8s.io/asm-ingressgateway created Running: kubectl wait --for=condition=available --timeout=600s deployment/asm-ingressgateway -n istio-system deployment.apps/asm-ingressgateway condition met Scaling the Istio ingress gateway to zero replicas... Continue? [Y/n] Y Running: kubectl -n istio-system patch hpa istio-ingressgateway --patch {"spec":{"minReplicas":1}} horizontalpodautoscaler.autoscaling/istio-ingressgateway patched (no change) Running: kubectl -n istio-system scale deployment istio-ingressgateway --replicas=0 deployment.apps/istio-ingressgateway scaled OKreconfigurer le webhook pour utiliser le plan de contrôle géré par Google. Toutes les charges de travail commencent par utiliser le plan de contrôle géré par Google:
${WORKDIR}/migrate_addon -d tmpdir --command replace-webhookLe résultat ressemble à ce qui suit :
Configuring sidecar injection to use Anthos Service Mesh by default... Continue? [Y/n] Y Running: kubectl patch mutatingwebhookconfigurations istio-sidecar-injector --type=json -p=[{"op": "replace", "path": "/webhooks"}] mutatingwebhookconfiguration.admissionregistration.k8s.io/istio-sidecar-injector patched Revision tag "default" created, referencing control plane revision "asm-managed". To enable injection using this revision tag, use 'kubectl label namespace <NAMESPACE> istio.io/rev=default' OKModifiez les libellés de tous les espaces de noms avec le libellé Cloud Service Mesh, puis effectuez un redémarrage progressif de toutes les charges de travail pour les obtenir sur le plan de contrôle géré par Google:
export NAMESPACE=NAMESPACE_NAME \ kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite` kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}Vous pouvez ignorer le message
"istio-injection not found"dans le résultat. Cela signifie que l'espace de noms ne portait pas précédemment le libelléistio-injection, auquel on s'attend dans de nouvelles installations de Cloud Service Mesh ou de nouveaux déploiements. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois leistio-injectionet le libellé de révision, toutes les commandeskubectl labelde la documentation Istio sur GKE incluent la suppression du libelléistio-injection.Finalisez la migration en exécutant la commande suivante:
${WORKDIR}/migrate_addon -d tmpdir --command write-markerLe résultat ressemble à ce qui suit :
Current migration state: SUCCESS Running: kubectl apply -f - configmap/asm-addon-migration-state created OK
Désactivez Istio sur GKE en exécutant la commande suivante:
Cluster zonal
gcloud beta container clusters update ${CLUSTER_1} \ --project=$PROJECT_ID \ --zone=${CLUSTER_1_LOCATION} \ --update-addons=Istio=DISABLEDClusters régionaux
gcloud beta container clusters update ${CLUSTER_1} \ --project=$PROJECT_ID \ --region=${CLUSTER_1_LOCATION} \ --update-addons=Istio=DISABLEDNettoyez les configurations en exécutant la commande suivante:
${WORKDIR}/migrate_addon -d tmpdir --command cleanupLe résultat ressemble à ce qui suit :
Cleaning up old resources... Running: kubectl get cm -n istio-system asm-addon-migration-state -ojsonpath={.data.migrationStatus} Will delete IstioOperator/istio-1-6-11-gke-0.istio-system Will delete ServiceAccount/istio-citadel-service-account.istio-system ... Will delete DestinationRule/istio-policy.istio-system Will delete DestinationRule/istio-telemetry.istio-system Will delete Secret/istio-ca-secret.istio-system Deleting resources previously listed... Continue? [Y/n] Y Running: kubectl delete IstioOperator istio-1-6-11-gke-0 -n istio-system --ignore-not-found istiooperator.install.istio.io "istio-1-6-11-gke-0" deleted Running: kubectl delete ServiceAccount istio-citadel-service-account -n istio-system --ignore-not-found serviceaccount "istio-citadel-service-account" deleted-ingressgateway -n istio-system --ignore-not-found ... Running: kubectl delete Secret istio-ca-secret -n istio-system --ignore-not-found secret "istio-ca-secret" deleted Running: kubectl delete -n istio-system jobs -lk8s-app=istio,app=security job.batch "istio-security-post-install-1.4.10-gke.8" deletedAssurez-vous que les déploiements et les services d'Istio sur GKE ont bien été supprimés du cluster:
kubectl --context=${CLUSTER_1_CTX} -n istio-system get deployments,servicesLe résultat ressemble à ce qui suit :
NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/asm-ingressgateway 1/1 1 1 10m NAME TYPE CLUSTER-IP EXTERNAL-IP AGE PORT(S) service/istio-ingressgateway LoadBalancer 10.64.5.208 34.139.100.237 95m 15020:31959/TCP,80:30971/TCP,443:31688/TCP,31400:31664/TCP,15029:32493/TCP,15030:31722/TCP,15031:30198/TCP,15032:31910/TCP,15443:31222/TCP
Vous ne voyez que le service et le déploiement de la passerelle d'entrée de Cloud Service Mesh.
Félicitations, Vous avez migré d'Istio sur GKE vers Cloud Service Mesh avec le plan de contrôle géré par Google et l'autorité de certification Cloud Service Mesh sans temps d'arrêt pour vos applications.
Effectuer un rollback des modifications
Dans cette section, si vous ne souhaitez pas utiliser Cloud Service Mesh, vous pouvez effectuer un rollback de vos modifications Cloud Service Mesh. Une fois cette section terminée, vos charges de travail retournent dans Istio sur GKE.
Effectuez un rollback pour les modifications apportées au webhook de mutation:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhookModifiez les libellés des espaces de noms pour utiliser l'injection side-car Istio sur GKE au lieu de Cloud Service Mesh en exécutant la commande suivante:
Pour les espaces de noms avec des charges de travail de la version 1.4:
export NAMESPACE=NAMESPACE_NAME kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwritePour les espaces de noms avec des charges de travail de la version 1.6:
export NAMESPACE=NAMESPACE_NAME kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwriteRedémarrez progressivement tous les objets Deployment présents dans l'espace de noms:
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}Attendez quelques minutes et assurez-vous que tous les pods sont en cours d'exécution:
kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get podsLe résultat ressemble à ce qui suit :
NAME READY STATUS RESTARTS AGE deploymentName1-PodName 2/2 Running 0 101s deploymentName2-PodName 2/2 Running 2 100s ...
Vérifiez la version du proxy Envoy side-car de l'un des pods pour vérifier que vous disposez de proxys Envoy sur Istio sur GKE v1.4 déployés :
export POD_NAME=NAME_OF_ANY_POD_IN_NAMESPACE kubectl --context=${CLUSTER_1_CTX} get pods ${POD_NAME} -n ${NAMESPACE} -o json | jq '.status.containerStatuses[].image'Le résultat ressemble à ce qui suit :
"gke.gcr.io/istio/proxyv2:1.4.10-gke.8" "appContainerImage"
ou
"gke.gcr.io/istio/proxyv2:1.6.14-gke.4" "appContainerImage"
Vérifiez et testez vos applications après le redémarrage.
Effectuez un rollback pour les modifications de l'autorité de certification Cloud Service Mesh:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-caRéactivez le webhook Istio Galley:
${WORKDIR}/migrate_addon -d tmpdir --command enable-galley-webhook
Vous avez effectué un rollback de vos modifications vers Istio sur GKE.
Déployer Online Boutique
Dans cette section, vous allez déployer un exemple d'application basée sur des microservices, appelée Boutique en ligne, sur le cluster GKE. Online Boutique est déployé dans un espace de noms compatible avec Istio. Vous allez vérifier que l'application fonctionne et qu'Istio sur GKE injecte les proxys side-car à chaque pod.
Si vous disposez déjà de clusters avec des applications, vous pouvez ignorer la création d'un espace de noms et le déploiement d'Online Boutique. Vous pouvez suivre le même processus pour tous les espaces de noms dans la section Migrer des charges de travail vers Cloud Service Mesh.
Déployez Online Boutique sur le cluster GKE :
kpt pkg get \ https://github.com/GoogleCloudPlatform/microservices-demo.git/release \ online-boutique kubectl --context=${CLUSTER_1_CTX} create namespace online-boutique kubectl --context=${CLUSTER_1_CTX} label namespace online-boutique istio-injection=enabled kubectl --context=${CLUSTER_1_CTX} -n online-boutique apply -f online-boutiqueAttendez que tous les déploiements soient prêts :
kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator kubectl --context=${CLUSTER_1_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationserviceAssurez-vous qu'il existe deux conteneurs par pod : le conteneur d'applications et le proxy side-car Istio qu'Istio sur GKE injecte automatiquement dans le pod :
kubectl --context=${CLUSTER_1_CTX} -n online-boutique get podsLe résultat ressemble à ce qui suit :
NAME READY STATUS RESTARTS AGE adservice-7cbc9bd9-t92k4 2/2 Running 0 3m21s cartservice-d7db78c66-5qfmt 2/2 Running 1 3m23s checkoutservice-784bfc794f-j8rl5 2/2 Running 0 3m26s currencyservice-5898885559-lkwg4 2/2 Running 0 3m23s emailservice-6bd8b47657-llvgv 2/2 Running 0 3m27s frontend-764c5c755f-9wf97 2/2 Running 0 3m25s loadgenerator-84cbcd768c-5pdbr 2/2 Running 3 3m23s paymentservice-6c676df669-s779c 2/2 Running 0 3m25s productcatalogservice-7fcf4f8cc-hvf5x 2/2 Running 0 3m24s recommendationservice-79f5f4bbf5-6st24 2/2 Running 0 3m26s redis-cart-74594bd569-pfhkz 2/2 Running 0 3m22s shippingservice-b5879cdbf-5z7m5 2/2 Running 0 3m22s
Vous pouvez également vérifier la version du proxy side-car Envoy de l'un des pods pour vérifier que vous disposez bien des proxys Envoy d'Istio sur GKE v1.4 déployés :
export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_1_CTX} -o jsonpath='{.items[0].metadata.name}') kubectl --context=${CLUSTER_1_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'Le résultat ressemble à ce qui suit :
"gke.gcr.io/istio/proxyv2:1.4.10-gke.8" "gcr.io/google-samples/microservices-demo/frontend:v0.3.4"
Accédez à l'application en accédant à l'adresse IP de l'adresse IP du service
istio-ingressgateway:kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
Questions fréquentes
Cette section décrit les questions fréquentes et les réponses associées sur la migration d'Istio sur GKE vers Cloud Service Mesh.
Pourquoi ai-je migré d'Istio sur GKE vers Cloud Service Mesh ?
Istio sur Google Kubernetes Engine est une fonctionnalité bêta qui déploie Istio géré par Google sur un cluster Google Kubernetes Engine (GKE). Istio sur GKE déploie une version non compatible (Istio version 1.4). Afin de vous fournir les dernières fonctionnalités du maillage de services et la mise en œuvre d'un maillage de services compatible, nous mettons à niveau tous les utilisateurs d'Istio sur GKE vers Cloud Service Mesh.
Cloud Service Mesh est le produit de maillage de services géré et compatible de Google, fourni par les API Istio. Cloud Service Mesh est pour Istio ce que GKE est pour Kubernetes. Étant donné que Cloud Service Mesh est basé sur les API Istio, vous pouvez continuer à utiliser vos configurations Istio lorsque vous migrez vers Cloud Service Mesh. De plus, il n'existe pas de dépendance vis-à-vis d'un fournisseur propriétaire.
Cloud Service Mesh offre les avantages suivants:
- Un maillage de services géré par Google et compatible avec Google.
- Des API Istio sans dépendance vis-à-vis d'un fournisseur.
- Des tableaux de bord de télémétrie prêts à l'emploi et une gestion des SLO sans la nécessité de gérer des solutions tierces supplémentaires.
- Des options d'autorité de certification hébergées par Google.
- Une intégration à la mise en réseau Google Cloud et à Identity-Aware Proxy (IAP).
- Une compatibilité avec des plates-formes hybrides et multi-cloud.
Pour en savoir plus sur les fonctionnalités et les capacités de Cloud Service Mesh, consultez la page Fonctionnalités compatibles avec le plan de contrôle géré par Google.
Y a-t-il un temps d'arrêt associé à cette migration ?
Le script de migration est conçu pour éviter les temps d'arrêt. Le script installe Cloud Service Mesh en tant que plan de contrôle Canary avec votre plan de contrôle Istio existant. L'objet istio-ingressgateway est mis à niveau sur place. Vous modifiez ensuite les libellés des espaces de noms compatibles avec Istio pour commencer à utiliser Cloud Service Mesh avec l'autorité de certification Cloud Service Mesh.
Assurez-vous que PodDisruptionBudgets est correctement configuré pour vos applications afin de ne pas subir de temps d'arrêt. Même si vous pouvez éviter les temps d'arrêt, si vous effectuez vous-même cette migration, nous vous recommandons de l'effectuer pendant un intervalle de maintenance planifié. Les migrations basées sur Google sont effectuées pendant un intervalle de maintenance GKE. Assurez-vous que des intervalles de maintenance sont configurés pour vos clusters GKE.
L'utilisation de Cloud Service Mesh est-elle payante ?
Il existe deux manières d'utiliser Cloud Service Mesh sur GKE:
Si vous êtes abonné à GKE Enterprise, Cloud Service Mesh est inclus dans votre abonnement GKE Enterprise.
Si vous n'êtes pas abonné à GKE Enterprise, vous pouvez utiliser Cloud Service Mesh en tant que produit autonome sur GKE (sur Google Cloud). Pour en savoir plus, consultez les tarifs de Cloud Service Mesh.
Existe-t-il des fonctionnalités ou des configurations non compatibles avec la dernière version de Cloud Service Mesh ?
Le script vérifie toutes les configurations Istio et les migre vers la dernière version de Cloud Service Mesh. Certaines configurations peuvent nécessiter la migration d'étapes supplémentaires de la version 1.4 d'Istio vers la version 1.10 de Cloud Service Mesh. Le script effectue une vérification de configuration et vous informe si des configurations nécessitent des étapes supplémentaires.
La migration modifie-t-elle mes configurations Istio actuelles ?
Non, vos configurations Istio fonctionnent sur Cloud Service Mesh sans nécessiter de modifications.
Après avoir migré vers Cloud Service Mesh, puis-je revenir à Istio ?
Oui, les services Cloud Service Mesh sont sans engagement. Vous pouvez désinstaller Cloud Service Mesh et réinstaller Istio à tout moment.
En cas d'échec de la migration, est-il possible d'effectuer un rollback ?
Oui, le script vous permet d'effectuer un rollback vers votre version précédente d'Istio sur GKE.
Quelle version d'Istio puis-je migrer à l'aide de ce script ?
Le script vous aide à effectuer la migration d'Istio sur GKE version 1.4 vers Cloud Service Mesh version 1.10. Le script valide votre version d'Istio pendant la phase de pré-migration et vous indique si votre version d'Istio peut être migrée.
Comment obtenir de l'aide supplémentaire concernant cette migration ?
Notre équipe d'assistance se fera un plaisir de vous aider. Vous pouvez ouvrir une demande d'assistance à partir de Google Cloud Console. Pour en savoir plus, consultez la page Gérer des demandes d'assistance.
Que se passe-t-il si je ne migre pas vers Cloud Service Mesh ?
Vos composants Istio continuent de fonctionner, mais Google ne gère plus votre installation Istio. Vous ne recevez plus de mises à jour automatiques et l'installation n'est pas garantie de fonctionner pendant la mise à jour de la version du cluster Kubernetes.
Pour en savoir plus, consultez la page Compatibilité avec Istio.