Von Istio on GKE zu Cloud Service Mesh migrieren

In diesem Leitfaden wird gezeigt, wie Sie einen GKE-Cluster (Google Kubernetes Engine) mit Istio in Google Kubernetes Engine (Istio in GKE) Version 1.4 oder 1.6 (Beta) bis verwalteten Cloud Service Mesh mit dem von Google verwalteten Steuerungsebene und Cloud Service Mesh-Zertifizierungsstelle.

Vorbereitung

Für diese Anleitung sind die folgenden Voraussetzungen erforderlich:

• Einen GKE-Cluster mit aktiviertem Istio on GKE. Wenn Sie mehrere GKE-Cluster haben, führen Sie für alle Cluster die gleichen Schritte aus.

• Istio on GKE muss Version 1.4 oder 1.6 sein.

• Sie benötigen die GKE-Version 1.17.17-gke.3100+, 1.18.16-gke.1600+, 1.19.8-gke.1600+ oder höher.

• Der GKE-Cluster muss an einem dieser Standorte ausgeführt werden.

• Der Nutzer oder das Dienstkonto, das dieses Skript ausführt, benötigt die unter Projekt einrichten dokumentierten IAM-Berechtigungen.

• Dieser Leitfaden wurde in Cloud Shell getestet. Daher empfehlen wir, die Schritte in diesem Leitfaden mit Cloud Shell auszuführen.

Lernziele

• Von Google verwaltete Cloud Service Mesh-Steuerungsebene im regulären Kanal bereitstellen Diese Anleitung bezieht sich speziell auf die regulären, stabile oder schnellen Kanäle und erfordert leicht abgeänderte Anweisungen. Weitere Informationen zu Release-Versionen finden Sie hier.
• Migrieren Sie Istio-Konfigurationen zu Cloud Service Mesh.
• Cloud Service Mesh-Zertifizierungsstelle konfigurieren
• Anwendungen zu Cloud Service Mesh migrieren
• Upgrade von istio-ingressgateway von Istio on GKE auf Cloud Service Mesh
• Cloud Service Mesh-Migration abschließen oder Rollback auf Istio on GKE ausführen

Umgebung einrichten

So richten Sie Ihre Umgebung ein:

1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

   Cloud Shell aktivieren

   Unten auf der Seite der Google Cloud Console befindet sich Cloud Shell Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI und die Google Cloud-Befehlszeile bereits installiert sind und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

   Hinweis: Das Skript funktioniert unter macOS nicht. Das Skript wurde nur in Cloud Shell getestet. Für das Skript sind die folgenden Anwendungen erforderlich, die alle standardmäßig in Cloud Shell enthalten sind:

   • gcloud (Version 346.0.0 und höher)
   • kubectl (Client-Version 1.21 und höher)
   • jq
   • sed
   • curl
   • awk

2. Erstellen Sie die Umgebungsvariablen, die in dieser Anleitung verwendet werden:

   # 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. Erstellen Sie einen WORKDIR-Ordner. Alle mit dieser Anleitung verknüpften Dateien enden in WORKDIR, sodass Sie WORKDIR löschen können, wenn Sie fertig sind.

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

4. Erstellen Sie eine KUBECONFIG-Datei für diese Anleitung. Sie können auch Ihr Vorhandene KUBECONFIG-Datei, die den Clusterkontext für die GKE-Cluster, der zu Cloud Service Mesh migriert werden soll.

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

5. Rufen Sie die Anmeldedaten für den GKE-Cluster ab und speichern Sie den Kontext in einer Variablen:

   Zonale Cluster

   gcloud container clusters get-credentials ${CLUSTER_1} \
     --zone=${CLUSTER_1_LOCATION}
   
   export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}
   

   Regionale Cluster

   gcloud container clusters get-credentials ${CLUSTER_1} \
     --region=${CLUSTER_1_LOCATION}
   
   export CLUSTER_1_CTX=gke_${PROJECT_ID}_${CLUSTER_1_LOCATION}_${CLUSTER_1}
   

6. Ihre Cluster müssen in einer Flotte registriert sein. Dieser Schritt kann separat vor der Installation oder im Rahmen der Installation ausgeführt werden. Dazu übergeben Sie die Flags „--fleet-id“ und eines der Flags „--enable-all“ oder „--enable-registration“.

7. In Ihrem Projekt muss das Service Mesh-Feature aktiviert sein. Sie könnten im Rahmen der Installation durch Übergeben eines der Flags --enable-all oder --enable-registration oder durch Führen Sie vor der Installation folgenden Befehl aus:

     gcloud container hub mesh enable --project=FLEET_PROJECT_ID
   

   Dabei ist FLEET_PROJECT_ID die Projekt-ID des Flottenhostprojekts.

Optionaler Schritt

Wenn der Cluster ein privater Cluster ist (mit aktiviertem master-authorized-networks), fügen Sie $SHELL_IP zur Zulassungsliste master-authorized-networks hinzu. Wenn Sie bereits Zugriff auf Ihren Cluster haben, ist dieser Schritt möglicherweise nicht erforderlich.

Zonale Cluster

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

Regionale Cluster

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

Cloud Service Mesh installieren.

In diesem Abschnitt stellen Sie Cloud Service Mesh mit der von Google verwalteten Steuerungsebene des regulären Kanals im GKE-Cluster bereit. Diese Steuerungsebene wird anfänglich als zweite (oder Canary-)Steuerungsebene bereitgestellt.

1. Laden Sie die neueste Version des Skripts, mit dem Cloud Service Mesh im aktuellen Arbeitsverzeichnis installiert wird, herunter und machen Sie das Skript ausführbar:

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

2. Führen Sie das Installationsskript aus, um den GKE-Cluster zu konfigurieren um Cloud Service Mesh mit der von Google verwalteten Steuerungsebene des regulären Kanals zu installieren:

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

   Dies kann einige Minuten dauern.

3. Von Google verwaltete Steuerungsebene prüfen

4. Kopieren Sie istioctl in den Ordner WORKDIR:

   cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
   

Im nächsten Abschnitt laden Sie zur Unterstützung das Skript migrate_addon herunter und führen es aus. bei der Migration zum Cloud Service Mesh. Das istioctl-Befehlszeilentool muss sich im selben Ordner wie das Skript migrate_addon befinden. Sie verwenden den Ordner WORKDIR sowohl für das istioctl-Befehlszeilentool als auch für das Skript migrate_addon.

Konfigurationen zu Cloud Service Mesh migrieren

In diesem Abschnitt migrieren Sie Istio on GKE-Konfigurationen zu Cloud Service Mesh. Das unterstützte Skript ermittelt, welche Konfigurationen migriert werden können und welche nicht.

1. Laden Sie das Migrationstool herunter und machen Sie es ausführbar:

   curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/migrate-addon > ${WORKDIR}/migrate_addon
   chmod +x ${WORKDIR}/migrate_addon
   

2. Deaktivieren Sie den Galley-Validierungs-Webhook. Dieser Schritt ist erforderlich, um einige der 1.4-Konfigurationen zu Cloud Service Mesh zu migrieren. Beantworten Sie beide Fragen mit Y:

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

   Die Ausgabe sieht etwa so aus:

   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. Prüfen Sie die Konfiguration und migrieren Sie sie manuell. Mit diesem Schritt können Sie einige Konfigurationen identifizieren, die manuell migriert werden müssen, bevor Arbeitslasten zur von Google verwalteten Steuerungsebene migriert werden.

   ${WORKDIR}/migrate_addon -d tmpdir --command config-check
   

   Die Ausgabe sieht etwa so aus:

   Installing the authentication CR migration tool...
   OK
   
   Checking for configurations that will need to be explicitly migrated...
   No resources found
   

Benutzerdefinierte Konfigurationen migrieren

Möglicherweise müssen Sie benutzerdefinierte Konfigurationen manuell migrieren, bevor Sie zu Cloud Service Mesh migrieren. Das obige Skript ermittelt benutzerdefinierte Konfigurationen und gibt Informationen darüber aus, was erforderlich ist. Diese Anpassungen sind so:

• Erkannte benutzerdefinierte Envoy-Filter werden vom Cloud Service Mesh nicht unterstützt. Entfernen Sie diese nach Möglichkeit. Envoy-Filter werden derzeit von der von Google verwalteten Steuerungsebene nicht unterstützt.

• Erkanntes benutzerdefiniertes Plug-in-Zertifikat. Die Plug-in-Zertifikate werden nicht zu Cloud Service Mesh migriert. Wenn Plug-in-Zertifikate mit Istio in GKE verwendet werden, werden diese Zertifikate nachdem die Arbeitslasten zur von Google verwalteten Steuerungsebene migriert sind. Alle Arbeitslasten Zertifikate verwenden, die von der Google Cloud Service Mesh-Zertifizierungsstelle signiert wurden. Plug-in-Zertifikate werden von der Cloud Service Mesh-Zertifizierungsstelle nicht unterstützt. Diese Meldung dient zu Informationszwecken und es ist keine Aktion erforderlich.

• Erkannte Sicherheitsrichtlinien, die nicht migriert werden konnten. <Fehlerursache>. Dies schlägt in der Regel fehl, da Alpha-AuthZ-Richtlinien manuell migriert werden müssen. Weitere Informationen und Informationen zum Migrieren von Richtlinien finden Sie unter Pre-Istio 1.4-Alphasicherheitsrichtlinie zu den aktuellen APIs migrieren. Weitere Informationen zur Fehlermeldung finden Sie unter security-policy-migrate.

• Es wurde eine inkompatible VirtualService-Konfiguration erkannt. <Bestimmte verworfene Konfiguration>. Sie müssen die folgenden VirtualService-Konfigurationen aktualisieren:

  • Die Verwendung von appendHeaders wird nicht unterstützt. Verwenden Sie stattdessen spec.http.headers.
  • Die Verwendung von websocketUpgrade ist nicht erforderlich. Sie ist standardmäßig aktiviert.
  • Ersetzen Sie das Feld abort.percent durch abort.percentage.

• Benutzerdefinierte Installation von Mixer-Ressourcen, die nicht migriert werden konnten. Erfordert manuelle Migration zu telemetryv2. Wenn benutzerdefinierte Mixer zusätzlich zur standardmäßigen Installation von Istio on GKE konfiguriert sind, müssen Sie diese Richtlinien manuell zu Telemetrie Version 2 migrieren. Weitere Informationen hierzu finden Sie unter Istio-Messwerte anpassen.

• Deployment <deploymentName> könnte ein benutzerdefiniertes Gateway sein. Sie müssen dies manuell migrieren. Sie müssen alle Gateway-Deployments außer istio-ingressgateway, die standardmäßig installiert sind, manuell migrieren. Informationen zum Upgrade von Gateways für die von Google verwaltete Steuerungsebene finden Sie unter Von Google verwaltete Steuerungsebene konfigurieren.

So migrieren Sie Konfigurationen:

1. Migrieren Sie alle benutzerdefinierten Konfigurationen manuell (mit Ausnahme der letzten aufgeführten Konfiguration), bevor Sie mit Schritt 2 fortfahren.

2. Verwenden Sie das Migrationstool, um die Konfigurationen zu migrieren, die automatisch migriert (oder ignoriert) werden können.

   ${WORKDIR}/migrate_addon -d tmpdir --command migrate-configs
   

   Die Ausgabe sieht in etwa so aus:

   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. Wenden Sie die Root-Vertrauensstellung der Cloud Service Mesh-Zertifizierungsstelle an. So können Sie von der aktuellen Citadel-Zertifizierungsstelle zur Cloud Service Mesh-Zertifizierungsstelle migrieren, ohne Ausfallzeiten für Ihre Anwendungen.

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

   Die Ausgabe sieht in etwa so aus:

   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
   
   

   Dieser Schritt dauert einige Minuten für das Cloud Service Mesh-Root-Zertifikat auf alle Namespaces verteilt werden soll. Warten Sie, bis das Skript mit einer OK-Nachricht beendet wurde.

Der vorherige Schritt führt Folgendes aus:

• Installiert den Root of Trust der Cloud Service Mesh-Zertifizierungsstelle für alle Arbeitslasten in der Cluster.

• Ändert die Konfigurationen der Deployments der Steuerungsebene istio-pilot, istiod und istio-citadel. Die Änderungen umfassen Folgendes:

  • Upgrade der Images auf die neuesten Builds ausführen.
  • trust-domain-Überprüfung durch Festlegen von PILOT_SKIP_VALIDATE_TRUST_DOMAIN=true deaktivieren
  • Root of Trust der Cloud Service Mesh-Zertifizierungsstelle zu istio-citadel hinzufügen, um die ConfigMap auf alle Namespaces zu verteilen
  • Root of Trust der Cloud Service Mesh-Zertifizierungsstelle zu istio-ca-secret hinzufügen, um den Stamm zu verteilen Zertifikat.

• Speichert die älteren Konfigurationsmanifeste im tmpdir.

• Enthält Schritte für die Rollback-Funktion (weiter unten dokumentiert).

Arbeitslasten zu Cloud Service Mesh migrieren

In diesem Abschnitt migrieren Sie auf Istio on GKE ausgeführte Arbeitslasten zu Cloud Service Mesh. Nach der Migration prüfen Sie, ob die richtige Sidecar-Datei Proxys (Cloud Service Mesh) werden in jeden Pod eingefügt und die Anwendung wie erwartet funktioniert.

Wenn Sie diese Prozedur auf einem vorhandenen Cluster ausführen, wählen Sie einen Namespace aus, der migriert werden soll.

1. Definieren Sie den Namespace als Variable. wird dieser Namespace migriert zu Cloud Service Mesh:

   export NAMESPACE=NAMESPACE_NAME
   

2. Wenn Sie Arbeitslasten zu Cloud Service Mesh migrieren möchten, müssen Sie den Namespace für Cloud Service Mesh neu beschriften. Durch das Hinzufügen von Labels zum Namespace kann Cloud Service Mesh um automatisch Sidecars in alle Arbeitslasten einzufügen. Führen Sie den folgenden Befehl aus, um den Namespace mit einem Label zu versehen und legen Sie das Label auf asm-managed fest:

   kubectl --context=${CLUSTER_1_CTX} label namespace ${NAMESPACE} istio.io/rev=asm-managed istio-injection- --overwrite
   

3. Führen Sie einen rollierenden Neustart aller Deployments im Namespace durch:

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

   Die Ausgabe sieht etwa so aus:

   deployment.apps/deploymentName1 restarted
   deployment.apps/deploymentName2 restarted
   ...
   

4. Sorgen Sie dafür, dass alle Pods neu gestartet und mit zwei Containern pro Pod ausgeführt werden:

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

   Die Ausgabe sieht etwa so aus:

   NAME                        READY   STATUS    RESTARTS   AGE
   deploymentName1-PodName     2/2     Running   0          101s
   deploymentName2-PodName     2/2     Running   2          100s
   ...
   

   Eine gute Möglichkeit, diesen Schritt zu überprüfen, bietet das AGE der Pods. Achten Sie darauf, dass der Wert kurz ist, z. B. einige Minuten.

5. Prüfen Sie die Sidecar-Envoy-Proxy-Version von einem der Pods von einem beliebigen Bereitstellung im Namespace, um zu bestätigen, dass jetzt Cloud Service Mesh-Envox-Proxys bereitgestellt wurden:

   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'
   

   Die Ausgabe sieht in etwa so aus:

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

6. Prüfen und testen Sie Anwendungen nach dem Neustart.

   kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
   

7. Optional: Wenn Sie möchten, dass Google Upgrades der Proxys verwaltet, aktivieren Sie die von Google verwaltete Datenebene.

Status der Migration abrufen

Führen Sie den folgenden Befehl aus, um den Status der Migration aufzurufen:

kubectl get cm/asm-addon-migration-state -n istio-system -ojsonpath={.data}

Die Ausgabe gibt an, ob die Migrationen abgeschlossen, ausstehend oder fehlgeschlagen sind:

{"migrationStatus":"SUCCESS"}

{"migrationStatus":"PENDING"}

{"migrationStatus":"MIGRATION_CONFIG_ERROR"}

{"migrationStatus":"CONTROLPLANE_PROVISION_ERROR"}

Wenn migrationStatus SUCCESS ausgibt, wurde die Steuerungsebene erfolgreich ausgeführt Upgrade auf Cloud Service Mesh durchgeführt. Führen Sie die Schritte aus, um die Datenebene manuell zu aktualisieren unter Arbeitslasten migrieren.

Wenn migrationStatus einen anderen Status als SUCCESS ausgibt, haben Sie folgende Möglichkeiten:

• Wenn der Migrationsfehler keine Auswirkungen auf Ihre vorhandenen Istio on GKE-Arbeitslasten hat, müssen Sie nichts weiter unternehmen. Andernfalls führe bei Bedarf einen Rollback durch.
• Die benutzerdefinierten Konfigurationen im Cluster aktualisieren und die Migration manuell noch einmal ausführen, wenn migrationStatus die Anzahl von MIGRATION_CONFIG_ERROR anzeigt.

Sie können sich die Messwerte der Steuerungsebene nach erfolgreicher Migration im Metrics Explorer ansehen. Weitere Informationen finden Sie unter verify_control_plane_metrics.

Auf Cloud Service Mesh-Dashboards zugreifen

In diesem Abschnitt rufen Sie die Cloud Service Mesh-Dashboards auf. Achten Sie darauf, dass Sie die goldenen Signale für alle Dienste erhalten. Sie sollten außerdem in der Lage sein, Ihre Anwendungstopologie zu sehen.

1. Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.

   Zum Cloud Service Mesh

2. Sie sollten nun die Messwerte und die Topologie für Ihre Dienste einsehen können.

Weitere Informationen zu Cloud Service Mesh-Dashboards finden Sie unter Cloud Service Mesh in der Google Cloud Console kennenlernen

Hinweis: Es kann einige Minuten dauern, bis die Topologie- und Tabellenansicht in den Cloud Service Mesh-Dashboards die richtigen Daten enthält.

Erfolgreiche Migration abschließen

In diesem Abschnitt stellen Sie Ihr Istio in GKE für Cloud Service Mesh-Migration. Bevor Sie mit diesem Abschnitt fortfahren, mit Cloud Service Mesh fortfahren möchten. In diesem Abschnitt wird auch beschrieben, wie Sie Ihre Istio on GKE-Artefakte bereinigen. Wenn Sie ein Rollback zu Istio on GKE durchführen möchten, fahren Sie mit dem nächsten Abschnitt fort.

1. Ersetzen Sie das istio-ingressgateway (Teil von Standard-Istio on GKE) durch das von Google verwaltete Gateway für die Steuerungsebene:

   ${WORKDIR}/migrate_addon -d tmpdir --command replace-gateway
   

   Die Ausgabe sieht etwa so aus:

   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. Konfigurieren Sie den Webhook für die Verwendung der von Google verwalteten Steuerungsebene neu. Alle Arbeitslasten verwenden die von Google verwaltete Steuerungsebene:

   ${WORKDIR}/migrate_addon -d tmpdir --command replace-webhook
   

   Die Ausgabe sieht in etwa so aus:

   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. Kennzeichnen Sie alle Namespaces mit dem Cloud Service Mesh-Label und führen Sie eine rollierender Neustart aller Arbeitslasten, um sie auf den Von Google verwaltete Steuerungsebene:

   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}
   

   Sie können die Nachricht "istio-injection not found" in der Ausgabe ignorieren. Das bedeutet, dass der Namespace bisher nicht das Label istio-injection hatte, was bei Neuinstallationen von Cloud Service Mesh oder neuen Bereitstellungen zu erwarten wäre. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Istio on GKE-Dokumentation das Entfernen des Labels istio-injection.

4. Schließen Sie die Migration mit dem folgenden Befehl ab:

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

   Die Ausgabe sieht etwa so aus:

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

5. Deaktivieren Sie Istio on GKE mit dem folgenden Befehl:

   Zonale Cluster

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

   Regionale Cluster

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

6. Bereinigen Sie die Konfigurationen mit dem folgenden Befehl:

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

   Die Ausgabe sieht etwa so aus:

   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. Prüfen Sie, ob Deployments und Dienste von Istio on GKE erfolgreich aus dem Cluster entfernt wurden:

   kubectl --context=${CLUSTER_1_CTX} -n istio-system get deployments,services
   

   Die Ausgabe sieht in etwa so aus:

   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
   
   

   Sie sehen nur den Dienst und das Deployment des Cloud Service Mesh-Ingress-Gateways.

Glückwunsch! Sie haben ohne Ausfallzeiten bei Ihren Anwendungen eine erfolgreiche Migration von Istio on GKE zu Cloud Service Mesh mit der von Google verwalteten Steuerungsebene und der Cloud Service Mesh-Zertifizierungsstelle durchgeführt.

Rollback von Änderungen durchführen

Wenn Sie in diesem Abschnitt nicht mit Cloud Service Mesh fortfahren möchten, können Sie ein Rollback Ihrer Cloud Service Mesh-Änderungen durchführen. Nach Abschluss dieses Abschnitts werden Ihre Arbeitslasten zurück zu Istio on GKE verschoben.

1. Führen Sie ein Rollback der Änderungen am Webhook durch:

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

2. Versehen Sie die Namespaces mit neuen Labels, um Istio in der GKE-Sidecar-Injektion zu verwenden statt Cloud Service Mesh verwenden. Dazu führen Sie den folgenden Befehl aus:

   Für Namespaces mit Arbeitslasten der Version 1.4:

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

   Für Namespaces mit Arbeitslasten der Version 1.6:

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

3. Führen Sie einen rollierenden Neustart aller Deployments im Namespace durch:

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

4. Warten Sie einige Minuten und prüfen Sie, ob alle Pods ausgeführt werden:

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

   Die Ausgabe sieht etwa so aus:

   NAME                       READY   STATUS    RESTARTS   AGE
   deploymentName1-PodName    2/2     Running   0          101s
   deploymentName2-PodName    2/2     Running   2          100s
   ...
   
   

5. Prüfen Sie die Envoy-Proxy-Version der Sidecar-Datei von einem der Pods, um zu bestätigen, dass Sie Envoy-Proxys von Istio on GKE v1.4 bereitgestellt haben:

   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'
   

   Die Ausgabe sieht in etwa so aus:

   "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
   "appContainerImage"
   

   oder

   "gke.gcr.io/istio/proxyv2:1.6.14-gke.4"
   "appContainerImage"
   

6. Prüfen und testen Sie Anwendungen nach dem Neustart.

7. Führen Sie ein Rollback der Änderungen an der Cloud Service Mesh-Zertifizierungsstelle durch:

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

8. Aktivieren Sie den Istio Galley-Webhook wieder:

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

Sie haben Ihre Änderungen erfolgreich auf Istio on GKE zurückgesetzt.

Online Boutique bereitstellen

In diesem Abschnitt stellen Sie eine auf Mikrodiensten basierende Beispielanwendung namens „Online Boutique” im GKE-Cluster bereit. Online Boutique wird in einem Istio-fähigen Namespace bereitgestellt. Prüfen Sie, ob die Anwendung funktioniert und Istio on GKE die Sidecar-Proxys in jeden Pod einfügt.

Wenn Sie bereits Cluster mit Anwendungen haben, können Sie einen neuen Namespace erstellen und Online Boutique bereitstellen. Den gleichen Prozess können Sie für alle Namespaces in der Abschnitt Arbeitslasten zu Cloud Service Mesh migrieren.

1. Stellen Sie Online Boutique im GKE-Cluster bereit:

   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. Warten Sie, bis alle Deployments bereit sind:

   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. Prüfen Sie, ob pro Pod zwei Container vorhanden sind: der Anwendungscontainer und der Istio-Sidecar-Proxy, der Istio on GKE automatisch in den Pod einfügt:

   kubectl --context=${CLUSTER_1_CTX} -n online-boutique get pods
   

   Die Ausgabe sieht etwa so aus:

   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. Sie können auch anhand der Sidecar-Envoy-Proxy-Version von einem der Pods prüfen, ob Sie Istio on GKE v1.4-Envoy-Proxys bereitgestellt haben:

   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'
   

   Die Ausgabe sieht etwa so aus:

   "gke.gcr.io/istio/proxyv2:1.4.10-gke.8"
   "gcr.io/google-samples/microservices-demo/frontend:v0.3.4"
   

5. Greifen Sie über die IP-Adresse der Dienst-IP-Adresse istio-ingressgateway auf die Anwendung zu:

   kubectl --context=${CLUSTER_1_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
   

Häufig gestellte Fragen

In diesem Abschnitt finden Sie Antworten auf häufig gestellte Fragen und zugehörige Antworten zu von Istio on GKE zu Cloud Service Mesh migrieren.

Warum werde ich von Istio on GKE zu Cloud Service Mesh migriert?

Istio in Google Kubernetes Engine ist ein Beta-Feature, das von Google verwaltetes Istio in einem GKE-Cluster (Google Kubernetes Engine) bereitstellt. Istio on GKE stellt eine nicht unterstützte Version (Istio-Version 1.4) bereit. Um Ihnen den neuesten Service zur Verfügung zu stellen und einer unterstützten Service-Mesh-Implementierung Istio on GKE-Nutzer mit Cloud Service Mesh

Cloud Service Mesh ist das verwaltete und unterstützte Service Mesh-Produkt von Google, das auf Istio APIs basiert. Cloud Service Mesh ist für Istio, was GKE ist Kubernetes. Da Cloud Service Mesh auf Istio APIs basiert, können Sie Ihre Istio-Konfigurationen bei der Migration zu Cloud Service Mesh. Darüber hinaus gibt es keine proprietäre Anbieterbindung.

Cloud Service Mesh bietet die folgenden Vorteile:

• Ein von Google verwaltetes und von Google unterstütztes Service Mesh
• Istio APIs ohne Anbieterbindung.
• Sofort einsatzbereite Telemetrie-Dashboards und SLO-Verwaltung, ohne dass zusätzliche Lösungen von Drittanbietern verwaltet werden müssen.
• Optionen für von Google gehostete Zertifizierungsstellen.
• Einbindung in Google Cloud-Netzwerke und Identity-Aware Proxy (IAP).
• Unterstützung von Hybrid- und Multi-Cloud-Plattformen

Weitere Informationen zu den Features und Funktionen von Cloud Service Mesh finden Sie unter Von Google verwaltete Features der Steuerungsebene

Kommt bei dieser Migration eine Ausfallzeit vor?

Das Migrationsskript ist so konzipiert, dass Ausfallzeiten vermieden werden. Das Skript installiert Cloud Service Mesh als Canary-Steuerungsebene zusammen mit Ihrer vorhandenen Istio-Steuerungsebene. istio-ingressgateway wird aktualisiert. Anschließend benennen Sie die Istio-fähigen Namespaces um, um zu beginnen, Cloud Service Mesh mit der Cloud Service Mesh-Zertifizierungsstelle verwenden.

Stellen Sie sicher, dass Sie PodDisruptionBudgets Ihre Anwendungen ordnungsgemäß konfiguriert sind, damit Sie Anwendungsausfallzeiten. Auch wenn Sie Ausfallzeiten vermeiden können, wird empfohlen, dass Sie diese Migration während eines geplanten Wartungsfensters durchführen, wenn Sie diese Migration selbst durchführen. Von Google gesteuerte Migrationen werden während eines GKE-Wartungsfensters ausgeführt. Für Ihre GKE-Cluster müssen Wartungsfenster konfiguriert sein.

Fallen für die Nutzung des Cloud Service Mesh Kosten an?

Es gibt zwei Möglichkeiten, Cloud Service Mesh in GKE zu verwenden:

• Wenn Sie GKE Enterprise-Abonnent sind, ist Cloud Service Mesh enthalten als Teil Ihres GKE Enterprise-Abos

• Wenn Sie kein GKE Enterprise-Abonnent sind, können Sie Cloud Service Mesh als eigenständiges Produkt in GKE (mit Google Cloud) verwenden. Weitere Informationen finden Sie unter Cloud Service Mesh-Preisdetails

Gibt es Features oder Konfigurationen, die in der neuesten Version des Cloud Service Mesh nicht unterstützt werden?

Das Skript prüft alle Istio-Konfigurationen und migriert sie auf die neueste Version Cloud Service Mesh-Version. Es gibt bestimmte Konfigurationen, die möglicherweise zusätzliche Schritte erfordern, die von der Istio-Version 1.4 zu Cloud Service Mesh Version 1.10 migriert werden müssen. Das Skript führt eine Konfigurationsprüfung aus und informiert Sie, wenn Konfigurationen zusätzliche Schritte erfordern.

Ändert die Migration meine aktuellen Istio-Konfigurationen?

Nein, Ihre Istio-Konfigurationen funktionieren in Cloud Service Mesh, ohne dass Änderungen.

Kann ich nach der Migration zu Cloud Service Mesh wieder zurück zu Istio migrieren?

Ja. Es besteht keine Verpflichtung, Cloud Service Mesh zu verwenden. Sie können Cloud Service Mesh deinstallieren und Istio jederzeit neu installieren.

Ist ein Rollback möglich, falls die Migration fehlschlägt?

Ja, mit dem Skript können Sie ein Rollback zu Ihrer vorherigen Istio on GKE-Version durchführen.

Welche Version von Istio kann ich mit diesem Skript migrieren?

Das Skript unterstützt Sie bei der Migration von der Istio on GKE-Version 1.4 zur Cloud Service Mesh-Version 1.10. Das Skript prüft Ihre Istio-Version vor der Migration und informiert Sie darüber, ob Ihre Istio-Version migriert werden kann.

Wo erhalte ich weitere Hilfe bei der Migration?

Unser Supportteam hilft Ihnen gern weiter. Sie können eine Supportanfrage über die Google Cloud Console erstellen. Weitere Informationen finden Sie unter Supportfälle verwalten.

Was passiert, wenn ich nicht zu Cloud Service Mesh migriere?

Ihre Istio-Komponenten funktionieren weiterhin, aber Google verwaltet Ihre Istio-Installation nicht mehr. Sie erhalten keine automatischen Updates mehr und die Installation kann nicht garantiert werden, wenn die Version des Kubernetes-Clusters aktualisiert wird.

Weitere Informationen finden Sie unter Istio-Unterstützung.