Upgrade von Apigee Hybrid auf Version 1.12 ausführen

Version 1.12 

Unterstützte Versionen:

• v1.13 (aktuellste Version)                        
• v1.12                         
• v1.11                         
• Liste der unterstützten Versionen

Nicht unterstützte Versionen:

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

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

Ä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.
  Wichtig: Aufgrund der Datenbankänderung kann kein Rollback für die aktualisierte apigee-datastore-Komponente durchgeführt werden. Daher ist es von größter Bedeutung, Ihre Cassandra-Datenbank und Ihre Hybrid-Installation vor dem Upgrade zu sichern. Beachten Sie die folgenden Szenarien, wenn Sie ein Rollback für Ihr Upgrade durchführen müssen:

  • Cassandra noch nicht aktualisiert: Sie können alle Änderungen rückgängig machen.
  • Cassandra wurde aktualisiert und alle Cassandra-Pods sind fehlerfrei: Sie können ein Rollback für Änderungen an allen Komponenten außer apigee-datastore ausführen. Ihre Version 1.11.x funktioniert weiterhin mit einer Instanz der Version 1.12 von apigee-datastore, auf der Cassandra v4 ausgeführt wird.
  • Cassandra wurde aktualisiert und die Cassandra-Pods befinden sich in einem fehlerhaften Zustand: Sie müssen die Hybrid-Version 1.12 deinstallieren und die Installation von Version 11 aus einer Sicherung wiederherstellen.
• Einstellung von apigeectl: Ab Version 1.12 unterstützt Apigee Hybrid nur Helm für die Installation und Verwaltung Ihrer Hybrid-Installation.
  Achtung: apigeectl wurde am 17. April 2024 eingestellt. Das Tool apigeectl wird für Apigee Hybrid v1.12 nicht unterstützt. Der Support für apigeectl für Apigee Hybrid v1.10 und v1.11 endet am 17. April 2025. Weitere Informationen finden Sie unter Einstellung von apigeectl.
  Wichtig: Wenn Sie Version 1.11 mit apigeectl verwalten, müssen Sie zuerst Ihre Installation von Version 1.11 migrieren, um Helm zu verwenden, bevor Sie ein Upgrade auf Version 1.12 durchführen. Folgen Sie der Anleitung unter Apigee Hybrid zu Helm-Diagrammen von apigeectl migrieren.

• 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.
    Hinweis: Sie können keine Regionen hinzufügen oder Cassandra-Knoten skalieren, während Sie Komponenten verschiedener Hybrid-Versionen ausführen.
  • Wenn sich die Komponente apigee-datastore in einem fehlerhaften Zustand befindet, müssen Sie aus einer v1.11-Sicherung eine v1.11-Installation wiederherstellen.
    Hinweis: Versionen können bei der Wiederherstellung nicht kombiniert werden. Sie müssen eine Sicherung, die in einer Version 1.11-Installation erstellt wurde, in einer Version 1.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.
  • Wenn Sie Ihre Hybrid-Installation mit apigeectl verwalten, müssen Sie zuerst Ihre Cluster zur Helm-Verwaltung migrieren. Weitere Informationen finden Sie in der Dokumentation zu Hybrid v1.11 unter Apigee Hybrid von apigeectl zu Helm migrieren.
  • Wenn in Ihrer Hybrid-Installation eine Version vor Version 1.11 ausgeführt wird, müssen Sie vor dem Upgrade auf Version 1.12 ein Upgrade auf Version 1.11 ausführen. Siehe Upgrade von Apigee Hybrid auf Version 1.11 ausführen.
• 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.2 – Übersicht

Das Upgrade auf die Apigee Hybrid-Version 1.12 erfordert möglicherweise Ausfallzeiten.

Beim Upgrade des Apigee-Controllers auf Version 1.12.2 wird für alle Apigee-Bereitstellungen ein rollierender Neustart ausgeführt. Achten Sie darauf, dass mindestens zwei Cluster in derselben oder in einer anderen Region/einem anderen Rechenzentrum ausgeführt werden, um während eines rollierenden Neustarts die Ausfallzeiten in hybriden Produktionsumgebungen zu minimieren. Leiten Sie den gesamten Produktionstraffic zu einem einzelnen Cluster und nehmen Sie den Cluster, für den Sie das Upgrade machen, offline. Danach können Sie mit dem Upgrade fortfahren. Wiederholen Sie den Vorgang für jeden Cluster.

Apigee empfiehlt, alle Cluster so schnell wie möglich zu aktualisieren, um Auswirkungen auf die Produktion zu reduzieren. Es gibt keine zeitliche Begrenzung dafür, wann nach dem ersten Cluster alle weiteren Cluster aktualisiert werden müssen. Bis zur Aktualisierung aller verbleibenden Cluster sind die folgenden Vorgänge jedoch betroffen:

• Die Cassandra-Sicherung und -Wiederherstellung funktioniert nicht mit gemischten Versionen. Beispielsweise kann eine Sicherung von Hybrid 1.11 nicht zum Wiederherstellen einer Hybrid 1.12-Instanz verwendet werden.
• Cassandra-Datenstreaming funktioniert nicht zwischen gemischten Hybrid-Versionen. Daher können Ihre Cassandra-Cluster nicht horizontal skaliert werden.
• Die Regionserweiterung und die Außerbetriebnahme sind betroffen, da diese Vorgänge vom Cassandra-Datenstreaming abhängen.

Hinweis: Änderungen an der Verwaltungsebene müssen während eines Upgrades nicht angehalten werden. Alle erforderlichen Änderungen an der Verwaltungsebene sind in der Upgradeanleitung enthalten.

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

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

     Beispiel:

     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

     Beispiel:

     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

     Beispiel:

     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

     Beispiel:

     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

     Beispiel:

     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

   Mac OS

   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.

Klicken Sie, um eine Liste der unterstützten Plattformen einzublenden

	1.10 ^(3)	1.11	1.12
GKE in Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.25.x 1.26.x 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
GKE on AWS	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x^(12) 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x (K8s v1.25.x) 1.26.x^(12) 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x^(12) 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
GKE on Azure	1.13.x 1.14.x 1.26.x^(12) 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x 1.26.x^(12) 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x^(12) 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
Google Distributed Cloud (nur Software) on VMware ^(1) ^(13)	1.13.x 1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(12) 1.29.x^(≥ 1.12.1)
Google Distributed Cloud (nur Software) auf Bare Metal ^(1)	1.13.x 1.14.x (K8s v1.25.x) 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^(12)^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(12)^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^(12) 1.29.x^(≥ 1.12.1)
EKS^(7)	1.24.x 1.25.x 1.26.x 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.25.x 1.26.x 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
AKS^(7)	1.24.x 1.25.x 1.26.x 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.25.x 1.26.x 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
OpenShift^(7)	4.11 4.12 4.14^(≥ 1.10.5) 4.15^(≥ 1.10.5)	4.12 4.13 4.14 4.15^(≥ 1.11.2) 4.16^(≥ 1.11.2)	4.12 4.13 4.14 4.15 4.16^(≥ 1.12.1)
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	v1.26.2+rke2r1 v1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
VMware Tanzu	–	–	v1.26.x
Komponenten	1.10	1.11	1.12
Cloud Service Mesh	1.17.x^(10)	1.18.x^(10)	1.19.x^(10)
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	4.0
Kubernetes	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
kubectl			1.27.x 1.28.x 1.29.x
Helm	3.10+	3.10+	3.14.2+
Secret Store CSI driver		1.3.4	1.4.1
Vault		1.13.x	1.15.2
^(1) Folgen Sie in der lokalen Anthos-Version 1.13 (Google Distributed Cloud) dieser Anleitung, um Konflikte mit cert-manager zu vermeiden: Konflikt mit cert-manager-Installation ^(2) Support ab Apigee Hybrid-Version 1.7.2 und höher verfügbar.. ^(3) Die offiziellen EOL-Daten für Apigee Hybrid-Versionen 1.10 und niedriger wurden erreicht. Regelmäßige monatliche Patches sind nicht mehr verfügbar. Diese Releases werden nicht mehr offiziell unterstützt, mit Ausnahme von Kunden mit expliziten und offiziellen Ausnahmen für weiteren Support. Andere Kunden müssen ein Upgrade ausführen. ^(4) Die lokalen Anthos-Versionen 1.12 und älter (Google Distributed Cloud) werden nicht mehr unterstützt. Weitere Informationen finden Sie in der Richtlinie für die Versionsunterstützung von Distributed Cloud on bare metal und in der Liste der unterstützten Versionen von Distributed Cloud on VMware. ^(5)Für Google Distributed Cloud auf Bare Metal oder VMware ist Cloud Service Mesh 1.14 oder höher erforderlich. Wir empfehlen ein Upgrade auf die Hybrid-Version 1.8 und einen Wechsel zum Apigee Ingress Gateway, für das Sie Cloud Service Mesh nicht mehr auf Ihrem Hybridcluster installieren müssen. ^(6) Support ab Apigee Hybrid-Version 1.8.4 verfügbar. ^(7) Wird ab Apigee Hybrid-Version 1.8.4 nicht mehr unterstützt. ^(8) Support ab Apigee Hybrid-Version 1.7.6 verfügbar. ^(9) Wird ab Apigee Hybrid-Version 1.8.5 nicht mehr unterstützt. ^(10) Anthos Service Mesh wird automatisch mit Apigee Hybrid 1.9 und höher installiert. ^(11) Support ab Apigee Hybrid-Version 1.9.2 verfügbar. ^(12) Die GKE on AWS-Versionsnummern spiegeln jetzt die Kubernetes-Versionen wider. Weitere Informationen für Versionsdetails und empfohlene Patches finden Sie im Abschnitt Unterstützung für GKE Enterprise-Versionen und -Upgrades. ^(13) Vault ist in Google Distributed Cloud for VMware nicht zertifiziert. ^(14) Support ab Apigee Hybrid-Version 1.10.5 verfügbar. ^(15) Support ab Apigee Hybrid-Version 1.11.2 verfügbar. ^(16) Support ab Apigee Hybrid-Version 1.12.1 verfügbar.

Angehängte Cluster

Für Apigee Hybrid-Versionen 1.7.x und niedriger müssen Sie angehängte GKE-Cluster von Anthos verwenden, wenn Sie Apigee Hybrid in einem Multi-Cloud-Kontext auf Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) oder einem anderen unterstützten Kubernetes-Drittanbieter ausführen möchten. Mit dem Clusteranhang kann Google die Nutzung von Cloud Service Mesh messen.

Für die Apigee Hybrid-Version 1.8.x sind angehängte GKE-Cluster erforderlich, wenn Sie Cloud Service Mesh für Ihr Ingress-Gateway verwenden. Wenn Sie das Ingress-Gateway von Apigee verwenden, sind angehängte Cluster optional.

Hinweis: Hybridinstallationen werden derzeit in Autopilot-Clustern nicht unterstützt.

Hybrid 1.12.2-Laufzeit installieren

Achtung: Erstellen Sie während des Upgrades keine neuen Umgebungen.

Upgrade auf Helm-Diagramme vorbereiten

Bei diesem Upgradeverfahren wird davon ausgegangen, dass Sie denselben Namespace und dieselben Dienstkonten für die aktualisierte Installation verwenden. Wenn Sie Konfigurationsänderungen vornehmen, achten Sie darauf, diese Änderungen in Ihrer Überschreibungsdatei zu berücksichtigen, bevor Sie die Helm-Diagramme installieren.

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.2
   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:
   Hinweis: Ab diesem Schritt sollten alle Befehle im Stammverzeichnis des Diagramm-Repositorys ausgeführt werden.
   Hinweis: Dies ist die einzige unterstützte Methode zum Installieren von Apigee-CRDs. Verwenden Sie kubectl apply nicht ohne -k und lassen Sie --server-side nicht weg.
   Hinweis: Für diesen Schritt sind erhöhte Clusterberechtigungen erforderlich.

   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

Hinweis: Verwenden Sie vor dem Ausführen eines der Helm-Upgrade-/-Installationsbefehle das Helm-Probelauf-Feature, indem Sie --dry-run am Ende des Befehl hinzufügen. Mit helm -h können Sie unterstützte Befehle, Optionen und die Nutzung auflisten.

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:
   Hinweis: Für diesen Schritt sind höhere Clusterberechtigungen erforderlich. Führen Sie helm -h oder helm upgrade -h aus, um Details zu erfahren.

   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
   

   Hinweis: Verwenden Sie für migrierte Installationen:

   helm upgrade operator apigee-operator/ \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --force \
     -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.2   1.12.2

   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
   

   Hinweis: Verwenden Sie für migrierte Installationen:

   helm upgrade datastore apigee-datastore/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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
   

   Hinweis: Verwenden Sie für migrierte Installationen:

   helm upgrade telemetry apigee-telemetry/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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
   

   Hinweis: Verwenden Sie für migrierte Installationen:

   helm upgrade redis apigee-redis/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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
   

   Hinweis: Verwenden Sie für migrierte Installationen:

   helm upgrade ingress-manager apigee-ingress-manager/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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
   

   Hinweis: Verwenden Sie für migrierte Installationen:

   helm upgrade ORG_NAME apigee-org/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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.2

   Aktualisieren Sie das Diagramm:

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

   Hinweis:
   Verwenden Sie für migrierte Installationen:

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --set env=ENV_NAME \
     --force \
     -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
      

      Hinweis: Verwenden Sie für migrierte Installationen:

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

      Hinweis: ENV_GROUP_RELEASE_NAME darf im Namespace apigee nur einmal vorkommen.

      Wenn Sie beispielsweise eine Umgebung mit dem Namen prod und eine Umgebungsgruppe mit dem Namen prod haben, legen Sie für ENV_GROUP_RELEASE_NAME einen eindeutigen Wert wie prod-envgroup fest.

   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

Glückwunsch! Sie haben ein Upgrade auf die Apigee Hybrid-Version 1.12.2 ausgeführt. Rufen Sie zum Testen des Upgrades einen Proxy für die neue Installation auf. Ein Beispiel finden Sie unter Schritt 10: API-Proxy bereitstellen in der Installationsanleitung für Apigee Hybrid 1.12.

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 apigee-datastore-Komponente der Version 1.12 ist abwärtskompatibel mit Hybrid-Komponenten der Version 1.11.

Warnung: Ein Rollback für apigee-datastore ist nicht möglich. Die Dateninkompatibilität zwischen verschiedenen Versionen der Cassandra-Datenbank verhindert ein Rollback auf die vorherige Version.

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

      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:
   • CSI-Sicherungen (Cloud Storage Interface): Cassandra-CSI-Sicherung und -Wiederherstellung.
   • Nicht-CSI-Sicherungen: In einer einzelnen Region wiederherstellen.
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

Hinweis:> Verwenden Sie diese Rollback-Methode, um ein Rollback von einer aktualisierten Hybrid-Region auf die vorherige Hybrid-Version durchzuführen. Diese Methode ist zur Wiederherstellung nach einem fehlgeschlagenen Upgrade vorgesehen, wenn noch nicht alle Regionen aktualisiert wurden.

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 apigee-datastore-Komponente der Version 1.12 ist abwärtskompatibel mit Hybrid-Komponenten der Version 1.11.

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

      Beispiel:

      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

      Beispiel:

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

      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.

Wichtig: Derzeit wird der Cassandra-Datenspeicher teilweise aktualisiert. Wir empfehlen, ein Upgrade noch einmal durchzuführen, indem Sie alle Probleme beheben, die während des vorherigen Upgrades aufgetreten sind, und den Vorgang wiederholen. Wenn kein weiteres Upgrade durchgeführt werden kann, wird empfohlen, den Datenspeicher mithilfe der Anleitung unter Installation mit mehreren Regionen auf eine frühere Version wiederherstellen wiederherzustellen.

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.

Tipp: Zur Minimierung von Ausfallzeiten bei multiregionalen Installationen empfiehlt Apigee, jeweils nur eine Region zu erstellen und 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:
   • CSI-Sicherungen (Cloud Storage Interface): Cassandra-CSI-Sicherung und -Wiederherstellung.
   • Nicht-CSI-Sicherungen: In mehreren Regionen wiederherstellen.
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

      Beispiel:

      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.
      Achtung: Verwenden Sie die folgenden Befehle mit äußerster Vorsicht.

      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;

      Beispiel:

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

   kubectl delete pod -n POD_NAME

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

      Beispiel:

      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

      Beispiel:

      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

      Beispiel:

      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

      Beispiel:

      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.
   Hinweis: Der Controller geht wieder in den Zustand releasing über, aber dieses Mal erstellt er Pods mit den Images für Hybrid 1.12, die hochgefahren werden, und Cassandra tritt dem Cluster bei und wird UN (UP/NORMAL).

   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

      Beispiel:

      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

      Beispiel:

      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

      Beispiel:

      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.