Upgrade von Apigee Hybrid auf Version 1.8 ausführen

Einführung in das Apigee Ingress-Gateway

Ab Version 1.8 bietet Apigee Hybrid ein neues Feature zum Verwalten des Ingress-Gateways für die Hybridinstallation: Apigee Ingress-Gateway. Anthos Service Mesh ist keine Voraussetzung für die Hybridinstallation mehr. Mit dem Apigee-Ingress-Gateway stellt Apigee die Routingkonfiguration nicht mehr an Anthos Service Mesh bereit. Nach dem Upgrade müssen Sie den Traffic zum neuen Apigee Ingress-Gateway migrieren, bevor Sie das Feature verwenden können.

Apigee verwendet für das Ingress-Gateway einen kleinen Teil der Anthos Service Mesh-Funktionen. Ab der Hybridversion 1.8 enthält Apigee Hybrid ein Ingress-Gateway, das im Rahmen von Apigee Hybrid-Upgrades installiert und aktualisiert wird. Sie benötigen daher keine Kenntnisse über Anthos Service Mesh, um Apigee Hybrid zu installieren, zu aktualisieren und zu verwalten. Probleme mit Ingress-Gateway-Versionen und Kompatibilität mit Apigee Hybrid-Releases werden automatisch behoben.

Es gibt zwei Migrationsszenarien:

  • Multi-Cluster- oder Multi-Region-Migration (empfohlen):

    Bevor Sie zu einem neuen Ingress für Apigee wechseln, leeren Sie den gesamten Traffic von dem zu migrierenden Cluster zu einem anderen Cluster oder einer anderen Region. Dadurch haben Sie Zeit, zu testen, ob das neue Apigee-Ingress-Gateway wie erwartet funktioniert. Verschieben Sie dann den Traffic zurück zum aktualisierten Cluster.

  • Direktes Upgrade (nicht in Produktionsumgebungen empfohlen):

    Während des Upgrades ruft Apigee das neue Ingress-Gateway mit einer von Ihnen angegebenen IP-Adresse auf. Sie können dann testen, ob das neue Apigee-Ingress-Gateway wie erwartet funktioniert, und dann den Traffic auf das neue Ingress-Gateway verschieben. Während dieses Upgrades kann es zu Ausfallzeiten kommen.

Wenn Sie Apigee Hybrid auf Version 1.8 aktualisieren, müssen Sie das Apigee Ingress-Gateway in Ihrer Überschreibungsdatei konfigurieren. Nach dem Upgrade steuern Sie, welchen Typ von Ingress-Gateway Ihre Cluster verwenden. Dazu leiten Sie die A- oder CNAME-Einträge bei Ihrem Registrator an die IP-Adresse des Apigee Ingress-Gateways oder für Anthos Service Mesh weiter.

Upgrade auf Version 1.8.8 – Übersicht

Die Schritte zum Upgrade von Apigee Hybrid werden in den folgenden Abschnitten erläutert:

  1. Bereiten Sie das Upgrade vor..
  2. Installieren Sie die Hybrid-Laufzeitversion 1.8.8.
  3. Wählen Sie für das Ingress-Gateway eine der folgenden Optionen aus:

Voraussetzung

In dieser Upgrade-Anleitung wird davon ausgegangen, dass Sie die Apigee Hybrid-Version 1.7.x oder eine frühere Patch-Version von Version 1.8.x installiert haben und ein Upgrade auf Version 1.8.8 durchführen möchten. Wenn Sie eine Aktualisierung von einer früheren Version ausführen, lesen Sie die Anleitung unter Upgrade von Apigee Hybrid auf Version 1.7 ausführen.

Wenn Sie weiterhin Anthos Service Mesh verwenden möchten, müssen Sie darauf achten, dass Anthos Service Mesh auf eine unterstützte Version aktualisiert wird. Die unterstützten Versionen von Anthos Service Mesh finden Sie in der Tabelle Unterstützte Plattformen.

Bereiten Sie das Upgrade auf Version 1.8 vor.

  1. In dieser Anleitung wird die Umgebungsvariable APIGEECTL_HOME für das Verzeichnis in Ihrem Dateisystem verwendet, in dem Sie apigeectl installiert haben. Wechseln Sie bei Bedarf in das Verzeichnis apigeectl und definieren Sie die Variable mit dem folgenden Befehl:

    Linux

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Mac OS

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Windows

    set APIGEECTL_HOME=%CD%
    echo %APIGEECTL_HOME%
  2. Erstellen Sie eine Sicherungskopie Ihres $APIGEECTL_HOME/-Verzeichnisses der Version 1.7. Beispiel:
    tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
  3. Sichern Sie Ihre Cassandra-Datenbank entsprechend der Anleitung unter Cassandra-Sicherung und -Wiederherstellung.

Fügen Sie dem Dienstkonto für die Apigee-Laufzeit die Rolle Cloud Trace Agent hinzu. (Optional)

Optional: Wenn Sie Cloud Trace verwenden möchten und diesen Schritt noch nicht bei der Installation von Hybrid v1.7 ausgeführt haben, achten Sie darauf, dass Ihr Dienstkonto für Ihre Apigee-Laufzeitdienste die Cloud Trace-Agent-Rolle hat. (roles/cloudtrace.agent).

In Produktionsumgebungen ist dies normalerweise das Dienstkonto apigee-runtime. In Nicht-Produktionsumgebungen ist dies in der Regel das Dienstkonto apigee-non-prod.

Sie können die Rolle in der Benutzeroberfläche Cloud Console > IAM und Verwaltung > Dienstkonten oder mit den folgenden Befehlen hinzufügen:

  1. Rufen Sie die E-Mail-Adresse Ihres Dienstkontos mit dem folgenden Befehl ab:

    Produktion

    gcloud iam service-accounts list --filter "apigee-runtime"

    Wenn es mit dem Muster apigee-runtime@$ORG_NAME.iam.gserviceaccount.com übereinstimmt, können Sie dieses Muster im nächsten Schritt verwenden.

    Non-prod

    gcloud iam service-accounts list --filter "apigee-non-prod"

    Wenn es mit dem Muster apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com übereinstimmt, können Sie dieses Muster im nächsten Schritt verwenden.

  2. Weisen Sie dem Dienstkonto die Rolle Cloud Trace-Agent zu:

    Produktion

    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
        --role="roles/cloudtrace.agent"

    Non-prod

    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
        --role="roles/cloudtrace.agent"

    Beispiel

    gcloud projects add-iam-policy-binding hybrid-example-project \
        --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
        --role="roles/cloudtrace.agent"

    Dabei gilt: $PROJECT_ID ist der Name des Google Cloud-Projekts, in dem Apigee Hybrid installiert ist.

Installation von Apigee Ingress Gateway vorbereiten

So installieren Sie das Apigee Ingress-Gateway als Teil des Upgrades: Sie müssen die folgende ingressGateways-Property zu Ihrer Überschreibungsdatei hinzufügen.

Syntax

ingressGateways:
- name: INGRESS_NAME
  replicaCountMin: REPLICAS_MIN
  replicaCountMax: REPLICAS_MAX
  resources:
    requests:
      cpu: CPU_COUNT_REQ
      memory: MEMORY_REQ
    limits:
      cpu: CPU_COUNT_LIMIT
      memory: MEMORY_LIMIT
  svcAnnotations:  # optional. See Known issue 243599452.
    SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
  svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

Beispiel

ingressGateways:
- name: prod1
  replicaCountMin: 2
  replicaCountMax: 100
  resources:
    requests:
      cpu: 1
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi 
  • INGRESS_NAME ist der Name des Ingress-Deployments. Dies kann ein beliebiger Name sein, der die folgenden Anforderungen erfüllt:
    • Darf maximal 17 Zeichen lang sein
    • Darf nur kleingeschriebene, alphanumerische Zeichen enthalten, "-" oder ".".
    • Muss mit einem alphanumerischen Zeichen beginnen.
    • Muss mit einem alphanumerischen Zeichen enden.

    Weitere Informationen finden Sie in der Referenz zu Konfigurationsattributen unter ingressGateways[].name.

  • REPLICAS_MIN und REPLICAS_MAX sind die minimalen und maximalen Replikatzahlen für das Apigee-Ingress-Gateway in Ihrer Installation. Weitere Informationen und Standardeinstellungen finden Sie unter ingressGateways[].replicaCountMin und ingressGateways[].replicaCountMax in der Referenz zu Konfigurationsattributen.
  • CPU_COUNT_REQ und MEMORY_REQ sind die CPU- und Speicheranforderung für jedes Replikat des Apigee Ingress-Gateways in Ihrer Installation.

    Weitere Informationen und Standardeinstellungen finden Sie unter ingressGateways[].resources.requests.cpu und ingressGateways[].resources.requests.memory in der Referenz zu Konfigurationsattributen.

  • CPU_COUNT_LIMIT und MEMORY_LIMIT: die maximalen CPU- und Arbeitsspeicherlimits für jedes Replikat des Apigee Ingress-Gateways in Ihrer Installation.

    Weitere Informationen und Standardeinstellungen finden Sie unter ingressGateways[].resources.limits.cpu und ingressGateways[].resources.limits.memory in der Referenz zu Konfigurationsattributen.

  • SVC_ANNOTATIONS_KEY und SVC_ANNOTATIONS_VALUE (optional):

    Dies ist ein Schlüssel/Wert-Paar, das Annotationen für Ihren Standarddienst für eingehenden Traffic bereitstellt. Annotationen werden von Ihrer Cloud Platform verwendet, um Ihre Hybridinstallation zu konfigurieren, z. B. um den Load-Balancer-Typ auf intern oder extern festzulegen. Beispiel:

    ingressGateways:
      svcAnnotations:
        networking.gke.io/load-balancer-type: "Internal"

    Annotationen variieren je nach Plattform. Erforderliche und vorgeschlagene Annotationen finden Sie in der Dokumentation Ihrer Plattform.

    Weitere Informationen finden Sie unter ingressGateways[].svcAnnotations in der Referenz zu Konfigurationsattributen.
  • SVC_LOAD_BALANCER_IP (optional): Ermöglicht das Zuweisen einer statischen IP-Adresse für Ihren Load-Balancer. Auf Plattformen, die die Angabe der IP-Adresse des Load-Balancers unterstützen, wird der Load-Balancer mit dieser IP-Adresse erstellt. Auf Plattformen, auf denen Sie die IP-Adresse des Load-Balancers nicht angeben können, wird dieses Attribut ignoriert.

    Wenn Sie Ihrem Load-Balancer keine statische IP-Adresse zugewiesen haben, lassen Sie dieses Attribut in der Überschreibungsdatei weg.

    Siehe ingressGateways[].svcLoadBalancerIP in der Referenz zu Konfigurationsattributen.

Nehmen Sie zusätzliche Änderungen an Ihrer Überschreibungsdatei vor, um optionale v1.8-Features zu aktivieren oder zu deaktivieren.

Fügen Sie der overrides.yaml-Datei die folgenden Attribute hinzu, um neue Funktionen in Hybrid v1.8 zu aktivieren. Diese Funktionen sind optional.

  • UDCA ist jetzt auf Organisationsebene standardmäßig aktiviert. Die Verwendung einer einzigen UDCA-Bereitstellung zur Verarbeitung von Traffic für alle Umgebungen verhindert eine Unterauslastung der UDCA-Pods und erhöht die Verfügbarkeit von Knotenressourcen für andere Apigee-Komponenten. Die UDCA auf Organisationsebene verwendet ein einziges Dienstkonto für alle Umgebungen: apigee-udca.

    Wenn Sie in verschiedenen Umgebungen unterschiedliche Dienstkonten für UDCA verwenden, beachten Sie, dass jetzt das Dienstkonto verwendet wird, das auf Organisationsebene in Ihrer Überschreibungendatei mit udca:serviceAccountPath angegeben wurde, anstatt das, das auf der Umgebungsebene mit envs:udca:serviceAccountPath angegebene ist.

    Apigee Hybrid v 1.8 unterstützt die umgebungsbezogene UDCA. Wenn Sie die UDCA pro Umgebung beibehalten möchten, legen Sie orgScopedUDCA: false fest.

    Weitere Informationen finden Sie in der Referenz zu Konfigurationsattributen unter orgScopedUDCA.

  • Aktivieren Sie validateOrg, um eine strenge Validierung zu erfordern, dass die Apigee-Organisation und -Umgebung aktiv sind und mit dem Google Cloud Platform-Projekt arbeiten, das in Ihrer overrides-Datei angegeben ist.
    validateOrg: true

    Weitere Informationen finden Sie in der Referenz zu Konfigurationsattributen unter validateOrg.

Hybrid 1.8.8-Laufzeit installieren

  1. Sie müssen das Hybrid-Basisverzeichnis geöffnet haben. Dies ist das übergeordnete Verzeichnis des Verzeichnisses, in dem sich die ausführbare Datei apigeectl befindet:
    cd $APIGEECTL_HOME/..
  2. Laden Sie das Releasepaket für Ihr Betriebssystem mit dem folgendem Befehl herunter. Wählen Sie Ihre Plattform in der folgenden Tabelle aus:

    Linux

    Linux 64-Bit:

    curl -LO \
      https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_linux_64.tar.gz

    macOS

    Mac 64-Bit:

    curl -LO \
      https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_mac_64.tar.gz

    Windows

    Windows 64-Bit:

    curl -LO ^
      https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip
  3. Benennen Sie Ihr aktuelles apigeectl/-Verzeichnis in einen Backupverzeichnisnamen um. Beispiel:

    Linux

    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

    macOS

    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/ 

    Windows

    rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7 
  4. Extrahieren Sie die heruntergeladenen gzip-Dateiinhalte in Ihr Hybrid-Basisverzeichnis. Das Hybrid-Basisverzeichnis ist das Verzeichnis, in dem sich das umbenannte Verzeichnis apigeectl-v1.7 befindet:

    Linux

    tar xvzf filename.tar.gz -C ./

    macOS

    tar xvzf filename.tar.gz -C ./

    Windows

    tar xvzf filename.zip -C ./
  5. Die TAR-Inhalte werden standardmäßig in einem Verzeichnis gezeigt, dessen Name die Version und Plattform enthält. Beispiel: ./apigeectl_1.8.8-xxxxxxx_linux_64. Benennen Sie dieses Verzeichnis mit dem folgenden Befehl in apigeectl um:

    Linux

    mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl

    macOS

    mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl

    Windows

    rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl
  6. Wechseln Sie in das Verzeichnis apigeectl:
    cd ./apigeectl

    Dieses Verzeichnis ist das Basisverzeichnis apigeectl. Hier befindet sich der ausführbare Befehl apigeectl.

  7. In dieser Anleitung wird die Umgebungsvariable $APIGEECTL_HOME für das Verzeichnis in Ihrem Dateisystem verwendet, in dem das Dienstprogramm apigeectl installiert ist. Wechseln Sie bei Bedarf in das Verzeichnis apigeectl und definieren Sie die Variable mit dem folgenden Befehl:

    Linux

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Mac OS

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Windows

    set APIGEECTL_HOME=%CD%
    echo %APIGEECTL_HOME%
  8. Prüfen Sie die Version von apigeectl mit dem Befehl version:
    ./apigeectl version
    Version: 1.8.8
  9. Wechseln Sie zum Verzeichnis hybrid-base-directory/hybrid-files. Im Verzeichnis hybrid-files befinden sich Konfigurationsdateien wie die Überschreibungsdatei, Zertifikate und Dienstkonten. Beispiel:
    cd $APIGEECTL_HOME/../hybrid-files
  10. Prüfen Sie mit dem folgenden Befehl, ob kubectl auf den richtigen Kontext eingestellt ist. Der aktuelle Kontext sollte auf den Cluster eingestellt werden, in dem Sie Apigee Hybrid aktualisieren.
    kubectl config get-contexts | grep \*
  11. Im Verzeichnis hybrid-files:
    1. Aktualisieren Sie die folgenden symbolischen Links zu $APIGEECTL_HOME. Mit diesen Links können Sie den neu installierten Befehl apigeectl aus dem Verzeichnis hybrid-files ausführen:
      ln -nfs $APIGEECTL_HOME/tools tools
      ln -nfs $APIGEECTL_HOME/config config
      ln -nfs $APIGEECTL_HOME/templates templates
      ln -nfs $APIGEECTL_HOME/plugins plugins
    2. Prüfen Sie, ob die Symlinks ordnungsgemäß erstellt wurden. Führen Sie dazu den folgenden Befehl aus und achten Sie darauf, dass die Linkpfade auf die richtigen Speicherorte verweisen:
      ls -l | grep ^l
  12. Führen Sie eine Probelaufinitialisierung aus, um nach Fehlern zu suchen:
    ${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client

    Dabei ist OVERRIDES_FILE der Name Ihrer Überschreibungsdatei, z. B. ./overrides/overrides.yaml.

  13. Wenn keine Fehler auftreten, initialisieren Sie Hybrid 1.8.8: Mit diesem Befehl wird auch das Apigee Ingress-Gateway installiert und konfiguriert:
    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
  14. Prüfen Sie den Initialisierungsstatus:
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Bei Erfolg lautet die Ausgabe: All containers ready.

    Als weitere Prüfung können Sie auch den folgenden Befehl ausführen, um den Status von ApigeeDataStore zu prüfen:

    kubectl describe apigeeds -n apigee

    Suchen Sie in der Ausgabe nach State: running.

  15. Suchen Sie mit dem Probelauf des Befehls apply mit dem Flag --dry-run nach Fehlern:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
  16. Wenn keine Fehler vorhanden sind, wenden Sie die Überschreibungen an. Wählen Sie je nach Ihrer Installation die Anleitung für Produktionsumgebungen oder Nicht-Produktionsumgebungen und folgen Sie diesen.

    Produktion

    In Produktionsumgebungen sollten Sie jede Hybridkomponente einzeln aktualisieren und den Status der aktualisierten Komponente prüfen, bevor Sie mit der nächsten Komponente fortfahren.

    1. Sie müssen sich im Verzeichnis hybrid-files befinden.
    2. Wenden Sie Ihre Überschreibungen an, um Upgrade von Cassandra durchzuführen:
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
    3. Abschluss prüfen:
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

      Fahren Sie mit dem nächsten Schritt nur fort, wenn die Pods bereit sind.

    4. Wenden Sie Ihre Überschreibungen an, um Telemetriekomponenten zu aktualisieren, und prüfen Sie den Fortschritt:
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    5. Richten Sie die Redis-Komponenten ein:
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
    6. Wenn Sie Ihre Überschreibungen an, um zu aktualisieren die Komponenten auf Organisationsebene (MART, Watcher, Apigee Connect) und prüfen Sie den Abschluss des Vorgangs:
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    7. Nutzen Sie Überschreibungen, um Ihre Umgebungen zu aktualisieren. Sie haben zwei Möglichkeiten:
      • Jede Umgebung separat: Sie wenden die Überschreibungen auf eine einzelne Umgebung gleichzeitig an und prüfen den Fortschritt. Wiederholen Sie den Schritt für jede Umgebung:
        $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
        $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

        Dabei ist ENV_NAME der Name der Umgebung, die Sie aktualisieren.

      • Alle Umgebungen gleichzeitig: Sie können die Überschreibungen auf alle Umgebungen gleichzeitig anwenden und den Abschluss prüfen:
        $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
        $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    8. Wenden Sie Ihre Überschreibungen an, um die virtualhosts-Komponenten zu aktualisieren, und prüfen Sie den Fortschritt:
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Non-prod

    In den meisten Nicht-Produktionsumgebungen, Demo- und Testumgebungen können Sie die Überschreibungen auf alle Komponenten gleichzeitig anwenden. Wenn Ihre Nicht-Produktionsumgebung groß und komplex ist oder eine Produktionsumgebung nachahmt, können Sie die Anleitung zum Upgrade von Produktionsumgebungen verwenden.

    1. Sie müssen sich im Verzeichnis hybrid-files befinden.
    2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
    3. Prüfen Sie den Status:
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Aktualisieren Sie Ihre Kubernetes-Version

Aktualisieren Sie Ihre Kubernetes-Plattform auf die von Hybrid 1.8 unterstützten Versionen. Weitere Informationen finden Sie in der Dokumentation der Plattform.

Traffic von Anthos Service Mesh auf Apigee Ingress-Gateway umstellen

So wechseln Sie den Traffic zum Apigee Ingress-Gateway:

  1. Geben Sie das Apigee Ingress-Gateway frei. Folgen Sie den Schritten unter Apigee-Ingress-Gateway freigeben.
  2. Neues Ingress-Gateway durch Aufrufen eines Proxys testen Testen Sie idealerweise alle wichtigen Proxys, die derzeit bereitgestellt sind.
  3. Aktualisieren Sie zum Ändern des Traffics Ihre DNS-Einträge so, dass sie auf die IP-Adresse für Ihr neues Apigee Ingress-Gateway verweisen. Je nach DNS-Anbieter können Sie den Traffic möglicherweise schrittweise zum neuen Endpunkt verschieben. Tipp: Sie finden die externe IP-Adresse des Apigee Ingress-Gateways mit dem folgenden Befehl:
    kubectl get svc -n apigee -l app=apigee-ingressgateway

    Die Ausgabe sollte in etwa so aussehen:

    NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
    apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h
  4. Überwachen Sie die Dahsboards, um zu prüfen, ob der gesamte Laufzeittraffic funktioniert. Fahren Sie nur mit dem nächsten Schritt fort, wenn alles wie erwartet funktioniert. Achten Sie darauf, dass kein Traffic über Ihr altes Ingress-Gateway (Anthos Service Mesh) geleitet wird, da die DNS-Aktualisierung aufgrund von DNS-Caching möglicherweise nur langsam übernommen wird.
  5. Wenn Sie die Konfiguration von Apigee für Anthos Service Mesh beenden möchten, führen Sie die Schritte unter Konfiguration für ASM beenden im Leitfaden zum Verwalten von Apigee Ingress-Gateway aus.
  6. Testen sie erneut und überwachen Sie den API-Proxy-Traffic.
  7. Folgen Sie der Anleitung in der Anthos Service Mesh-Dokumentation, um Anthos Service Mesh aus dem Cluster zu deinstallieren.

Upgrade von Anthos Service Mesh auf Version 1.15 ausführen

Führen Sie die entsprechenden Schritte mit der Anthos Service Mesh-Dokumentation aus, die für Ihre Plattform geeignet ist:

Die Anleitung zum Installieren und Konfigurieren von Anthos Service Mesh unterscheidet sich je nach Plattform. Die Plattformen sind in folgende Kategorien unterteilt:

  • GKE: Google Kubernetes Engine-Cluster, die in Google Cloud ausgeführt werden.
  • Außerhalb von Google Cloud: Anthos-Cluster, die auf Folgendem ausgeführt werden:
    • Anthos Clusters on VMware (GKE On-Prem)
    • Anthos on Bare Metal
    • Anthos-Cluster in AWS
    • Amazon EKS
  • Andere Kubernetes-Plattformen: Konforme Cluster, die erstellt und ausgeführt werden auf:
    • AKS
    • EKS
    • OpenShift

GKE

Die Abfolge für das Upgrade auf die Anthos Service Mesh-Version 1.13.9 für Ihre Hybridinstallation sieht so aus:

  1. Bereiten Sie das Upgrade vor.
  2. Installieren Sie die neue Version von Anthos Service Mesh.
  3. Löschen Sie die Deployments, Dienste und Webhooks der vorherigen Anthos Service Mesh-Version aus Ihrer aktuellen Installation.
  4. Aktualisieren Sie Ihre Gateways und konfigurieren Sie die neuen Webhooks.

Upgrade von Anthos Service Mesh auf Version 1.13.9vorbereiten

  1. Prüfen Sie die Anforderungen unter Upgrade von Anthos Service Mesh durchführen, führen Sie das Upgrade jedoch noch nicht durch.
  2. Bestimmen Sie vor der Installation der neuen Version die aktuelle Überarbeitung. Sie benötigen diese Informationen, um die Bereitstellungen, Dienste und Webhooks der vorherigen Anthos Service Mesh-Version aus Ihrer aktuellen Installation zu löschen. Verwenden Sie den folgenden Befehl, um die aktuelle istiod-Überarbeitung in einer Umgebungsvariable zu speichern:
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
    echo $DELETE_REV

    Die Ausgabe sollte in etwa so aussehen: 1.12.9-asm.2.

  3. Erstellen Sie eine neue overlay.yaml-Datei oder prüfen Sie, ob Ihre vorhandene overlay.yaml-Datei den folgenden Inhalt hat:
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      components:
        ingressGateways:
        - name: istio-ingressgateway
          enabled: true
          k8s:
            nodeSelector:
              # default node selector, if different or not using node selectors, change accordingly.
              cloud.google.com/gke-nodepool: apigee-runtime
            resources:
              requests:
                cpu: 1000m
            service:
              type: LoadBalancer
              loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
              ports:
                - name: http-status-port
                  port: 15021
                - name: http2
                  port: 80
                  targetPort: 8080
                - name: https
                  port: 443
                  targetPort: 8443
      meshConfig:
        accessLogFormat:
          '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
    
  4. Folgen Sie der Anleitung in den folgenden Abschnitten der Dokumentation zu Anthos Service Mesh:
    1. asmcli herunterladen
    2. Clusteradministratorberechtigungen erteilen
    3. Projekt und Cluster validieren
    4. Upgrade mit optionalen Features ausführen Beenden Sie den Vorgang, bevor Sie mit dem Abschnitt „Upgrade für Gateways durchführen” beginnen.
  5. Wechseln Sie zur neuen Steuerungsebene:
    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
    2. Weisen Sie das neuere Überarbeitungslabel einer Umgebungsvariable zu.

      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

      export UPGRADE_REV="REVISION_LABEL"
    3. Fügen Sie das Überarbeitungslabel dem Namespace istio-system hinzu und entfernen Sie das Label istio-injection (falls vorhanden) mit dem folgenden Befehl.
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV 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 istio-injection als auch das Label revision enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Entfernen des Labels istio-injection.

    4. Starten Sie die Pods neu, um die erneute Injektion auszulösen.
      kubectl rollout restart deployment -n istio-system
    5. Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.
    6. 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. Löschen Sie die vorherigen Versionen:
    1. Wechseln Sie in das Verzeichnis, in dem Sie asmcli installiert haben.
    2. Speichern Sie das Ausgabeverzeichnis für Ihre Anthos Service Mesh-Installation in der Umgebungsvariablen DIR_PATH. Dies ist dasselbe Verzeichnis, das Sie im Verfahren Upgrade mit optionalen Funktionen angegeben haben.
      export DIR_PATH=OUTPUT_DIR
    3. Erstellen Sie ein Shell-Skript mit den folgenden Befehlen:
      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      
    4. Führen Sie das Skript aus, um die vorherigen Versionen zu löschen.

Außerhalb von Google Cloud

Diese Anleitung behandelt das Upgrade von Anthos Service Mesh auf:

  • Anthos Clusters on VMware (GKE On-Prem)
  • Anthos on Bare Metal
  • Anthos-Cluster in AWS
  • Amazon EKS

Die Abfolge für das Upgrade auf die Anthos Service Mesh-Version 1.13.9 für Ihre Hybridinstallation sieht so aus:

  1. Bereiten Sie das Upgrade vor.
  2. Installieren Sie die neue Version von Anthos Service Mesh.
  3. Löschen Sie die Deployments, Dienste und Webhooks der vorherigen Anthos Service Mesh-Version aus Ihrer aktuellen Installation.
  4. Aktualisieren Sie Ihre Gateways und konfigurieren Sie die neuen Webhooks.

Upgrade von Anthos Service Mesh auf Version 1.13.9vorbereiten

  1. Prüfen Sie die Anforderungen unter Upgrade von Anthos Service Mesh durchführen, führen Sie das Upgrade jedoch noch nicht durch.
  2. Bestimmen Sie vor der Installation der neuen Version die aktuelle Überarbeitung. Sie benötigen diese Informationen, um die Bereitstellungen, Dienste und Webhooks der vorherigen Anthos Service Mesh-Version aus Ihrer aktuellen Installation zu löschen. Verwenden Sie den folgenden Befehl, um die aktuelle istiod-Überarbeitung in einer Umgebungsvariable zu speichern:
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
    echo $DELETE_REV

    Die Ausgabe sollte in etwa so aussehen: 1.12.9-asm.2.

  3. Erstellen Sie eine neue overlay.yaml-Datei oder prüfen Sie, ob Ihre vorhandene overlay.yaml-Datei den folgenden Inhalt hat:
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:  
      components:
        ingressGateways:
        - name: istio-ingressgateway
          enabled: true
          k8s:
            nodeSelector:
              # default node selector, if different or not using node selectors, change accordingly.
              cloud.google.com/gke-nodepool: apigee-runtime
            resources:
              requests:
                cpu: 1000m
            service:
              type: LoadBalancer
              loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
              ports:
                - name: http-status-port
                  port: 15021
                - name: http2
                  port: 80
                  targetPort: 8080
                - name: https
                  port: 443
                  targetPort: 8443
      values:
        gateways:
          istio-ingressgateway:
            runAsRoot: true
    
      meshConfig:
        accessLogFormat:
          '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
    
  4. Folgen Sie der Anleitung in den folgenden Abschnitten der Dokumentation zu Anthos Service Mesh:
    1. asmcli herunterladen
    2. Clusteradministratorberechtigungen erteilen
    3. Projekt und Cluster validieren
    4. Upgrade mit optionalen Features ausführen Beenden Sie den Vorgang, bevor Sie mit dem Abschnitt „Upgrade für Gateways durchführen” beginnen.
  5. Wechseln Sie zur neuen Steuerungsebene:
    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
    2. Weisen Sie das neuere Überarbeitungslabel einer Umgebungsvariable zu.

      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

      export UPGRADE_REV="REVISION_LABEL"
    3. Fügen Sie das Überarbeitungslabel dem Namespace istio-system hinzu und entfernen Sie das Label istio-injection (falls vorhanden) mit dem folgenden Befehl.
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV 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 istio-injection als auch das Label revision enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Entfernen des Labels istio-injection.

    4. Starten Sie die Pods neu, um die erneute Injektion auszulösen.
      kubectl rollout restart deployment -n istio-system
    5. Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.
    6. 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. Löschen Sie die vorherigen Versionen:
    1. Wechseln Sie in das Verzeichnis, in dem Sie asmcli installiert haben.
    2. Speichern Sie das Ausgabeverzeichnis für Ihre Anthos Service Mesh-Installation in der Umgebungsvariablen DIR_PATH. Dies ist dasselbe Verzeichnis, das Sie im Verfahren Upgrade mit optionalen Funktionen angegeben haben.
      export DIR_PATH=OUTPUT_DIR
    3. Erstellen Sie ein Shell-Skript mit den folgenden Befehlen:
      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      
    4. Führen Sie das Skript aus, um die vorherigen Versionen zu löschen.

AKS / EKS

In dieser Anleitung ist das Verfahren zur Aktualisierung der Version istio-1.13.9-asm.10 von Anthos Service Mesh (ASM) auf mit Anthos verbundenen Clustern dasselbe wie bei einer Neuinstallation.

Installation von Anthos Service Mesh vorbereiten

  1. Bestimmen Sie vor der Installation der neuen Version die aktuelle Überarbeitung. Sie benötigen diese Informationen, um den validierenden Webhook und den mutierenden Webhook aus Ihrer aktuellen Anthos Service Mesh-Installation zu löschen. Verwenden Sie den folgenden Befehl, um die aktuelle istiod-Überarbeitung in einer Umgebungsvariable zu speichern:
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
    echo $DELETE_REV

    Die Ausgabe sollte in etwa so aussehen: 1.12.9-asm.2.

  2. Linux

  3. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz
  4. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit OpenSSL:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig
    openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
    
  5. 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.13.9-asm.10-linux-amd64.tar.gz

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.13.9-asm.10 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.
  6. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden:
    cd istio-1.13.9-asm.10
  7. Fügen Sie die Tools der Einfachheit halber im Verzeichnis /bin Ihrem PATH hinzu:
    export PATH=$PWD/bin:$PATH
  8. Mac OS

  9. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz
  10. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit OpenSSL:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig
    openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
    
  11. 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.13.9-asm.10-osx.tar.gz

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.13.9-asm.10 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.
  12. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden:
    cd istio-1.13.9-asm.10
  13. Fügen Sie die Tools der Einfachheit halber im Verzeichnis /bin Ihrem PATH hinzu:
    export PATH=$PWD/bin:$PATH
  14. Windows

  15. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip
  16. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit OpenSSL:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig
    openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
    
  17. 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.13.9-asm.10-win.zip

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.13.9-asm.10 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.
  18. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden:
    cd istio-1.13.9-asm.10
  19. Fügen Sie die Tools im Verzeichnis /bin Ihrem PATH hinzu:
    set PATH=%CD%\bin:%PATH%
  20. Nachdem Anthos Service Mesh Istio installiert ist, prüfen Sie die Version von istioctl:
    istioctl version
  21. Erstellen Sie einen Namespace namens "istio-system" für die Komponenten der Steuerungsebene:
    kubectl create namespace istio-system

Anthos Service Mesh installieren

  1. Bearbeiten Sie die overlay.yaml-Datei oder erstellen Sie eine neue mit folgendem Inhalt:
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      meshConfig:
        accessLogFile: /dev/stdout
        enableTracing: true
        accessLogFormat:
          '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
      components:
        ingressGateways:
        - name: istio-ingressgateway
          enabled: true
          k8s:
            service:
              type: LoadBalancer
              ports:
              - name: status-port
                port: 15021
                targetPort: 15021
              - name: http2
                port: 80
                targetPort: 8080
              - name: https
                port: 443
                targetPort: 8443
    
  2. Installieren Sie Anthos Service Mesh mit istioctl mithilfe des Profils asm-multicloud:
    istioctl install \
        --set profile=asm-multicloud \
        --set revision="asm-1139-10" \
        --filename overlay.yaml

    Die Ausgabe sollte in etwa so aussehen:

    kubectl get pods -n istio-system
    NAME                                   READY   STATUS    RESTARTS   AGE
    istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
    istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
    istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
    istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s
    

    Mit dem Argument --set revision wird istiod ein Überarbeitungslabel im Format istio.io/rev=asm-1139-10 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 sie mit einer Überarbeitung kennzeichnen, die mit dem Label auf istiod übereinstimmt.

  3. Prüfen Sie, ob Ihre Installation abgeschlossen ist:
    kubectl get svc -n istio-system

    Die Ausgabe sollte in etwa so aussehen:

    NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
    istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
    istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
    istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s
    
  4. Wechseln Sie zur neuen Steuerungsebene:
    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
    2. Weisen Sie das neuere Überarbeitungslabel einer Umgebungsvariable zu.

      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

      export UPGRADE_REV="REVISION_LABEL"
    3. Fügen Sie das Überarbeitungslabel dem Namespace istio-system hinzu und entfernen Sie das Label istio-injection (falls vorhanden) mit dem folgenden Befehl.
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV 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 istio-injection als auch das Label revision enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Entfernen des Labels istio-injection.

    4. Starten Sie die Pods neu, um die erneute Injektion auszulösen.
      kubectl rollout restart deployment -n istio-system
    5. Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.
    6. Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die Schritte, um den Namespace mit einem Label zu versehen und Pods neu zu starten.
  5. Löschen Sie die vorherigen Versionen:
    1. Wechseln Sie in das Verzeichnis, in dem Sie asmcli installiert haben.
    2. Erstellen Sie ein Shell-Skript mit den folgenden Befehlen:
      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      
    3. Führen Sie das Skript aus, um die vorherigen Versionen zu löschen.

OpenShift

In dieser Anleitung ist das Verfahren zur Aktualisierung der Version istio-1.13.9-asm.10 von Anthos Service Mesh (ASM) auf mit Anthos verbundenen Clustern dasselbe wie bei einer Neuinstallation.

Installation von Anthos Service Mesh vorbereiten

  1. Bestimmen Sie vor der Installation der neuen Version die aktuelle Überarbeitung. Sie benötigen diese Informationen, um den validierenden Webhook und den mutierenden Webhook aus Ihrer aktuellen Anthos Service Mesh-Installation zu löschen. Verwenden Sie den folgenden Befehl, um die aktuelle istiod-Überarbeitung in einer Umgebungsvariable zu speichern:
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
    echo $DELETE_REV

    Die Ausgabe sollte in etwa so aussehen: 1.12.9-asm.2.

  2. Linux

  3. Weisen Sie istio-system die Sicherheitskontextbeschränkung anyuid (SCC) mit dem folgenden OpenShift-Befehlszeilenbefehl (oc) zu:
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  4. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz
  5. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit OpenSSL:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig
    openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
    
  6. 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.13.9-asm.10-linux-amd64.tar.gz

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.13.9-asm.10 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.
  7. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden:
    cd istio-1.13.9-asm.10
  8. Fügen Sie die Tools der Einfachheit halber im Verzeichnis /bin Ihrem PATH hinzu:
    export PATH=$PWD/bin:$PATH
  9. Mac OS

  10. Weisen Sie istio-system die Sicherheitskontextbeschränkung anyuid (SCC) mit dem folgenden OpenShift-Befehlszeilenbefehl (oc) zu:
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  11. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz
  12. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit OpenSSL:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig
    openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
    
  13. 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.13.9-asm.10-osx.tar.gz

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.13.9-asm.10 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.
  14. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden:
    cd istio-1.13.9-asm.10
  15. Fügen Sie die Tools der Einfachheit halber im Verzeichnis /bin Ihrem PATH hinzu:
    export PATH=$PWD/bin:$PATH
  16. Windows

  17. Weisen Sie istio-system die Sicherheitskontextbeschränkung anyuid (SCC) mit dem folgenden OpenShift-Befehlszeilenbefehl (oc) zu:
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  18. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip
  19. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit OpenSSL:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig
    openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF
    
  20. 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.13.9-asm.10-win.zip

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.13.9-asm.10 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.
  21. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden:
    cd istio-1.13.9-asm.10
  22. Fügen Sie die Tools im Verzeichnis /bin Ihrem PATH hinzu:
    set PATH=%CD%\bin:%PATH%
  23. Nachdem Anthos Service Mesh Istio installiert ist, prüfen Sie die Version von istioctl:
    istioctl version
  24. Erstellen Sie einen Namespace namens "istio-system" für die Komponenten der Steuerungsebene:
    kubectl create namespace istio-system

Webhook für die Validierung konfigurieren

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

  1. Erstellen Sie eine Datei mit dem Namen istiod-service.yaml und mit folgendem Inhalt:
    apiVersion: v1
    kind: Service
    metadata:
      name: istiod
      namespace: istio-system
      labels:
        istio.io/rev: asm-1139-10
        app: istiod
        istio: pilot
        release: istio
    spec:
      ports:
        - port: 15010
          name: grpc-xds # plaintext
          protocol: TCP
        - port: 15012
          name: https-dns # mTLS with k8s-signed cert
          protocol: TCP
        - port: 443
          name: https-webhook # validation and injection
          targetPort: 15017
          protocol: TCP
        - port: 15014
          name: http-monitoring # prometheus stats
          protocol: TCP
      selector:
        app: istiod
        istio.io/rev: asm-1139-10
      meshConfig:
        accessLogFormat:
          '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
    
  2. Verwenden Sie kubectl, um die validierende Webhook-Konfiguration anzuwenden:
    kubectl apply -f istiod-service.yaml
  3. Prüfen Sie, ob die Konfiguration angewendet wurde:
    kubectl get svc -n istio-system

    Die Antwort sollte in etwa so aussehen:

    NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
    istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s
    

Anthos Service Mesh installieren

  1. Bearbeiten Sie die overlay.yaml-Datei oder erstellen Sie eine neue mit folgendem Inhalt:
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    spec:
      meshConfig:
        accessLogFile: /dev/stdout
        enableTracing: true
        accessLogFormat:
          '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
      components:
        ingressGateways:
          - name: istio-ingressgateway
            enabled: true
            k8s:
              service:
                type: LoadBalancer
                ports:
                - name: status-port
                  port: 15021
                  targetPort: 15021
                - name: http2
                  port: 80
                  targetPort: 8080
                - name: https
                  port: 443
                  targetPort: 8443
    
  2. Installieren Sie Anthos Service Mesh mit istioctl mithilfe des Profils asm-multicloud:
    istioctl install \
        --set profile=asm-multicloud \
        --set revision="asm-1139-10" \
        --filename overlayfile.yaml

    Die Ausgabe sollte in etwa so aussehen:

    kubectl get pods -n istio-system
    NAME                                   READY   STATUS    RESTARTS   AGE
    istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
    istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
    istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
    istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s
    

    Mit dem Argument --set revision wird istiod ein Überarbeitungslabel im Format istio.io/rev=1.6.11-asm.1 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 sie mit einer Überarbeitung kennzeichnen, die mit dem Label auf istiod übereinstimmt.

  3. Prüfen Sie, ob Ihre Installation abgeschlossen ist:
    kubectl get svc -n istio-system

    Die Ausgabe sollte in etwa so aussehen:

    NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
    istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
    istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
    istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s
    
  4. Wechseln Sie zur neuen Steuerungsebene:
    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
    2. Weisen Sie das neuere Überarbeitungslabel einer Umgebungsvariable zu.

      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

      export UPGRADE_REV="REVISION_LABEL"
    3. Fügen Sie das Überarbeitungslabel dem Namespace istio-system hinzu und entfernen Sie das Label istio-injection (falls vorhanden) mit dem folgenden Befehl.
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV 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 istio-injection als auch das Label revision enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Entfernen des Labels istio-injection.

    4. Starten Sie die Pods neu, um die erneute Injektion auszulösen.
      kubectl rollout restart deployment -n istio-system
    5. Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.
    6. Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die Schritte, um den Namespace mit einem Label zu versehen und Pods neu zu starten.
  5. Löschen Sie die vorherigen Versionen:
    1. Wechseln Sie in das Verzeichnis, in dem Sie asmcli installiert haben.
    2. Erstellen Sie ein Shell-Skript mit den folgenden Befehlen:
      #!/bin/bash
      
      set -ex
      
      if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
        kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
        kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
      fi
      
    3. Führen Sie das Skript aus, um die vorherigen Versionen zu löschen.

Rollback für Upgrade durchführen

So führen Sie ein Rollback für ein Upgrade durch:

  1. Bereinigen Sie abgeschlossene Jobs für den Namespace der Hybridlaufzeit. Dabei ist NAMESPACE der Namespace, der in der Überschreibungsdatei angegeben ist, wenn Sie einen Namespace angegeben haben. Wenn nicht, ist der Standard-Namespace apigee:
    kubectl delete job -n NAMESPACE \
      $(kubectl get job -n NAMESPACE \
      -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  2. Bereinigen Sie abgeschlossene Jobs für den Namespace apigee-system:
    kubectl delete job -n apigee-system \
      $(kubectl get job -n apigee-system \
      -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  3. Ändern Sie die Variable APIGEECTL_HOME so, dass sie auf das Verzeichnis verweist, das die ursprüngliche Version von apigeectl enthält. Beispiel:
    export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
  4. Machen Sie die Änderungen an der Datei overrides rückgängig:
    1. Entfernen oder kommentieren Sie ingressGateways und alle zugehörigen Attribute.
    2. Setzen Sie den Wert von virtualhosts.selector.app auf den vorherigen Wert. Beispiel:
      virtualhosts:
        - name: my-env-group
          selector:
            app: istio-ingressgateway
    3. Entfernen oder kommentieren Sie ao.args.disableIstioConfigInAPIServer aus.
  5. Führen Sie im Stammverzeichnis der Installation, zu der Sie ein Rollback machen möchten, apigeectl apply aus, prüfen Sie den Status Ihrer Pods und führen Sie dann apigeectl init aus. Achten Sie darauf, die Original-Überschreibungsdatei für die Version zu verwenden, für die Sie ein Rollback durchführen möchten:
    1. Führen Sie im Verzeichnis mit Hybriddateien apigeectl apply aus:
      $APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE

      Dabei ist ORIGINAL_OVERRIDES_FILE der relative Pfad und der Dateiname der Überschreibungsdatei für Ihre vorherige Version der Hybridinstallation, z. B. ./overrides/overrides1.7.yaml.

    2. Prüfen Sie den Status der Pods:
      kubectl -n NAMESPACE get pods

      Dabei ist NAMESPACE Ihr Apigee Hybrid-Namespace.

    3. Prüfen Sie den Status von apigeeds:
      kubectl describe apigeeds -n apigee

      Die Ausgabe sollte in etwa so aussehen:

      Status:
        Cassandra Data Replication:
        Cassandra Pod Ips:
          10.8.2.204
        Cassandra Ready Replicas:  1
        Components:
          Cassandra:
            Last Successfully Released Version:
              Revision:  v1-f8aa9a82b9f69613
              Version:   v1
            Replicas:
              Available:  1
              Ready:      1
              Total:      1
              Updated:    1
            State:        running
        Scaling:
          In Progress:         false
          Operation:
          Requested Replicas:  0
        State:                 running
      

      Fahren Sie nur mit dem nächsten Schritt fort, wenn der apigeeds-Pod ausgeführt wird.

    4. Führen Sie den folgenden Befehl aus, um zu notieren, was die neuen Replikatwerte nach dem Upgrade für den Nachrichtenprozessor sein werden. Wenn diese Werte nicht mit dem zuvor festgelegten Wert übereinstimmen, ändern Sie die Werte in der Überschreibungsdatei entsprechend Ihrer vorherigen Konfiguration.
      apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2

      Die Ausgabe sollte in etwa so aussehen:

            autoScaler:
              minReplicas: 2
              maxReplicas: 10
    5. Wenn Sie ein Rollback auf die Hybrid-Version 1.8.4 oder früher ausführen, löschen Sie die Controller-Bereitstellung, die von Hybrid-Version 1.8.5 und höher verwendet wird:
      kubectl -n apigee-system delete deploy apigee-controller-manager
    6. Führen Sie apigeectl init aus.
      $APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
      
  6. Löschen Sie die Bereitstellung des Apigee Ingress Gateway-Managers. Diese Komponente ist nur für Apigee Hybrid-Versionen 1.8 und höher relevant.
    kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager

    Dabei ist NAMESPACE Ihr Apigee Hybrid-Namespace.