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) sur Cloud Service Mesh géré avec le service géré par Google le plan de contrôle 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 Cloud Service Mesh géré par Google dans le canal standard. Ce guide est propre à la version standard. Les versions stable et rapide nécessitent des instructions légèrement modifiées. Pour en savoir plus sur les versions disponibles, cliquez ici.
• Migrer des configurations Istio vers Cloud Service Mesh
• Configurez l'autorité de certification Cloud Service Mesh.
• Migrez des applications vers Cloud Service Mesh.
• Mettez à niveau istio-ingressgateway d'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 :

1. Dans la console Google Cloud, activez Cloud Shell.

   Activer Cloud Shell

   En bas de la page de la console Google Cloud, Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un à l'aide de la Google Cloud CLI et Google Cloud CLI déjà installé, et avec des valeurs déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

   Remarque : Le script ne fonctionne pas sur macOS. Le script n'a été testé que sur Cloud Shell. Le script nécessite les applications suivantes (qui sont toutes incluses par défaut dans Cloud Shell) :

   • gcloud (version 346.0.0 et ultérieure)
   • kubectl (version 1.21 du client et ultérieure)
   • jq
   • sed
   • curl
   • awk

2. 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.
   

3. Créer un dossier WORKDIR. Tous les fichiers associés à ce guide se trouvent dans WORKDIR afin que vous puissiez supprimer WORKDIR lorsque vous avez terminé.

   mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`
   

4. Créez un fichier KUBECONFIG pour ce guide : Vous pouvez également utiliser votre fichier KUBECONFIG existant qui contient le contexte du cluster pour le Cluster GKE à migrer vers Cloud Service Mesh.

   touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
   

5. Obtenez 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}
   

6. Les clusters doivent être enregistrés sur un parc. Cette étape peut être effectuée séparément avant l'installation ou dans le cadre de l'installation en transmettant --fleet-id et l'un des indicateurs --enable-all ou --enable-registration.

7. 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_ID
   

   où 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 du canal standard géré par Google sur le cluster GKE. Cette commande est initialement déployé en même temps qu'un second plan de contrôle.

1. Téléchargez la dernière version du script qui installe Cloud Service Mesh. au répertoire de travail actuel et rendez le script exécutable:

   curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
   chmod +x asmcli
   

2. Pour configurer le cluster GKE, exécutez le script d'installation Pour installer Cloud Service Mesh avec le plan de contrôle du canal standard géré par Google:

   ./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 regular
   

   Cette étape peut prendre quelques minutes.

3. Valider le plan de contrôle géré par Google

4. Copiez istioctl dans le dossier WORKDIR:

   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.

1. 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_addon
   

2. Désactivez le webhook de validation Galley. Cette étape est nécessaire pour migrer des configurations 1.4 à Cloud Service Mesh. Répondez Y aux deux questions:

   ${WORKDIR}/migrate_addon -d tmpdir --command disable-galley-webhook
   

   Le 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" deleted
   
   

3. Vé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-check
   

   Le 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 des 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 migrés vers Cloud Service Mesh. Si certificats de plug-in sont utilisés avec Istio sur GKE, ces certificats 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 de 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 VirtualService suivantes:

  • L'utilisation de appendHeaders n'est pas acceptée. Utilisez plutôt spec.http.headers.
  • L'utilisation de websocketUpgrade n'est pas nécessaire. Il est activé par défaut.
  • Remplacez le champ abort.percent par abort.percentage.

• 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:

1. Migrez manuellement toutes les configurations personnalisées (à l'exception de la dernière configuration répertoriée) avant de passer à l'étape 2.

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-configs
   

   Le 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
   
   

3. Appliquez la confiance racine de l'autorité de certification Cloud Service Mesh. Vous pouvez ainsi migrer l'autorité de certification citadelle actuelle vers l'autorité de certification Cloud Service Mesh sans subir de temps d'arrêt à vos applications.

   ${WORKDIR}/migrate_addon -d tmpdir --command configure-mesh-ca
   

   Le 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
   OK
   
   

   Cette étape prend quelques minutes pour le certificat racine Cloud Service Mesh à 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:

• Il 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, istiod et istio-citadel. Les modifications incluent les suivantes:

  • Mise à niveau des images vers les dernières compilations
  • Désactivez la validation trust-domain en définissant PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true.
  • Ajouter la racine de confiance de l'autorité de certification Cloud Service Mesh à istio-citadel pour distribuer ConfigMap à tous les espaces de noms.
  • Ajouter la racine de confiance de l'autorité de certification Cloud Service Mesh à istio-ca-secret pour distribuer la racine certificat.

• 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, vous vérifierez que le bon des proxys (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.

1. Définissez l'espace de noms en tant que variable. cet espace de noms est migré Cloud Service Mesh:

   export NAMESPACE=NAMESPACE_NAME
   

2. Pour migrer des charges de travail vers Cloud Service Mesh, vous devez modifier l'étiquette de l'espace de noms pour Cloud Service Mesh. L'étiquetage de l'espace de noms permet à Cloud Service Mesh pour injecter automatiquement des side-cars dans 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- --overwrite
   

3. Redé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
   ...
   

4. 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 pods
   

   Le 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 AGE des pods. Assurez-vous que la valeur est courte (par exemple, quelques minutes).

5. Vérifiez la version du proxy Envoy side-car depuis n'importe lequel des pods Déploiement dans l'espace de noms pour confirmer que les proxys Envoy de Cloud Service Mesh sont maintenant 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 :

   "gcr.io/gke-release/asm/proxyv2:1.11.5-asm.3"
   "appContainerImage"
   

6. 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}'
   

7. (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 renvoie SUCCESS, le plan de contrôle a réussi mis à niveau vers Cloud Service Mesh. Pour mettre à jour manuellement le plan de données, procédez comme suit : consultez la section Migrer des charges de travail.

Si migrationStatus renvoie un état autre que SUCCESS, vous pouvez choisir de soit:

• 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.
• Mettre à jour les configurations personnalisées dans le cluster et réexécuter la migration manuellement si migrationStatus s'affiche MIGRATION_CONFIG_ERROR

Une fois la migration terminée, vous pouvez afficher les métriques du plan de contrôle dans l'Explorateur de métriques. Pour en savoir plus, consultez la section verify_control_plane_metrics.

Accéder aux tableaux de bord Cloud Service Mesh

Dans cette section, vous 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.

1. Dans la console Google Cloud, accédez à la page Cloud Service Mesh.

   Accéder à Cloud Service Mesh

2. 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 Découvrir Cloud Service Mesh dans la console Google Cloud

Remarque :La topologie et la vue Tableau des tableaux de bord Cloud Service Mesh peuvent prenez quelques minutes pour représenter les bonnes données.

Effectuer une migration réussie

Dans cette section, vous finalisez votre déploiement Istio sur GKE pour Migration 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.

1. 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-gateway
   

   Le 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
   OK
   

2. reconfigurer 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-webhook
   

   Le 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'
   OK
   

3. Ajoutez à nouveau l'étiquette "Cloud Service Mesh" à tous les espaces de noms et effectuez une le redémarrage progressif de toutes les charges de travail 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 n'avait pas auparavant Le libellé istio-injection, qui est attendu dans les nouvelles de Cloud Service Mesh ou de nouveaux déploiements. Comme l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le l'étiquette de révision, toutes les commandes kubectl label du La documentation d'Istio sur GKE inclut la suppression Libellé istio-injection.

4. Finalisez la migration en exécutant la commande suivante:

   ${WORKDIR}/migrate_addon -d tmpdir --command write-marker
   

   Le résultat ressemble à ce qui suit :

   Current migration state: SUCCESS
   Running: kubectl apply -f -
   configmap/asm-addon-migration-state created
   OK
   
   

5. 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=DISABLED
   

   Clusters régionaux

   gcloud beta container clusters update ${CLUSTER_1} \
       --project=$PROJECT_ID \
       --region=${CLUSTER_1_LOCATION} \
       --update-addons=Istio=DISABLED
   

6. Nettoyez les configurations en exécutant la commande suivante:

   ${WORKDIR}/migrate_addon -d tmpdir --command cleanup
   

   Le 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" deleted
   

7. Assurez-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,services
   

   Le 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 Cloud Service Mesh.

Félicitations, Vous avez bien migré depuis Istio sur GKE à Cloud Service Mesh avec le plan de contrôle géré par Google l'autorité de certification de Cloud Service Mesh sans aucun 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 des modifications de Cloud Service Mesh. Une fois cette section terminée, vos charges de travail retournent dans Istio sur GKE.

1. Effectuez un rollback des modifications du webhook en mutation:

   ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook
   

2. Modifiez 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 version 1.4:

   export NAMESPACE=NAMESPACE_NAME
   kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite
   

   Pour les espaces de noms avec des charges de travail version 1.6:

   export NAMESPACE=NAMESPACE_NAME
   kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=istio-1611 --overwrite
   

3. Redémarrez progressivement tous les objets Deployment présents dans l'espace de noms:

   kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
   

4. Attendez quelques minutes et assurez-vous que tous les pods sont en cours d'exécution:

   kubectl --context=${CLUSTER_1_CTX} -n ${NAMESPACE} get pods
   

   Le 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
   ...
   
   

5. 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"
   

6. Vérifiez et testez vos applications après le redémarrage.

7. Effectuez un rollback des modifications apportées à l'autorité de certification Cloud Service Mesh:

   ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca
   

8. Ré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 de Section Migrer des charges de travail vers Cloud Service Mesh.

1. 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-boutique
   

2. Attendez 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 recommendationservice
   

3. Assurez-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 pods
   

   Le 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
   

4. 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"
   

5. 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 suis-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). Pour vous fournir les derniers services de maillage de services et une implémentation compatible du maillage de services, nous mettons à jour d'utilisateurs d'Istio sur GKE à Cloud Service Mesh.

Cloud Service Mesh est le produit de maillage de services géré et compatible de Google basées sur les API Istio. Cloud Service Mesh est pour Istio ce que GKE à 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 réétiquetez ensuite les espaces de noms compatibles avec Istio pour avec l'autorité de certification Cloud Service Mesh.

Assurez-vous d'avoir PodDisruptionBudgets correctement configurés pour vos applications afin d'éviter les temps d'arrêt des applications. 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 façons d'utiliser Cloud Service Mesh sur GKE:

• Si vous êtes abonné à GKE Enterprise, Cloud Service Mesh est inclus en tant que 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 étapes supplémentaires pour migrer d'Istio version 1.4 vers Cloud Service Mesh version 1.10. 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 des 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 depuis 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 un demande d'assistance depuis la console Google Cloud. 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.