Diese Seite ist Teil einer mehrseitigen Anleitung, in der erläutert wird, wie Sie von Istio zur Anthos Service Mesh-Version 1.10.6 in einem GKE-Cluster für ein Mesh mit mehreren Clustern migrieren, die sich in verschiedenen Google Cloud-Projekten befinden. Wenn Sie über eine frühere Version von Istio verfügen, müssen Sie vor der Migration zu Anthos Service Mesh ein Upgrade ausführen. Wenn Sie ein Upgrade ausführen müssen, rufen Sie die Seite Istio aktualisieren in der entsprechenden Version von Istio auf. Das Upgrade von Istio auf mehr als eine Nebenversion (z. B. 1.6.x auf 1.8.x) in einem Schritt wird nicht offiziell getestet oder empfohlen.
Informationen zu Migrationen in einem Mesh-Netzwerk mit einem einzelnen Cluster oder für ein Mesh-Netzwerk, das mehrere Cluster im selben Google Cloud-Projekt enthält, finden Sie unter Installation, Migration und Upgrade für GKE.
Hinweise
Bevor Sie Anthos Service Mesh installieren, müssen folgende Voraussetzungen erfüllt sein:
- Richten Sie Ihre Umgebung ein, um die benötigten Tools zu installieren.
- Richten Sie Ihr Projekt ein, um die erforderlichen APIs zu aktivieren und Berechtigungen festzulegen.
- Richten Sie den Cluster ein, um die erforderlichen Clusteroptionen zu aktivieren.
Migration vorbereiten
Weitere Informationen finden Sie unter Migration von Istio vorbereiten.
Folgen Sie für die Migration von Istio dem revisionsbasierten Upgradeprozess (in der Istio-Dokumentation als "Canary-Upgrades" bezeichnet). Mit einem revisionsbasierten Upgrade installieren Sie eine neue Version der Steuerungsebene zusammen mit der vorhandenen Steuerungsebene. Wenn Sie istioctl install
ausführen, fügen Sie e ine Option hinzu, mit der Sie ein revision
-Label festlegen können, das die neue Steuerungsebene identifiziert.
Anschließend migrieren Sie zur neuen Version. Legen Sie dazu für Ihre Arbeitslasten dasselbe revision
-Label fest und führen Sie einen rollierenden Neustart durch, um die neue Anthos Service Mesh-Version und -Konfiguration in die Proxys einzufügen. Bei diesem Ansatz können Sie die Auswirkungen des Upgrades auf einen kleinen Prozentsatz Ihrer Arbeitslasten überwachen. Nachdem Sie Ihre Anwendung getestet haben, können Sie den gesamten Traffic zur neuen Version migrieren. Dieser Ansatz ist wesentlich sicherer als ein direktes Upgrade, bei dem eine neue Steuerungsebene die vorherige Version der Steuerungsebene ersetzt.
Anmeldedaten und Berechtigungen festlegen
Initialisieren Sie Ihr Projekt, um es für die Installation vorzubereiten. Mit diesem Befehl wird unter anderem ein Dienstkonto erstellt, mit dem Komponenten der Datenebene, wie der Sidecar-Proxy, sicher auf die Daten und Ressourcen Ihres Projekts zugreifen können.
curl --request POST \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --data '' \ "https://meshconfig.googleapis.com/v1alpha1/projects/${PROJECT_ID}:initialize"
Der Befehl gibt ein Paar leere geschweifte Klammern zurück:
{}
Rufen Sie die Anmeldedaten für die Authentifizierung ab, um mit dem Cluster zu interagieren: Mit diesem Befehl wird auch der aktuelle Kontext für
kubectl
auf den Cluster festgelegt.gcloud container clusters get-credentials ${CLUSTER_NAME} \ --project=${PROJECT_ID}
Gewähren Sie dem aktuellen Nutzer Cluster-Administratorberechtigungen. Sie benötigen diese Berechtigungen, um die erforderlichen Regeln für die rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) für Anthos Service Mesh zu erstellen.
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole=cluster-admin \ --user="$(gcloud config get-value core/account)"
Wenn der Fehler "cluster-admin-binding" already exists
angezeigt wird, können Sie ihn ignorieren und mit der vorhandenen Cluster-Administratorbindung fortfahren.
Installationsdatei herunterladen
Linux
Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-linux-amd64.tar.gz
Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit
openssl
:curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-linux-amd64.tar.gz.1.sig openssl dgst -verify /dev/stdin -signature istio-1.10.6-asm.2-linux-amd64.tar.gz.1.sig istio-1.10.6-asm.2-linux-amd64.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
Folgende Ausgabe wird erwartet:
Verified OK
Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis:
tar xzf istio-1.10.6-asm.2-linux-amd64.tar.gz
Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis
istio-1.10.6-asm.2
ein Installationsverzeichnis erstellt, das Folgendes enthält:- Beispielanwendungen im Verzeichnis
samples
. - Das
istioctl
-Befehlszeilentool, mit dem Sie Anthos Service Mesh installieren, befindet sich im Verzeichnisbin
. - Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis
manifests/profiles
.
- Beispielanwendungen im Verzeichnis
Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden.
cd istio-1.10.6-asm.2
macOS
Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-osx.tar.gz
Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit
openssl
:curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-osx.tar.gz.1.sig openssl dgst -sha256 -verify /dev/stdin -signature istio-1.10.6-asm.2-osx.tar.gz.1.sig istio-1.10.6-asm.2-osx.tar.gz <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
Folgende Ausgabe wird erwartet:
Verified OK
Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis:
tar xzf istio-1.10.6-asm.2-osx.tar.gz
Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis
istio-1.10.6-asm.2
ein Installationsverzeichnis erstellt, das Folgendes enthält:- Beispielanwendungen im Verzeichnis
samples
. - Das
istioctl
-Befehlszeilentool, mit dem Sie Anthos Service Mesh installieren, befindet sich im Verzeichnisbin
. - Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis
manifests/profiles
.
- Beispielanwendungen im Verzeichnis
Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden.
cd istio-1.10.6-asm.2
Windows
Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-win.zip
Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit
openssl
:curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-win.zip.1.sig openssl dgst -verify - -signature istio-1.10.6-asm.2-win.zip.1.sig istio-1.10.6-asm.2-win.zip <<'EOF' -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF
Folgende Ausgabe wird erwartet:
Verified OK
Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis:
tar xzf istio-1.10.6-asm.2-win.zip
Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis
istio-1.10.6-asm.2
ein Installationsverzeichnis erstellt, das Folgendes enthält:- Beispielanwendungen im Verzeichnis
samples
. - Das
istioctl
-Befehlszeilentool, mit dem Sie Anthos Service Mesh installieren, befindet sich im Verzeichnisbin
. - Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis
manifests/profiles
.
- Beispielanwendungen im Verzeichnis
Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden.
cd istio-1.10.6-asm.2
Ressourcenkonfigurationsdateien vorbereiten
Wenn Sie den Befehl istioctl install
ausführen, geben Sie -f istio-operator.yaml
in der Befehlszeile an. Diese Datei enthält Informationen zu Ihrem Projekt und Cluster, die Anthos Service Mesh erfordert. Sie müssen ein Paket mit istio-operator.yaml
- und anderen Ressourcenkonfigurationsdateien herunterladen, um die Projekt- und Clusterinformationen festlegen zu können.
So bereiten Sie die Ressourcenkonfigurationsdateien vor:
Mesh CA
Erstellen Sie ein neues Verzeichnis für die Ressourcenkonfigurationsdateien des Anthos Service Mesh-Pakets. Es empfiehlt sich, den Clusternamen als Verzeichnisnamen zu verwenden.
Wechseln Sie zu dem Verzeichnis, in das Sie das Anthos Service Mesh-Paket herunterladen möchten.
Prüfen Sie die
kpt
-Version. Führen Sie eine kpt-Version vor 1.x aus:kpt version
Die Ausgabe sollte in etwa so aussehen:
0.39.2
Wenn Sie
kpt
-Version 1.x oder höher haben, lesen Sie den Abschnitt Umgebung einrichten, um die erforderliche Version für Ihr Betriebssystem herunterzuladen.Laden Sie das Paket herunter:
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.10-asm asm
Legen Sie die Projekt-ID für das Projekt fest, in dem der Cluster erstellt wurde:
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
Legen Sie die Projektnummer für das Flotten-Hostprojekt fest:
kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
Legen Sie den Clusternamen fest:
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
Legen Sie die Standardzone oder -region fest:
kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
Setzen Sie das Tag auf die Version des Anthos Service Mesh, das Sie installieren:
kpt cfg set asm anthos.servicemesh.tag 1.10.6-asm.2
Legen Sie die Überarbeitung in den Konfigurationsdateien der Anthos Service Mesh-Paketressourcen fest:
kpt cfg set asm anthos.servicemesh.rev asm-1106-2
Wenn Sie Anthos Service Mesh installieren, legen Sie ein Überarbeitungslabel auf
istiod
fest. Sie müssen für den Validierungs-Webhook dieselbe Überarbeitung festlegen.Da sich die Cluster in Ihrer Multi-Cluster-Konfiguration in verschiedenen Projekten befinden, müssen Sie die vertrauenswürdigen Domain-Aliasse für die anderen Projekte konfigurieren, die das Service Mesh mit mehreren Clustern oder mehreren Projekten bilden.
Rufen Sie die Projekt-ID aller Cluster im Multi-Cluster-/Multi-Projekt-Mesh ab.
Legen Sie für die Projekt-ID jedes Clusters die vertrauenswürdigen Domain-Aliase fest. Wenn Sie beispielsweise Cluster in drei Projekten haben, führen Sie den folgenden Befehl aus und ersetzen Sie
PROJECT_ID_1
,PROJECT_ID_2
undPROJECT_ID_3
durch die Projekt-ID jedes Clusters.kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog
Wenn Sie die Cluster in den anderen Projekten konfigurieren, können Sie denselben Befehl verwenden.
Mithilfe der vertrauenswürdigen Domain-Aliasse kann Mesh CA Arbeitslasten in Clustern in anderen Projekten authentifizieren. Zusätzlich zur Festlegung der vertrauenswürdigen Domain-Aliasse müssen Sie nach der Installation von Anthos Service Mesh das clusterübergreifende Load-Balancing aktivieren.
Geben Sie die Werte der
kpt
-Setter aus:kpt cfg list-setters asm
Die Ausgabe dieses Befehls sieht in etwa so aus:
NAME VALUE anthos.servicemesh.canonicalServiceHub gke.gcr.io/asm/canonical-service-controller:1.10.6-asm.2 anthos.servicemesh.controlplane.monitoring.enabled true anthos.servicemesh.hub gke.gcr.io/asm anthos.servicemesh.hubMembershipID MEMBERSHIP_ID anthos.servicemesh.tag 1.10.6-asm.2 anthos.servicemesh.trustDomainAliases [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog] base-dir base gcloud.compute.location us-central gcloud.compute.network default gcloud.compute.subnetwork default gcloud.container.cluster example-cluster-1 gcloud.container.cluster.clusterSecondaryRange gcloud.container.cluster.releaseChannel REGULAR gcloud.container.cluster.servicesSecondaryRange gcloud.container.nodepool.max-nodes 4 gcloud.core.project example-project-12345 gcloud.project.environProjectID FLEET_PROJECT_ID gcloud.project.environProjectNumber 1234567890123 gcloud.project.projectNumber 9876543210987
Prüfen Sie, ob die Werte für die folgenden Setter korrekt sind:
- anthos.servicemesh.rev
- anthos.servicemesh.tag
- anthos.servicemesh.trustDomainAliases
- gcloud.compute.location
- gcloud.container.cluster
- gcloud.core.project
- gcloud.project.environProjectNumber
Sie können die Werte für die anderen Setter ignorieren.
Istio CA
Erstellen Sie ein neues Verzeichnis für die Ressourcenkonfigurationsdateien des Anthos Service Mesh-Pakets. Es empfiehlt sich, den Clusternamen als Verzeichnisnamen zu verwenden.
Wechseln Sie zu dem Verzeichnis, in das Sie das Anthos Service Mesh-Paket herunterladen möchten.
Prüfen Sie die
kpt
-Version. Führen Sie eine kpt-Version vor 1.x aus:kpt version
Die Ausgabe sollte in etwa so aussehen:
0.39.2
Wenn Sie die
kpt
-Version 1.x oder höher haben, laden Sie die erforderliche Version herunter:curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2 chmod +x kpt_0_39_2 alias kpt="$(readlink -f kpt_0_39_2)"
Laden Sie das Paket herunter:
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.10-asm asm
Legen Sie die Projekt-ID für das Projekt fest, in dem der Cluster erstellt wurde:
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
Legen Sie die Projektnummer für das Flotten-Hostprojekt fest:
kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}
Legen Sie den Clusternamen fest:
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
Legen Sie die Standardzone oder -region fest:
kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
Setzen Sie das Tag auf die Version des Anthos Service Mesh, das Sie installieren:
kpt cfg set asm anthos.servicemesh.tag 1.10.6-asm.2
Legen Sie die Überarbeitung in den Konfigurationsdateien der Anthos Service Mesh-Paketressourcen fest:
kpt cfg set asm anthos.servicemesh.rev asm-1106-2
Geben Sie die Werte der
kpt
-Setter aus:kpt cfg list-setters asm
Die Ausgabe dieses Befehls sieht in etwa so aus:
NAME VALUE anthos.servicemesh.canonicalServiceHub gke.gcr.io/asm/canonical-service-controller:1.10.6-asm.2 anthos.servicemesh.controlplane.monitoring.enabled true anthos.servicemesh.hub gke.gcr.io/asm anthos.servicemesh.hubMembershipID MEMBERSHIP_ID anthos.servicemesh.tag 1.10.6-asm.2 anthos.servicemesh.trustDomainAliases base-dir base gcloud.compute.location us-central gcloud.compute.network default gcloud.compute.subnetwork default gcloud.container.cluster example-cluster-1 gcloud.container.cluster.clusterSecondaryRange gcloud.container.cluster.releaseChannel REGULAR gcloud.container.cluster.servicesSecondaryRange gcloud.container.nodepool.max-nodes 4 gcloud.core.project example-project-12345 gcloud.project.environProjectID FLEET_PROJECT_ID gcloud.project.environProjectNumber 1234567890123 gcloud.project.projectNumber 9876543210987
Prüfen Sie, ob die Werte für die folgenden Setter korrekt sind:
- anthos.servicemesh.rev
- anthos.servicemesh.tag
- gcloud.compute.location
- gcloud.container.cluster
- gcloud.core.project
- gcloud.project.environProjectNumber
Sie können die Werte für die anderen Setter ignorieren.
Zu Anthos Service Mesh migrieren
Mesh CA
Prüfen Sie, ob der aktuelle
kubeconfig
-Kontext auf den Cluster verweist, auf dem Sie Anthos Service Mesh installieren möchten:kubectl config current-context
Die Ausgabe hat das folgende Format:
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
Der
kubeconfig
-Kontext und die Werte derkpt
-Setter müssen übereinstimmen. Führen Sie bei Bedarf den Befehlgcloud container clusters get-credentials
aus, um den aktuellenkubeconfig
-Kontext festzulegen.Wechseln Sie gegebenenfalls zum Verzeichnis
istio-1.10.6-asm.2
. Deristioctl
-Client ist versionsabhängig. Sie müssen die Version im Verzeichnisistio-1.10.6-asm.2/bin
verwenden.Führen Sie den folgenden Befehl aus, um die neue Steuerungsebene mit dem Profil
asm-gcp-multiproject
bereitzustellen. Wenn Sie ein unterstütztes optionales Feature aktivieren möchten, fügen Sie in der folgenden Befehlszeile-f
und den YAML-Dateinamen hinzu. Weitere Informationen finden Sie unter Optionale Features aktivieren.bin/istioctl install \ -f asm/istio/istio-operator.yaml \ -f asm/istio/options/multiproject.yaml \ -f asm/istio/options/multicluster.yaml \ --revision=asm-1106-2
Mit dem Argument
--revision
wirdistiod
ein Überarbeitungslabel im Formatistio.io/rev=asm-1106-2
hinzugefügt. Das Überarbeitungslabel wird vom automatischen Sidecar-Injektor-Webhook verwendet, um eingefügte Sidecars mit einer bestimmtenistiod
-Überarbeitung zu verknüpfen. Wenn Sie die automatische Sidecar-Injektion für einen Namespace aktivieren möchten, müssen Sie ihn mit einer Überarbeitung versehen, die eineristiod
-Bereitstellung entspricht.Mit den folgenden Dateien werden die Einstellungen in der Datei
istio-operator.yaml
überschrieben:Mit der Datei
multiproject.yaml
wird das Profilasm-gcp-multiproject
festgelegt.Mit der Datei
multicluster.yaml
werden die Einstellungen konfiguriert, die Anthos Service Mesh für eine Konfiguration mit mehreren Clustern benötigt.
Prüfen Sie, ob die Pods der Steuerungsebene in
istio-system
aktiv sind:kubectl get pods -n istio-system
Beispielausgabe:
NAME READY STATUS RESTARTS AGE istio-ingressgateway-c56675fcd-86zdn 1/1 Running 0 2m9s istio-ingressgateway-c56675fcd-vn4nv 1/1 Running 0 2m21s istiod-asm-1106-2-6d5cfd4b89-xztlr 1/1 Running 0 3m44s istiod-fb7f746f4-wcntn 1/1 Running 0 50m
Zwei Deployments der Steuerungsebene und Dienste werden parallel ausgeführt.
Stellen Sie den kanonischen Dienstüberwacher in Ihrem Cluster bereit:
kubectl apply -f asm/canonical-service/controller.yaml
Der kanonische Dienstüberwacher gruppiert Arbeitslasten, die zum selben logischen Dienst gehören. Weitere Informationen zu kanonischen Diensten finden Sie in der Übersicht Kanonische Dienste.
Istio CA
Prüfen Sie, ob der aktuelle
kubeconfig
-Kontext auf den Cluster verweist, auf dem Sie Anthos Service Mesh installieren möchten:kubectl config current-context
Die Ausgabe hat das folgende Format:
gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME
Der
kubeconfig
-Kontext und die Werte derkpt
-Setter müssen übereinstimmen. Führen Sie bei Bedarf den Befehlgcloud container clusters get-credentials
aus, um den aktuellenkubeconfig
-Kontext festzulegen.Wechseln Sie gegebenenfalls zum Verzeichnis
istio-1.10.6-asm.2
. Deristioctl
-Client ist versionsabhängig. Sie müssen die Version im Verzeichnisistio-1.10.6-asm.2/bin
verwenden.Führen Sie den folgenden Befehl aus, um die neue Steuerungsebene mit dem Profil
asm-gcp-multiproject
bereitzustellen. Wenn Sie ein unterstütztes optionales Feature aktivieren möchten, fügen Sie in der folgenden Befehlszeile-f
und den YAML-Dateinamen hinzu. Weitere Informationen finden Sie unter Optionale Features aktivieren.bin/istioctl install \ -f asm/istio/istio-operator.yaml \ -f asm/istio/options/citadel-ca.yaml \ -f asm/istio/options/multiproject.yaml \ -f asm/istio/options/multicluster.yaml \ --revision=asm-1106-2
Mit dem Argument
--revision
wirdistiod
ein Überarbeitungslabel im Formatistio.io/rev=asm-1106-2
hinzugefügt. Das Überarbeitungslabel wird vom automatischen Sidecar-Injektor-Webhook verwendet, um eingefügte Sidecars mit einer bestimmtenistiod
-Überarbeitung zu verknüpfen. Wenn Sie die automatische Sidecar-Injektion für einen Namespace aktivieren möchten, müssen Sie ihn mit einer Überarbeitung versehen, die eineristiod
-Bereitstellung entspricht.Mit den folgenden Dateien werden die Einstellungen in der Datei
istio-operator.yaml
überschrieben:citadel-ca.yaml
konfiguriert die Istio-Zertifizierungsstelle als Zertifizierungsstelle.Mit der Datei
multiproject.yaml
wird das Profilasm-gcp-multiproject
festgelegt.Mit der Datei
multicluster.yaml
werden die Einstellungen konfiguriert, die Anthos Service Mesh für eine Konfiguration mit mehreren Clustern benötigt.
Prüfen Sie, ob die Pods der Steuerungsebene in
istio-system
aktiv sind:kubectl get pods -n istio-system
Beispielausgabe:
NAME READY STATUS RESTARTS AGE istio-ingressgateway-c56675fcd-86zdn 1/1 Running 0 2m9s istio-ingressgateway-c56675fcd-vn4nv 1/1 Running 0 2m21s istiod-asm-1106-2-6d5cfd4b89-xztlr 1/1 Running 0 3m44s istiod-fb7f746f4-wcntn 1/1 Running 0 50m
Zwei Deployments der Steuerungsebene und Dienste werden parallel ausgeführt.
Stellen Sie den kanonischen Dienstüberwacher in Ihrem Cluster bereit:
kubectl apply -f asm/canonical-service/controller.yaml
Der kanonische Dienstüberwacher gruppiert Arbeitslasten, die zum selben logischen Dienst gehören. Weitere Informationen zu kanonischen Diensten finden Sie in der Übersicht Kanonische Dienste.
Arbeitslasten bereitstellen und neu bereitstellen
Die Installation ist erst abgeschlossen, wenn Sie die automatische Sidecar-Proxy-Injektion aktivieren (automatische Injektion). Migrationen von OSS Istio sowie Upgrades folgen einem revisionsbasierten Upgradevorgang. Dieser wird in der Istio-Dokumentation als „Canary-Upgrade“ bezeichnet. Bei einem überarbeitungsbasierten Upgrade wird die neue Version der Steuerungsebene zusammen mit der vorhandenen Steuerungsebene installiert. Anschließend verschieben Sie einige Ihrer Arbeitslasten auf die neue Version. Damit können Sie die Auswirkungen des Upgrades mit einem kleinen Prozentsatz der Arbeitslasten prüfen, bevor Sie den gesamten Traffic zur neuen Version migrieren.
Bei der Ausführung von istioctl install
legten Sie ein Überarbeitungslabel im Format istio.io/rev=asm-1106-2
für istiod
fest. Zur Aktivierung der automatischen Injektion fügen Sie zu Ihren Namespaces ein entsprechendes Überarbeitungslabel hinzu. Das Überarbeitungslabel wird vom Sidecar-Injektor-Webhook verwendet, um eingefügte Sidecars mit einer bestimmten istiod
-Überarbeitung zu verknüpfen. Nachdem Sie das Label hinzugefügt haben, starten Sie die Pods im Namespace neu, damit die Sidecars eingefügt werden.
Rufen Sie das Revisionslabel ab, das sich auf
istiod
und demistio-ingressgateway
befindet.kubectl get pod -n istio-system -L istio.io/rev
Die Ausgabe des Befehls sieht in etwa so aus:
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-65d884685d-6hrdk 1/1 Running 0 67m istio-ingressgateway-65d884685d-94wgz 1/1 Running 0 67m istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb 1/1 Running 0 5s asm-1106-2 istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1106-2 istiod-asm-176-1-67998f4b55-lrzpz 1/1 Running 0 68m asm-198-3 istiod-asm-176-1-67998f4b55-r76kr 1/1 Running 0 68m asm-198-3 istiod-asm-182-2-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1106-2 istiod-asm-182-2-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1106-2
Notieren Sie sich in der Ausgabe unter der Spalte
REV
den Wert des Überarbeitungslabels für die neue Version. In diesem Beispiel ist der Wertasm-1106-2
.Notieren Sie sich außerdem den Wert im Überarbeitungslabel der alten
istiod
-Version. Diesen Wert benötigen Sie, um die alte Version vonistiod
zu löschen, wenn Sie die Arbeitslasten in die neue Version verschoben haben. In der Beispielausgabe lautet der Wert für das Überarbeitungslabel der alten Versionasm-198-3
.
Legen Sie für
istio-ingressgateway
die neue Überarbeitung fest. Ändern Sie im folgenden BefehlREVISION
in den Wert, der dem Überarbeitungslabel der neuen Version entspricht.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'
Erwartete Ausgabe:
service/istio-ingressgateway patched
Fügen Sie das Überarbeitungslabel einem Namespace hinzu und entfernen Sie das
istio-injection
-Label (falls vorhanden). Geben Sie im folgenden Befehl fürREVISION
den Wert an, der der neuen Überarbeitung vonistiod
entspricht.kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
Wenn in der Ausgabe
"istio-injection not found"
angezeigt wird, können Sie dies ignorieren. Das bedeutet, dass der Namespace bisher nicht das Labelistio-injection
hatte. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl dasistio-injection
als auch das Überarbeitungslabel enthält, enthalten allekubectl label
-Befehle in der Anthos Service Mesh-Dokumentation das Labelistio-injection
.Starten Sie die Pods neu, um die erneute Injektion auszulösen.
kubectl rollout restart deployment -n NAMESPACE
Überprüfen Sie, ob Ihre Pods so konfiguriert sind, dass sie auf die neue Version von
istiod
verweisen.kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.
Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die Schritte, um den Namespace mit einem Label zu versehen und Pods neu zu starten.
Wenn Sie sicher sind, dass Ihre Anwendung wie erwartet funktioniert, fahren Sie mit den Schritten für die Umstellung auf die neue Version von
istiod
fort. Wenn ein Problem mit Ihrer Anwendung auftritt, führen Sie die Schritte zum Rollback aus.Umstellung vornehmen
Wenn Sie sicher sind, dass Ihre Anwendung wie erwartet funktioniert, entfernen Sie die alte Steuerungsebene, um die Umstellung auf die neue Version abzuschließen.
Wechseln Sie in das Verzeichnis, in dem sich die Dateien aus dem GitHub-Repository
anthos-service-mesh
befinden.Konfigurieren Sie den validierten Webhook so, dass er die neue Steuerungsebene verwendet.
kubectl apply -f asm/istio/istiod-service.yaml
Löschen Sie das alte
istio-ingressgateway
-Deployment. Der Befehl, den Sie ausführen, hängt davon ab, ob Sie von Istio migrieren oder ein Upgrade von einer vorherigen Version von Anthos Service Mesh durchführen:Migrieren
Wenn Sie von Istio migriert haben, hat die alte
istio-ingressgateway
-Datei kein Überarbeitungslabel.kubectl delete deploy/istio-ingressgateway -n istio-system
Upgrade
Wenn Sie ein Upgrade von einer früheren Anthos Service Mesh-Version durchgeführt haben, ersetzen Sie im folgenden Befehl
OLD_REVISION
durch das Überarbeitungslabel für die vorherige Version vonistio-ingressgateway
.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
Löschen Sie die alte Version von
istiod
. Der verwendete Befehl hängt davon ab, ob Sie von Istio migrieren oder ein Upgrade von einer früheren Version von Anthos Service Mesh durchführen.Migrieren
Wenn Sie von Istio migriert haben, hat die alte
istio-ingressgateway
-Datei kein Überarbeitungslabel.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
Upgrade
Wenn Sie ein Upgrade von einer früheren Anthos Service Mesh-Version durchgeführt haben, achten Sie im folgenden Befehl darauf, dass
OLD_REVISION
mit dem Überarbeitungslabel für die vorherige Version vonistiod
übereinstimmt.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
Entfernen Sie die alte Version der
IstioOperator
-Konfiguration.kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
Die erwartete Ausgabe sieht in etwa so aus:
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
Rollback
Wenn beim Testen der Anwendung mit der neuen
istiod
-Version ein Problem auftritt, gehen Sie so vor, um ein Rollback auf die vorherige Version auszuführen:Wechseln Sie zurück zur alten Version von
istio-ingressgateway
. Ersetzen Sie im folgenden BefehlOLD_REVISION
durch die vorherige Version.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
Benennen Sie Ihren Namespace um, um die automatische Injektion mit der vorherigen Version von
istiod
zu aktivieren. Der zu verwendende Befehl hängt davon ab, ob Sie ein Überarbeitungslabel oderistio-injection=enabled
mit der vorherigen Version verwendet haben.Wenn Sie ein Überarbeitungslabel für die automatische Injektion verwendet haben, führen Sie Folgendes aus:
kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
Wenn Sie
istio-injection=enabled
verwendet haben, führen Sie Folgendes aus:kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
Erwartete Ausgabe:
namespace/NAMESPACE labeled
Prüfen Sie, ob das Überarbeitungslabel im Namespace mit dem Überarbeitungslabel in der vorherigen Version von
istiod
übereinstimmt:kubectl get ns NAMESPACE --show-labels
Starten Sie die Pods neu, um die erneute Einfügung auszulösen, damit die Proxys die Istio-Version erhalten:
kubectl rollout restart deployment -n NAMESPACE
Entfernen Sie das neue
istio-ingressgateway
-Deployment. Achten Sie darauf, dass der Wert vonREVISION
im folgenden Befehl korrekt ist.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
Entfernen Sie die neue Version von
istiod
. Achten Sie darauf, dass der Wert vonREVISION
im folgenden Befehl korrekt ist.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
Entfernen Sie die neue Version der
IstioOperator
-Konfiguration.kubectl delete IstioOperator installed-state-REVISION -n istio-system
Die erwartete Ausgabe sieht in etwa so aus:
istiooperator.install.istio.io "installed-state-REVISION" deleted
Wenn Sie das Flag
--disable_canonical_service
nicht angegeben haben, hat das Skript den Canonical Service-Controller aktiviert. Wir empfehlen, ihn aktiviert zu lassen. Falls Sie ihn jedoch deaktivieren müssen, finden Sie weitere Informationen unter Canonical Service-Controller aktivieren und deaktivieren.
Nächste Schritte
- Beispielanwendung Online Boutique auf Anthos Service Mesh bereitstellen
- Multi-Cluster-Mesh einrichten