Migrer d'Istio sur GKE vers Anthos 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 (version bêta) vers Anthos Service Mesh Version 1.10 avec le plan de contrôle géré par Google d'Anthos Service Mesh et l'autorité de certification Anthos Service Mesh (CA).

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. Si vous n'avez pas de cluster GKE ou si vous souhaitez d'abord tester ce guide sur un nouveau cluster (test), vous pouvez suivre la procédure décrite dans l'annexe A. pour créer un cluster GKE avec Istio sur GKE activé et déployer une application de test

  • 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éployer la version 1.10 du plan de contrôle géré par Google d'Anthos Service Mesh
  • Migrez les configurations Istio vers Anthos Service Mesh.
  • Configurez Mesh CA.
  • Migrez des applications vers Anthos Service Mesh.
  • Mettez à niveau istio-ingressgateway de Istio sur GKE vers Anthos Service Mesh.
  • Finalisez la migration Anthos Service Mesh ou effectuez un rollback vers Istio sur GKE.

Configurer votre environnement

Pour configurer votre environnement, procédez comme suit :

  1. Dans Google Cloud Console, activez Cloud Shell :

    Activer Cloud Shell

    En bas de la fenêtre de Cloud Console, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel le SDK Cloud et l'outil de ligne de commande gcloud sont déjà installés et dont les valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

  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 contenant le contexte du cluster pour le cluster GKE à migrer vers Anthos 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}
    

É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 Anthos Service Mesh

Dans cette section, vous déployez Anthos Service Mesh version 1.10 avec le plan de contrôle géré par Google sur le cluster GKE. Ce plan de contrôle est déployé en même temps qu'Istio sur GKE, en tant que deuxième plan de contrôle (ou Canary).

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

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.10 > install_asm_1_10
    chmod +x install_asm_1_10
    
  2. Pour configurer le cluster GKE, exécutez le script d'installation permettant d'installer Anthos Service Mesh avec le plan de contrôle géré par Google:

    ./install_asm_1_10 --mode install --managed \
    -p ${PROJECT_ID} \
    -l ${CLUSTER_1_LOCATION} \
    -n ${CLUSTER_1} \
    --verbose \
    --output_dir ${CLUSTER_1} \
    --enable-all \
    --enable-registration \
    --option cni-managed
    

    Cette étape peut prendre quelques minutes.

  3. Copiez istioctl version 1.10 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 Anthos 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 les configurations vers Anthos Service Mesh

Dans cette section, vous migrez des configurations Istio sur GKE vers Anthos 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/master/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 certaines des configurations 1.4 vers Anthos 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 les configurations personnalisées avant de migrer vers Anthos 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 Anthos 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 Anthos 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 Mesh. Les certificats de plug-in ne sont pas compatibles avec Mesh CA. 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 racine de confiance de Mesh CA. Cela vous permet de migrer de l'autorité de certification Citadel actuelle vers Mesh CA sans aucun temps d'arrêt pour 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 que le certificat racine Anthos 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 Mesh CA 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 Mesh CA à istio-citadel pour distribuer le ConfigMap à tous les espaces de noms
    • Ajouter la racine de confiance Mesh CA à istio-ca-secret pour 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 Anthos Service Mesh

Dans cette section, vous migrez des charges de travail exécutées sur Istio sur GKE vers Anthos Service Mesh. Après la migration, vérifiez que les proxys side-car appropriés (Anthos Service Mesh) sont injectés dans chaque pod et que l'application fonctionne comme prévu.

Si vous avez créé un cluster de test en suivant les étapes décrites dans l'annexe A, vous utiliserez l'espace de noms online-boutique comme exemple. 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é vers Anthos Service Mesh:

    export NAMESPACE=NAMESPACE_NAME # or online-boutique if using the test cluster in Appendix A
    
  2. Pour migrer des charges de travail vers Anthos Service Mesh, vous devez modifier les étiquettes de l'espace de noms pour Anthos Service Mesh. L'ajout d'un libellé à l'espace de noms permet à Anthos 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-rapid:

    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed-rapid 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 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 la version 1.10 d'Anthos 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.10.2-asm.2"
    "appContainerImage"
    
  6. Vérifiez et testez vos applications après le redémarrage.

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 bien été mis à niveau vers Anthos Service Mesh. Pour mettre à jour manuellement le plan de données, suivez la procédure décrite dans la section Migrer des charges de travail.

Si migrationStatus génère tout autre état que SUCCESS, vous pouvez choisir l'une des options suivantes:

  • N'effectuez aucune action supplémentaire. L'erreur de migration ne devrait pas avoir d'incidence sur vos charges de travail Istio existantes sur GKE. Google réessaie d'effectuer la migration lors de la prochaine release.

  • Mettez à jour les configurations personnalisées du cluster et réexécutez manuellement la migration si migrationStatus affiche MIGRATION_CONFIG_ERROR.

Accéder aux tableaux de bord Anthos Service Mesh

Dans cette section, accédez aux tableaux de bord Anthos 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 Google Cloud Console, accédez à la page Anthos Service Mesh.

    Accéder à Anthos 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 Anthos Service Mesh, consultez la page Explorer Anthos Service Mesh dans Cloud Console.

Effectuer une migration réussie

Dans cette section, vous allez finaliser votre migration Istio sur GKE vers Anthos Service Mesh. Avant de poursuivre cette section, assurez-vous de vouloir continuer avec Anthos 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. Modifiez les libellés de tous les espaces de noms avec le libellé Anthos 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-rapid istio-injection- --overwrite`
    
        kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n
    ${NAMESPACE}
    
  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: COMPLETE
    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 de passerelle d'entrée d'Anthos Service Mesh et son déploiement.

Félicitations, Vous avez migré d'Istio sur GKE vers Anthos Service Mesh v1.10 avec le plan de contrôle géré par Google et Mesh CA sans temps d'arrêt pour vos applications.

Effectuer un rollback des modifications

Dans cette section, si vous ne souhaitez pas utiliser Anthos Service Mesh, vous pouvez effectuer un rollback de vos modifications Anthos Service Mesh. Une fois cette section terminée, vos charges de travail retournent dans Istio sur GKE.

  1. Modifiez les libellés des espaces de noms pour utiliser l'injection side-car Istio sur GKE au lieu d'Anthos Service Mesh en exécutant la commande suivante:

    export NAMESPACE=NAMESPACE_NAME
    kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev- istio-injection=enabled --overwrite
    
  2. Redémarrez progressivement tous les objets Deployment présents dans l'espace de noms:

    kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
    
  3. 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
    ...
    
    
  4. 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"
    
  5. Vérifiez et testez vos applications après le redémarrage.

  6. Effectuez un rollback pour les modifications de l'autorité de certification Mesh:

    ${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca
    
  7. Réactivez le webhook Istio Galley:

    ${WORKDIR}/migrate_addon -d tmpdir enable-galley-webook
    

Vous avez effectué un rollback de vos modifications vers Istio sur GKE.

Annexe A

Créer un cluster GKE avec Istio sur GKE

Dans cette section, vous allez déployer un cluster GKE avec Istio sur GKE activé. Vous pouvez utiliser un cluster GKE privé ou non privé. Les clusters GKE privés doivent disposer d'un point de terminaison GKE public. Vous allez également vérifier l'installation d'Istio sur GKE.

Si vous disposez déjà d'un cluster GKE, vous pouvez ignorer l'étape de création et vous assurer que vous avez accès au cluster qui utilise le fichier KUBECONFIG. Le contexte utilisé par ce guide est défini dans la variable ${CLUSTER_1_CTX}. Vous pouvez définir le contexte de votre cluster sur cette variable.

  1. 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.
    
  2. Créer un cluster GKE avec Istio sur GKE activé (cluster privé) Vous pouvez également effectuer ces étapes avec un cluster GKE non privé.

    Cluster zonal

    gcloud beta container clusters create ${CLUSTER_1} \
      --project ${PROJECT_ID} \
      --zone=${CLUSTER_1_LOCATION} \
      --machine-type "e2-standard-4" \
      --num-nodes "4" --min-nodes "2" --max-nodes "5" \
      --addons=Istio --istio-config=auth=MTLS_STRICT \
      --enable-master-authorized-networks \
      --master-authorized-networks ${SHELL_IP}/32 \
      --enable-private-nodes \
      --master-ipv4-cidr 172.16.0.32/28 \
      --enable-ip-alias \
      --enable-autoscaling
    

    Clusters régionaux

    gcloud beta container clusters create ${CLUSTER_1} \
      --project ${PROJECT_ID} \
      --region=${CLUSTER_1_LOCATION} \
      --machine-type "e2-standard-4" \
      --num-nodes "4" --min-nodes "2" --max-nodes "5" \
      --addons=Istio --istio-config=auth=MTLS_STRICT \
      --enable-master-authorized-networks \
      --master-authorized-networks ${SHELL_IP}/32 \
      --enable-private-nodes \
      --master-ipv4-cidr 172.16.0.32/28 \
      --enable-ip-alias \
      --enable-autoscaling
    
  3. Confirmez que le cluster est RUNNING :

    gcloud container clusters list
    

    Le résultat ressemble à ce qui suit :

    NAME      LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
    gke-east  us-east1-b  1.19.10-gke.1600  34.73.171.206  e2-standard-4  1.19.10-gke.1600  4          RUNNING
    
  4. Connectez-vous au cluster :

    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}
    

    Étape facultative

    Si vous utilisez Cloud Shell pour ces étapes, votre SHELL_IP peut changer. Dans ce cas, vous pouvez exécuter la commande suivante pour mettre à jour la valeur master-authorized-networks avec votre nouvelle adresse IP Cloud Shell.

    Pour mettre à jour la valeur master-authorized-networks de votre cluster, exécutez les commandes suivantes. Vous ne devez exécuter les commandes suivantes que lorsque votre adresse IP Cloud Shell change.

    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
    
  5. Assurez-vous qu'Istio est déployé sur le cluster. Vérifiez que tous les services sont déployés:

    kubectl --context=${CLUSTER_1_CTX} get service -n istio-system
    

    Le résultat ressemble à ce qui suit :

    NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                                                                                      AGE
    istio-citadel            ClusterIP      10.64.7.167    <none>        8060/TCP,15014/TCP                                                                                                                           90s
    istio-galley             ClusterIP      10.64.15.216   <none>        443/TCP,15014/TCP,9901/TCP                                                                                                                   90s
    istio-ingressgateway     LoadBalancer   10.64.9.36     <pending>     15020:31962/TCP,80:31663/TCP,443:31658/TCP,31400:32022/TCP,15029:31829/TCP,15030:30063/TCP,15031:32466/TCP,15032:30649/TCP,15443:30807/TCP   90s
    istio-pilot              ClusterIP      10.64.10.175   <none>        15010/TCP,15011/TCP,8080/TCP,15014/TCP                                                                                                       90s
    istio-policy             ClusterIP      10.64.1.82     <none>        9091/TCP,15004/TCP,15014/TCP                                                                                                                 90s
    istio-sidecar-injector   ClusterIP      10.64.13.43    <none>        443/TCP,15014/TCP                                                                                                                            90s
    istio-telemetry          ClusterIP      10.64.7.76     <none>        9091/TCP,15004/TCP,15014/TCP,42422/TCP                                                                                                       90s
    promsd                   ClusterIP      10.64.5.236    <none>        9090/TCP
    
  6. Assurez-vous que tous les pods sont en cours d'exécution et que les tâches sont terminées:

    kubectl --context=${CLUSTER_1_CTX} get pods -n istio-system
    

    Le résultat ressemble à ce qui suit :

    NAME                                             READY   STATUS      RESTARTS   AGE
    istio-citadel-f5586dffb-8c9sm                    1/1     Running     0          10m
    istio-galley-7975f77bbf-zxccq                    1/1     Running     0          10m
    istio-ingressgateway-b9477dcdb-gr7wb             1/1     Running     0          10m
    istio-pilot-59d4884d67-v6zh6                     2/2     Running     0          10m
    istio-policy-6885cb4644-h5pnv                    2/2     Running     1          10m
    istio-security-post-install-1.4.10-gke.8-q9w5s   0/1     Completed   0          10m
    istio-sidecar-injector-649d664b99-555dx          1/1     Running     0          10m
    istio-telemetry-59b6bf55c7-r2q57                 2/2     Running     1          10m
    istiod-istio-1611-6895859f65-zvlzq               1/1     Running     0          9m21s
    prometheus-6655946b9f-hdsrd                      2/2     Running     0          9m21s
    promsd-574ccb9745-w65pl                          2/2     Running     1          10m
    

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 Anthos 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}'
    

Étape suivante