Von Istio on GKE zu Cloud Service Mesh migrieren
In dieser Anleitung wird beschrieben, wie Sie einen GKE-Cluster (Google Kubernetes Engine) mit Istio in Google Kubernetes Engine (Istio in GKE) Version 1.4 oder 1.6 (Beta) auf verwaltetes Cloud Service Mesh mit der von Google verwalteten Steuerungsebene und der Cloud Service Mesh-Zertifizierungsstelle aktualisieren.
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
- Stellen Sie die von Google verwaltete Cloud Service Mesh-Steuerungsebene im regulären Kanal bereit. Diese Anleitung bezieht sich speziell auf die regulären, stabilen und 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.
- Konfigurieren Sie die Cloud Service Mesh-Zertifizierungsstelle.
- Anwendungen zum Cloud Service Mesh migrieren
- Führen Sie ein Upgrade von
istio-ingressgateway
von Istio on GKE auf Cloud Service Mesh durch. - Schließen Sie die Cloud Service Mesh-Migration ab oder führen Sie ein Rollback zu Istio in GKE durch.
Umgebung einrichten
So richten Sie Ihre Umgebung ein:
Aktivieren Sie Cloud Shell in der Google Cloud Console.
Unten auf der Seite der Google Cloud Console wird eine Cloud Shell-Sitzung mit einer Befehlszeilen-Eingabeaufforderung gestartet. Cloud Shell ist eine Shell-Umgebung, in der die Google Cloud CLI und die Google Cloud CLI bereits installiert und die Werte bereits für Ihr aktuelles Projekt festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
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.
Erstellen Sie einen
WORKDIR
-Ordner. Alle mit dieser Anleitung verknüpften Dateien enden inWORKDIR
, sodass SieWORKDIR
löschen können, wenn Sie fertig sind.mkdir -p addon-to-asm && cd addon-to-asm && export WORKDIR=`pwd`
Erstellen Sie eine
KUBECONFIG
-Datei für diese Anleitung. Sie können auch Ihre vorhandeneKUBECONFIG
-Datei verwenden, die den Clusterkontext für den GKE-Cluster enthält, der zu Cloud Service Mesh migriert werden soll.touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
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}
Ihre Cluster müssen in einer Flotte registriert sein. Dieser Schritt kann separat vor der Installation oder als Teil der Installation durchgeführt werden. Dazu übergeben Sie die Flags „--fleet-id“ und eines der Flags „--enable-all“ oder „--enable-registration“.
In Ihrem Projekt muss das Service Mesh-Feature aktiviert sein. Sie können es im Rahmen der Installation aktivieren, indem Sie eines der Flags --enable-all oder --enable-registration übergeben oder vor der Installation den folgenden Befehl ausführen:
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 eines regulären Kanals im GKE-Cluster bereit. Diese Steuerungsebene wird zuerst zusammen als zweite (oder Canary-)Steuerungsebene bereitgestellt.
Laden Sie die neueste Version des Skripts herunter, das Cloud Service Mesh im aktuellen Arbeitsverzeichnis installiert, und machen Sie das Skript ausführbar:
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli chmod +x asmcli
Führen Sie zum Konfigurieren des GKE-Cluster das Installationsskript aus, 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.
Kopieren Sie
istioctl
in den OrdnerWORKDIR
:cp ./${CLUSTER_1}/istioctl ${WORKDIR}/.
Im nächsten Abschnitt laden Sie das Skript migrate_addon
herunter und führen es aus, um die Migration zu Cloud Service Mesh zu unterstützen. 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.
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
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 in 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
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 in 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 vor der Migration zu Cloud Service Mesh manuell 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 on GKE verwendet werden, werden diese Zertifikate nach der Migration der Arbeitslasten zur von Google verwalteten Steuerungsebene nicht verwendet. Alle Arbeitslasten verwenden Zertifikate, 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 stattdessenspec.http.headers
. - Die Verwendung von
websocketUpgrade
ist nicht erforderlich. Sie ist standardmäßig aktiviert. - Ersetzen Sie das Feld
abort.percent
durchabort.percentage
.
- Die Verwendung von
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:
Migrieren Sie alle benutzerdefinierten Konfigurationen manuell (mit Ausnahme der letzten aufgeführten Konfiguration), bevor Sie mit Schritt 2 fortfahren.
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
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 ohne Ausfallzeiten für Ihre Anwendungen migrieren.
${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, bis das Cloud Service Mesh-Root-Zertifikat an alle Namespaces verteilt wird. 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 im Cluster.
Ändert die Konfigurationen der Deployments der Steuerungsebene
istio-pilot
,istiod
undistio-citadel
. Die Änderungen umfassen Folgendes:- Upgrade der Images auf die neuesten Builds ausführen.
trust-domain
-Überprüfung durch Festlegen vonPILOT_SKIP_VALIDATE_TRUST_DOMAIN=true
deaktivieren- Root of Trust der Cloud Service Mesh-Zertifizierungsstelle zu
istio-citadel
hinzufügen, umConfigMap
auf alle Namespaces zu verteilen. - Root of Trust der Cloud Service Mesh-Zertifizierungsstelle zu
istio-ca-secret
hinzufügen, um das Root-Zertifikat zu verteilen.
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 Arbeitslasten, die auf Istio in GKE ausgeführt werden, zu Cloud Service Mesh. Prüfen Sie nach der Migration, ob die richtigen Sidecar-Proxys (Cloud Service Mesh) in jeden Pod eingefügt wurden 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.
Definieren Sie den Namespace als Variable. Dieser Namespace wird zu Cloud Service Mesh migriert:
export NAMESPACE=NAMESPACE_NAME
Zum Migrieren von Arbeitslasten zu Cloud Service Mesh müssen Sie den Namespace für Cloud Service Mesh neu benennen. Durch das Hinzufügen von Labels zum Namespace kann Cloud Service Mesh automatisch Sidecars in alle Arbeitslasten einfü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
Führen Sie einen rollierenden Neustart aller Deployments im Namespace durch:
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
Die Ausgabe sieht in etwa so aus:
deployment.apps/deploymentName1 restarted deployment.apps/deploymentName2 restarted ...
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 in 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.Prüfen Sie die Sidecar-Proxy-Version des Envoy-Proxys von einem der Pods aus einem beliebigen Deployment im Namespace, um zu bestätigen, dass jetzt Cloud Service Mesh-Envoy-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"
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}'
Optional: Wenn Google Upgrades der Proxys verwalten soll, 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 auf Cloud Service Mesh aktualisiert. Führen Sie die Schritte unter Arbeitslasten migrieren aus, um die Datenebene manuell zu aktualisieren.
Wenn migrationStatus
einen anderen Status als SUCCESS
ausgibt, haben Sie folgende Möglichkeiten:
- Ergreifen Sie keine zusätzlichen Maßnahmen, wenn sich der Migrationsfehler nicht auf Ihr vorhandenes Istio on GKE-Arbeitslasten auswirkt. Andernfalls können Sie bei Bedarf ein rollback durchführen.
- Die benutzerdefinierten Konfigurationen im Cluster aktualisieren und die Migration manuell noch einmal ausführen, wenn
migrationStatus
die Anzahl vonMIGRATION_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 und prüfen, ob Sie die goldenen Signale für alle Dienste erhalten. Sie sollten außerdem in der Lage sein, Ihre Anwendungstopologie zu sehen.
Rufen Sie in der Google Cloud Console die Seite Cloud Service Mesh auf.
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 erkunden.
Erfolgreiche Migration abschließen
In diesem Abschnitt schließen Sie die Migration von Istio on GKE zu Cloud Service Mesh ab. Bevor Sie mit diesem Abschnitt fortfahren, müssen Sie mit Cloud Service Mesh fortfahren. 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.
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 in 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
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
Kennzeichnen Sie alle Namespaces mit dem Cloud Service Mesh-Label und führen Sie einen rollierenden Neustart aller Arbeitslasten durch, um sie auf die von Google verwaltete Steuerungsebene zu übertragen:
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 zuvor nicht das Labelistio-injection
hatte, was Sie bei Neuinstallationen von Cloud Service Mesh oder neuen Bereitstellungen erwarten sollten. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl dasistio-injection
- als auch das Überarbeitungslabel hat, beinhalten allekubectl label
-Befehle in der Istio on GKE-Dokumentation das Entfernen des Labelsistio-injection
.Schließen Sie die Migration mit dem folgenden Befehl ab:
${WORKDIR}/migrate_addon -d tmpdir --command write-marker
Die Ausgabe sieht in etwa so aus:
Current migration state: SUCCESS Running: kubectl apply -f - configmap/asm-addon-migration-state created OK
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
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
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 die Bereitstellung des Cloud Service Mesh-Ingress-Gateways.
Glückwunsch! Sie haben mit der von Google verwalteten Steuerungsebene und der Cloud Service Mesh-Zertifizierungsstelle erfolgreich von Istio on GKE zu Cloud Service Mesh migriert, ohne dass es zu Ausfallzeiten für Ihre Anwendungen kommt.
Rollback von Änderungen durchführen
Wenn Sie in diesem Abschnitt nicht mit Cloud Service Mesh fortfahren möchten, können Sie ein Rollback für Ihre Cloud Service Mesh-Änderungen durchführen. Nach Abschluss dieses Abschnitts werden Ihre Arbeitslasten zurück zu Istio on GKE verschoben.
Rollback der Änderungen des mutierenden Webhooks durchführen:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mutatingwebhook
Benennen Sie die Namespaces um, um Istio in der GKE-Sidecar-Einfügung anstelle von Cloud Service Mesh zu verwenden. Führen Sie dazu 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
Führen Sie einen rollierenden Neustart aller Deployments im Namespace durch:
kubectl --context=${CLUSTER_1_CTX} rollout restart deployment -n ${NAMESPACE}
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 in etwa so aus:
NAME READY STATUS RESTARTS AGE deploymentName1-PodName 2/2 Running 0 101s deploymentName2-PodName 2/2 Running 2 100s ...
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"
Prüfen und testen Sie Anwendungen nach dem Neustart.
Führen Sie ein Rollback der Änderungen der Cloud Service Mesh-Zertifizierungsstelle durch:
${WORKDIR}/migrate_addon -d tmpdir --command rollback-mesh-ca
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. Führen Sie diesen Vorgang für alle Namespaces im Abschnitt Arbeitslasten zu Cloud Service Mesh migrieren aus.
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
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
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 in 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
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 in etwa so aus:
"gke.gcr.io/istio/proxyv2:1.4.10-gke.8" "gcr.io/google-samples/microservices-demo/frontend:v0.3.4"
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 häufig gestellte Fragen und zugehörige Antworten zur Migration von Istio on GKE zu Cloud Service Mesh.
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. Damit Sie die neuesten Service Mesh-Funktionen und eine unterstützte Service-Mesh-Implementierung erhalten, führen wir ein Upgrade aller Nutzer von Istio in GKE auf Cloud Service Mesh durch.
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 das, was GKE für Kubernetes ist. Da Cloud Service Mesh auf Istio APIs basiert, können Sie bei der Migration zu Cloud Service Mesh weiterhin Ihre Istio-Konfigurationen verwenden. Darüber hinaus gibt es keine proprietäre Anbieterbindung.
Cloud Service Mesh bietet folgende 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 Leistungsmerkmalen 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 zusammen mit der vorhandenen Istio-Steuerungsebene als Canary-Steuerungsebene. istio-ingressgateway
wird aktualisiert. Anschließend benennen Sie die Istio-fähigen Namespaces um, um Cloud Service Mesh mit der Cloud Service Mesh-Zertifizierungsstelle zu verwenden.
Achten Sie darauf, dass PodDisruptionBudgets richtig für Ihre Anwendungen konfiguriert ist, um Anwendungsausfälle zu vermeiden. 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 in Ihrem GKE Enterprise-Abo enthalten.
Wenn Sie kein GKE Enterprise-Abonnent sind, können Sie Cloud Service Mesh als eigenständiges Produkt in GKE (in Google Cloud) verwenden. Weitere Informationen finden Sie unter Cloud Service Mesh – Preise.
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 zur neuesten Cloud Service Mesh-Version. Bei bestimmten Konfigurationen sind möglicherweise zusätzliche Schritte erforderlich, um von Istio-Version 1.4 zu Cloud Service Mesh-Version 1.10 zu migrieren. 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 erforderlich sind.
Kann ich nach der Migration zu Cloud Service Mesh wieder zurück zu Istio migrieren?
Ja, Sie müssen das Cloud Service Mesh nicht verwenden. Sie können jederzeit Cloud Service Mesh deinstallieren und Istio 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 Istio on GKE Version 1.4 zu 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 über die Google Cloud Console eine Supportanfrage öffnen. 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.