Upgrade für Anthos Service Mesh durchführen

Auf dieser Seite erfahren Sie, wie Sie:

• Führen Sie asmcli aus, um ein Upgrade von Anthos Service Mesh auf Anthos Service Mesh 1.13.9 durchzuführen.

• Stellen Sie optional ein Ingress-Gateway bereit.

• Canary-Upgrade durchführen, um Ihre Arbeitslasten auf die neue Steuerungsebene zu migrieren.

Die Anthos Service Mesh-Version, von der Sie ein Upgrade ausführen können, unterscheidet sich je nach Plattform.

GKE

Von den folgenden Versionen ist ein direktes Upgrade auf Anthos Service Mesh 1.13.9-asm.10 in Google Kubernetes Engine möglich:

1.11+

Lokal

Ein direktes Upgrade auf Anthos Service Mesh 1.13.9-asm.10 in GKE on VMware und Google Distributed Cloud Virtual for Bare Metal ist aus den folgenden Versionen möglich:

1.11+

GKE on AWS

Ein direktes Upgrade auf Anthos Service Mesh 1.13.9-asm.10 in GKE on AWS ist aus den folgenden Versionen möglich:

1.11+

Amazon EKS

Wenn Sie Anthos Service Mesh 1.7 auf EKS installiert haben, müssen Sie Anthos Service Mesh 1.13 auf einem neuen Cluster installieren. Upgrades von Anthos Service Mesh 1.7 auf Anthos Service Mesh 1.13 werden nicht unterstützt.

Microsoft AKS

Wenn Sie Anthos Service Mesh 1.7 auf EKS installiert haben, müssen Sie Anthos Service Mesh 1.13 auf einem neuen Cluster installieren. Upgrades von Anthos Service Mesh 1.7 auf Anthos Service Mesh 1.13 werden nicht unterstützt.

Hinweise

Warnung: GitOps-Tools (einschließlich Config Management, Argo CD, Terraform und Jenkins) können die Installation, Migration oder Upgrades von Anthos Service Mesh beeinträchtigen. Die besten Ergebnisse erzielen Sie, wenn Sie Ihre GitOps-Tools deaktivieren, bevor Sie Anthos Service Mesh installieren, migrieren oder aktualisieren.

Folgende Voraussetzungen müssen Sie erfüllt haben:

• Prüfen Sie die Voraussetzungen.
• Lesen Sie die Informationen unter Installation planen.
• Installieren Sie die erforderlichen Tools.
• Laden Sie asmcli herunter.
• Erteilen Sie Clusteradministratorberechtigungen.
• Validieren Sie Projekt und Cluster.

Warnung: GitOps-Tools (einschließlich Config Management, Argo CD, Terraform und Jenkins) können die Installation, Migration oder Upgrades von Anthos Service Mesh beeinträchtigen. Die besten Ergebnisse erzielen Sie, wenn Sie Ihre GitOps-Tools deaktivieren, bevor Sie Anthos Service Mesh installieren, migrieren oder aktualisieren.

Anpassungen der Steuerungsebene

Wenn Sie die vorherige Installation angepasst haben, benötigen Sie dieselben Anpassungen, wenn Sie ein Upgrade auf eine neue Anthos Service Mesh-Version durchführen oder von Istio migrieren. Wenn Sie die Installation angepasst haben, indem Sie istioctl install das Flag --set values hinzugefügt haben, müssen Sie diese Einstellungen in einer YAML-Datei vom Typ IstioOperator hinzufügen, die als Overlay-Datei bezeichnet wird. Sie geben die Overlay-Datei an, indem Sie beim Ausführen des Skripts die Option --custom_overlay mit dem Dateinamen verwenden. Das Skript übergibt die Overlay-Datei an istioctl install.

Achtung: Wird die Overlay-Datei weggelassen, führt dies trotzdem zu einer erfolgreichen Installation. Ihr Service Mesh hat jedoch eine andere Konfiguration, als Sie beabsichtigt haben, da die ausgelassenen Werte auf die Standardeinstellungen zurückgesetzt werden, wenn die Steuerungsebene und das Ingress-Gateway neu bereitgestellt werden.

Zertifizierungsstelle

Das Ändern der Zertifizierungsstelle während eines Upgrades führt zu Ausfallzeiten. Während des Upgrades wird mTLS-Traffic unterbrochen, bis alle Arbeitslasten auf die neue Steuerungsebene mit der neuen Zertifizierungsstelle übertragen wurden.

Upgrade für Anthos Service Mesh durchführen

Im Folgenden wird beschrieben, wie Sie ein Upgrade für Anthos Service Mesh durchführen:

1. Wenn Sie ein Upgrade eines Multi-Cluster-Mesh-Netzwerks in GKE durchführen, das die Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) verwendet, führen Sie asmcli create-mesh aus, um das Multi-Cluster-Mesh-Netzwerk so zu konfigurieren, dass es der Workload Identity der Flotte vertraut, damit beim clusterübergreifenden Load-Balancing während des Upgrades keine Ausfallzeit auftritt.

2. Führen Sie asmcli install aus, um Anthos Service Mesh auf einem einzelnen Cluster zu installieren. In den folgenden Abschnitten finden Sie Beispiele für Befehlszeilen. Die Beispiele enthalten sowohl erforderliche Argumente als auch optionale Argumente, die für Sie nützlich sein könnten. Wir empfehlen, immer das Argument output_dir anzugeben, damit Sie Beispielgateways und Tools wie istioctl leicht finden können. In der Navigationsleiste auf der rechten Seite finden Sie eine Liste der Beispiele.

3. Optional können Sie ein Ingress-Gateway installieren oder aktualisieren. Standardmäßig installiert asmcli das istio-ingressgateway nicht. Wir empfehlen, die Steuerungsebene und die Gateways separat bereitzustellen und zu verwalten. Wenn Sie das standardmäßige istio-ingressgateway für die clusterinterne Steuerungsebene installieren möchten, fügen Sie das Argument --option legacy-default-ingressgateway ein.

4. Damit die Einrichtung von Anthos Service Mesh abgeschlossen werden kann, müssen Sie die automatische Sidecar-Injektion aktivieren und die Arbeitslasten (noch einmal) bereitstellen.

Multi-Cluster-Mesh-Netzwerk konfigurieren, um der Workload Identity der Flotte zu vertrauen

Wenn Sie ein Multi-Cluster-Mesh-Netzwerk in GKE aktualisieren, das Mesh CA als Zertifizierungsstelle verwendet, müssen Sie asmcli create-mesh ausführen, bevor Sie jeden Cluster aktualisieren. Mit diesem Befehl wird Mesh CA so konfiguriert, dass nach dem Upgrade der Flotten-Workload Identity-Pool FLEET_PROJECT_ID.svc.id.goog als Vertrauensdomain verwendet wird. Befehl asmcli create-mesh:

• Registriert alle Cluster in derselben Flotte
• Konfiguriert das Mesh-Netzwerk so, dass der Workload Identity der Flotte vertraut wird
• Erstellt Remote-Secrets

Sie können entweder den URI für jeden Cluster oder den Pfad zur kubeconfig-Datei angeben.

Cluster-URI

Ersetzen Sie im folgenden Befehl FLEET_PROJECT_ID durch die Projekt-ID des Flottenhostprojekts und den Cluster-URI durch den Clusternamen, die Zone oder Region und die Projekt-ID für jeden Cluster.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PROJECT_ID_1/CLUSTER_LOCATION_1/CLUSTER_NAME_1 \
    PROJECT_ID_2/CLUSTER_LOCATION_2/CLUSTER_NAME_2 # \
    # Add a line for each cluster in the mesh

kubeconfig-Datei

Ersetzen Sie im folgenden Befehl FLEET_PROJECT_ID durch die Projekt-ID des Flottenhostprojekts und PATH_TO_KUBECONFIG durch den Pfad zu jeder kubeconfig-Datei.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2 # \
    # Add a line for each cluster in the mesh

Upgrade mit Standardfeatures und Mesh CA durchführen

In diesem Abschnitt wird gezeigt, wie Sie asmcli ausführen, um Anthos Service Mesh mit den unterstützten Standardfeatures für Ihre Plattform zu aktualisieren und die Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) als die Zertifizierungsstelle aktivieren.

Plattformhinweis: Mesh CA wird in GKE on AWS, Amazon EKS oder Microsoft AKS nicht unterstützt. Wenn Sie asmcli install ausführen und --ca mesh_ca auf diesen Plattformen angeben, schlägt die Installation fehl.

GKE

Führen Sie den folgenden Befehl aus, um die Steuerungsebene mit Standardfeatures und Mesh CA zu aktualisieren. Geben Sie Ihre Werte in die vorhandenen Platzhalter ein.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

• --project_id, --cluster_name und --cluster_location geben die Projekt-ID an, in der sich der Cluster befindet, den Clusternamen und entweder die Clusterzone oder -region.
• --fleet_id: Projekt-ID des Hostprojekts der Flotte. Wenn Sie diese Option nicht angeben, verwendet asmcli das Projekt, in dem der Cluster bei der Registrierung erstellt wurde.
• --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.
  Hinweis: Notieren Sie sich dieses --output_dir-Verzeichnis. Sie müssen bei der Bereitstellung von Gateways darauf verweisen.
• --enable_all: Ermöglicht dem Skript Folgendes:
  • Erforderliche IAM-Berechtigungen gewähren.
  • Erforderliche Google APIs aktivieren.
  • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
  • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
• --ca mesh_ca Verwendet Mesh CA als Zertifizierungsstelle. Das Ändern der Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten. asmcli konfiguriert Mesh CA für die Verwendung der Workload Identity der Flotte.

Lokal

Führen Sie die folgenden Befehle in GKE on VMware oder Google Distributed Cloud Virtual for Bare Metal aus, um die Steuerungsebene mit Standardfeatures und Mesh CA zu aktualisieren. Geben Sie Ihre Werte in die vorhandenen Platzhalter ein.

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

   kubectl config use-context CLUSTER_NAME
   

2. Führen Sie asmcli install aus.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der vollständige Pfad zur kubeconfig-Datei. Die Umgebungsvariable $PWD funktioniert hier nicht. Darüber hinaus funktionieren relative kubeconfig-Dateispeicherorte, die „~“ verwenden, 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.
   • --platform multicloud Gibt an, dass es sich bei der Plattform um etwas anderes als Google Cloud handelt, z. B. eine lokale oder Multi-Cloud-Plattform.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • --ca mesh_ca Verwendet Mesh CA als Zertifizierungsstelle. Das Ändern von Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten. asmclikonfiguriert Mesh CA, um die Flotten-Workload-Identität zu verwenden

Upgrade von Standardfeatures mit CA Service

In diesem Abschnitt wird gezeigt, wie Sie asmcli ausführen, um Anthos Service Mesh mit den standardmäßigen unterstützten Features für Ihre Plattform zu aktualisieren und Certificate Authority Service zu aktivieren.

GKE

Führen Sie den folgenden Befehl aus, um die Steuerungsebene mit Standardfeatures und Certificate Authority Service zu installieren. Geben Sie Ihre Werte in die vorhandenen Platzhalter ein.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca gcp_cas \
  --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL

• --project_id, --cluster_name und --cluster_location geben die Projekt-ID an, in der sich der Cluster befindet, den Clusternamen und entweder die Clusterzone oder -region.
• --fleet_id: Projekt-ID des Hostprojekts der Flotte. Wenn Sie diese Option nicht angeben, verwendet asmcli das Projekt, in dem der Cluster bei der Registrierung erstellt wurde.
• --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.
  Hinweis: Notieren Sie sich dieses --output_dir-Verzeichnis. Sie müssen bei der Bereitstellung von Gateways darauf verweisen.
• --enable_all: Ermöglicht dem Skript Folgendes:
  • Erforderliche IAM-Berechtigungen gewähren.
  • Erforderliche Google APIs aktivieren.
  • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
  • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
• --ca gcp_casVerwenden Sie Certificate Authority Service als Zertifizierungsstelle. Das Ändern von Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten. asmcli konfiguriert den Zertifizierungsstellendienst für die Verwendung des Workload Identity der Flotte.
• --ca_pool Die vollständige Kennung für den CA-Pool des Certificate Authority Service.

Lokal

Führen Sie die folgenden Befehle in GKE on VMware oder Google Distributed Cloud Virtual for Bare Metal aus, um ein Upgrade der Steuerungsebene mit Standardfeatures und Certificate Authority Service durchzuführen. Geben Sie Ihre Werte in die vorhandenen Platzhalter ein.

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

   kubectl config use-context CLUSTER_NAME
   

2. Führen Sie asmcli install aus.

   ./asmcli install \
    --kubeconfig KUBECONFIG_FILE \
    --fleet_id FLEET_PROJECT_ID \
    --output_dir DIR_PATH \
    --enable_all \
    --ca gcp_cas \
    --platform multicloud \
    --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der vollständige Pfad zur kubeconfig-Datei. Die Umgebungsvariable $PWD funktioniert hier nicht. Darüber hinaus funktionieren relative kubeconfig-Dateispeicherorte, die „~“ verwenden, 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.
   • --platform multicloud Gibt an, dass es sich bei der Plattform um etwas anderes als Google Cloud handelt, z. B. eine lokale oder Multi-Cloud-Plattform.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • --ca gcp_casVerwenden Sie Certificate Authority Service als Zertifizierungsstelle. Das Ändern von Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten. asmcli konfiguriert den Zertifizierungsstellendienst für die Verwendung des Workload Identity der Flotte.
   • --ca_pool Die vollständige Kennung für den CA-Pool des Certificate Authority Service.

Upgrade für Standardfeatures mit Istio CA durchführen

In diesem Abschnitt wird gezeigt, wie Sie asmcli ausführen, um Anthos Service Mesh mit den unterstützten Standardfeatures für Ihre Plattform zu aktualisieren und Istio CA zu aktivieren.

GKE

Führen Sie den folgenden Befehl aus, um die Steuerungsebene mit Standardfeatures und Istio CA zu aktualisieren. Geben Sie Ihre Werte in die angegebenen Platzhalter ein.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel

• --project_id, --cluster_name und --cluster_location geben die Projekt-ID an, in der sich der Cluster befindet, den Clusternamen und entweder die Clusterzone oder -region.
• --fleet_id: Projekt-ID des Hostprojekts der Flotte. Wenn Sie diese Option nicht angeben, verwendet asmcli das Projekt, in dem der Cluster bei der Registrierung erstellt wurde.
• --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.
  Hinweis: Notieren Sie sich dieses --output_dir-Verzeichnis. Sie müssen bei der Bereitstellung von Gateways darauf verweisen.
• --enable_all: Ermöglicht dem Skript Folgendes:
  • Erforderliche IAM-Berechtigungen gewähren.
  • Erforderliche Google APIs aktivieren.
  • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
  • Den Cluster bei der Flotte registrieren, falls noch nicht geschehen.
• -ca citadel: Istio-Zertifizierungsstelle verwenden. Das Ändern der Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten.

Lokal

Führen Sie die folgenden Befehle in GKE on VMware oder Google Distributed Cloud Virtual for Bare Metal aus, um ein Upgrade der Steuerungsebene mit Standardfeatures und Istio-CA durchzuführen. Geben Sie Ihre Werte in die vorhandenen Platzhalter ein.

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

   kubectl config use-context CLUSTER_NAME
   

2. Führen Sie asmcli install aus.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der vollständige Pfad zur kubeconfig-Datei. Die Umgebungsvariable $PWD funktioniert hier nicht. Darüber hinaus funktionieren relative kubeconfig-Dateispeicherorte, die „~“ verwenden, 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.
   • --platform multicloud Gibt an, dass es sich bei der Plattform um etwas anderes als Google Cloud handelt, z. B. eine lokale oder Multi-Cloud-Plattform.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • -ca citadel: Verwenden Sie Istio-CA als Zertifizierungsstelle.
   • --ca_cert: Zwischenzertifikat.
   • --ca_key: Schlüssel für das Zwischenzertifikat.
   • --root_cert: Root-Zertifikat.
   • --cert_chain: Zertifikatskette.

AWS

Führen Sie die folgenden Befehle in GKE on AWS aus, um ein Upgrade der Steuerungsebene mit Standardfeatures und Istio-Zertifizierungsstelle durchzuführen. Geben Sie Ihre Werte in die vorhandenen Platzhalter ein. Sie können Ingress für das öffentliche oder das private Subnetz aktivieren.

Öffentlich

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

   kubectl config use-context CLUSTER_NAME
   

2. Führen Sie asmcli install aus.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der vollständige Pfad zur kubeconfig-Datei. Die Umgebungsvariable $PWD funktioniert hier nicht. Darüber hinaus funktionieren relative kubeconfig-Dateispeicherorte, die „~“ verwenden, 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.
   • --platform multicloud Gibt an, dass es sich bei der Plattform um etwas anderes als Google Cloud handelt, z. B. eine lokale oder Multi-Cloud-Plattform.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • -ca citadel: Verwenden Sie Istio-CA als Zertifizierungsstelle.
   • --ca_cert: Zwischenzertifikat.
   • --ca_key: Schlüssel für das Zwischenzertifikat.
   • --root_cert: Root-Zertifikat.
   • --cert_chain: Zertifikatskette.

Privat

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

   kubectl config use-context CLUSTER_NAME
   

2. Speichern Sie die folgende YAML-Datei in einer Datei mit dem Namen istio-operator-internal-lb.yaml:

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     components:
       ingressGateways:
       - enabled: true
         k8s:
           serviceAnnotations:
             service.beta.kubernetes.io/aws-load-balancer-internal: "true"
         name: istio-ingressgateway
   

3. Führen Sie asmcli install aus.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
     --custom_overlay istio-operator-internal-lb.yaml
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der vollständige Pfad zur kubeconfig-Datei. Die Umgebungsvariable $PWD funktioniert hier nicht. Darüber hinaus funktionieren relative kubeconfig-Dateispeicherorte, die „~“ verwenden, 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.
   • --platform multicloud Gibt an, dass es sich bei der Plattform um etwas anderes als Google Cloud handelt, z. B. eine lokale oder Multi-Cloud-Plattform.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • -ca citadel: Verwenden Sie Istio-CA als Zertifizierungsstelle.
   • --ca_cert: Zwischenzertifikat.
   • --ca_key: Schlüssel für das Zwischenzertifikat.
   • --root_cert: Root-Zertifikat.
   • --cert_chain: Zertifikatskette.

Amazon EKS

Führen Sie die folgenden Befehle in Amazon EKS aus, um die Steuerungsebene mit Standardfeatures und Istio CA zu aktualisieren. Geben Sie Ihre Werte in die vorhandenen Platzhalter ein.

Plattformhinweis: Wenn Sie Anthos Service Mesh 1.7 auf EKS installiert haben, müssen Sie Anthos Service Mesh 1.13 in einem neuen Cluster installieren. Upgrades von Anthos Service Mesh 1.7 auf Anthos Service Mesh 1.13 werden nicht unterstützt.

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

   kubectl config use-context CLUSTER_NAME
   

2. Führen Sie asmcli install aus.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der vollständige Pfad zur kubeconfig-Datei. Die Umgebungsvariable $PWD funktioniert hier nicht. Darüber hinaus funktionieren relative kubeconfig-Dateispeicherorte, die „~“ verwenden, 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.
   • --platform multicloud Gibt an, dass es sich bei der Plattform um etwas anderes als Google Cloud handelt, z. B. eine lokale oder Multi-Cloud-Plattform.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • -ca citadel: Verwenden Sie Istio-CA als Zertifizierungsstelle.
   • --ca_cert: Zwischenzertifikat.
   • --ca_key: Schlüssel für das Zwischenzertifikat.
   • --root_cert: Root-Zertifikat.
   • --cert_chain: Zertifikatskette.

Microsoft AKS

Führen Sie die folgenden Befehle in Amazon EKS aus, um die Steuerungsebene mit Standardfeatures und Istio CA zu aktualisieren. Geben Sie Ihre Werte in die vorhandenen Platzhalter ein.

Hinweis: Wenn Sie Anthos Service Mesh 1.7 auf AKS installiert haben, müssen Sie Anthos Service Mesh 1.13 in einem neuen Cluster installieren. Upgrades von Anthos Service Mesh 1.7 auf Anthos Service Mesh 1.13 werden nicht unterstützt.

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

   kubectl config use-context CLUSTER_NAME
   

2. Führen Sie asmcli install aus.

   HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der vollständige Pfad zur kubeconfig-Datei. Die Umgebungsvariable $PWD funktioniert hier nicht. Darüber hinaus funktionieren relative kubeconfig-Dateispeicherorte, die „~“ verwenden, 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.
   • --platform multicloud Gibt an, dass es sich bei der Plattform um etwas anderes als Google Cloud handelt, z. B. eine lokale oder Multi-Cloud-Plattform.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • -ca citadel: Verwenden Sie Istio-CA als Zertifizierungsstelle.
   • --ca_cert: Zwischenzertifikat.
   • --ca_key: Schlüssel für das Zwischenzertifikat.
   • --root_cert: Root-Zertifikat.
   • --cert_chain: Zertifikatskette.

Upgrade mit optionalen Features durchführen

Eine Overlay-Datei ist eine YAML-Datei mit einer benutzerdefinierten IstioOperator-Ressource, die Sie an asmcli übergeben, um die Steuerungsebene zu konfigurieren. Sie können die Standardkonfiguration der Steuerungsebene überschreiben und ein optionales Feature aktivieren, indem Sie die YAML-Datei an asmcli übergeben. Sie können mehrere Overlays ebenenweise platzieren. Jede Overlay-Datei überschreibt die Konfiguration auf den vorherigen Ebenen.

GKE

Führen Sie den folgenden Befehl aus, um die Steuerungsebene mit einem optionalen Feature zu installieren. Wenn Sie mehrere Dateien hinzufügen möchten, geben Sie --custom_overlay und den Dateinamen an. Beispiel: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml. Geben Sie Ihre Werte in die vorhandenen Platzhalter ein.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

• --project_id, --cluster_name und --cluster_location geben die Projekt-ID an, in der sich der Cluster befindet, den Clusternamen und entweder die Clusterzone oder -region.
• --fleet_id: Projekt-ID des Hostprojekts der Flotte. Wenn Sie diese Option nicht angeben, verwendet asmcli das Projekt, in dem der Cluster bei der Registrierung erstellt wurde.
• --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.
  Hinweis: Notieren Sie sich dieses --output_dir-Verzeichnis. Sie müssen bei der Bereitstellung von Gateways darauf verweisen.
• --enable_all: Ermöglicht dem Skript Folgendes:
  • Erforderliche IAM-Berechtigungen gewähren.
  • Erforderliche Google APIs aktivieren.
  • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
  • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
• --ca mesh_ca Verwendet Mesh CA als Zertifizierungsstelle. Das Ändern der Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten. asmcli konfiguriert Mesh CA für die Verwendung der Workload Identity der Flotte.
• --custom_overlay: Den Namen der Overlay-Datei angeben.

Außerhalb von Google Cloud

Führen Sie die folgenden Befehle in GKE on VMware, Google Distributed Cloud Virtual for Bare Metal, GKE on AWS, Amazon EKS oder Microsoft AKS aus. Geben Sie Ihre Werte in die angegebenen Platzhalter ein.

Plattformhinweis: Wenn Sie Anthos Service Mesh 1.7 auf EKS installiert haben, müssen Sie Anthos Service Mesh 1.13 in einem neuen Cluster installieren. Upgrades von Anthos Service Mesh 1.7 auf Anthos Service Mesh 1.13 werden nicht unterstützt.

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

   kubectl config use-context CLUSTER_NAME
   

2. Führen Sie asmcli install aus.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca \
     --custom_overlay OVERLAY_FILE
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der vollständige Pfad zur kubeconfig-Datei. Die Umgebungsvariable $PWD funktioniert hier nicht. Darüber hinaus funktionieren relative kubeconfig-Dateispeicherorte, die „~“ verwenden, 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.
   • --platform multicloud Gibt an, dass es sich bei der Plattform um etwas anderes als Google Cloud handelt, z. B. eine lokale oder Multi-Cloud-Plattform.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • --ca mesh_ca Verwendet Mesh CA als Zertifizierungsstelle. Das Ändern der Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten. asmcli konfiguriert Mesh CA für die Verwendung der Workload Identity der Flotte.
   • --custom_overlay: Den Namen der Overlay-Datei angeben.

Upgrade für Gateways durchführen

Wenn Sie Gateways bereitgestellt haben, müssen Sie diese ebenfalls aktualisieren. Wenn Sie ein einfaches Upgrade vornehmen möchten, lesen Sie den Abschnitt "Direkte Upgrades" im Leitfaden Gateways installieren und aktualisieren.

Warnung: Wenn Sie Anthos Service Mesh mit einer anderen Methode als asmcli installiert haben, wird das standardmäßige installierte Ingress-Gateway entfernt, es sei denn, Sie übergeben die --option legacy-default-ingressgateway-Argument.

Zur neuen Steuerungsebene wechseln

1. Rufen Sie das Überarbeitungslabel auf istiod ab.

   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
   istiod-asm-1139-10-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1129-0
   istiod-asm-1139-10-67998f4b55-r76kr           1/1     Running   0          68m   asm-1129-0
   istiod-1129-0-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1139-10
   istiod-1129-0-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1139-10

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

   2. Notieren Sie sich außerdem den Wert im Überarbeitungslabel der alten istiod-Version. Diesen Wert benötigen Sie, um die alte Version von istiod 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 Version asm-1129-0.

2. Fügen Sie das Überarbeitungslabel zu einem Anwendungs-Namespace hinzu und entfernen Sie das Label istio-injection (falls vorhanden). Geben Sie im folgenden Befehl für REVISION den Wert an, der der neuen Überarbeitung von istiod 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 Label istio-injection hatte. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl das istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Label istio-injection.

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.

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. 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. Verschieben Sie das Standard-Tag:

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
      

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

   1. 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 von istiod übereinstimmt:

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

   2. Löschen Sie die Ressource validatingwebhookconfiguration für die alte Überarbeitung:

      kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found
      

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

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

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

      kubectl get ns NAMESPACE --show-labels
      

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

   4. Entfernen Sie die neue Version von istiod. Achten Sie darauf, dass der Wert von REVISION im folgenden Befehl korrekt ist.

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

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

   6. Wenn Sie das Flag --disable_canonical_service nicht angegeben haben, hat asmcli den kanonischen Dienstüberwacher aktiviert. Wir empfehlen, ihn aktiviert zu lassen. Falls Sie ihn jedoch deaktivieren müssen, finden Sie weitere Informationen unter Kanonischen Dienstüberwacher aktivieren und deaktivieren.

   7. Wenn Sie Gateways bereitgestellt haben, ändern Sie das Überarbeitungslabel für den Namespace oder die Bereitstellung entsprechend der vorherigen Version von istiod. Führen Sie den gleichen Vorgang aus, der im Abschnitt "Direkte Upgrades" des Leitfadens Gateways installieren und aktualisieren beschrieben ist.

Arbeitslasten bereitstellen und neu bereitstellen

Die Installation (oder das Upgrade) 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 revisionsbasierten Upgrade wird die neue Version der Steuerungsebene zusammen mit der vorhandenen Steuerungsebene installiert. Anschließend verschieben Sie einige Ihrer Arbeitslasten zur neuen 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.

Das Skript legt ein Überarbeitungslabel im Format istio.io/rev=asm-1139-10 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.

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 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-1139-10
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1139-10
   istiod-asm-1139-10-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1129-0
   istiod-asm-1139-10-67998f4b55-r76kr          1/1     Running   0          68m   asm-1129-0
   istiod-asm-1129-0-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1139-10
   istiod-asm-1129-0-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1139-10

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

   2. Notieren Sie sich außerdem den Wert im Überarbeitungslabel der alten istiod-Version. Diesen Wert benötigen Sie, um die alte Version von istiod 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 Version asm-1129-0.

2. Fügen Sie das Überarbeitungslabel einem Namespace hinzu und entfernen Sie das istio-injection-Label (falls vorhanden). Geben Sie im folgenden Befehl für REVISION den Wert an, der der neuen Überarbeitung von istiod 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 Label istio-injection hatte. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl das istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Label istio-injection.

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.

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. 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. Verschieben Sie das Standard-Tag.

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
      

   4. 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 von istio-ingressgateway.

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

   5. 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 von istiod übereinstimmt.

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

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

   1. Wechseln Sie zurück zur alten Version von istio-ingressgateway. Ersetzen Sie im folgenden Befehl OLD_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"}]'
      

   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. Achten Sie darauf, dass der Wert von REVISION im folgenden Befehl korrekt ist.

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

   6. Entfernen Sie die neue Version von istiod. Achten Sie darauf, dass der Wert von REVISION im folgenden Befehl korrekt ist.

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

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

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