Diese Seite wurde von der Cloud Translation API übersetzt.

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

Ä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:

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.
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.
Aktualisieren Sie die neu hinzugefügte Region auf Hybrid 1.12.
Leiten Sie den Traffic in die neue Region um und validieren Sie den Traffic.
Führen Sie nach der Validierung ein Upgrade der älteren Region mit Hybrid 1.12 durch.
Sie wechseln mit dem gesamten Traffic zurück zur älteren Region und validieren den Traffic.
Außerbetriebnahme der neuen Region.

Überlegungen vor dem Upgrade einer multiregionalen Installation

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

Sichern und validieren Sie Daten aus jeder Region, bevor Sie mit dem Upgrade beginnen.
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.
Überprüfen Sie den Traffic in der neu aktualisierten Region.
Führen Sie erst nach der Validierung des Traffics in der vorherigen Region ein Upgrade für jede nachfolgende Region durch.
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.14.2 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.3 – Übersicht

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

Beim Upgrade des Apigee-Controllers auf Version 1.12.3 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.

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

Bereiten Sie das Upgrade vor..
- Cassandra-Sicherung.
- Sichern Sie die Hybrid-Installationsverzeichnisse.
Installieren Sie die Hybrid-Laufzeitversion 1.12.3.

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:

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

. . .

Einen Pod löschen:

kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

Beispiel:

kubectl delete pod -n apigee apigee-cassandra-default-0

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:

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

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

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%
```
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
```
Sichern Sie Ihre Cassandra-Datenbank entsprechend der Anleitung unter Cassandra-Sicherung und -Wiederherstellung.

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/`

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 ⁽³⁾	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⁽¹²⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x (K8s v1.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 Azure	1.13.x 1.14.x 1.26.x⁽¹²⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.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)}
Google Distributed Cloud (nur Software) on VMware ⁽¹⁾ ⁽¹³⁾	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⁽¹²⁾ 1.29.x^{(≥ 1.12.1)}
Google Distributed Cloud (nur Software) auf Bare Metal ⁽¹⁾	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⁽¹²⁾^{(≥ 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⁽¹²⁾ 1.29.x^{(≥ 1.12.1)}
EKS⁽⁷⁾	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⁽⁷⁾	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⁽⁷⁾	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⁽¹⁰⁾	1.18.x⁽¹⁰⁾	1.19.x⁽¹⁰⁾
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
⁽¹⁾ 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 ⁽²⁾ Support ab Apigee Hybrid-Version 1.7.2 und höher verfügbar.. ⁽³⁾ 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. ⁽⁴⁾ 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. ⁽⁵⁾ 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. ⁽⁶⁾ Support ab Apigee Hybrid-Version 1.8.4 verfügbar. ⁽⁷⁾ Wird ab Apigee Hybrid-Version 1.8.4 nicht mehr unterstützt. ⁽⁸⁾ Support ab Apigee Hybrid-Version 1.7.6 verfügbar. ⁽⁹⁾ Wird ab Apigee Hybrid-Version 1.8.5 nicht mehr unterstützt. ⁽¹⁰⁾ Anthos Service Mesh wird automatisch mit Apigee Hybrid 1.9 und höher installiert. ⁽¹¹⁾ Support ab Apigee Hybrid-Version 1.9.2 verfügbar. ⁽¹²⁾ 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. ⁽¹³⁾ Vault ist in Google Distributed Cloud for VMware nicht zertifiziert. ⁽¹⁴⁾ Support ab Apigee Hybrid-Version 1.10.5 verfügbar. ⁽¹⁵⁾ Support ab Apigee Hybrid-Version 1.11.2 verfügbar. ⁽¹⁶⁾ 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.

Hybrid 1.12.3-Laufzeit installieren

Upgrade auf Helm-Diagramme vorbereiten

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

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

Installieren Sie die aktualisierten Apigee-CRDs:

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.

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

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

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

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.

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.

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

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

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

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

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

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

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

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

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

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 beschrieben, wie Sie alle Apigee Hybrid-Komponenten außer apigee-datastore von Version 1.12 auf Version 1.11 zurücksetzen. 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:

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

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

Führen Sie die folgenden Befehle aus, um alle Komponenten außer apigee-datastore rückgängig zu machen:

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

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

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

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

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

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

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

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

Prüfen Sie, ob alle Pods ausgeführt werden oder abgeschlossen sind:

kubectl get pods -n APIGEE_NAMESPACE

kubectl get pods -n apigee-system

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 aus einer Sicherung wiederherstellen, die von einer Version 1.11-Installation erstellt wurde. Mit der folgenden Sequenz können Sie die vorherige Version wiederherstellen.

Wenn Sie keine aktive Installation von 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.
Wiederherstellen Sie die Region der Version 1.11 (oder eine neue Installation) aus der Sicherung. Folgen Sie dazu der Anleitung unter:
- CSI-Sicherungen (Cloud Storage Interface): Cassandra-CSI-Sicherung und -Wiederherstellung.
- Nicht-CSI-Sicherungen: In einer einzelnen Region wiederherstellen.
Traffic zur wiederhergestellten Installation prüfen
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

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

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

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

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.

Wechseln Sie in das Verzeichnis, in dem die vorherigen Apigee Hybrid-Helm-Diagramme installiert sind.
Ändern Sie den Kontext in die Region, die aktualisiert wurde.
```
kubectl config use-context UPGRADED_REGION_CONTEXT
    
```

Prüfen Sie, ob alle Pods ausgeführt werden:

kubectl get pods -n APIGEE_NAMESPACE

kubectl get pods -n apigee-system

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

Führen Sie die folgenden Befehle aus, um alle Komponenten außer apigee-datastore rückgängig zu machen:

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

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

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

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

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

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

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

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

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:

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.
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.
Bereinigen Sie die fehlgeschlagene Region. Folgen Sie dazu der Anleitung unter Region nach einem fehlgeschlagenen Upgrade wiederherstellen.
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 aus einer Sicherung wiederherstellen, die von einer Version 1.11-Installation erstellt wurde. Mit der folgenden Sequenz können Sie die vorherige Version wiederherstellen.

Wenn Sie keine aktive Installation von 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.
Wiederherstellen Sie die Region der Version 1.11 (oder eine neue Installation) aus der Sicherung. Folgen Sie dazu der Anleitung unter:
- CSI-Sicherungen (Cloud Storage Interface): Cassandra-CSI-Sicherung und -Wiederherstellung.
- Nicht-CSI-Sicherungen: In mehreren Regionen wiederherstellen.
Traffic zur wiederhergestellten Installation prüfen
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.
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.

Validieren Sie den Status des Cassandra-Clusters aus einer Live-Region:

Legen Sie den kubectl-Kontext auf die Region fest, die entfernt werden soll:
```
kubectl config use-context CONTEXT_OF_LIVE_REGION
```

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

Führen Sie einen der Cassandra-Pods aus:

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

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

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]

Bereinigen Sie die Replikation des Cassandra-Schlüsselbereichs:

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

Validieren Sie die Replikationseinstellungen des Cassandra-Schlüsselbereichs, indem Sie einen Client-Container erstellen. Folgen Sie dazu der Anleitung unter Client-Container erstellen.

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)

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'};

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.

Führen Sie einen der Cassandra-Pods aus:

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Prüfen Sie den Status des Cassandra-Clusters:

nodetool -u JMX_USER -pw JMX_PASSWORD status

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

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

Nachdem der Verweis entfernt wurde, beenden Sie den Pod. Der neue Cassandra-Pod sollte dem Cluster beitreten.
```
kubectl delete pod -n POD_NAME
```

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.

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.

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

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

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

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

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

Prüfen Sie, ob alle Pods Running sind und der Cassandra-Cluster wieder fehlerfrei ist.

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

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

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.

Upgrade von Apigee Hybrid auf Version 1.12 ausführen

Änderungen von Apigee Hybrid v1.11

Überlegungen vor dem Start eines Upgrades auf Version 1.12

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

Überlegungen vor dem Upgrade einer multiregionalen Installation

Vorbereitung

Beschränkungen

Upgrade auf Version 1.12.3 – Übersicht

Upgrade auf Version 1.12 vorbereiten

Cassandra sichern

Hybrid-Installationsverzeichnisse sichern

Linux

Mac OS

Windows

Prod

Non-prod

Aktualisieren Sie Ihre Kubernetes-Version

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

Komponenten

Angehängte Cluster

Hybrid 1.12.3-Laufzeit installieren

Upgrade auf Helm-Diagramme vorbereiten

Apigee Hybrid-Helm-Diagramme installieren

Rollback zu einer vorherigen Version durchführen

Rollback und Wiederherstellung für eine einzelne Region

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

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

Multiregionales Rollback und Wiederherstellung

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

Multiregionale Installation auf eine vorherige Version wiederherstellen

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

ANHANG: Region nach einem fehlgeschlagenen Upgrade wiederherstellen

APPENDIX: DOWN-Knoten aus dem Cassandra-Cluster entfernen

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

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

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

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

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

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