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 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.
  • 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-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, une session 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.

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

  7. La fonctionnalité Service Mesh doit être activée sur votre projet. Vous pourriez activer dans le cadre de l'installation en transmettant l'un des indicateurs --enable-all ou --enable-registration, ou en 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 géré par Google du canal standard 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 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 regular

    Cette étape peut prendre quelques minutes.

  3. Vérifier 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 certaines des configurations 1.4 vers 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 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-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 le ConfigMap à tous les espaces de noms
    • Ajouter la racine de confiance de l'autorité de certification Cloud Service Mesh à 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 Cloud Service Mesh

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

  1. Définissez l'espace de noms en tant que variable. Cet espace de noms est migré vers 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'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- --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 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 migrationStatus 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

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. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Istio sur GKE incluent la suppression du 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 de 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 pour les modifications apportées au webhook de mutation : 

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

  2. Attribuez un nouveau libellé aux 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 de la 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 dans la 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 est pour Kubernetes. Comme Cloud Service Mesh est basé sur les API Istio, vous pouvez continuez à 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 parallèlement à 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 l'utilisation de 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 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 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.