Anthos Service Mesh in GKE in einem Mesh mit mehreren Projekten upgraden

In dieser Anleitung wird beschrieben, wie Sie ein Upgrade von 1.8 or a 1.9 patch release auf Anthos Service Mesh 1.9.8 in einem GKE-Cluster (Google Kubernetes Engine) für ein Mesh-Netzwerk mit mehreren Clustern ausführen, die sich in verschiedenen Google Cloud-Projekten befinden.

Hinweise

Bevor Sie Anthos Service Mesh installieren, müssen folgende Voraussetzungen erfüllt sein:

Upgrade vorbereiten

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.

Das Skript folgt dem Upgradeprozess Überarbeitung (in der Istio-Dokumentation als „Canary-Upgrade“ bezeichnet). Mit einem Überarbeitungsupgrade installiert das Skript zusätzlich zur vorhandenen Steuerungsebene eine neue Überarbeitung der Steuerungsebene. Bei der Installation der neuen Version enthält das Skript das Label revision, mit dem die neue Steuerungsebene identifiziert wird.

Anschließend migrieren Sie zur neuen Version. Legen Sie dazu für Ihre Arbeitslasten dasselbe revision-Label fest und führen Sie einen rollierenden Neustart durch, um die Proxys noch einmal einzufügen, damit sie die neue Anthos Service Mesh-Version und -Konfiguration verwenden. Bei diesem Ansatz können Sie die Auswirkungen des Upgrades auf einen kleinen Prozentsatz Ihrer Arbeitslasten überwachen. Nachdem Sie Ihre Anwendung getestet haben, können Sie den gesamten Traffic zur neuen Version migrieren. Dieser Ansatz ist viel sicherer als ein direktes Upgrade, bei dem neue Komponenten der Steuerungsebene die vorherige Version ersetzen.

Umgebungsvariablen einrichten

  1. Rufen Sie die Projekt-ID des Projekts ab, in dem der Cluster erstellt wurde, sowie die Projektnummer für das Environ-Hostprojekt.

    gcloud

    Führen Sie dazu diesen Befehl aus:

    gcloud projects list

    Console

    1. Wechseln Sie in der Google Cloud Console zur Seite Dashboard.

      Zur Seite "Dashboard"

    2. Klicken Sie oben auf der Seite auf die Drop-down-Liste Auswählen aus. Wählen Sie im angezeigten Fenster Auswählen aus Ihr Projekt aus.

      Die Projekt-ID wird auf der Dashboard-Karte Projektinformationen des Projekts angezeigt.

  2. Erstellen Sie eine Umgebungsvariable für die Projekt-ID des Projekts, in dem der Cluster erstellt wurde: 

    export PROJECT_ID=YOUR_PROJECT_ID

  3. Erstellen Sie eine Umgebungsvariable für die Projektnummer des Environ-Hostprojekts.

    export ENVIRON_PROJECT_NUMBER=YOUR_ENVIRON_PROJECT_NUMBER

  4. Erstellen Sie die folgenden Umgebungsvariablen:

    • Legen Sie den Clusternamen fest: 

      export CLUSTER_NAME=YOUR_CLUSTER_NAME

    • Legen Sie CLUSTER_LOCATION entweder auf Ihre Clusterzone oder Clusterregion fest: 

      export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION

  5. Legen Sie die Standardzone oder -region für das Google Cloud-CLI fest. Wenn Sie hier keine Standardeinstellung festlegen, müssen Sie in den gcloud container clusters-Befehlen auf dieser Seite entweder die Option --zone oder --region angeben.

    • Wenn Sie einen Cluster mit einer einzelnen Zone haben, legen Sie die Standardzone fest:

      gcloud config set compute/zone ${CLUSTER_LOCATION}

    • Wenn Sie einen regionalen Cluster haben, legen Sie die Standardregion fest:

      gcloud config set compute/region ${CLUSTER_LOCATION}

    Tipp: Um die Einrichtung Ihrer Shell-Umgebung in Zukunft zu erleichtern, können Sie die export-Anweisungen für jede Umgebungsvariable kopieren und in ein einfaches Shell-Skript einfügen, das Sie beim Start einer neuen Shell beziehen (source). Außerdem können Sie die gcloud-Befehle hinzufügen, die Standardwerte zum Skript festlegen. Sie können auch gcloud init verwenden, um eine benannte gcloud-Konfiguration zu erstellen und zu aktivieren.

Anmeldedaten und Berechtigungen festlegen

  1. Rufen Sie die Anmeldedaten für die Authentifizierung ab, um mit dem Cluster zu interagieren: Mit diesem Befehl wird auch der aktuelle Kontext für kubectl auf den Cluster festgelegt.

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --project=${PROJECT_ID}

  2. Gewähren Sie dem aktuellen Nutzer Cluster-Administratorberechtigungen. Sie benötigen diese Berechtigungen, um die erforderlichen Regeln für die rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) für Anthos Service Mesh zu erstellen.

    kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user="$(gcloud config get-value core/account)"

Wenn der Fehler "cluster-admin-binding" already exists angezeigt wird, können Sie ihn ignorieren und mit der vorhandenen Cluster-Administratorbindung fortfahren.

Installationsdatei herunterladen

Linux

  1. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-linux-amd64.tar.gz

  2. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.9.8-asm.6-linux-amd64.tar.gz.1.sig istio-1.9.8-asm.6-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    Folgende Ausgabe wird erwartet: Verified OK

  3. Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis:

     tar xzf istio-1.9.8-asm.6-linux-amd64.tar.gz

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.9.8-asm.6 ein Installationsverzeichnis erstellt, das Folgendes enthält:

    • Beispielanwendungen im Verzeichnis samples.
    • Das istioctl-Befehlszeilentool, mit dem Sie Anthos Service Mesh installieren, befindet sich im Verzeichnis bin.
    • Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis manifests/profiles.

  4. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden.

    cd istio-1.9.8-asm.6

macOS

  1. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-osx.tar.gz

  2. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.9.8-asm.6-osx.tar.gz.1.sig istio-1.9.8-asm.6-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    Folgende Ausgabe wird erwartet: Verified OK

  3. Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis:

    tar xzf istio-1.9.8-asm.6-osx.tar.gz

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.9.8-asm.6 ein Installationsverzeichnis erstellt, das Folgendes enthält:

    • Beispielanwendungen im Verzeichnis samples.
    • Das istioctl-Befehlszeilentool, mit dem Sie Anthos Service Mesh installieren, befindet sich im Verzeichnis bin.
    • Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis manifests/profiles.

  4. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden.

    cd istio-1.9.8-asm.6

Windows

  1. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-win.zip

  2. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.8-asm.6-win.zip.1.sig
openssl dgst -verify - -signature istio-1.9.8-asm.6-win.zip.1.sig istio-1.9.8-asm.6-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    Folgende Ausgabe wird erwartet: Verified OK

  3. Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis:

    tar xzf istio-1.9.8-asm.6-win.zip

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.9.8-asm.6 ein Installationsverzeichnis erstellt, das Folgendes enthält:

    • Beispielanwendungen im Verzeichnis samples.
    • Das istioctl-Befehlszeilentool, mit dem Sie Anthos Service Mesh installieren, befindet sich im Verzeichnis bin.
    • Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis manifests/profiles.

  4. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden.

    cd istio-1.9.8-asm.6

Ressourcenkonfigurationsdateien vorbereiten

Wenn Sie den Befehl istioctl install ausführen, geben Sie -f istio-operator.yaml in der Befehlszeile an. Diese Datei enthält Informationen zu Ihrem Projekt und Cluster, die Anthos Service Mesh erfordert. Sie müssen ein Paket mit istio-operator.yaml- und anderen Ressourcenkonfigurationsdateien herunterladen, um die Projekt- und Clusterinformationen festlegen zu können.

So bereiten Sie die Ressourcenkonfigurationsdateien vor:

Mesh CA

  1. Erstellen Sie ein neues Verzeichnis für die Ressourcenkonfigurationsdateien des Anthos Service Mesh-Pakets. Es empfiehlt sich, den Clusternamen als Verzeichnisnamen zu verwenden.

  2. Wechseln Sie zu dem Verzeichnis, in das Sie das Anthos Service Mesh-Paket herunterladen möchten.

  3. Prüfen Sie die kpt-Version. Führen Sie eine kpt-Version vor 1.x aus:

    kpt version

    Die Ausgabe sollte in etwa so aussehen:

    0.39.2

    Wenn Sie kpt-Version 1.x oder höher haben, lesen Sie den Abschnitt Umgebung einrichten, um die erforderliche Version für Ihr Betriebssystem herunterzuladen.

  4. Laden Sie das Paket herunter:

    kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-asm asm

  5. Legen Sie die Projekt-ID für das Projekt fest, in dem der Cluster erstellt wurde:

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}

  6. Legen Sie die Projektnummer für das Flotten-Hostprojekt fest:

    kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

  7. Legen Sie den Clusternamen fest:

    kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

  8. Legen Sie die Standardzone oder -region fest:

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

  9. Setzen Sie das Tag auf die Version des Anthos Service Mesh, das Sie installieren:

    kpt cfg set asm anthos.servicemesh.tag 1.9.8-asm.6

  10. Legen Sie die Überarbeitung in den Konfigurationsdateien der Anthos Service Mesh-Paketressourcen fest:

    kpt cfg set asm anthos.servicemesh.rev asm-198-6

    Wenn Sie Anthos Service Mesh installieren, legen Sie ein Überarbeitungslabel auf istiod fest. Sie müssen für den Validierungs-Webhook dieselbe Überarbeitung festlegen.

  11. Da sich die Cluster in Ihrer Multi-Cluster-Konfiguration in verschiedenen Projekten befinden, müssen Sie die vertrauenswürdigen Domain-Aliasse für die anderen Projekte konfigurieren, die das Service Mesh mit mehreren Clustern oder mehreren Projekten bilden.

    1. Rufen Sie die Projekt-ID aller Cluster im Multi-Cluster-/Multi-Projekt-Mesh ab.

    2. Legen Sie für die Projekt-ID jedes Clusters die vertrauenswürdigen Domain-Aliase fest. Wenn Sie beispielsweise Cluster in drei Projekten haben, führen Sie den folgenden Befehl aus und ersetzen Sie PROJECT_ID_1, PROJECT_ID_2 und PROJECT_ID_3 durch die Projekt-ID jedes Clusters.

      kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog

      Wenn Sie die Cluster in den anderen Projekten konfigurieren, können Sie denselben Befehl verwenden.

      Mithilfe der vertrauenswürdigen Domain-Aliasse kann Mesh CA Arbeitslasten in Clustern in anderen Projekten authentifizieren. Zusätzlich zur Festlegung der vertrauenswürdigen Domain-Aliasse müssen Sie nach der Installation von Anthos Service Mesh das clusterübergreifende Load-Balancing aktivieren.

  12. Geben Sie die Werte der kpt-Setter aus:

    kpt cfg list-setters asm

    Die Ausgabe dieses Befehls sieht in etwa so aus: 

                              NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.9.8-asm.6
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.9.8-asm.6
anthos.servicemesh.trustDomainAliases                [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog]
base-dir                                             base
gcloud.compute.location                              us-central
gcloud.compute.network                               default
gcloud.compute.subnetwork                            default
gcloud.container.cluster                             example-cluster-1
gcloud.container.cluster.clusterSecondaryRange
gcloud.container.cluster.releaseChannel              REGULAR
gcloud.container.cluster.servicesSecondaryRange
gcloud.container.nodepool.max-nodes                  4
gcloud.core.project                                  example-project-12345
gcloud.project.environProjectID                      FLEET_PROJECT_ID
gcloud.project.environProjectNumber                  1234567890123
gcloud.project.projectNumber                         9876543210987

    Prüfen Sie, ob die Werte für die folgenden Setter korrekt sind:

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • anthos.servicemesh.trustDomainAliases
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    Sie können die Werte für die anderen Setter ignorieren.

Istio CA

  1. Erstellen Sie ein neues Verzeichnis für die Ressourcenkonfigurationsdateien des Anthos Service Mesh-Pakets. Es empfiehlt sich, den Clusternamen als Verzeichnisnamen zu verwenden.

  2. Wechseln Sie zu dem Verzeichnis, in das Sie das Anthos Service Mesh-Paket herunterladen möchten.

  3. Prüfen Sie die kpt-Version. Führen Sie eine kpt-Version vor 1.x aus:

    kpt version

    Die Ausgabe sollte in etwa so aussehen:

    0.39.2

    Wenn Sie die kpt-Version 1.x oder höher haben, laden Sie die erforderliche Version herunter:

    curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2
chmod +x kpt_0_39_2
alias kpt="$(readlink -f kpt_0_39_2)"

  4. Laden Sie das Paket herunter:

    kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.9-asm asm

  5. Legen Sie die Projekt-ID für das Projekt fest, in dem der Cluster erstellt wurde:

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}

  6. Legen Sie die Projektnummer für das Flotten-Hostprojekt fest:

    kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

  7. Legen Sie den Clusternamen fest:

    kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

  8. Legen Sie die Standardzone oder -region fest:

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

  9. Setzen Sie das Tag auf die Version des Anthos Service Mesh, das Sie installieren:

    kpt cfg set asm anthos.servicemesh.tag 1.9.8-asm.6

  10. Legen Sie die Überarbeitung in den Konfigurationsdateien der Anthos Service Mesh-Paketressourcen fest:

    kpt cfg set asm anthos.servicemesh.rev asm-198-6

  11. Geben Sie die Werte der kpt-Setter aus:

    kpt cfg list-setters asm

    Die Ausgabe dieses Befehls sieht in etwa so aus: 

                              NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.9.8-asm.6
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.9.8-asm.6
anthos.servicemesh.trustDomainAliases
base-dir                                             base
gcloud.compute.location                              us-central
gcloud.compute.network                               default
gcloud.compute.subnetwork                            default
gcloud.container.cluster                             example-cluster-1
gcloud.container.cluster.clusterSecondaryRange
gcloud.container.cluster.releaseChannel              REGULAR
gcloud.container.cluster.servicesSecondaryRange
gcloud.container.nodepool.max-nodes                  4
gcloud.core.project                                  example-project-12345
gcloud.project.environProjectID                      FLEET_PROJECT_ID
gcloud.project.environProjectNumber                  1234567890123
gcloud.project.projectNumber                         9876543210987

    Prüfen Sie, ob die Werte für die folgenden Setter korrekt sind:

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    Sie können die Werte für die anderen Setter ignorieren.

Upgrade von Anthos Service Mesh durchführen

Mesh CA

  1. Prüfen Sie, ob der aktuelle kubeconfig-Kontext auf den Cluster verweist, auf dem Sie Anthos Service Mesh installieren möchten:

    kubectl config current-context

    Die Ausgabe hat das folgende Format:

    gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

    Der kubeconfig-Kontext und die Werte der kpt-Setter müssen übereinstimmen. Führen Sie bei Bedarf den Befehl gcloud container clusters get-credentials aus, um den aktuellen kubeconfig-Kontext festzulegen.

  2. Wechseln Sie gegebenenfalls zum Verzeichnis istio-1.9.8-asm.6. Der istioctl-Client ist versionsabhängig. Sie müssen die Version im Verzeichnis istio-1.9.8-asm.6/bin verwenden.

  3. Führen Sie den folgenden Befehl aus, um die neue Steuerungsebene mit dem Profil asm-gcp-multiproject bereitzustellen. Wenn Sie ein unterstütztes optionales Feature aktivieren möchten, fügen Sie in der folgenden Befehlszeile -f und den YAML-Dateinamen hinzu. Weitere Informationen finden Sie unter Optionale Features aktivieren.

    bin/istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml \
  -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
  --revision=asm-198-6

    Mit dem Argument --revision wird istiod ein Überarbeitungslabel im Format istio.io/rev=asm-198-6 hinzugefügt. Das Überarbeitungslabel wird vom automatischen Sidecar-Injektor-Webhook verwendet, um eingefügte Sidecars mit einer bestimmten istiod-Überarbeitung zu verknüpfen. Wenn Sie die automatische Sidecar-Injektion für einen Namespace aktivieren möchten, müssen Sie ihn mit einer Überarbeitung versehen, die einer istiod-Bereitstellung entspricht.

    Mit den folgenden Dateien werden die Einstellungen in der Datei istio-operator.yaml überschrieben:

    • Mit der Datei multiproject.yaml wird das Profil asm-gcp-multiproject festgelegt.

    • Mit der Datei multicluster.yaml werden die Einstellungen konfiguriert, die Anthos Service Mesh für eine Konfiguration mit mehreren Clustern benötigt.

    • Die Datei revisioned-istio-ingressgateway.yaml konfiguriert ein überarbeitetes Deployment für das istio-ingressgateway.

  4. Prüfen Sie, ob die Pods der Steuerungsebene in istio-system aktiv sind:

    kubectl get pods -n istio-system

    Beispielausgabe:

    NAME                                        READY   STATUS    RESTARTS   AGE
istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
istiod-asm-198-6-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

    Zwei Deployments der Steuerungsebene und Dienste werden parallel ausgeführt.

  5. Stellen Sie den kanonischen Dienstüberwacher in Ihrem Cluster bereit:

    kubectl apply -f asm/canonical-service/controller.yaml

    Der kanonische Dienstüberwacher gruppiert Arbeitslasten, die zum selben logischen Dienst gehören. Weitere Informationen zu kanonischen Diensten finden Sie in der Übersicht Kanonische Dienste.

Istio CA

  1. Prüfen Sie, ob der aktuelle kubeconfig-Kontext auf den Cluster verweist, auf dem Sie Anthos Service Mesh installieren möchten:

    kubectl config current-context

    Die Ausgabe hat das folgende Format:

    gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

    Der kubeconfig-Kontext und die Werte der kpt-Setter müssen übereinstimmen. Führen Sie bei Bedarf den Befehl gcloud container clusters get-credentials aus, um den aktuellen kubeconfig-Kontext festzulegen.

  2. Wechseln Sie gegebenenfalls zum Verzeichnis istio-1.9.8-asm.6. Der istioctl-Client ist versionsabhängig. Sie müssen die Version im Verzeichnis istio-1.9.8-asm.6/bin verwenden.

  3. Führen Sie den folgenden Befehl aus, um die neue Steuerungsebene mit dem Profil asm-gcp-multiproject bereitzustellen. Wenn Sie ein unterstütztes optionales Feature aktivieren möchten, fügen Sie in der folgenden Befehlszeile -f und den YAML-Dateinamen hinzu. Weitere Informationen finden Sie unter Optionale Features aktivieren.

    bin/istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/citadel-ca.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml \
  -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
  --revision=asm-198-6

    Mit dem Argument --revision wird istiod ein Überarbeitungslabel im Format istio.io/rev=asm-198-6 hinzugefügt. Das Überarbeitungslabel wird vom automatischen Sidecar-Injektor-Webhook verwendet, um eingefügte Sidecars mit einer bestimmten istiod-Überarbeitung zu verknüpfen. Wenn Sie die automatische Sidecar-Injektion für einen Namespace aktivieren möchten, müssen Sie ihn mit einer Überarbeitung versehen, die einer istiod-Bereitstellung entspricht.

    Mit den folgenden Dateien werden die Einstellungen in der Datei istio-operator.yaml überschrieben:

    • citadel-ca.yaml konfiguriert die Istio-Zertifizierungsstelle als Zertifizierungsstelle.

    • Mit der Datei multiproject.yaml wird das Profil asm-gcp-multiproject festgelegt.

    • Mit der Datei multicluster.yaml werden die Einstellungen konfiguriert, die Anthos Service Mesh für eine Konfiguration mit mehreren Clustern benötigt.

    • Die Datei revisioned-istio-ingressgateway.yaml konfiguriert ein überarbeitetes Deployment für das istio-ingressgateway.

  4. Prüfen Sie, ob die Pods der Steuerungsebene in istio-system aktiv sind:

    kubectl get pods -n istio-system

    Beispielausgabe:

    NAME                                        READY   STATUS    RESTARTS   AGE
istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
istiod-asm-198-6-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

    Zwei Deployments der Steuerungsebene und Dienste werden parallel ausgeführt.

  5. Stellen Sie den kanonischen Dienstüberwacher in Ihrem Cluster bereit:

    kubectl apply -f asm/canonical-service/controller.yaml

    Der kanonische Dienstüberwacher gruppiert Arbeitslasten, die zum selben logischen Dienst gehören. Weitere Informationen zu kanonischen Diensten finden Sie in der Übersicht Kanonische Dienste.

Arbeitslasten bereitstellen und neu bereitstellen

Die Installation ist erst abgeschlossen, wenn Sie die automatische Sidecar-Proxy-Injektion aktivieren (automatische Injektion). Migrationen von OSS Istio sowie Upgrades folgen einem revisionsbasierten Upgradevorgang. Dieser wird in der Istio-Dokumentation als „Canary-Upgrade“ bezeichnet. Bei einem überarbeitungsbasierten Upgrade wird die neue Version der Steuerungsebene zusammen mit der vorhandenen Steuerungsebene installiert. Anschließend verschieben Sie einige Ihrer Arbeitslasten auf die neue Version. Damit können Sie die Auswirkungen des Upgrades mit einem kleinen Prozentsatz der Arbeitslasten prüfen, bevor Sie den gesamten Traffic zur neuen Version migrieren.

Bei der Ausführung von istioctl install legten Sie ein Überarbeitungslabel im Format istio.io/rev=asm-198-6 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.

Wenn Sie revisioned-istio-ingressgateway.yaml beim Ausführen von istioctl install einbezogen haben, wird ein überarbeitetes Deployment für istio-ingressgateway konfiguriert. So können Sie steuern, wann Sie zur neuen Version wechseln.

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

    1. Prüfen Sie, ob Sie sowohl die alte als auch die neue Version von istio-ingressgateway haben.

      • Wenn Sie beim Upgrade die Option revisioned-istio-ingressgateway angegeben haben, wurde ein Canary-Upgrade von istio-ingressgateway durchgeführt. In diesem Fall zeigt die Ausgabe sowohl die alte als auch die neue Version von istio-ingressgateway an.

      • Wenn Sie beim Upgrade revisioned-istio-ingressgateway nicht angegeben haben, wurde ein direktes Upgrade von istio-ingressgateway durchgeführt. In diesem Fall enthält Ihre Ausgabe nur die neue Version.

    2. Notieren Sie sich in der Ausgabe unter der Spalte REV den Wert des Überarbeitungslabels für die neue Version. In diesem Beispiel ist der Wert asm-198-6.

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

  2. Wenn Sie sowohl die alte als auch die neue Version von istio-ingressgateway haben, wechseln Sie istio-ingressgateway zur neuen Überarbeitung. Ändern Sie im folgenden Befehl REVISION in den Wert, der dem Überarbeitungslabel der neuen Version entspricht.

    kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

    Erwartete Ausgabe: service/istio-ingressgateway patched

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

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

    kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

  9. Führen Sie folgenden Befehl noch einmal aus, um zu prüfen, ob Sie sowohl die alte als auch die neue Version von istio-ingressgateway oder nur die neue Version haben. Dies bestimmt, wie mit der Umstellung auf die neue Version von istio-ingressgateway oder einem Rollback auf die alte Version umgegangen wird.

    kubectl get pod -n istio-system -L istio.io/rev

    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. Wenn Sie sowohl die alte als auch die neue Version von istio-ingressgateway nutzen, 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 machen:

      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

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

    5. 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. Der verwendete Befehl hängt davon ab, ob Sie die alte und die neue Version von istio-ingressgateway oder nur die neue Version haben.

      • Wenn Sie sowohl die alte als auch die neue Version von istio-ingressgateway verwenden, führen Sie den kubectl patch service-Befehl aus und ersetzen OLD_REVISION durch die alte Überarbeitung.

        kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'

      • Wenn Sie nur die neue Version von istio-ingressgateway haben, führen Sie den kubectl rollout undo-Befehl aus.

        kubectl -n istio-system rollout undo deploy istio-ingressgateway

    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. Wenn Sie sowohl die alte als auch die neue Version von istio-ingressgateway verwenden, 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.

Nächste Schritte