Diese Seite wurde von der Cloud Translation API übersetzt.

Upgrade von Apigee Hybrid auf Version 1.15 ausführen

Dieses Verfahren behandelt das Upgrade von der Apigee Hybrid-Version 1.14.x auf die Apigee Hybrid-Version 1.15.0.

Änderungen von Apigee Hybrid v1.14

Bitte beachten Sie die folgende Änderung:

Unterstützung großer Nachrichtennutzlasten:Ab Version 1.15 und auch im Patch-Release 1.14.2 unterstützt Apigee jetzt Nachrichtennutzlasten mit einer Größe von bis zu 30 MB. Weitere Informationen finden Sie unter:
- Unterstützung für große Nutzlasten in Apigee Hybrid konfigurieren
- runtime.resources.limits.memory in der Referenz zu Konfigurationsattributen.
- runtime.resources.requests.memory in der Referenz zu Konfigurationsattributen.
Strengere Prüfungen der Klasseninstanziierung: In Apigee Hybrid enthält die JavaCallout-Richtlinie jetzt zusätzliche Sicherheitsmaßnahmen bei der Instanziierung von Java-Klassen. Die verbesserte Sicherheitsmaßnahme verhindert die Bereitstellung von Richtlinien, mit denen direkt oder indirekt versucht wird, Aktionen auszuführen, für die nicht zulässige Berechtigungen erforderlich sind.
In den meisten Fällen funktionieren vorhandene Richtlinien weiterhin wie erwartet. Es besteht jedoch die Möglichkeit, dass Richtlinien, die auf Drittanbieterbibliotheken basieren oder benutzerdefinierten Code enthalten, der indirekt Vorgänge auslöst, für die erhöhte Berechtigungen erforderlich sind, betroffen sind.

Wichtig:Diese Änderung wurde in Version 1.14.1 eingeführt. Wenn Sie ein Upgrade von Version 1.14.0 oder früher durchführen, folgen Sie der Anleitung unter Richtlinien nach dem Upgrade von Version 1.14.0 oder früher validieren, um das Richtlinienverhalten zu validieren.

Weitere Informationen zu den Funktionen in Hybrid-Version 1.14 finden Sie in den Versionshinweisen zu Apigee Hybrid v1.14.0.

Vorbereitung

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

Wenn in Ihrer Hybrid-Installation eine Version vor Version 1.14 ausgeführt wird, müssen Sie vor dem Upgrade auf Version 1.15 ein Upgrade auf Version 1.14 ausführen. Weitere Informationen finden Sie unter Upgrade von Apigee Hybrid auf Version 1.14 ausführen.
Helm-Version Version 3.14.2 und höher
kubectl: Eine unterstützte Version von kubectl, die für Ihre Kubernetes-Plattformversion geeignet ist. Weitere Informationen finden Sie unter Unterstützte Plattformen und Versionen: kubectl.
cert-manager: Eine unterstützte Version von cert-manager. Weitere Informationen finden Sie unter Unterstützte Plattformen und Versionen: cert-manager. Bei Bedarf führen Sie im Abschnitt Upgrade auf Version 1.15 vorbereiten unten ein Upgrade von cert-manager durch.

Bevor Sie auf Version 1.15.0 aktualisieren – Einschränkungen und wichtige Hinweise

In Apigee Hybrid 1.15.0 wird ein neues, erweitertes Proxy-Limit pro Umgebung eingeführt, mit dem Sie mehr Proxys und freigegebene Abläufe in einer einzelnen Umgebung bereitstellen können. Unter Limits: API-Proxys finden Sie Informationen zu den Beschränkungen für die Anzahl der Proxys und freigegebenen Abläufe, die Sie pro Umgebung bereitstellen können. Diese Funktion ist nur für neu erstellte Hybridorganisationen verfügbar und kann nicht auf aktualisierte Organisationen angewendet werden. Wenn Sie diese Funktion verwenden möchten, führen Sie eine Neuinstallation von Hybrid 1.15.0 durch und erstellen Sie eine neue Organisation.

Diese Funktion ist ausschließlich im Rahmen des Abos für 2024 verfügbar und unterliegt den Berechtigungen, die im Rahmen dieses Abos gewährt werden. Weitere Informationen zu dieser Funktion finden Sie unter Erweiterte Proxy-Limits pro Umgebung.
Das Upgrade auf Apigee Hybrid-Version 1.15 erfordert möglicherweise Ausfallzeiten.

Beim Upgrade des Apigee-Controllers auf Version 1.15.0 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 funktioniert die Cassandra-Sicherung und -Wiederherstellung jedoch nicht mit gemischten Versionen. Beispielsweise kann eine Sicherung von Hybrid 1.14 nicht zum Wiederherstellen einer Hybrid 1.15-Instanz verwendet werden.
Änderungen an der Verwaltungsebene müssen während eines Upgrades nicht vollständig angehalten werden. Alle erforderlichen vorübergehenden Änderungen an der Verwaltungsebene sind unten in der Upgradeanleitung aufgeführt.

Upgrade auf Version 1.15.0 – Übersicht

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

Bereiten Sie das Upgrade vor..
Installieren Sie die Hybrid-Laufzeitversion 1.15.0.

Upgrade auf Version 1.15 vorbereiten

Hybridinstallation 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.14. 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.14-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Sichern Sie Ihre Cassandra-Datenbank entsprechend der Anleitung unter Cassandra-Sicherung und -Wiederherstellung.
Wichtig:Ab Version 1.14 enthalten Schutzmaßnahmen die folgenden sicherungsbezogenen Prüfungen, die während des Apigee Hybrid-Upgrades erzwungen werden.
1. Das Back-up muss aktiviert sein, damit bei Bedarf eine Wiederherstellung auf die vorherige Version möglich ist.
2. Wenn die CSI-Sicherung aktiviert ist, muss innerhalb der letzten 24 Stunden vor dem Upgrade eine Sicherung erstellt werden. So wird das Risiko eines potenziellen Datenverlusts minimiert, wenn eine Wiederherstellung der vorherigen Version erforderlich ist.
Weitere Informationen zu den Prüfungen der Schutzmaßnahmen finden Sie unter Schutzmaßnahmen.

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 Federation for GKE 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.14 als auch von Hybrid 1.15 unterstützt wird. Weitere Informationen finden Sie in der Dokumentation der Plattform.

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

Unterstützte Versionen

	1.13	1,14	1,15
GKE auf Google Cloud	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x
GKE on AWS	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x	1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x	1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x 1.32.x
GKE on Azure	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x	1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x	1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x 1.32.x
Google Distributed Cloud (nur Software) auf VMware ⁽⁵⁾	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x	1.28.x⁽⁴⁾ 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x
Google Distributed Cloud (nur Software) auf Bare Metal	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x	1.28.x⁽⁴⁾ 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x
EKS	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x
AKS	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x
OpenShift⁽⁹⁾	4.12 4.13 4.14 4.15 4.16	4.13 4.14 4.15 4.16 4.17	4.16 4.17 4.18
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x	v1.27.x 1.28.x 1.29.x 1.30.x 1.31.x	v1.28.x 1.29.x 1.30.x 1.31.x 1.32.x
VMware Tanzu	v1.26.x	v1.26.x	v1.26.x
Komponenten	1.13	1,14	1,15
Cloud Service Mesh	1.19.x⁽³⁾	1.22.x⁽³⁾	1.22.x⁽³⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.15.x⁽¹⁰⁾ 1.16.x⁽¹⁰⁾ 1.17.x⁽¹⁰⁾	1.15.x⁽¹⁰⁾ 1.16.x⁽¹⁰⁾ 1.17.x⁽¹⁰⁾	1.16.x⁽¹⁰⁾ 1.17.x⁽¹⁰⁾
Cassandra	4,0	4,0	4.0
Kubernetes	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x
kubectl	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x
Helm	3.14.2+	3.14.2+	3.14.2+
Secret Store CSI driver	1.4.6+	1.4.6+	1.4.6+
Vault	1.15.2	1.17.2	1.17.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 ⁽²⁾ Die offiziellen EOL-Daten für Apigee Hybrid-Versionen 1.12 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. ⁽³⁾ Cloud Service Mesh wird automatisch mit Apigee Hybrid 1.9 und höher installiert. ⁽⁴⁾ 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. ⁽⁹⁾ Apigee Hybrid wird auf OpenShift mit der Kubernetes-Version getestet und zertifiziert, die in jeder spezifischen OCP-Version enthalten ist. ⁽¹⁰⁾ Bei einigen Versionen von cert-manager kann es vorkommen, dass das CA-Zertifikat des Webhook-TLS-Servers nicht automatisch verlängert wird. Um dies zu vermeiden, empfiehlt Apigee Folgendes: Hybrid v1.13:Verwenden Sie cert-manager-Version 1.15.5+. Hybrid v1.14:Verwenden Sie Cert Manager-Versionen 1.15.5+ oder 1.16.3+. Hybrid v1.15:Verwenden Sie cert-manager-Versionen 1.16.3+ oder 1.17.2+.

Nicht unterstützte Versionen

	1.6 ⁽²⁾	1.7 ⁽²⁾	1.8 ⁽²⁾	1.9 ⁽²⁾	1.10 ⁽²⁾	1.11 ⁽²⁾	1.12 ⁽²⁾
GKE auf Google Cloud	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.21.x ^{(≤ 1.8.3)} 1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
GKE on AWS	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x (K8s v1.23.x) 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	1.12.x 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
GKE on Azure	1.8.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
Google Distributed Cloud (nur Software) auf VMware ⁽⁵⁾	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x 1.15.x (K8s v1.26.x)	1.12.x 1.13.x 1.14.x 1.15.x (K8s v1.26.x)	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)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)(8)}
Google Distributed Cloud (nur Software) auf Bare Metal	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x 1.10.x 1.11.x ^{(≥ 1.7.2)} 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.12.x 1.13.x 1.14.x 1.15.x	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)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)(8)}
EKS	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
AKS	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
OpenShift⁽⁹⁾	4.6 4.7 4.8	4.7 4.8	4.8 4.9 4.10	4.10 4.11	4.11 4.12 4.14^{(≥ 1.10.5)(6)} 4.15^{(≥ 1.10.5)(6)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)(7)} 4.16^{(≥ 1.11.2)(7)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)(8)}
Rancher Kubernetes Engine (RKE)	–	–	–	1.3.8	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
VMware Tanzu	–	–	–	–	–	–	v1.26.x
Komponenten	1.6 ⁽²⁾	1.7 ⁽²⁾	1.8 ⁽²⁾	1.9 ⁽²⁾	1.10 ⁽²⁾	1.11 ⁽²⁾	1.12 ⁽²⁾
Cloud Service Mesh	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x ^{(≥ 1.7.2)} 1.14.x 1.15.x ^{(≥ 1.7.6)}	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x⁽³⁾	1.17.x⁽³⁾	1.17.x^{(v1.11.0 - v1.11.1)}⁽³⁾ 1.18.x^{(≥ 1.11.2)(7)}⁽³⁾	1.18.x⁽³⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	1.10.x 1.11.x	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	3.11	3.11	3.11	3.11	4.0
Kubernetes				1.23.x 1.24.x 1.25.x	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 1.29.x
kubectl					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 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 ⁽²⁾ Die offiziellen EOL-Daten für Apigee Hybrid-Versionen 1.12 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. ⁽³⁾ Cloud Service Mesh wird automatisch mit Apigee Hybrid 1.9 und höher installiert. ⁽⁴⁾ 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. ⁽⁹⁾ Apigee Hybrid wird auf OpenShift mit der Kubernetes-Version getestet und zertifiziert, die in jeder spezifischen OCP-Version enthalten ist. ⁽¹⁰⁾ Bei einigen Versionen von cert-manager kann es vorkommen, dass das CA-Zertifikat des Webhook-TLS-Servers nicht automatisch verlängert wird. Um dies zu vermeiden, empfiehlt Apigee Folgendes: Hybrid v1.13:Verwenden Sie cert-manager-Version 1.15.5+. Hybrid v1.14:Verwenden Sie Cert Manager-Versionen 1.15.5+ oder 1.16.3+. Hybrid v1.15:Verwenden Sie cert-manager-Versionen 1.16.3+ oder 1.17.2+.

Istio-CRDs entfernen

Das Vorhandensein von istio.io-Custom Resource Definitions (CRDs) in einem Apigee Hybrid-Cluster kann zu Fehlern in apigee-ingressgateway-manager-Pods führen.

Weitere Informationen zu istio.io-CRDs in Apigee Hybrid finden Sie unter Bekanntes Problem 416634326.

Mit dem folgenden Befehl können Sie ermitteln, ob Sie istio.io-CRDs in Ihrem Cluster haben:

kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io

Ihre Ausgabe sieht in etwa so aus, wenn Ihr Cluster istio.io CRDs hat:

kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io
  authorizationpolicies.security.istio.io
  destinationrules.networking.istio.io
  envoyfilters.networking.istio.io
  gateways.networking.istio.io
  peerauthentications.security.istio.io
  proxyconfigs.networking.istio.io
  requestauthentications.security.istio.io
  serviceentries.networking.istio.io
  sidecars.networking.istio.io
  telemetries.telemetry.istio.io
  virtualservices.networking.istio.io
  wasmplugins.extensions.istio.io
  workloadentries.networking.istio.io
  workloadgroups.networking.istio.io

Optional: Speichern Sie die CRDs lokal, falls Sie sie neu erstellen müssen:
```
kubectl get crd $(cat istio-crd.csv) -o yaml > istio-crd.yaml
```
Hinweis:Wenn Sie Istio in Ihrem Cluster für andere Zwecke als Apigee verwenden, müssen Sie die Version 1.22.7-asm.4-distroless verwenden.
Löschen Sie die istio.io-CRDs:
Probelauf:
```
kubectl delete crd $(cat istio-crd.csv) --dry-run=client
```
Tipp:Sie können entweder --dry-run=client oder --dry-run=server verwenden. Weitere Informationen finden Sie unter kubectl delete-Optionen.

Ausführen:
```
kubectl delete crd $(cat istio-crd.csv)
```

Listen Sie die ingress-manager-Pods auf, die neu installiert oder erstellt werden sollen:

kubectl get deployments -n apigee

Beispielausgabe:

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager       1/1     1            1           32d
apigee-ingressgateway-manager   2/2     2            2           32d

Starten Sie die ingress-manager-Pods neu:

kubectl rollout restart deployment -n APIGEE_NAMESPACE apigee-ingressgateway-manager

Hybrid 1.15.0-Laufzeit installieren

Pipeline zur Datenerfassung konfigurieren

Ab Hybrid v1.14 ist die neue Pipeline für Analyse- und Debugging-Daten standardmäßig für alle Apigee Hybrid-Organisationen aktiviert. Sie müssen die Schritte unter Publisher-Zugriff auf Analytics aktivieren ausführen, um den Autorisierungsablauf zu konfigurieren.

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.15.0
helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar

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.17.2/cert-manager.yaml
```
Eine Liste der unterstützten Versionen finden Sie unter Unterstützte Plattformen und Versionen: cert-manager.

Hinweis:Bei einigen Versionen von cert-manager kann es vorkommen, dass das CA-Zertifikat des Webhook-TLS-Servers nicht automatisch verlängert wird. Um dies zu vermeiden, empfiehlt Apigee die Verwendung von Cert Manager-Versionen 1.16.3+ oder 1.17.2+.
Wenn Ihr Apigee-Namespace nicht apigee ist, bearbeiten Sie die apigee-operator/etc/crds/default/kustomization.yaml-Datei und ersetzen Sie den namespace-Wert durch Ihren Apigee-Namespace.
```
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: APIGEE_NAMESPACE
```
Wenn Sie apigee als Namespace verwenden, müssen Sie die Datei nicht bearbeiten.

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=server

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                    2024-08-21T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2024-08-21T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2024-08-21T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2024-08-21T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2024-08-21T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2024-08-21T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2024-08-21T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2024-08-21T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2024-08-21T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2024-08-21T14: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 \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Aktualisieren Sie das Diagramm:

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

Prüfen Sie die Installation des Apigee-Operators:

helm ls -n APIGEE_NAMESPACE

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee   3          2024-08-21 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.15.0   1.15.0

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

kubectl -n APIGEE_NAMESPACE 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=server

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_NAMESPACE 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=server

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_NAMESPACE 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=server

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_NAMESPACE 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=server

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_NAMESPACE 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=server
```
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_NAMESPACE get apigeeorg
```
```
NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d
```
Hinweis: Wenn der Upgrade-Befehl mit dem Fehler Forbidden: state: releasing fehlschlägt, haben die vorhandenen Komponenten noch den Status „Wird veröffentlicht“. Sie können warten, bis das aktuelle Update abgeschlossen ist, und es dann noch einmal versuchen. Prüfen Sie den Release-Status mit dem folgenden Befehl:
```
kubectl get org -n APIGEE_NAMESPACE
```
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=server
```
- ENV_RELEASE_NAME ist ein Name, der verwendet wird, um Installationen und Upgrades des Diagramms apigee-env nachzuverfolgen. Dieser Name muss sich von den anderen Helm-Releasenamen in Ihrer Installation unterscheiden. Normalerweise entspricht dies ENV_NAME. Wenn Ihre Umgebung jedoch denselben Namen wie Ihre Umgebungsgruppe hat, müssen Sie unterschiedliche Release-Namen für die Umgebung und die Umgebungsgruppe verwenden, z. B. dev-env-release und dev-envgroup-release. Weitere Informationen zu Releases in Helm finden Sie in der Helm-Dokumentation unter Three big concepts class="external".
- ENV_NAME ist der Name der Umgebung, die Sie aktualisieren.
- OVERRIDES_FILE ist die neue Überschreibungsdatei für Version 1.15.0.
Aktualisieren Sie das Diagramm:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Prüfen Sie, ob sie aktiv ist, indem Sie den Status der entsprechenden Umgebung prüfen:
```
kubectl -n APIGEE_NAMESPACE get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```

Hinweis: Wenn der Upgrade-Befehl mit dem Fehler Forbidden: state: releasing fehlschlägt, haben die vorhandenen Komponenten noch den Status „Wird veröffentlicht“. Sie können warten, bis das aktuelle Update abgeschlossen ist, und es dann noch einmal versuchen. Prüfen Sie den Release-Status mit dem folgenden Befehl:

kubectl get env -n APIGEE_NAMESPACE

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=server
```
  ENV_GROUP_RELEASE_NAME ist der Name, mit dem Sie zuvor das Diagramm apigee-virtualhost installiert haben. Normalerweise ist es 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: 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 den Wert von ENV_GROUP_RELEASE_NAME auf 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_NAMESPACE get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n APIGEE_NAMESPACE get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```
Nachdem Sie überprüft haben, dass alle Installationen erfolgreich aktualisiert wurden, löschen Sie die ältere apigee-operator-Version aus dem apigee-system-Namespace.
1. Deinstallieren Sie den alten operator-Release:
```
helm delete operator -n apigee-system
```
2. Löschen Sie den Namespace apigee-system:
```
kubectl delete namespace apigee-system
```
Führen Sie noch einmal ein Upgrade von operator in Ihrem Apigee-Namespace durch, um die gelöschten Ressourcen mit Clusterbereich neu zu installieren:
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml
```

Richtlinien nach dem Upgrade von Version 1.14.0 oder früher validieren

Mit diesem Verfahren können Sie das Verhalten der JavaCallout-Richtlinie nach dem Upgrade von Version 1.14.0 validieren.

Prüfen, ob die Java-JAR-Dateien unnötige Berechtigungen anfordern
Prüfen Sie nach der Bereitstellung der Richtlinie die Laufzeitlogs, um festzustellen, ob die folgende Logmeldung vorhanden ist: "Failed to load and initialize class ...". Wenn Sie diese Meldung sehen, bedeutet das, dass für das bereitgestellte JAR unnötige Berechtigungen angefordert wurden. Um dieses Problem zu beheben, untersuchen Sie den Java-Code und aktualisieren Sie die JAR-Datei.
Java-Code untersuchen und aktualisieren
Überprüfen Sie den Java-Code (einschließlich der Abhängigkeiten), um die Ursache für möglicherweise unzulässige Vorgänge zu ermitteln. Ändern Sie den Quellcode bei Bedarf.
Richtlinien mit aktiviertem Sicherheitscheck testen:
Aktivieren Sie in einer nicht produktiven Umgebung das Flag für die Sicherheitsprüfung und stellen Sie Ihre Richtlinien mit einem aktualisierten JAR noch einmal bereit. So legen Sie das Flag fest:
- Legen Sie in der Datei apigee-env/values.yaml unter runtime:cwcAppend: den Wert conf_security-secure.constructor.only auf true fest. Beispiel:
```
# Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
```
- Aktualisieren Sie das apigee-env-Diagramm für die Umgebung, um die Änderung anzuwenden. Beispiel:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Wenn die Log-Meldung "Failed to load and initialize class ..." weiterhin vorhanden ist, ändern und testen Sie das JAR so lange, bis die Log-Meldung nicht mehr angezeigt wird.
Sicherheitscheck in der Produktionsumgebung aktivieren
Nachdem Sie die JAR-Datei in der Nicht-Produktionsumgebung gründlich getestet und geprüft haben, aktivieren Sie die Sicherheitsprüfung in Ihrer Produktionsumgebung, indem Sie das Flag conf_security-secure.constructor.only auf true setzen und das apigee-env-Diagramm für die Produktionsumgebung aktualisieren, um die Änderung zu übernehmen.

Rollback zu einer vorherigen Version durchführen

Wenn Sie ein Rollback auf die vorherige Version durchführen möchten, verwenden Sie die ältere Diagrammversion, um den Upgradeprozess in umgekehrter Reihenfolge zurückzusetzen. Beginnen Sie mit apigee-virtualhost und arbeiten Sie sich zurück zu apigee-operator. Setzen Sie dann die CRDs wieder auf den vorherigen Zustand zurück.

Tipp:Wenn Sie die letzte Releaseversion kennen, können Sie den helm rollback-Befehl anstelle des unten beschriebenen helm upgrade-Befehls verwenden.

Setzen Sie alle Diagramme von apigee-virtualhost bis apigee-datastore auf die Standardeinstellungen zurück. Bei den folgenden Befehlen wird davon ausgegangen, dass Sie die Diagramme aus der vorherigen Version (v1.14.x) verwenden.

Führen Sie den folgenden Befehl für jede Umgebungsgruppe aus:

helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f 1.14_OVERRIDES_FILE

Führen Sie den folgenden Befehl für jede Umgebung aus:

helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f 1.14_OVERRIDES_FILE

Setzen Sie die restlichen Diagramme mit Ausnahme von apigee-operator auf die Standardeinstellungen zurück.

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade redis apigee-redis/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

Erstellen Sie den Namespace apigee-system.
```
kubectl create namespace apigee-system
```

Patchen Sie die Ressourcenannotation zurück auf den Namespace apigee-system.

kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-namespace='apigee-system'

Wenn Sie auch den Release-Namen geändert haben, aktualisieren Sie die Annotation mit dem Release-Namen operator.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='operator'
```

Installieren Sie apigee-operator wieder im Namespace apigee-system.

helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.14_OVERRIDES_FILE

Machen Sie die CRDs rückgängig, indem Sie die älteren CRDs neu installieren.

kubectl apply -k apigee-operator/etc/crds/default/ \
  --server-side \
  --force-conflicts \
  --validate=false

Bereinigen Sie die apigee-operator-Version aus dem APIGEE_NAMESPACE-Namespace, um das Rollback abzuschließen.
```
helm uninstall operator -n APIGEE_NAMESPACE
```
Einige Ressourcen auf Clusterebene, z. B. clusterIssuer, werden gelöscht, wenn operator deinstalliert wird. Installieren Sie sie mit dem folgenden Befehl neu:
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.14_OVERRIDES_FILE
```

Upgrade von Apigee Hybrid auf Version 1.15 ausführen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Änderungen von Apigee Hybrid v1.14

Vorbereitung

Bevor Sie auf Version 1.15.0 aktualisieren – Einschränkungen und wichtige Hinweise

Upgrade auf Version 1.15.0 – Übersicht

Upgrade auf Version 1.15 vorbereiten

Hybridinstallation sichern

Linux

Mac OS

Windows

Prod

Non-prod

Aktualisieren Sie Ihre Kubernetes-Version

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

Unterstützte Versionen

Komponenten

Nicht unterstützte Versionen

Komponenten

Istio-CRDs entfernen

Hybrid 1.15.0-Laufzeit installieren

Pipeline zur Datenerfassung konfigurieren

Upgrade auf Helm-Diagramme vorbereiten

Apigee Hybrid-Helm-Diagramme installieren

Richtlinien nach dem Upgrade von Version 1.14.0 oder früher validieren

Rollback zu einer vorherigen Version durchführen

Upgrade von Apigee Hybrid auf Version 1.15 ausführen