Upgrade von Apigee Hybrid auf Version 1.12 ausführen

Dieses Verfahren behandelt das Upgrade von der Apigee Hybrid-Version 1.11.x auf die Apigee Hybrid-Version 1.12.0.

Änderungen von Apigee Hybrid v1.11

In der Apigee Hybrid-Version 1.12 werden die folgenden Änderungen eingeführt, die sich auf den Upgradeprozess auswirken. Eine vollständige Liste der Funktionen in Version 1.12 finden Sie in den Versionshinweisen zu Hybrid v1.12.0.

  • Cassandra 4.x: Ab Version 1.12 verwendet Apigee Hybrid Cassandra-Version 4 und höher.
  • Einstellung von apigeectl: Ab Version 1.12 unterstützt Apigee Hybrid nur Helm für die Installation und Verwaltung Ihrer Hybrid-Installation.
  • Eine neue Suite von Messwerten für das Monitoring von Apigee-Proxys und Zielendpunkten ist verfügbar. Bei der Hybrid-Version 1.12 werden die überwachten ProxyV2- und TargetV2-Ressourcen nicht mehr standardmäßig verwendet. Alle Proxy- und Zielmesswerte werden in den überwachten Ressourcen Proxy und Target veröffentlicht.

    Wenn Sie weiterhin Messwerte an die überwachten Ressourcen ProxyV2 und TargetV2 ausgeben möchten, setzen Sie metrics.disablePrometheusPipeline in overrides.yaml auf true.

    Wenn Sie messwertbasierte Benachrichtigungen konfiguriert haben, prüfen Sie die Verwendung der richtigen Messwerte für Ihre Hybrid-Installation. Weitere Informationen finden Sie unter Messwertbasierte Benachrichtigungen.

Überlegungen vor dem Start eines Upgrades auf Version 1.12

Das Upgrade von der Apigee Hybrid-Version 1.11 auf Version 1.12 enthält ein Upgrade der Cassandra-Datenbank von Version 3.11.x auf Version 4.x. Während das Cassandra-Upgrade im Rahmen des Apigee Hybrid-Upgrades durchgeführt wird, sollten Sie Folgendes berücksichtigen:

  • Das Upgrade der Cassandra-Version erfolgt im Hintergrund und erfolgt jeweils auf einem Pod (oder Cassandra-Knoten). Planen Sie daher während des Upgrades eine reduzierte Datenbankkapazität ein.
  • Skalieren Sie Ihre Cassandra-Kapazität und achten Sie darauf, dass die Laufwerksauslastung fast bei oder unter 50% liegt, bevor Sie mit dem Upgrade beginnen.
  • Validieren und testen Sie Ihre Cassandra-Sicherungs- und Wiederherstellungsverfahren.
  • Sichern Sie die Cassandra-Daten in Ihrer Hybrid-Version 1.11-Installation, bevor Sie mit dem Upgrade beginnen und Ihre Sicherungen validieren.
  • Das Upgrade von apigee-datastore führt zu einer vorübergehenden Erhöhung des CPU-Verbrauchs aufgrund von Aufgaben nach dem Upgrade, die von Cassandra ausgeführt werden.
  • Nachdem Sie die Komponente apigee-datastore (Cassandra) aktualisiert haben, können Sie diese Komponente nicht mehr auf die vorherige Version zurücksetzen. Es gibt zwei Szenarien für das Rollback eines Upgrades auf die Hybrid-Version 1.12 nach dem Upgrade der apigee-datastore-Komponente:
    • Wenn die Komponente apigee-datastore in einem fehlerfreien Zustand ist, andere Komponenten jedoch ein Rollback erfordern, können Sie diese anderen Komponenten einzeln zurücksetzen.
    • Wenn sich die Komponente apigee-datastore in einem fehlerhaften Zustand befindet, müssen Sie aus einer v1.11-Sicherung eine v1.11-Installation wiederherstellen.

Überlegungen vor dem Upgrade einer Installation für eine Einzelregion

Wenn Sie ein Rollback zu einer vorherigen Version von Apigee Hybrid durchführen müssen, erfordert der Vorgang möglicherweise Ausfallzeiten. Wenn Sie eine Installation für eine Einzelregion aktualisieren, möchten Sie möglicherweise eine zweite Region erstellen und dann jeweils nur eine Region in der folgenden Reihenfolge aktualisieren:

  1. Fügen Sie Ihrer vorhandenen Installation eine zweite Region mit derselben Hybrid-Version hinzu. Weitere Informationen finden Sie unter Multiregionale Bereitstellung in der Dokumentation zu Version 1.11.
  2. Sichern und validieren Sie Daten aus der ersten Region, bevor Sie ein Upgrade starten. Weitere Informationen finden Sie unter Cassandra-Sicherungsübersicht in der Dokumentation zu Version 1.11.
  3. Aktualisieren Sie die neu hinzugefügte Region auf Hybrid 1.12.
  4. Leiten Sie den Traffic in die neue Region um und validieren Sie den Traffic.
  5. Führen Sie nach der Validierung ein Upgrade der älteren Region mit Hybrid 1.12 durch.
  6. Sie wechseln mit dem gesamten Traffic zurück zur älteren Region und validieren den Traffic.
  7. Außerbetriebnahme der neuen Region.

Überlegungen vor dem Upgrade einer multiregionalen Installation

Apigee empfiehlt die folgende Abfolge für das Upgrade einer multiregionalen Installation:

  1. Sichern und validieren Sie Daten aus jeder Region, bevor Sie mit dem Upgrade beginnen.
  2. Führen Sie ein Upgrade der Hybrid-Version in einer Region durch und prüfen Sie, ob alle Pods ausgeführt werden, um das Upgrade zu validieren.
  3. Überprüfen Sie den Traffic in der neu aktualisierten Region.
  4. Führen Sie erst nach der Validierung des Traffics in der vorherigen Region ein Upgrade für jede nachfolgende Region durch.
  5. Wenn ein Upgrade in einer multiregionalen Bereitstellung möglicherweise rückgängig gemacht werden muss, bereiten Sie sich darauf vor, den Traffic von fehlgeschlagenen Regionen wegzuleiten und in der Region, in der der Traffic umgeleitet wird, genügend Kapazität hinzuzufügen, um Traffic für beide Regionen zu verarbeiten.

Vorbereitung

Prüfen Sie vor dem Upgrade auf die Hybrid-Version 1.12, ob Ihre Installation die folgenden Anforderungen erfüllt:

  • Eine Installation von Apigee Hybrid Version 1.11, die mit Helm verwaltet wird.
  • Helm-Version Version 3.10 und höher
  • kubectl-Version 1.27, 1.28 oder 1.29 (empfohlen).
  • cert-manager Version 1.13.0 Bei Bedarf führen Sie im Abschnitt Upgrade auf Version vorbereiten unten ein Upgrade von cert-manager durch.

Beschränkungen

Beachten Sie die folgenden Einschränkungen, wenn Sie das Upgrade von Apigee Hybrid-Version 1.11 auf Version 1.12 planen. Mithilfe von Planungen können Sie Ausfallzeiten reduzieren, wenn Sie nach dem Upgrade ein Rollback oder eine Wiederherstellung durchführen müssen.

  • Sicherungen von Hybrid 1.12 können aufgrund der Inkompatibilität zwischen den beiden Versionen nicht in Hybrid 1.11 wiederhergestellt werden und umgekehrt.
  • Sie können Datenspeicher-Pods während des Upgrades auf Version 1.12 nicht skalieren. Erfüllen Sie Ihre Skalierungsanforderungen in allen Regionen, bevor Sie mit dem Upgrade Ihrer Hybrid-Installation beginnen.
  • In einer Hybrid-Installation mit einer Region können Sie die Datenspeicherkomponente nicht zurücksetzen, sobald der Datenspeicher-Upgrade abgeschlossen ist. Sie können einen Cassandra 4.x-Datenspeicher nicht zu einem Cassandra 3.x-Datenspeicher zurücksetzen. Dies erfordert eine Wiederherstellung von Ihrer letzten Sicherung der Cassandra 3.x-Daten (aus Ihrer Hybrid-Version 1.11-Installation).
  • Das Löschen oder Hinzufügen einer Region wird während des Upgrades nicht unterstützt. Bei einem Upgrade für mehrere Regionen müssen Sie das Upgrade aller Regionen abschließen, bevor Sie Regionen hinzufügen oder löschen können.

Upgrade auf Version 1.12.0 – Übersicht

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

  1. Bereiten Sie das Upgrade vor..
    • Cassandra-Sicherung.
    • Sichern Sie die Hybrid-Installationsverzeichnisse.
  2. Installieren Sie die Hybrid-Laufzeitversion 1.12.0

Upgrade auf Version 1.12 vorbereiten

Cassandra sichern

  • Sichern Sie Ihre Cassandra-Datenbank in allen anwendbaren Regionen und validieren Sie die Daten in der Hybrid-Version 1.11-Installation, bevor Sie mit dem Upgrade beginnen. Siehe Sicherungen überwachen in der Dokumentation zu Version 1.11.
  • Starten Sie alle Cassandra-Pods im Cluster neu, bevor Sie mit dem Upgrade beginnen, damit eventuell noch vorhandene Probleme zum Vorschein kommen können.

    Sie können die Cassandra-Pods neu starten und testen, indem Sie jeden Pod einzeln löschen und dann prüfen, ob er wieder ausgeführt wird und die Bereitschaftsprüfung erfolgreich war:

    1. Listen Sie die Cassandra-Pods auf:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Beispiele:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      
      . . .
    2. Einen Pod löschen:
      kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

      Beispiele:

      kubectl delete pod -n apigee apigee-cassandra-default-0
    3. Prüfen Sie den Status, indem Sie die Cassandra-Pods noch einmal auflisten:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Beispiele:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          16s
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      
      . . .
  • Wenden Sie die letzte bekannte Überschreibungsdatei noch einmal an, um sicherzustellen, dass keine Änderungen vorgenommen wurden. So können Sie dieselbe Konfiguration für das Upgrade auf die Hybrid-Version 1.12 verwenden.
  • Achten Sie darauf, dass alle Cassandra-Knoten in allen Regionen den Status UN (Up / Normal) haben. Wenn sich ein Cassandra-Knoten in einem anderen Status befindet, adressieren Sie diesen zuerst, bevor Sie das Upgrade starten.

    Mit den folgenden Befehlen können Sie den Status Ihrer Cassandra-Knoten validieren:

    1. Listen Sie die Cassandra-Pods auf:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Beispiele:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      apigee-cassandra-default-3   1/1     Running   0          16m
      apigee-cassandra-default-4   1/1     Running   0          14m
      apigee-cassandra-default-5   1/1     Running   0          13m
      apigee-cassandra-default-6   1/1     Running   0          9m
      apigee-cassandra-default-7   1/1     Running   0          9m
      apigee-cassandra-default-8   1/1     Running   0          8m
    2. Prüfen Sie den Status der Knoten für jeden Cassandra-Pod mit dem Befehl kubectl nodetool status:
      kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME nodetool status

      Beispiele:

      kubectl -n apigee exec -it apigee-cassandra-default-0 nodetool status
      Datacenter: us-east1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
      UN  10.16.2.6    690.17 KiB  256          48.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
      UN  10.16.4.6    705.55 KiB  256          51.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1
      UN  10.16.11.11  674.36 KiB  256          48.3%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
      UN  10.16.1.11   697.03 KiB  256          49.8%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
      UN  10.16.5.13   703.64 KiB  256          50.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
      UN  10.16.8.15   700.42 KiB  256          50.6%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1
      UN  10.16.11.3   697.03 KiB  256          49.8%             dad221ff-dad1-de33-2cd3-f1.672367e6f  ra-1
      UN  10.16.14.16  704.04 KiB  256          50.9%             1feed042-a4b6-24ab-49a1-24d4cef95473  ra-1
      UN  10.16.16.1   699.82 KiB  256          50.6%             beef93af-fee0-8e9d-8bbf-efc22d653596  ra-1

Hybrid-Installationsverzeichnisse sichern

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

    Linux

    export APIGEE_HELM_CHARTS_HOME=$PWD
    echo $APIGEE_HELM_CHARTS_HOME

    macOS

    export APIGEE_HELM_CHARTS_HOME=$PWD
    echo $APIGEE_HELM_CHARTS_HOME

    Windows

    set APIGEE_HELM_CHARTS_HOME=%CD%
    echo %APIGEE_HELM_CHARTS_HOME%
  2. Erstellen Sie eine Sicherungskopie Ihres $APIGEE_HELM_CHARTS_HOME/-Verzeichnisses der Version 1.11. Sie können einen beliebigen Sicherungsprozess verwenden. So können Sie beispielsweise eine tar-Datei Ihres gesamten Verzeichnisses erstellen:
    tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.11-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
  3. Sichern Sie Ihre Cassandra-Datenbank entsprechend der Anleitung unter Cassandra-Sicherung und -Wiederherstellung.
  4. Wenn Sie Dienstzertifikatdateien (.json) in Ihren Überschreibungen zur Authentifizierung von Dienstkonten verwenden, müssen Sie darauf achten, dass sich die Zertifikatsdateien Ihres Dienstkontos im richtigen Helm-Diagrammverzeichnis befinden. Helm-Diagramme können keine Dateien außerhalb der einzelnen Diagrammverzeichnisse lesen.

    Dieser Schritt ist nicht erforderlich, wenn Sie Kubernetes-Secrets oder Workload Identity zum Authentifizieren von Dienstkonten verwenden.

    Die folgende Tabelle zeigt das Ziel für jede Dienstkontodatei je nach Installationstyp:

    Prod

    Dienstkonto Standarddateiname Helm-Diagrammverzeichnis
    apigee-cassandra PROJECT_ID-apigee-cassandra.json $APIGEE_HELM_CHARTS_HOME/apigee-datastore/
    apigee-logger PROJECT_ID-apigee-logger.json $APIGEE_HELM_CHARTS_HOME/apigee-telemetry/
    apigee-mart PROJECT_ID-apigee-mart.json $APIGEE_HELM_CHARTS_HOME/apigee-org/
    apigee-metrics PROJECT_ID-apigee-metrics.json $APIGEE_HELM_CHARTS_HOME/apigee-telemetry/
    apigee-runtime PROJECT_ID-apigee-runtime.json $APIGEE_HELM_CHARTS_HOME/apigee-env
    apigee-synchronizer PROJECT_ID-apigee-synchronizer.json $APIGEE_HELM_CHARTS_HOME/apigee-env/
    apigee-udca PROJECT_ID-apigee-udca.json $APIGEE_HELM_CHARTS_HOME/apigee-org/
    apigee-watcher PROJECT_ID-apigee-watcher.json $APIGEE_HELM_CHARTS_HOME/apigee-org/

    Non-prod

    Erstellen Sie in jedem der folgenden Verzeichnisse eine Kopie der Dienstkontodatei apigee-non-prod:

    Dienstkonto Standarddateiname Helm-Diagrammverzeichnisse
    apigee-non-prod PROJECT_ID-apigee-non-prod.json $APIGEE_HELM_CHARTS_HOME/apigee-datastore/
    $APIGEE_HELM_CHARTS_HOME/apigee-telemetry/
    $APIGEE_HELM_CHARTS_HOME/apigee-org/
    $APIGEE_HELM_CHARTS_HOME/apigee-env/
  5. Achten Sie darauf, dass sich Ihr TLS-Zertifikat und die Schlüsseldateien (.crt, .key und/oder .pem) im Verzeichnis $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/ befinden.

Aktualisieren Sie Ihre Kubernetes-Version

Prüfen Sie die Version Ihrer Kubernetes-Plattform und führen Sie bei Bedarf ein Upgrade Ihrer Kubernetes-Plattform auf eine Version durch, die sowohl von Hybrid 1.10 als auch von Hybrid 1.12 unterstützt wird. Weitere Informationen finden Sie in der Dokumentation der Plattform.

Hybrid 1.12.0-Laufzeit installieren

Upgrade auf Helm-Diagramme vorbereiten

  1. Rufen Sie die Apigee Helm-Diagramme ab.

    Apigee Hybrid-Diagramme werden in Google Artifact Registry gehostet:

    oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts

    Kopieren Sie mit dem Befehl pull alle Apigee Hybrid-Helm-Diagramme in Ihren lokalen Speicher:

    export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
    export CHART_VERSION=1.12.0
    helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
    helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar
    
  2. Aktualisieren Sie bei Bedarf Cert-Manager.

    Wenn Sie die Cert-Manager-Version aktualisieren müssen, installieren Sie die neue Version mit dem folgenden Befehl:

    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
    
  3. Installieren Sie die aktualisierten Apigee-CRDs:
    1. Verwenden Sie das Probelauf-Feature kubectl, indem Sie den folgenden Befehl ausführen:

      kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run=server
      
    2. Führen Sie nach der Validierung mit dem Probelaufbefehl den folgenden Befehl aus:

      kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
      
    3. Prüfen Sie die Installation mit dem kubectl get crds-Befehl:
      kubectl get crds | grep apigee

      Ihre Ausgabe sollte in etwa so aussehen:

      apigeedatastores.apigee.cloud.google.com                    2023-10-09T14:48:30Z
      apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
      apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
      apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
      apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
      apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
      apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
      apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
      apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
      cassandradatareplications.apigee.cloud.google.com           2023-10-09T14:48:35Z
      
  4. Prüfen Sie die Labels auf den Clusterknoten. Standardmäßig plant Apigee Daten-Pods auf Knoten mit dem Label cloud.google.com/gke-nodepool=apigee-data und Laufzeit-Pods auf Knoten mit dem Label cloud.google.com/gke-nodepool=apigee-runtime. Sie können die Knotenpoollabels in der Datei overrides.yaml anpassen.

    Weitere Informationen finden Sie unter Dedizierte Knotenpools konfigurieren.

Apigee Hybrid-Helm-Diagramme installieren

  1. Wenn Sie dies nicht getan haben, rufen Sie das APIGEE_HELM_CHARTS_HOME-Verzeichnis auf. Führen Sie die folgenden Befehle in diesem Verzeichnis aus.
  2. Aktualisieren Sie den Apigee-Operator/-Controller:

    Probelauf:

    helm upgrade operator apigee-operator/ \
      --install \
      --create-namespace \
      --namespace apigee-system \
      -f OVERRIDES_FILE \
      --dry-run
    

    Aktualisieren Sie das Diagramm:

    helm upgrade operator apigee-operator/ \
      --install \
      --create-namespace \
      --namespace apigee-system \
      -f OVERRIDES_FILE
    

    Prüfen Sie die Installation des Apigee-Operators:

    helm ls -n apigee-system
    
    NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
    operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.0   1.12.0
    

    Prüfen Sie, ob er aktiv ist, indem Sie die Verfügbarkeit prüfen:

    kubectl -n apigee-system get deploy apigee-controller-manager
    
    NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
    apigee-controller-manager   1/1     1            1           7d20h
    
  3. Aktualisieren Sie den Apigee-Datenspeicher:

    Probelauf:

    helm upgrade datastore apigee-datastore/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
    

    Aktualisieren Sie das Diagramm:

    helm upgrade datastore apigee-datastore/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE
    

    Prüfen Sie dessen Status, um sicherzustellen, dassapigeedatastore aktiv ist.

    kubectl -n apigee get apigeedatastore default
    
    NAME      STATE       AGE
    default   running    2d
    
  4. Aktualisieren Sie die Apigee-Telemetrie:

    Probelauf:

    helm upgrade telemetry apigee-telemetry/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
    

    Aktualisieren Sie das Diagramm:

    helm upgrade telemetry apigee-telemetry/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE
    

    Prüfen Sie den Status, um sicherzustellen, dass dieses Element aktiv ist:

    kubectl -n apigee get apigeetelemetry apigee-telemetry
    
    NAME               STATE     AGE
    apigee-telemetry   running   2d
    
  5. Führen Sie ein Upgrade von Apigee Redis durch:

    Probelauf:

    helm upgrade redis apigee-redis/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
    

    Aktualisieren Sie das Diagramm:

    helm upgrade redis apigee-redis/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE
    

    Prüfen Sie den Status, um sicherzustellen, dass dieses Element aktiv ist:

    kubectl -n apigee get apigeeredis default
    
    NAME      STATE     AGE
    default   running   2d
    
  6. Aktualisieren Sie den Apigee-Ingress-Manager:

    Probelauf:

    helm upgrade ingress-manager apigee-ingress-manager/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
    

    Aktualisieren Sie das Diagramm:

    helm upgrade ingress-manager apigee-ingress-manager/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE
    

    Prüfen Sie, ob er aktiv ist, indem Sie die Verfügbarkeit prüfen:

    kubectl -n apigee get deployment apigee-ingressgateway-manager
    
    NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
    apigee-ingressgateway-manager   2/2     2            2           2d
    
  7. Führen Sie ein Upgrade der Apigee-Organisation durch:

    Probelauf:

    helm upgrade ORG_NAME apigee-org/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE \
      --dry-run
    

    Aktualisieren Sie das Diagramm:

    helm upgrade ORG_NAME apigee-org/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      -f OVERRIDES_FILE
    

    Prüfen Sie den Status der entsprechenden Organisation, um sicherzustellen, dass sie aktiv ist:

    kubectl -n apigee get apigeeorg
    
    NAME                      STATE     AGE
    apigee-org1-xxxxx          running   2d
    
  8. Führen Sie einen Upgrade für die Umgebung aus.

    Sie dürfen jeweils nur eine Umgebung installieren. Geben Sie die Umgebung mit --set env=ENV_NAME an:

    Probelauf:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      --set env=ENV_NAME \
      -f OVERRIDES_FILE \
      --dry-run
    
    • ENV_RELEASE_NAME ist der Name, mit dem Sie zuvor das Diagramm apigee-env installiert haben. In der Hybrid-Version 1.10 ist es normalerweise apigee-env-ENV_NAME. In der Hybrid-Version 1.11 und höher ist dies in der Regel ENV_NAME.
    • ENV_NAME ist der Name der Umgebung, die Sie aktualisieren.
    • OVERRIDES_FILE ist die neue Überschreibungsdatei für Version 1.12.0.

    Aktualisieren Sie das Diagramm:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      --set env=ENV_NAME \
      -f OVERRIDES_FILE
    

    Prüfen Sie, ob sie aktiv ist, indem Sie den Status der entsprechenden Umgebung prüfen:

    kubectl -n apigee get apigeeenv
    
    NAME                          STATE       AGE   GATEWAYTYPE
    apigee-org1-dev-xxx            running     2d
    
  9. Führen Sie ein Upgrade der Umgebungsgruppen (virtualhosts) durch.
    1. Sie dürfen jeweils nur eine Umgebungsgruppe (virtualhost) upgraden. Geben Sie die Umgebungsgruppe mit --set envgroup=ENV_GROUP_NAME an: Wiederholen Sie folgende Befehle für alle Umgebungsgruppen, die in der Datei overrides.yaml erwähnt werden:

      Probelauf:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        -f OVERRIDES_FILE \
        --dry-run
      

      ENV_GROUP_RELEASE_NAME ist der Name, mit dem Sie zuvor das Diagramm apigee-virtualhost installiert haben. In der Hybrid-Version 1.10 ist es normalerweise apigee-virtualhost-ENV_GROUP_NAME. In der Hybrid-Version 1.11 und höher ist dies in der Regel ENV_GROUP_NAME.

      Aktualisieren Sie das Diagramm:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        -f OVERRIDES_FILE
      
    2. Prüfen Sie den Status der ApigeeRoute (AR).

      Durch die Installation von virtualhosts wird ApigeeRouteConfig (ARC) erstellt. Dieses Element erstellt intern ApigeeRoute (ARC), nachdem der Apigee-Watcher die Umgebungsgruppendetails aus der Steuerungsebene abgerufen hat. Prüfen Sie daher, ob die entsprechende AR ausgeführt wird:

      kubectl -n apigee get arc
      
      NAME                                STATE   AGE
      apigee-org1-dev-egroup                       2d
      
      kubectl -n apigee get ar
      
      NAME                                        STATE     AGE
      apigee-org1-dev-egroup-xxxxxx                running   2d
      

Rollback zu einer vorherigen Version durchführen

Dieser Abschnitt ist je nach Status der Komponente apigee-datastore nach dem Upgrade auf die Apigee Hybrid-Version 1.12 in Abschnitte unterteilt. Es gibt Verfahren für das Rollback einer einzelnen Region oder mehrerer Regionen mit der Komponente apigee-datastore in einem fehlerfreien Zustand und Verfahren zur Wiederherstellung oder zur Wiederherstellung aus einer Sicherung, wenn sich apigee-datastore in einem fehlerhaften Zustand befindet.

Rollback und Wiederherstellung für eine einzelne Region

Rollback durchführen, wenn apigee-datastore einen fehlerfreien Status hat

In diesem Verfahren wird erläutert, wie Sie ein Rollback jeder Apigee Hybrid-Komponente von v1.12 auf v1.11 außer apigee-datastore ausführen. Die v1.12-Komponente apigee-datastore ist mit Hybrid-v1.11-Komponenten abwärtskompatibel.

So führen Sie ein Rollback Ihrer Installation für eine einzelne Region auf Version 1.11 durch:

  1. Prüfen Sie vor dem Starten des Rollbacks, ob alle Pods ausgeführt werden:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  2. Validieren Sie den Release von Komponenten mit Helm:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Beispiel:

    helm -n apigee list
    NAME              NAMESPACE   REVISION   UPDATED                                   STATUS     CHART                           APP VERSION
    datastore         apigee      2          2024-03-29 17:08:07.917848253 +0000 UTC   deployed   apigee-datastore-1.12.0         1.12.0
    ingress-manager   apigee      2          2024-03-29 17:21:02.917333616 +0000 UTC   deployed   apigee-ingress-manager-1.12.0   1.12.0
    redis             apigee      2          2024-03-29 17:19:51.143728084 +0000 UTC   deployed   apigee-redis-1.12.0             1.12.0
    telemetry         apigee      2          2024-03-29 17:16:09.883885403 +0000 UTC   deployed   apigee-telemetry-1.12.0         1.12.0
    myhybridorg       apigee      2          2024-03-29 17:21:50.899855344 +0000 UTC   deployed   apigee-org-1.12.0               1.12.0
  3. Führen Sie mit den folgenden Befehlen ein Rollback für jede Komponente außer apigee-datastore aus:
    1. Erstellen Sie die folgende Umgebungsvariable:
      • PREVIOUS_HELM_CHARTS_HOME: Das Verzeichnis, in dem die vorherigen Apigee Hybrid-Helm-Diagramme installiert sind. Dies ist die Version, zu der Sie ein Rollback durchführen.
    2. Führen Sie ein Rollback der Virtualhosts durch. Wiederholen Sie den folgenden Befehl für jede Umgebungsgruppe, die in der Überschreibungsdatei erwähnt wird.
      helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set envgroup=ENV_GROUP_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_GROUP_RELEASE_NAME ist der Name, mit dem Sie zuvor das Diagramm apigee-virtualhost installiert haben. In der Hybrid-Version 1.10 ist es normalerweise apigee-virtualhost-ENV_GROUP_NAME. In der Hybrid-Version 1.11 und höher ist dies in der Regel ENV_GROUP_NAME.

    3. Führen Sie ein Rollback für Envs durch. Wiederholen Sie den folgenden Befehl für jede in der Überschreibungendatei erwähnte Umgebung.
      helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set env=ENV_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_RELEASE_NAME ist der Name, mit dem Sie zuvor das Diagramm apigee-env installiert haben. In der Hybrid-Version 1.10 ist es normalerweise apigee-env-ENV_NAME. In der Hybrid-Version 1.11 und höher ist dies in der Regel ENV_NAME.

      Prüfen Sie, ob sie aktiv ist, indem Sie den Status der entsprechenden Umgebung prüfen:

      kubectl -n apigee get apigeeenv
      
      NAME                  STATE     AGE   GATEWAYTYPE
      apigee-org1-dev-xxx   running   2d
      
    4. Führen Sie ein Rollback für die Organisation durch:
      helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Prüfen Sie den Status der entsprechenden Organisation, um sicherzustellen, dass sie aktiv ist:

      kubectl -n apigee get apigeeorg
      
      NAME                STATE     AGE
      apigee-org1-xxxxx   running   2d
      
    5. Führen Sie ein Rollback des Ingress-Managers durch:
      helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Prüfen Sie, ob er aktiv ist, indem Sie die Verfügbarkeit prüfen:

      kubectl -n apigee get deployment apigee-ingressgateway-manager
      
      NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-ingressgateway-manager   2/2     2            2           2d
      
    6. Führen Sie ein Rollback von Redis durch:
      helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Prüfen Sie den Status, um sicherzustellen, dass dieses Element aktiv ist:

      kubectl -n apigee get apigeeredis default
      
      NAME      STATE     AGE
      default   running   2d
      
    7. Führen Sie ein Rollback von Apigee Telemetry durch:
      helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Prüfen Sie den Status, um sicherzustellen, dass dieses Element aktiv ist:

      kubectl -n apigee get apigeetelemetry apigee-telemetry
      
      NAME               STATE     AGE
      apigee-telemetry   running   2d
      
    8. Führen Sie ein Rollback des Apigee-Controllers durch:
      helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
        --install \
        --namespace apigee-system \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE

      Prüfen Sie die Installation des Apigee-Operators:

      helm ls -n apigee-system
      
      NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
      operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.0   1.12.0
      

      Prüfen Sie, ob er aktiv ist, indem Sie die Verfügbarkeit prüfen:

      kubectl -n apigee-system get deploy apigee-controller-manager
      
      NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-controller-manager   1/1     1            1           7d20h
      
    9. Führen Sie ein Rollback der Apigee Hybrid-CRDs durch:
      kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
      
  4. Prüfen Sie, ob alle Pods ausgeführt werden oder abgeschlossen sind:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  5. Validieren Sie den Release aller Komponenten. Alle Komponenten sollten in der vorherigen Version sein, mit Ausnahme des Datenspeichers:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Beispiel:

    helm -n apigee  list
    NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
    datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
    ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
    redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
    telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
    myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

Wiederherstellung, wenn apigee-datastore nicht in einem guten Zustand ist

Wenn das Upgrade der Komponente apigee-datastore nicht erfolgreich war, können Sie apigee-datastore nicht von Version 1.12 auf Version 1.11 zurücksetzen. Stattdessen müssen Sie Daten aus einer Sicherung einer Version 1.11-Installation wiederherstellen. Verwenden Sie die folgende Sequenz, um Ihre vorherige Version wiederherzustellen.

  1. Wenn Sie keine aktive Installation der Apigee Hybrid-Version 1.11 haben (z. B. in einer anderen Region), erstellen Sie eine neue Installation von Version 1.11 mit Ihren gesicherten Diagrammen und Überschreibungsdateien. Weitere Informationen finden Sie in der Installationsanleitung für Apigee Hybrid Version 1.11.
  2. Stellen Sie die v1.11-Region (oder die neue Installation) aus Ihrer Sicherung wieder her. Folgen Sie dazu der Anleitung unter:
  3. Traffic zur wiederhergestellten Installation prüfen
  4. Optional: Entfernen Sie die Installation der Version 1.12 gemäß der Anleitung unter Hybrid-Laufzeit deinstallieren.

Multiregionales Rollback und Wiederherstellung

Rollback durchführen, wenn apigee-datastore einen fehlerfreien Status hat

In diesem Verfahren wird erläutert, wie Sie ein Rollback jeder Apigee Hybrid-Komponente von v1.12 auf v1.11 außer apigee-datastore ausführen. Die v1.12-Komponente apigee-datastore ist mit Hybrid-v1.11-Komponenten abwärtskompatibel.

  1. Prüfen Sie vor dem Starten des Rollbacks, ob alle Pods ausgeführt werden:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  2. Achten Sie darauf, dass alle Cassandra-Knoten in allen Regionen den Status UN (Up / Normal) haben. Wenn sich ein Cassandra-Knoten in einem anderen Status befindet, adressieren Sie diesen zuerst, bevor Sie den Upgradeprozess starten.

    Mit den folgenden Befehlen können Sie den Status Ihrer Cassandra-Knoten validieren:

    1. Listen Sie die Cassandra-Pods auf:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Beispiele:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
      apigee-cassandra-default-3   1/1     Running   0          16m
      apigee-cassandra-default-4   1/1     Running   0          14m
      apigee-cassandra-default-5   1/1     Running   0          13m
      apigee-cassandra-default-6   1/1     Running   0          9m
      apigee-cassandra-default-7   1/1     Running   0          9m
      apigee-cassandra-default-8   1/1     Running   0          8m
    2. Prüfen Sie den Status der Knoten für jeden Cassandra-Pod mit dem Befehl kubectl nodetool status:
      kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool -u JMX_USER -pw JMX_PASSWORD

      Beispiele:

      kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u jmxuser -pw JMX_PASSWORD status
      Datacenter: us-east1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --  Address      Load        Tokens   Owns (effective)   Host ID                                Rack
      UN  10.16.2.6    690.17 KiB  256      48.8%              b02089d1-0521-42e1-bbed-900656a58b68   ra-1
      UN  10.16.4.6    705.55 KiB  256      51.6%              dc6b7faf-6866-4044-9ac9-1269ebd85dab   ra-1
      UN  10.16.11.11  674.36 KiB  256      48.3%              c7906366-6c98-4ff6-a4fd-17c596c33cf7   ra-1
      UN  10.16.1.11   697.03 KiB  256      49.8%              ddf221aa-80aa-497d-b73f-67e576ff1a23   ra-1
      UN  10.16.5.13   703.64 KiB  256      50.9%              2f01ac42-4b6a-4f9e-a4eb-4734c24def95   ra-1
      UN  10.16.8.15   700.42 KiB  256      50.6%              a27f93af-f8a0-4c88-839f-2d653596efc2   ra-1
      UN  10.16.11.3   697.03 KiB  256      49.8%              dad221ff-dad1-de33-2cd3-f1.672367e6f   ra-1
      UN  10.16.14.16  704.04 KiB  256      50.9%              1feed042-a4b6-24ab-49a1-24d4cef95473   ra-1
      UN  10.16.16.1   699.82 KiB  256      50.6%              beef93af-fee0-8e9d-8bbf-efc22d653596   ra-1

    Wenn nicht alle Cassandra-Pods den Status UN haben, folgen Sie der Anleitung unter DOWN-Knoten aus Cassandra-Cluster entfernen.

  3. Wechseln Sie in das Verzeichnis, in dem die vorherigen Apigee Hybrid-Helm-Diagramme installiert sind.
  4. Ändern Sie den Kontext in die Region, die aktualisiert wurde.
    kubectl config use-context UPGRADED_REGION_CONTEXT
        
  5. Prüfen Sie, ob alle Pods ausgeführt werden:
    kubectl get pods -n APIGEE_NAMESPACE
    kubectl get pods -n apigee-system
  6. Prüfen Sie mit dem Helm-Befehl, ob alle Releases auf Hybrid v1.12 aktualisiert wurden:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Beispiel:

    helm -n apigee list
    NAME             NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
    datastore        apigee     2         2024-03-29 17:08:07.917848253 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
    ingress-manager  apigee     2         2024-03-29 17:21:02.917333616 +0000 UTC  deployed  apigee-ingress-manager-1.12.0  1.12.0
    redis            apigee     2         2024-03-29 17:19:51.143728084 +0000 UTC  deployed  apigee-redis-1.12.0            1.12.0
    telemetry        apigee     2         2024-03-29 17:16:09.883885403 +0000 UTC  deployed  apigee-telemetry-1.12.0        1.12.0
    myhybridorg      apigee     2         2024-03-29 17:21:50.899855344 +0000 UTC  deployed  apigee-org-1.12.0              1.12.0
  7. Führen Sie mit den folgenden Befehlen ein Rollback für jede Komponente außer apigee-datastore aus:
    1. Erstellen Sie die folgende Umgebungsvariable:
      • PREVIOUS_HELM_CHARTS_HOME: Das Verzeichnis, in dem die vorherigen Apigee Hybrid-Helm-Diagramme installiert sind. Dies ist die Version, zu der Sie ein Rollback durchführen.
    2. Führen Sie ein Rollback der Virtualhosts durch. Wiederholen Sie den folgenden Befehl für jede Umgebungsgruppe, die in der Überschreibungsdatei erwähnt wird.
      helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set envgroup=ENV_GROUP_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_GROUP_RELEASE_NAME ist der Name, mit dem Sie zuvor das Diagramm apigee-virtualhost installiert haben. In der Hybrid-Version 1.10 ist es normalerweise apigee-virtualhost-ENV_GROUP_NAME. In der Hybrid-Version 1.11 und höher ist dies in der Regel ENV_GROUP_NAME.

    3. Führen Sie ein Rollback für Envs durch. Wiederholen Sie den folgenden Befehl für jede in der Überschreibungendatei erwähnte Umgebung.
      helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        --set env=ENV_NAME \
        -f PREVIOUS_OVERRIDES_FILE
      

      ENV_RELEASE_NAME ist der Name, mit dem Sie zuvor das Diagramm apigee-env installiert haben. In der Hybrid-Version 1.10 ist es normalerweise apigee-env-ENV_NAME. In der Hybrid-Version 1.11 und höher ist dies in der Regel ENV_NAME.

      Prüfen Sie, ob jede Umgebung aktiv ist, indem Sie den Status der entsprechenden Umgebung prüfen:

      kubectl -n apigee get apigeeenv
      
      NAME                  STATE     AGE   GATEWAYTYPE
      apigee-org1-dev-xxx   running   2d
      
    4. Führen Sie ein Rollback für die Organisation durch:
      helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Prüfen Sie den Status der entsprechenden Organisation, um sicherzustellen, dass sie aktiv ist:

      kubectl -n apigee get apigeeorg
      
      NAME                STATE     AGE
      apigee-org1-xxxxx   running   2d
      
    5. Führen Sie ein Rollback des Ingress-Managers durch:
      helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Prüfen Sie, ob er aktiv ist, indem Sie die Verfügbarkeit prüfen:

      kubectl -n apigee get deployment apigee-ingressgateway-manager
      
      NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-ingressgateway-manager   2/2     2            2           2d
      
    6. Führen Sie ein Rollback von Redis durch:
      helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Prüfen Sie den Status, um sicherzustellen, dass dieses Element aktiv ist:

      kubectl -n apigee get apigeeredis default
      
      NAME      STATE     AGE
      default   running   2d
      
    7. Führen Sie ein Rollback von Apigee Telemetry durch:
      helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Prüfen Sie den Status, um sicherzustellen, dass dieses Element aktiv ist:

      kubectl -n apigee get apigeetelemetry apigee-telemetry
      
      NAME               STATE     AGE
      apigee-telemetry   running   2d
      
    8. Führen Sie ein Rollback des Apigee-Controllers durch:
      helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
        --install \
        --namespace apigee-system \
        --atomic \
        -f PREVIOUS_OVERRIDES_FILE
      

      Prüfen Sie die Installation des Apigee-Operators:

      helm ls -n apigee-system
      
      NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
      operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.0   1.12.0
      

      Prüfen Sie, ob er aktiv ist, indem Sie die Verfügbarkeit prüfen:

      kubectl -n apigee-system get deploy apigee-controller-manager
      
      NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
      apigee-controller-manager   1/1     1            1           7d20h
      
    9. Führen Sie ein Rollback der Apigee Hybrid-CRDs durch:
      kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
      
  8. Validieren Sie den Release aller Komponenten. Alle Komponenten sollten sich in der vorherigen Version befinden, mit Ausnahme von datastore:
    helm -n APIGEE_NAMESPACE list
    helm -n apigee-system list

    Beispiel:

    helm -n apigee  list
    NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
    datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
    ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
    redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
    telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
    myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0
    

    Jetzt wurden alle Releases außer datastore auf die vorherige Version zurückgesetzt.

Multiregionale Installation auf eine vorherige Version wiederherstellen

Stellen Sie die Region wieder her, in der das Upgrade in einem Upgrade für mehrere Regionen fehlgeschlagen ist. Entfernen Sie dazu die Verweise aus Multi-Region-Installationen. Diese Methode ist nur möglich, wenn mindestens eine Live-Region in Hybrid 1.11 vorhanden ist. Der v1.12-Datenspeicher ist mit v1.11-Komponenten kompatibel.

So stellen Sie fehlgeschlagene Regionen aus einer fehlerfreien Region wieder her:

  1. Leiten Sie den API-Traffic von den betroffenen Regionen an die funktionierende Arbeitsregion weiter. Planen Sie die Kapazität entsprechend, um den weitergeleiteten Traffic aus fehlgeschlagenen Regionen zu unterstützen.
  2. Deaktivieren Sie die betroffene Region. Führen Sie für jede betroffene Region die Schritte aus, die unter Hybridregion außer Betrieb nehmen beschrieben werden. Warten Sie, bis die Außerbetriebnahme abgeschlossen ist, bevor Sie fortfahren.

  3. Bereinigen Sie die fehlgeschlagene Region. Folgen Sie dazu der Anleitung unter Region nach einem fehlgeschlagenen Upgrade wiederherstellen.
  4. Stellen Sie die betroffene Region wieder her. Erstellen Sie zur Wiederherstellung eine neue Region, wie unter Multiregionale Bereitstellung in GKE, GKE On-Prem und AKS beschrieben.

Installation mit mehreren Regionen aus einer Sicherung mit apigee-datastore in einem fehlerhaften Zustand wiederherstellen

Wenn das Upgrade der Komponente apigee-datastore nicht erfolgreich war, können Sie kein Rollback von Version 1.12 auf Version 1.11 durchführen. Stattdessen müssen Sie Daten aus einer Sicherung einer Version 1.11-Installation wiederherstellen. Verwenden Sie die folgende Sequenz, um Ihre vorherige Version wiederherzustellen.

  1. Wenn Sie keine aktive Installation der Apigee Hybrid-Version 1.11 haben (z. B. in einer anderen Region), erstellen Sie eine neue Installation von Version 1.11 mit Ihren gesicherten Diagrammen und Überschreibungsdateien. Weitere Informationen finden Sie in der Installationsanleitung für Apigee Hybrid Version 1.11.
  2. Stellen Sie die v1.11-Region (oder die neue Installation) aus Ihrer Sicherung wieder her. Folgen Sie dazu der Anleitung unter:
  3. Traffic zur wiederhergestellten Installation prüfen
  4. Bei Installationen mit mehreren Regionen erstellen Sie die nächste Region neu und stellen diese wieder her. Weitere Informationen finden Sie unter Aus einer Sicherung wiederherstellen in mehreren Regionen wiederherstellen.
  5. Entfernen Sie die Installation von Version 1.12 gemäß der Anleitung unter Hybridlaufzeit deinstallieren.

ANHANG: Region nach einem fehlgeschlagenen Upgrade wiederherstellen

Entfernen Sie ein Rechenzentrum, wenn das Upgrade von 1.11 auf 1.12 fehlschlägt.

  1. Validieren Sie den Status des Cassandra-Clusters aus einer Live-Region:
    1. Legen Sie den kubectl-Kontext auf die Region fest, die entfernt werden soll:
      kubectl config use-context CONTEXT_OF_LIVE_REGION
    2. Listen Sie die Cassandra-Pods auf:
      kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

      Beispiele:

      kubectl get pods -n apigee -l app=apigee-cassandra
      NAME                 READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          2h
      apigee-cassandra-default-1   1/1     Running   0          2h
      apigee-cassandra-default-2   1/1     Running   0          2h
    3. Führen Sie einen der Cassandra-Pods aus:
      kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash
    4. Prüfen Sie den Status des Cassandra-Clusters:
      nodetool -u JMX_USER -pw JMX_PASSWORD status

      Die Ausgabe sollte in etwa so aussehen:

      Datacenter: dc-1
      ================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
      UN  10.48.12.16  813.84 KiB  256          100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
      UN  10.48.14.16  859.89 KiB  256          100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
      UN  10.48.0.18   888.95 KiB  256          100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
      
    5. Beschreiben Sie den Cluster, damit Sie nur IP-Adressen von Cassandra-Pods aus der Live-Region und alle in derselben Schemaversion sehen:
      nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

      Die Ausgabe sollte in etwa so aussehen:

      nodetool -u JMX_USER -pw JMX_PASSWORD describecluster
      
      Schema versions:
          4bebf2de-0582-31b4-9c5f-e36f60127e1b: [10.48.14.16, 10.48.12.16, 10.48.0.18]
      
  2. Bereinigen Sie die Replikation des Cassandra-Schlüsselbereichs:
    1. Rufen Sie den Job user-setup ab und löschen Sie ihn. Ein neuer user-setup-Job wird umgehend erstellt.
      kubectl get jobs -n APIGEE_NAMESPACE

      Beispiel:

      kubectl get jobs -n apigee
        NAME                                                           COMPLETIONS   DURATION   AGE
        apigee-cassandra-schema-setup-myhybridorg-8b3e61d          1/1           6m35s      3h5m
        apigee-cassandra-schema-val-myhybridorg-8b3e61d-28499150   1/1           10s        9m22s
       apigee-cassandra-user-setup-myhybridorg-8b3e61d            0/1           21s        21s
      
      kubectl delete jobs USER_SETUP_JOB_NAME -n APIGEE_NAMESPACE

      Die Ausgabe sollte zeigen, dass der neue Job beginnt:

      kubectl delete jobs apigee-cassandra-user-setup-myhybridorg-8b3e61d -n apigee
      
        apigee-cassandra-user-setup-myhybridorg-8b3e61d-wl92b         0/1     Init:0/1    0               1s
        
    2. Validieren Sie die Replikationseinstellungen des Cassandra-Schlüsselbereichs, indem Sie einen Client-Container erstellen. Folgen Sie dazu der Anleitung unter Client-Container erstellen.
    3. Rufen Sie alle Schlüsselbereiche ab. Führen Sie den Cassandra-Client-Pod aus und starten Sie dann einen cqlsh-Client:
      kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

      Stellen Sie eine Verbindung zum Cassandra-Server mit ddl user her, da dieser Berechtigungen zum Ausführen der folgenden Befehle benötigt:

      cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

      Rufen Sie die Schlüsselbereiche ab:

      select * from system_schema.keyspaces;

      Die Ausgabe sollte in etwa so aussehen, wobei dc-1 der Live-DC ist:

      select * from system_schema.keyspaces;
      
       keyspace_name            | durable_writes | replication
      --------------------------+----------------+--------------------------------------------------------------------------------
         kvm_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                    system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                  system_schema |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
       quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         rtc_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
             system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                         system |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                         perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                  system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         kms_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      
      (11 rows)
      
    4. Wenn der user-setup-Job aus irgendeinem Grund weiterhin Fehler aufweist und die Validierung fehlschlägt, verwenden Sie die folgenden Befehle, um die Replikation in den Schlüsselbereichen zu korrigieren.
      kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

      Stellen Sie eine Verbindung zum Cassandra-Server mit ddl user her, da dieser Berechtigungen zum Ausführen der folgenden Befehle benötigt:

      cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

      Rufen Sie die Schlüsselbereiche ab:

      select * from system_schema.keyspaces;

      Verwenden Sie die Namen der Schlüsselbereiche aus dem obigen Befehl und ersetzen Sie sie in den folgenden Beispielen

      alter keyspace quota_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace kms_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace kvm_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace cache_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace perses_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace rtc_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace system_distributed WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      alter keyspace system_traces WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
      .

    5. Prüfen Sie mit dem folgenden cqlsh-Befehl, ob alle Schlüsselbereiche in der richtigen Region repliziert werden:
      select * from system_schema.keyspaces;

      Beispiele:

      select * from system_schema.keyspaces;
      
       keyspace_name           | durable_writes | replication
      -------------------------+----------------+--------------------------------------------------------------------------------
      kvm_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                system_auth    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_schema    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
      quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      rtc_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
         system_distributed    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                     system    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                     perses    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_traces    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      kms_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
      
      (11 rows)

In dieser Phase haben Sie alle Verweise für den toten DC vollständig aus dem Cassandra-Cluster entfernt.

APPENDIX: DOWN-Knoten aus dem Cassandra-Cluster entfernen

Verwenden Sie dieses Verfahren, wenn Sie eine multiregionale Installation rückgängig machen und nicht alle Cassandra-Pods im Status „Up / Normal“ (UN) sind.

  1. Führen Sie einen der Cassandra-Pods aus:
    kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash
  2. Prüfen Sie den Status des Cassandra-Clusters:
    nodetool -u JMX_USER -pw JMX_PASSWORD status
  3. Prüfen Sie, ob der Knoten tatsächlich ausgefallen ist (DN). Führen Sie den Cassandra-Pod in einer Region aus, in der der Cassandra-Pod nicht gestartet werden kann.
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    UN  10.48.12.16  1.15 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
    UN  10.48.0.18   1.21 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
    UN  10.48.14.16  1.18 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
    
    Datacenter: us-west1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    DN  10.8.4.4     432.42 KiB  256     100.0%            cd672398-5c45-4c88-a424-86d757951e53  rc-1
    UN  10.8.19.6    5.8 MiB     256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
    UN  10.8.21.5    5.74 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1
    
  4. Entfernen Sie den Verweis auf den ausgefallenen Knoten (DN). Im obigen Beispiel entfernen wir die Referenz für den Host 10.8.4.4
    kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash
     nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID
    
    .
  5. Nachdem der Verweis entfernt wurde, beenden Sie den Pod. Der neue Cassandra-Pod sollte dem Cluster
    kubectl delete pod -n POD_NAME
    beitreten.
  6. Prüfen Sie, ob der neue Cassandra-Pod dem Cluster hinzugefügt wurde.
    Datacenter: dc-1
    ================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    UN  10.48.12.16  1.16 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
    UN  10.48.0.18   1.22 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
    UN  10.48.14.16  1.19 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
    
    Datacenter: us-west1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
    UN  10.8.19.6    5.77 MiB    256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
    UN  10.8.4.5     246.99 KiB  256     100.0%            0182e675-eec8-4d68-a465-69211b621601  rc-1
    UN  10.8.21.5    5.69 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

An diesem Punkt können Sie mit dem Upgrade fortfahren oder ein Rollback der verbleibenden Regionen des Clusters durchführen.

APPENDIX: Fehlerbehebung: apigee-datastore bleibt nach einem Rollback im hängen gebliebenen Zustand

Verwenden Sie dieses Verfahren, wenn Sie nach dem Upgrade ein Rollback von apigee-datastore auf Hybrid 1.11 durchgeführt haben und der Vorgang hängen bleibt.

  1. Bevor Sie den Status des Datenspeicher-Controllers erneut korrigieren, prüfen Sie, ob er sich im Status releasing befindet und die Pods nicht zusammen mit dem Status des Cassandra-Clusters angezeigt werden.
    1. Validieren Sie mit dem Helm-Befehl, dass für den Datenspeicher ein Rollback durchgeführt wurde:
      helm -n APIGEE_NAMESPACE list

      Beispiele:

      helm -n apigee list
      NAME              NAMESPACE  REVISION  UPDATED                                   STATUS    CHART                              APP VERSION
      datastore         apigee     3         2024-04-04 22:15:08.792539892 +0000 UTC   deployed   apigee-datastore-1.11.0           1.11.0
      ingress-manager   apigee     1         2024-04-02 22:24:27.564184968 +0000 UTC   deployed   apigee-ingress-manager-1.12.0     1.12.0
      redis             apigee     1         2024-04-02 22:23:59.938637491 +0000 UTC   deployed   apigee-redis-1.12.0               1.12.0
      telemetry         apigee     1         2024-04-02 22:23:39.458134303 +0000 UTC   deployed   apigee-telemetry-1.12             1.12.0
      myhybridorg       apigee     1         2024-04-02 23:36:32.614927914 +0000 UTC   deployed   apigee-org-1.12.0                 1.12.0
      
    2. Rufen Sie den Status der Cassandra-Pods ab:
      kubectl get pods -n APIGEE_NAMESPACE

      Beispiele:

      kubectl get pods -n apigee
      NAME                         READY   STATUS             RESTARTS      AGE
      apigee-cassandra-default-0   1/1     Running            0             2h
      apigee-cassandra-default-1   1/1     Running            0             2h
      apigee-cassandra-default-2   0/1     CrashLoopBackOff   4 (13s ago)   2m13s
      
    3. Prüfen Sie, ob der apigeeds-Controller im Releasestatus hängen bleibt:
      kubectl get apigeeds -n APIGEE_NAMESPACE

      Beispiele:

      kubectl get apigeeds -n apigee
      NAME      STATE       AGE
      default   releasing   46h
    4. Prüfen Sie den Status der Cassandra-Knoten (beachten Sie, dass sich ein Knoten im Zustand DN befindet, d. h. der Knoten steckt im Zustand CrashLoopBackOff fest):
      kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

      Beispiele:

      kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
      Defaulted container "apigee-cassandra" out of: apigee-cassandra, apigee-cassandra-ulimit-init (init)
      Datacenter: us-west1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --   Address       Load       Tokens   Owns (effective)   Host ID                               Rack
      UN   10.68.7.28    2.12 MiB   256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3  rc-1
      UN   10.68.10.29   2.14 MiB   256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452  rc-1
      DN   10.68.6.26    5.77 MiB   256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
      
  2. Aktualisieren Sie den Datenspeicher mit den Diagrammen aus 1.12.
    helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml
  3. Prüfen Sie, ob alle Pods Running sind und der Cassandra-Cluster wieder fehlerfrei ist.
    1. Prüfen Sie noch einmal, ob alle Pods READY sind:
      kubectl get pods -n APIGEE_NAMESPACE

      Beispiele:

      kubectl get pods -n apigee
      NAME                         READY   STATUS    RESTARTS   AGE
      apigee-cassandra-default-0   1/1     Running   0          29h
      apigee-cassandra-default-1   1/1     Running   0          29h
      apigee-cassandra-default-2   1/1     Running   0          60m
    2. Validieren Sie den Status des Cassandra-Clusters:
      kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

      Beispiele:

      kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
      Datacenter: us-west1
      ====================
      Status=Up/Down
      |/ State=Normal/Leaving/Joining/Moving
      --   Address       Load      Tokens   Owns (effective)   Host ID                                Rack
      UN   10.68.4.15    2.05 MiB  256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
      UN   10.68.7.28    3.84 MiB  256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3   rc-1
      UN   10.68.10.29   3.91 MiB  256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452   rc-1
        
    3. Validieren Sie den Status des apigeeds-Controllers:
      kubectl get apigeeds -n APIGEE_NAMESPACE

      Beispiele:

      kubectl get apigeeds -n apigee
      NAME      STATE     AGE
      default   running   2d1h

An diesem Punkt haben Sie den Datenspeicher korrigiert und er sollte sich im Status running befinden.