Canary-basierte Migration zur Cloud Service Mesh-Zertifizierungsstelle

Hinweis: In diesem Leitfaden wird beschrieben, wie Sie von der Istio-Zertifizierungsstelle zur Cloud Service Mesh-Zertifizierungsstelle mit einem Canary-basierten Ansatz mit minimaler oder gar keiner Ausfallzeit. Informationen zur Migration Ihrer Zertifizierungsstelle mit minimaler Ausfallzeit und ohne Migration der Kontrollebenen finden Sie unter Direkte CA-Migration.

Migration zur Cloud Service Mesh-Zertifizierungsstelle (Cloud Service Mesh-Zertifizierungsstelle) von Istio CA (auch bekannt als Citadel) erfordert die Migration der Root of Trust. Wenn Sie vor Cloud Service Mesh 1.10 von Istio in der Google Kubernetes Engine (GKE) zu Cloud Service Mesh mit der Cloud Service Mesh-Zertifizierungsstelle migrieren wollten, mussten Sie Ausfallzeiten planen, da Cloud 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 dann vollständig wiederhergestellt, wenn die Steuerungsebene und alle Arbeitslasten in allen Namespaces mit dem Zertifikat der Zertifizierungsstelle von Cloud Service Mesh 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.

Befolgen Sie die Schritte in dieser Anleitung für folgende Anwendungsfälle:

• Migration von Istio in GKE zur clusterinternen Steuerungsebene von Cloud Service Mesh 1.19.10-asm.9 mit Cloud Service Mesh-Zertifizierungsstelle
• Upgrade von Cloud Service Mesh 1.15 or a 1.16 patch release mit Istio CA auf die clusterinterne Steuerungsebene von Cloud Service Mesh 1.19.10-asm.9 mit Cloud Service Mesh-Zertifizierungsstelle

Beschränkungen

• Alle Cluster müssen sich im selben Google Cloud-Projekt befinden.

Vorbereitung

Führen Sie die Schritte unter Abhängige Tools installieren und Cluster validieren aus, um Folgendes zu tun:

• Erforderliche Tools installieren
• asmcli herunterladen
• Clusteradministratorberechtigungen erteilen
• Projekt und Cluster validieren

Erforderliche Tools

Während der Migration führen Sie das von Google bereitgestelltes Tool migrate_ca aus, um Folgendes für jeden Pod im Cluster zu validieren:

• Das Root-Zertifikat für die Istio-Zertifizierungsstelle und die Cloud Service Mesh-Zertifizierungsstelle.
• Das von Istio CA und der Cloud Service Mesh-Zertifizierungsstelle ausgestellte mTLS-Zertifikat der Arbeitslast
• Die von Istio CA und der Cloud Service Mesh-Zertifizierungsstelle konfigurierten vertrauenswürdigen Domains

Für dieses Tool gelten die folgenden Abhängigkeiten:

• awk
• grep
• istioctl Wenn Sie den asmcli install ausführen, wird die Version von istioctl heruntergeladen. die der Version des Cloud Service Mesh entspricht, das Sie installieren.
• jq
• kubectl
• openssl

Übersicht über die Migration

Für die Migration zur Cloud Service Mesh-Zertifizierungsstelle 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 Cloud Service Mesh-Zertifizierungsstelle und Arbeitslasten, die die Istio-Zertifizierungsstelle verwenden.

Im Folgenden finden Sie einen Überblick über die Migration zur Cloud Service Mesh-Zertifizierungsstelle:

1. Verteilen Sie den Root of Trust der Cloud Service Mesh-Zertifizierungsstelle.

   1. Installieren Sie eine neue Überarbeitung der Steuerungsebene, die die Istio-CA mit einer Option verwendet, die den Root of Trust der Cloud Service Mesh-Zertifizierungsstelle verteilt.

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

2. Zur Cloud Service Mesh-Zertifizierungsstelle migrieren. Nachdem nun alle Sidecar-Proxys mit der alten Root of Trust und dem Root of Trust der Cloud Service Mesh-Zertifizierungsstelle haben, können Sie zur Cloud Service Mesh-Zertifizierungsstelle migrieren. ohne Ausfallzeiten. Auch hier führen Sie den überarbeitungsbasierten Migrationsprozess durch:

   1. Installieren Sie eine Version der Steuerungsebene mit aktivierter Cloud Service Mesh-Zertifizierungsstelle.

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

   3. Entfernen Sie CA-Secrets im Cluster, die der alten CA zugeordnet sind, und starten Sie die neue Steuerungsebene neu.

Root of Trust der Cloud Service Mesh-Zertifizierungsstelle verteilen

Bevor Sie zur Cloud Service Mesh-Zertifizierungsstelle migrieren können, müssen alle GKE-Cluster im Mesh-Netzwerk Cloud 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 die Cloud Service Mesh-Zertifizierungsstelle 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 der Cloud Service Mesh-Zertifizierungsstelle migrieren, können sich Arbeitslasten, die die Cloud Service Mesh-Zertifizierungsstelle verwenden, bei Arbeitslasten mit der alten CA authentifizieren.

Neue Überarbeitung der Steuerungsebene installieren

Überarbeitung der Steuerungsebene mit einer Option installieren, die die Cloud Service Mesh-Zertifizierungsstelle verteilt Root of Trust.

1. Führen Sie die Schritte unter Abhängige Tools installieren und Cluster validieren aus, um mit dem von Google bereitgestellten Tool asmcli die neue Überarbeitung der Steuerungsebene zu installieren.

2. Prüfen Sie, ob Sie die Version von asmcli haben, die Cloud Service Mesh 1.11 oder höher installiert:

   ./asmcli --version
   

3. Führen Sie asmcli install aus. Ersetzen Sie im folgenden Befehl die Platzhalter durch Ihre Werte.

    ./asmcli install \
      --fleet_id FLEET_PROJECT_ID \
      --kubeconfig KUBECONFIG_FILE \
      --enable_all \
      --ca citadel \
      --ca_cert CA_CERT_FILE_PATH \
      --ca_key CA_KEY_FILE_PATH \
      --root_cert ROOT_CERT_FILE_PATH \
      --cert_chain CERT_CHAIN_FILE_PATH \
      --option ca-migration-citadel \
      --revision_name REVISION_1 \
      --output_dir DIR_PATH
   

• --fleet_id: Projekt-ID des Hostprojekts der Flotte.
• --kubeconfig Der Pfad zur Datei kubeconfig. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
• --output_dir: Fügen Sie diese Option hinzu, um ein Verzeichnis anzugeben, in das asmcli das Paket anthos-service-mesh herunterlädt und in dem die Installationsdatei extrahiert wird, die istioctl, Beispiele und Manifeste enthält. Andernfalls lädt asmcli die Dateien in ein tmp-Verzeichnis herunter. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
• --enable_all Ermöglicht dem Tool Folgendes:
  • Erforderliche IAM-Berechtigungen gewähren.
  • Erforderliche Google APIs aktivieren.
  • Legt im Cluster ein Label zur Angabe des Mesh-Netzwerks fest.
  • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
• -ca citadel Geben Sie zur Vermeidung von Ausfallzeiten Istio CA an. Die Option „citadel“ entspricht Istio CA. Wechseln Sie jetzt nicht zur Cloud Service Mesh-Zertifizierungsstelle.
• --ca_cert: Zwischenzertifikat.
• --ca_key: Schlüssel für das Zwischenzertifikat.
• --root_cert Root-Zertifikat.
• --cert_chain Zertifikatskette.
• --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.
• REVISION_1: empfohlen. Ein [Überarbeitungslabel](/service-mesh/docs/revisions-overview) ist ein Schlüssel/Wert-Paar, das auf der Steuerungsebene festgelegt wird. Der Überarbeitungslabelschlüssel ist immer istio.io/rev Standardmäßig legt das Tool den Wert für das Überarbeitungslabel anhand der Cloud Service Mesh-Version fest, z. B. asm-11910-9. Wir empfehlen, diese Option einzufügen und REVISION_1 durch einen Namen zu ersetzen, der die Installation beschreibt, z. B. asm-11910-9-distribute-root. Der Name muss ein DNS-1035-Label sein und aus alphanumerischen Zeichen in Kleinbuchstaben oder - bestehen. Außerdem muss er mit einem Buchstaben beginnen und mit einem alphanumerischen Zeichen enden (z. B. my-name oder abc-123).

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=<var>REVISION_1</var>-distribute-root versehen und Ihre Arbeitslasten neu starten. Wenn Sie Ihre Arbeitslasten nach dem Neustart testen, führen Sie ein Tool aus , um zu prüfen, ob der Sidecar-Proxy sowohl mit dem alten als auch mit dem neuen Stamm konfiguriert ist für die Cloud Service Mesh-Zertifizierungsstelle.

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

2. Laden Sie das Validierungstool herunter:

   curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
   

3. Legen Sie das ausführbare Bit für das Tool fest:

   chmod +x migrate_ca
   

4. Das Tool migrate_ca ruft istioctl auf, was versionsabhängig ist. Das Tool asmcli fügt istioctl 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 Befehl ISTIOCTL_PATH durch das Verzeichnis, das istioctl enthält, das das Tool heruntergeladen hat.

   export PATH=ISTIOCTL_PATH:$PATH
   which istioctl
   echo $PATH
   

5. Rufen Sie das Revisionslabel ab, das sich auf istiod und dem istio-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-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

   1. 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 von asmcli install angegeben haben. In diesem Beispiel ist der Wert asm-11910-9-distribute-root.

   2. 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 alte istiod-Überarbeitung. Die Beispielausgabe zeigt eine Migration von Istio, die die Überarbeitung default verwendet.

6. Fügen Sie das Überarbeitungslabel einem Namespace hinzu und entfernen Sie das istio-injection-Label (falls vorhanden). Ersetzen Sie im folgenden Befehl NAMESPACE 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 Label istio-injection hatte. Da das Verhalten der automatischen Injektion Nicht definiert, wenn ein Namespace sowohl den istio-injection als auch den Versionslabel, alle kubectl label-Befehle im Cloud Service Mesh explizit sicherstellen, dass nur ein Wert festgelegt ist.

7. Starten Sie die Pods neu, um die erneute Injektion auszulösen.

   kubectl rollout restart deployment -n NAMESPACE
   

8. Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.

9. Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die Schritte, um den Namespace mit einem Label zu versehen und Pods neu zu starten.

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

11. Wenn Sie Gateways migrieren müssen, führen Sie die Schritte unter Canary-Upgrades (erweitert) aus, um neue Gateway-Bereitstellungen zu installieren. Beachten Sie dabei folgende Punkte:

    • Verwenden Sie REVISION_1 als Überarbeitungslabel.
    • Stellen Sie die Gateway-Ressourcen im selben Namespace wie das Gateway der älteren Installation bereit, um eine Migration ohne Ausfallzeiten durchzuführen. Achten Sie darauf, dass die Dienstressourcen, die auf das ältere Gateway verweisen, jetzt auch die neueren Bereitstellungen enthalten sollten.
    • Löschen Sie die älteren Gateway-Bereitstellungen erst, wenn Sie sicher sind, -Anwendung ordnungsgemäß funktioniert (nach dem nächsten Schritt).

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

    1. Wechseln Sie in das Verzeichnis, in dem sich die Dateien aus dem GitHub-Repository anthos-service-mesh befinden.

    2. Konfigurieren Sie den validierten Webhook so, dass er die neue Steuerungsebene verwendet.

       kubectl apply -f asm/istio/istiod-service.yaml
       

    3. Löschen Sie das alte istio-ingressgateway-Deployment. Der Befehl, den Sie ausgeführt wird, hängt davon ab, ob Sie von Istio migrieren oder ein Upgrade ausführen aus einer früheren Version des Cloud Service Mesh:

       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 vorherigen Cloud Service Mesh-Version durchgeführt haben, ersetzen Sie OLD_REVISION durch den Überarbeitungslabel für die vorherige Version des istio-ingressgateway.

       kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
       

    4. 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 Cloud 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 vorherigen Cloud Service Mesh-Version durchgeführt haben, folgenden Befehl verwenden, achten Sie darauf, dass OLD_REVISION entspricht dem Überarbeitungslabel der vorherigen Version von istiod.

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
       

    5. Entfernen Sie die vorherige 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:

    1. Löschen Sie die neuen Gateway-Bereitstellungen, die in Schritt 11 installiert wurden.

    2. 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 oder istio-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

    3. Prüfen Sie, ob das Überarbeitungslabel im Namespace mit dem Überarbeitungslabel in der vorherigen Version von istiod übereinstimmt:

       kubectl get ns NAMESPACE --show-labels
       

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

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

    6. Entfernen Sie die neue Überarbeitung von istiod.

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
       

    7. Entfernen Sie die neue IstioOperator-Konfiguration.

       kubectl delete IstioOperator installed-state-asm-11910-9-distribute-root -n istio-system
       

       Die erwartete Ausgabe sieht in etwa so aus:

       istiooperator.install.istio.io "installed-state-asm-11910-9-distribute-root" deleted

Zur Cloud Service Mesh-Zertifizierungsstelle migrieren

Nachdem die Sidecar-Proxys für alle Arbeitslasten nun mit den alten und der neuen Root of Trust für die Cloud Service Mesh-Zertifizierungsstelle. Migration zur Cloud Service Mesh-Zertifizierungsstelle ähneln denen, die Sie zur Verteilung von den Root of Trust der Cloud Service Mesh-Zertifizierungsstelle:

Neue Steuerungsebene mit aktivierter Cloud Service Mesh-Zertifizierungsstelle installieren

Sie verwenden asmcli install, um eine neue Überarbeitung der Steuerungsebene zu installieren, für die Mesh CA aktiviert ist.

1. Wenn Sie die vorherige Installation angepasst haben, müssen Sie dieselben Overlay-Dateien angeben, wenn Sie asmcli install ausführen.

2. Führen Sie asmcli install aus. Ersetzen Sie im folgenden Befehl die Platzhalter durch Ihre Werte.

    ./asmcli install \
      --fleet_id FLEET_PROJECT_ID \
      --kubeconfig KUBECONFIG_FILE \
      --output_dir DIR_PATH \
      --enable_all \
      --ca mesh_ca \
      --root_cert ROOT_CERT_FILE_PATH \
      --cert_chain CERT_CHAIN_FILE_PATH
      --option ca-migration-meshca \
     --revision_name REVISION_2 \
     --output_dir DIR_PATH \
     OVERLAYS
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig: Pfad zur Datei kubeconfig. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
   • --output_dir: Fügen Sie diese Option hinzu, um ein Verzeichnis anzugeben, in das asmcli das Paket anthos-service-mesh herunterlädt und die Installationsdatei extrahiert, die istioctl, Beispiele und Manifeste enthält. Andernfalls lädt asmcli die Dateien in ein tmp-Verzeichnis herunter. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
   • --enable_all Ermöglicht dem Tool Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label zur Angabe des Mesh-Netzwerks festlegen.
     • Den Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • --ca mesh_ca Sie können jetzt zur Cloud Service Mesh-Zertifizierungsstelle wechseln, da der Root of Trust der Cloud Service Mesh-Zertifizierungsstelle verteilt wurde.
   • REVISION_2 Empfohlen. Ersetzen Sie REVISION_2 durch einen Namen, der die Installation beschreibt, z. B. asm-11910-9-meshca-ca-migration. Der Name muss ein DNS-1035-Label sein und aus alphanumerischen Zeichen in Kleinbuchstaben oder - bestehen. Außerdem muss er mit einem Buchstaben beginnen und mit einem alphanumerischen Zeichen enden (z. B. my-name oder abc-123).
   • --option ca-migration-migration Wenn Sie [Arbeitslasten neu bereitstellen](/service-mesh/docs/unified-install/install-anthos-service-mesh#deploy_and_redeploy_workloads), Mit dieser Option werden die Proxys so konfiguriert, dass sie den Root of Trust der Cloud Service Mesh-Zertifizierungsstelle verwenden.

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.

1. Rufen Sie das Revisionslabel ab, das sich auf istiod und dem istio-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-11910-9-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-11910-9-distribute-root
   istio-ingressgateway-asm-11910-9-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-11910-9-distribute-root
   istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-11910-9-meshca-ca-migration
   istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-11910-9-meshca-ca-migration
   istiod-asm-11910-9-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-11910-9-distribute-root
   istiod-asm-11910-9-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-11910-9-distribute-root
   istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-11910-9-meshca-ca-migration
   istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-11910-9-meshca-ca-migration

   1. Notieren Sie sich in der Ausgabe unter der Spalte REV den Wert des Überarbeitungslabels für die neue Version. In diesem Beispiel ist der Wert asm-11910-9-meshca-ca-migration.

   2. Notieren Sie sich außerdem den Wert im Überarbeitungslabel der älteren istiod-Version. Du brauchst dies, um die frühere Version von istiod zu löschen, wenn du fertig bist zum Verschieben von Arbeitslasten in die neue Version. In diesem Beispiel lautet der Wert des Überarbeitungslabels für die vorherige Überarbeitung asm-11910-9-distribute-root.

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

3. Starten Sie die Pods neu, um die erneute Injektion auszulösen.

   kubectl rollout restart deployment -n NAMESPACE
   

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

5. Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die Schritte, um den Namespace mit einem Label zu versehen und Pods neu zu starten.

6. Führen Sie die unter Direkte Upgrades beschriebenen Schritte aus, um die in Schritt 11 des vorherigen Abschnitts installierten älteren Gateway-Bereitstellungen auf die neueste Version REVISION_2 zu aktualisieren.

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

   1. Wechseln Sie in das Verzeichnis, in dem sich die Dateien aus dem GitHub-Repository anthos-service-mesh befinden.

   2. Konfigurieren Sie den validierten Webhook so, dass er die neue Steuerungsebene verwendet.

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. Löschen Sie das alte istio-ingressgateway-Deployment. Ersetzen Sie im folgenden Befehl OLD_REVISION durch das Überarbeitungslabel für die vorherige Version von istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
      

   4. Löschen Sie die alte istiod-Überarbeitung. Ersetzen Sie im folgenden Befehl OLD_REVISION durch das Überarbeitungslabel für die vorherige Version von istiod.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
      

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

   1. Führen Sie die Schritte unter Direkte Upgrades aus, um die zuvor in Schritt 6 dieses Abschnitts aktualisierten Gateway-Bereitstellungen auf die ältere Revision REVISION_1 zurückzusetzen.

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

   3. Prüfen Sie, ob das Überarbeitungslabel im Namespace mit dem Überarbeitungslabel in der vorherigen Version von istiod übereinstimmt:

      kubectl get ns NAMESPACE --show-labels
      

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

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

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

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

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

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
   

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