Für die Migration zur Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) von Istio CA (auch als Citadel bezeichnet) müssen Sie den Root of Trust migrieren. Wenn Sie vor Anthos Service Mesh 1.10 von Istio in Google Kubernetes Engine (GKE) zu Anthos Service Mesh mit Mesh CA migrieren wollten, mussten Sie Ausfallzeiten planen, da Anthos Service Mesh nicht mehrere Root-Zertifikate laden konnte. Daher vertrauen die neu bereitgestellten Arbeitslasten während der Migration dem neuen Root-Zertifikat, während andere dem alten Root-Zertifikat vertrauen. Arbeitslasten, die Zertifikate verwenden, die von verschiedenen Root-Zertifikaten signiert wurden, können sich nicht gegenseitig authentifizieren. Dies bedeutet, dass der mTLS-Traffic (mutual TLS) während der Migration unterbrochen wird. Der gesamte Cluster wird nur vollständig wiederhergestellt, wenn die Steuerungsebene und alle Arbeitslasten in allen Namespaces mit dem Zertifikat von Mesh CA neu bereitgestellt werden. Wenn Ihr Mesh-Netzwerk über mehrere Cluster mit Arbeitslasten verfügt, die Anfragen an Arbeitslasten in einem anderen Cluster senden, müssen auch alle Arbeitslasten in diesen Clustern aktualisiert werden.
Auf dieser Seite wird beschrieben, wie Sie mit minimaler oder gar keiner Ausfallzeit von Istio CA zu Mesh CA migrieren. Befolgen Sie die Schritte in dieser Anleitung für folgende Anwendungsfälle:
- Migration von Istio in GKE zur clusterinternen Steuerungsebene von Anthos Service Mesh 1.10.6-asm.2 mit Mesh CA
- Upgrade von Anthos Service Mesh 1.9 or a 1.10 patch release mit Istio CA auf die clusterinterne Steuerungsebene von Anthos Service Mesh 1.10.6-asm.2 mit Mesh CA
Beschränkungen
- Mesh CA wird nur in GKE unterstützt.
- Alle Cluster müssen sich im selben Google Cloud-Projekt befinden.
Vorbereitung
In diesem Leitfaden wird davon ausgegangen, dass Sie bereits Folgendes haben:
- Ein Google Cloud-Projekt
- Ein Cloud-Rechnungskonto
- Die erforderlichen Tools zum Ausführen des Skripts
install_asm
- Bei einem Multi-Cluster-Mesh-Netzwerk mit Istio CA muss für jeden Cluster dasselbe Root-Zertifikat festgelegt werden.
Erforderliche Tools
Während der Migration führen Sie das von Google bereitgestelltes Skript migrate_ca
aus, um Folgendes für jeden Pod im Cluster zu validieren:
- Root-Zertifikat für Istio CA und Mesh CA
- Das von Istio CA und Mesh CA ausgestellte mTLS-Zertifikat der Arbeitslast
- Die von Istio CA und Mesh CA konfigurierten vertrauenswürdigen Domains
Für dieses Skript gelten die folgenden Abhängigkeiten:
awk
grep
istioctl
Wenn Sie das Skriptinstall_asm
ausführen, wird die Version vonistioctl
heruntergeladen, die der Version von Anthos Service Mesh entspricht, die Sie installieren.jq
kubectl
openssl
Übersicht über die Migration
Für die Migration zu Mesh CA folgen Sie dem überarbeitungsbasierten Migrationsprozess (auch als "Canary-Upgrade" bezeichnet). Bei einer überarbeitungsbasierten Migration wird neben der vorhandenen Steuerungsebene eine neue Überarbeitung der Steuerungsebene neben der vorhandenen Steuerungsebene bereitgestellt. Anschließend verschieben Sie Ihre Arbeitslasten schrittweise in die neue Überarbeitung. Damit können Sie die Auswirkungen der Migration während des Prozesses überwachen. Während des Migrationsprozesses funktionieren Authentifizierung und Autorisierung vollständig zwischen Arbeitslasten, die die Mesh CA verwenden, und Arbeitslasten, die Istio CA verwenden.
Im Folgenden finden Sie einen Überblick über die Migration zu Mesh CA:
Verteilen Sie den Root of Trust von Mesh CA.
Installieren Sie eine neue Überarbeitung der Steuerungsebene mit einer Option, die den Root of Trust von Mesh CA verteilt.
Migrieren Sie Arbeitslasten zur neuen Steuerungsebene, Namespace für Namespace, und testen Sie Ihre Anwendung. Wenn alle Arbeitslasten erfolgreich zur neuen Steuerungsebene migriert wurden, entfernen Sie die alte Steuerungsebene.
Migrieren Sie zu Mesh CA. Nachdem Sie nun alle Sidecar-Proxys mit dem alten Root of Trust und dem Root of Trust von Mesh CA konfiguriert haben, können Sie ohne Ausfallzeit zu Mesh CA migrieren. Auch hier führen Sie den überarbeitungsbasierten Migrationsprozess durch:
Installieren Sie eine Überarbeitung der Steuerungsebene mit aktiviertem Mesh CA.
Migrieren Sie Arbeitslasten zur neuen Überarbeitung der Steuerungsebene, Namespace für Namespace, und testen Sie Ihre Anwendung. Wenn alle Arbeitslasten erfolgreich zur neuen Steuerungsebene migriert wurden, entfernen Sie die alte Steuerungsebene.
Entfernen Sie CA-Secrets im Cluster, die der alten CA zugeordnet sind, und starten Sie die neue Steuerungsebene neu.
Root of Trust von Mesh CA verteilen
Bevor Sie zu Mesh CA migrieren können, müssen alle GKE-Cluster im Mesh-Netzwerk Anthos Service Mesh 1.10 oder höher haben und alle Cluster müssen mit einer Steuerungsebenenoption konfiguriert sein, die den Root of Trust für Mesh CA auslöst, der an die Proxys aller Arbeitslasten im Cluster verteilt werden soll. Wenn der Prozess abgeschlossen ist, wird jeder Proxy sowohl mit dem alten als auch mit dem neuen Root of Trust konfiguriert. Wenn Sie mit diesem Schema zu Mesh CA migrieren, können sich Arbeitslasten, die Mesh CA verwenden, bei Arbeitslasten mit der alten CA authentifizieren.
Neue Überarbeitung der Steuerungsebene installieren
Installieren Sie die Überarbeitung der Steuerungsebene mit einer Option, die den Root of Trust von Mesh CA verteilt.
Führen Sie die Schritte unter Anthos Service Mesh in GKE installieren aus, um das von Google bereitgestellte Skript
install_asm
zu installieren und die neue Überarbeitung der Steuerungsebene zu installieren.Prüfen Sie, ob Sie die Version von
install_asm
haben, die Anthos Service Mesh 1.10 oder höher installiert:./install_asm --version
Führen Sie
install_asm
aus. Ersetzen Sie im folgenden Befehl die Platzhalter durch Ihre Werte.PROJECT_ID
: erforderlich. Die Projekt-ID des Projekts, in dem der Cluster erstellt wurde.CLUSTER_NAME
: erforderlich. Der Name des Clusters.CLUSTER_LOCATION
: erforderlich. Die Zone oder Region, in der sich der Cluster befindet.REVISION_1
: empfohlen. Ein Überarbeitungslabel ist ein Schlüssel/Wert-Paar, das auf der Steuerungsebene festgelegt wird. Der Schlüssel des Überarbeitungslabels ist immeristio.io/rev
. Standardmäßig legt das Skript den Wert für das Überarbeitungslabel anhand der Anthos Service Mesh-Version fest, z. B.asm-1106-2
. Wir empfehlen, diese Option einzufügen undREVISION_1
durch einen Namen zu ersetzen, der die Installation beschreibt, z. B.asm-1106-2-distribute-root
. Der Name muss ein DNS-1035-Label sein und aus alphanumerischen Zeichen in Kleinbuchstaben oder-
bestehen, mit einem Buchstaben beginnen und mit einem alphanumerischen Zeichen enden (z. B.my-name'
oderabc-123
). Der für die Validierung verwendete Regex lautet'[a-z]([-a-z0-9]*[a-z0-9])?')
.DIR_PATH
: erforderlich. Ein relativer Pfad zu einem Verzeichnis, in das das Skript dasanthos-service-mesh
-Paket und die Anthos Service Mesh-Installationsdatei herunterlädt, dieistioctl
, Beispiele und Manifeste enthält.OVERLAYS
: Optional. Wenn Sie Folgendes optionale Features aktivieren möchten, schließen Sie--custom_overlay
mit dem Namen der Overlay-Datei für jedes Feature ein. Wenn Sie keine optionalen Features aktivieren, löschen Sie diese Zeile und den umgekehrten Schrägstrich in der vorherigen Zeile../install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --ca citadel \ --enable_all \ --option ca-migration-citadel \ --revision_name REVISION_1 \ --output_dir DIR_PATH \ OVERLAYS
Die folgenden Befehlszeilenargumente sind erforderlich:
--ca citadel
: Geben Sie zur Vermeidung von Ausfallzeiten Istio CA an. Die Optioncitadel
entspricht Istio CA. Wechseln Sie jetzt nicht zu Mesh CA.--option ca-migration-citadel
: Wenn Sie Ihre Arbeitslasten neu bereitstellen, wird durch diese Option der neue Root of Trust an die Sidecar-Proxys der Arbeitslasten verteilt.
Arbeitslasten zur neuen Steuerungsebene migrieren
Um die Verteilung des neuen Root of Trust abzuschließen, müssen Sie Ihre Namespaces mit dem Überarbeitungslabel istio.io/rev=asm-1106-2-distribute-root
versehen und Ihre Arbeitslasten neu starten. Wenn Sie Ihre Arbeitslasten nach dem Neustart testen, führen Sie ein Skript aus, um zu prüfen, ob der Sidecar-Proxy mit dem alten und neuen Root of Trust für Mesh CA konfiguriert ist.
Legen Sie den aktuellen Kontext für
kubectl
fest. Ändern Sie im folgenden Befehl--region
in--zone
, wenn Sie einen Cluster mit einer einzelnen Zone haben.gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --region=CLUSTER_LOCATION
Laden Sie das Validierungsskript herunter:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.10-asm/scripts/ca-migration/migrate_ca > migrate_ca
Legen Sie das ausführbare Bit für das Skript fest:
chmod +x migrate_ca
Das Skript
migrate_ca
ruftistioctl
auf, was versionsabhängig ist. Das Skriptinstall_asm
fügtistioctl
in dem Verzeichnis, das Sie für--output_dir
angegeben haben, einen Symlink hinzu. Achten Sie darauf, dass sich das Verzeichnis am Anfang Ihres Pfads befindet. Ersetzen Sie im folgenden BefehlISTIOCTL_PATH
durch das Verzeichnis, dasistioctl
enthält, das das Skript heruntergeladen hat.export PATH=ISTIOCTL_PATH:$PATH which istioctl echo $PATH
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 sieht in etwa so aus:
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-5fd454f8ff-t7w9x 1/1 Running 0 36m default istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p 1/1 Running 0 18m asm-195-2-distribute-root istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs 1/1 Running 0 18m asm-195-2-distribute-root istiod-68bc495f77-shl2h 1/1 Running 0 36m default istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c 1/1 Running 0 18m asm-195-2-distribute-root istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s 1/1 Running 0 18m asm-195-2-distribute-root
Achten Sie in der Ausgabe unter der Spalte
REV
auf den Wert des Überarbeitungslabels für die neue Überarbeitung. Dieses entspricht dem Überarbeitungslabel, das Sie beim Ausführen voninstall_asm
angegeben haben. In diesem Beispiel ist der Wertasm-1106-2-distribute-root
.Sie müssen die alte Überarbeitung von
istiod
löschen, wenn Sie die Arbeitslasten in die neue Überarbeitung verschoben haben. Beachten Sie den Wert im Überarbeitungslabel für die alteistiod
-Überarbeitung. Die Beispielausgabe zeigt eine Migration von Istio, die die Überarbeitungdefault
verwendet.
Legen Sie für
istio-ingressgateway
die neue Überarbeitung fest. Achten Sie im folgenden Befehl darauf, dassREVISION_1
mit dem Wert des Überarbeitungslabels der neuen Überarbeitung übereinstimmt.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_1"}]'
Erwartete Ausgabe:
service/istio-ingressgateway patched
Fügen Sie das Überarbeitungslabel einem Namespace hinzu und entfernen Sie das
istio-injection
-Label (falls vorhanden). Ersetzen Sie im folgenden BefehlNAMESPACE
durch den Namespace, den Sie mit einem Label versehen möchten.kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 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_1
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.
Prüfen Sie, ob die Sidecar-Proxys für alle Arbeitslasten im Cluster mit den alten und neuen Root-Zertifikaten konfiguriert sind:
./migrate_ca check-root-cert
Erwartete Ausgabe:
Namespace: foo httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA] sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
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 Überarbeitung 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-ingressgatewqy
. 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.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
Entfernen Sie die neue Überarbeitung von
istiod
.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
Entfernen Sie die neue
IstioOperator
-Konfiguration.kubectl delete IstioOperator installed-state-asm-1106-2-distribute-root -n istio-system
Die erwartete Ausgabe sieht in etwa so aus:
istiooperator.install.istio.io "installed-state-asm-1106-2-distribute-root" deleted
Zu Mesh CA migrieren
Nachdem die Sidecar-Proxys für alle Arbeitslasten sowohl mit dem alten Root of Trust als auch mit dem neuen Root of Trust für Mesh CA konfiguriert sind, ähneln die Schritte zur Migration zu Mesh CA denen, mit denen Sie den Root of Trust von Mesh CA verteilt haben:
Neue Steuerungsebene mit aktiviertem Mesh CA installieren
Sie verwenden install_asm
, um eine neue Überarbeitung der Steuerungsebene zu installieren, für die Mesh CA aktiviert ist.
Wenn Sie die vorherige Installation angepasst haben, müssen Sie dieselben Overlay-Dateien angeben, wenn Sie
install_asm
ausführen.Führen Sie
install_asm
aus. Ersetzen Sie im folgenden Befehl die Platzhalter durch Ihre Werte.PROJECT_ID
: erforderlich. Die Projekt-ID des Projekts, in dem der Cluster erstellt wurde.CLUSTER_NAME
: erforderlich. Der Name des Clusters.CLUSTER_LOCATION
: erforderlich. Die Zone oder Region, in der sich der Cluster befindet.REVISION_2
: empfohlen. Ersetzen SieREVISION_2
durch einen Namen, der die Installation beschreibt, z. B.asm-1106-2-meshca-ca-migration
. Der Name muss ein DNS-1035-Label sein und aus alphanumerischen Zeichen in Kleinbuchstaben oder-
bestehen, mit einem Buchstaben beginnen und mit einem alphanumerischen Zeichen enden (z. B.my-name'
oderabc-123
). Der für die Validierung verwendete Regex lautet'[a-z]([-a-z0-9]*[a-z0-9])?')
.DIR_PATH
: erforderlich. Ein relativer Pfad zu einem Verzeichnis, in das das Skript dasanthos-service-mesh
-Paket und die Anthos Service Mesh-Installationsdatei herunterlädt, dieistioctl
, Beispiele und Manifeste enthält.OVERLAYS
: Optional. Wenn Sie Folgendes optionale Features aktivieren möchten, schließen Sie--custom_overlay
mit dem Namen der Overlay-Datei für jedes Feature ein. Wenn Sie keine optionalen Features aktivieren, löschen Sie diese Zeile und den umgekehrten Schrägstrich in der vorherigen Zeile.
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode install \ --ca mesh_ca \ --enable_all \ --option ca-migration-meshca \ --revision_name REVISION_2 \ --output_dir DIR_PATH \ OVERLAYS
Die folgenden Befehlszeilenargumente sind erforderlich:
--ca mesh_ca
: Sie können jetzt zu Mesh CA wechseln, da der Root of Trust von Mesh CA verteilt wurde.--option ca-migration-migration
: Wenn Sie Ihre Arbeitslasten noch einmal bereitstellen, konfiguriert diese Option die Proxys für die Verwendung des Root of Trust von Mesh CA.
Arbeitslasten zur neuen Steuerungsebene migrieren
Um die Installation abzuschließen, müssen Sie Ihre Namespaces mit dem neuen Überarbeitungslabel versehen und Ihre Arbeitslasten neu starten.
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 sieht etwa so aus:
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-asm-1106-2-distribute-root-65d884685d-6hrdk 1/1 Running 0 67m asm-1106-2-distribute-root istio-ingressgateway-asm-1106-2-distribute-root65d884685d-94wgz 1/1 Running 0 67m asm-1106-2-distribute-root istio-ingressgateway-asm-1106-2-meshca-ca-migration-8b5fc8767-gk6hb 1/1 Running 0 5s asm-1106-2-meshca-ca-migration istio-ingressgateway-asm-1106-2-meshca-ca-migration-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1106-2-meshca-ca-migration istiod-asm-1106-2-distribute-root-67998f4b55-lrzpz 1/1 Running 0 68m asm-1106-2-distribute-root istiod-asm-1106-2-distribute-root-67998f4b55-r76kr 1/1 Running 0 68m asm-1106-2-distribute-root istiod-asm-1106-2-meshca-ca-migration-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1106-2-meshca-ca-migration istiod-asm-1106-2-meshca-ca-migration-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1106-2-meshca-ca-migration
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-meshca-ca-migration
.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 diesem Beispiel lautet der Wert des Überarbeitungslabels für die vorherige Überarbeitungasm-1106-2-distribute-root
.
Legen Sie für
istio-ingressgateway
die neue Überarbeitung fest. Ändern Sie im folgenden BefehlREVISION_2
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_2"}]'
Erwartete Ausgabe:
service/istio-ingressgateway patched
Fügen Sie das neue Überarbeitungslabel einem Namespace hinzu. Ersetzen Sie im folgenden Befehl
NAMESPACE
durch den mit einem Label zu versehenden Namespace.kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
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_2
Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren. Achten Sie darauf, dass die mTLS-Kommunikation zwischen Arbeitslasten im alten Namespace und Arbeitslasten im neueren Namespace funktioniert.
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 sich sicher sind, dass Ihre Anwendung wie erwartet funktioniert, fahren Sie mit den Schritten für die Umstellung auf die neue Steuerungsebene 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. Ersetzen Sie im folgenden BefehlOLD_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
istiod
-Überarbeitung. Ersetzen Sie im folgenden BefehlOLD_REVISION
durch das Überarbeitungslabel für die vorherige Version vonistiod
.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
Entfernen Sie die alte
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 Überarbeitung
istiod
ein Problem aufgetreten ist, führen Sie die folgenden Schritte aus, um ein Rollback auf die vorherige Überarbeitung durchzuführen:Wechseln Sie zurück zum vorherigen
istio-ingressgatewqy
. 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 den Namespace neu, um die automatische Einfügung mit der vorherigen
istiod
-Überarbeitung zu aktivieren.kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --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.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
Entfernen Sie die neue Version von
istiod
. Achten Sie darauf, dass das Überarbeitungslabel im folgenden Befehl mit Ihrer Überarbeitung übereinstimmt.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
Entfernen Sie die neue Version der
IstioOperator
-Konfiguration.kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
Die erwartete Ausgabe sieht in etwa so aus:
istiooperator.install.istio.io "installed-state-REVISION_2" deleted
CA-Secrets entfernen und neue Steuerungsebene neu starten
Speichern Sie Secrets sicherheitshalber:
kubectl get secret/cacerts -n istio-system -o yaml > save_file_1 kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2
Entfernen Sie die CA-Secrets in dem Cluster, der der alten CA zugeordnet ist:
kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
Starten Sie die neu installierte Steuerungsebene neu. Dadurch wird sichergestellt, dass der alte Root of Trust von allen im Mesh-Netzwerk ausgeführten Arbeitslasten bereinigt wird.
kubectl rollout restart deployment -n istio-system