Upgrade von Apigee Hybrid auf Version 1.11 ausführen

Dieses Verfahren behandelt das Upgrade von der Apigee Hybrid-Version 1.10.x auf die Apigee Hybrid-Version 1.11.2 und von früheren Releases der Hybrid-Version 1.11.x auf Version 1.11.2.

Verwenden Sie dieselben Verfahren für Upgrades von Nebenversionen (z. B. Version 1.9 auf 1.10) und Patch-Upgrades (z. B. 1.10.0 auf 1.11.2).

Wenn Sie ein Upgrade von Apigee Hybrid-Version 1.9 oder älter ausführen, ist zuerst ein Upgrade auf die Hybrid-Version 1.10 erforderlich, bevor Sie auf Version 1.11.2 aktualisieren. Weitere Informationen finden Sie in der Anleitung unter Upgrade von Apigee Hybrid auf Version 1.10 ausführen.

Upgrade auf Version 1.11.2 – Übersicht

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

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

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

Die Cassandra-Sicherung und -Wiederherstellung funktioniert nicht mit gemischten Versionen. Beispielsweise kann eine Sicherung von Hybrid 1.10 nicht zum Wiederherstellen einer Hybrid 1.11-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..
Installieren Sie die Hybrid-Laufzeitversion 1.11.2

Vorbereitung

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

Helm-Diagramme und `apigeectl`

In Version 1.11 können Sie Apigee Hybrid entweder mit Helm-Diagrammen oder mit apigeectl installieren und verwalten. Apigee empfiehlt die Verwendung von Helm zur Verwaltung der Installation.

Von v1.10 mit `apigeectl` zu Helm v1.11 migrieren

So führen Sie ein Upgrade auf Apigee Hybrid v1.11, das von Helm verwaltet wird, über eine mit apigeectl verwaltete Hybrid-Version 1.10 durch:

Migrieren Sie zuerst Ihre Helm v1.10. Folgen Sie dazu der Anleitung unter Apigee Hybrid zu Helm-Diagrammen von apigeectl migrieren.
Folgen Sie der Anleitung für Helm-Diagramme unten, um ein Upgrade Ihrer Installation durchzuführen.
Hinweis: Beim Upgrade einer migrierten Installation müssen Sie ein --force-Flag in die helm upgrade-Befehle einfügen.

Upgrade auf Version 1.11 vorbereiten

Hybridinstallation sichern (empfohlen)

Helm

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

`apigeectl`

In den Beispielen in dieser Anleitung wird die folgende Verzeichnisstruktur verwendet. Ihre Installation kann abweichen. Passen Sie die Anleitung an die Struktur Ihrer Installation an.

hybrid-v1.11-root-directory/
└── apigeectl/
    └── config/
    └── plugins/
    └── templates/
    └── tools/
└── hybrid-files/
    └── overrides/
    └── service-accounts/
    └── certs/
hybrid-v1.10-root-directory/

In dieser Anleitung wird die Umgebungsvariable APIGEECTL_HOME für das Verzeichnis in Ihrem Dateisystem verwendet, in dem Sie apigeectl installiert haben. Wechseln Sie bei Bedarf in das Verzeichnis apigeectl und definieren Sie die Variable mit dem folgenden Befehl:
Linux
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```
Erstellen Sie eine Sicherungskopie Ihres $APIGEECTL_HOME/-Verzeichnisses der Version 1.10. Beispiel:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.10-backup.tar.gz $APIGEECTL_HOME
```
Sichern Sie Ihre Cassandra-Datenbank entsprechend der Anleitung unter Cassandra-Sicherung und -Wiederherstellung.

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.11 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) auf 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)}
	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)}
	–	–	v1.26.x
Komponenten	1.10	1.11	1.12
Anthos 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. ⁽⁵⁾Google Distributed Cloud auf Bare Metal oder VMware erfordert Anthos Service Mesh 1.14 oder höher. Wir empfehlen ein Upgrade auf die Hybrid-Version 1.8 und einen Wechsel zum Apigee Ingress Gateway, für das Sie Anthos 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 für 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 Anthos Service Mesh messen.

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

Hybrid 1.11.2-Laufzeit installieren

Helm

Upgrade auf Helm-Diagramme vorbereiten

Nehmen Sie die folgende Änderung an der Datei overrides.yaml vor, damit die Diagramme apigee-operator und apigee-env das richtige Tag 1.11.2-hotfix.2 verwenden:
```
ao:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-operators"
    tag: "1.11.2-hotfix.2"
runtime:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-runtime"
    tag: "1.11.2-hotfix.2"
```
Weitere Informationen finden Sie in den Versionshinweisen zu Apigee 1.11.2-hotfix.2.

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

Installieren Sie gegebenenfalls 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.11.1/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=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                    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.11.2   1.11.2

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

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Aktualisieren Sie den Apigee-Datenspeicher:

Probelauf:

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

Aktualisieren Sie das Diagramm:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  -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 \
  -f OVERRIDES_FILE \
  --dry-run

Aktualisieren Sie das Diagramm:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  -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 \
  -f OVERRIDES_FILE \
  --dry-run

Aktualisieren Sie das Diagramm:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace apigee \
  -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 \
  -f OVERRIDES_FILE \
  --dry-run

Aktualisieren Sie das Diagramm:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  -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 \
  -f OVERRIDES_FILE \
  --dry-run

Aktualisieren Sie das Diagramm:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  -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 \
  --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.11.2.
Aktualisieren Sie das Diagramm:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Hinweis:
Verwenden Sie für migrierte Installationen:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --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 \
  --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 \
  --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 \
  --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
```

`apigeectl`

Speichern Sie die aktuelle Versionsnummer mit dem folgenden Befehl in einer Variablen:

Linux

export VERSION=$(curl -s \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/current-version.txt?ignoreCache=1)

macOS

export VERSION=$(curl -s \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/current-version.txt)

Windows

for /f "tokens=*" %a in ('curl -s ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/current-version.txt') ^
do set VERSION=%a

Prüfen Sie mit dem folgenden Befehl, ob die Variable mit einer Versionsnummer ausgefüllt wurde. Wenn Sie eine andere Version verwenden möchten, können Sie diese stattdessen in einer Umgebungsvariablen speichern.
```
echo $VERSION
```
Sie sollten die neueste Apigee-Hybridversion sehen:
```
  1.11.2
```
Sie müssen das Hybrid-Basisverzeichnis geöffnet haben. Dies ist das übergeordnete Verzeichnis des Verzeichnisses, in dem sich die ausführbare Datei apigeectl befindet:
```
cd $APIGEECTL_HOME/..
```

Laden Sie das Releasepaket für Ihr Betriebssystem mit dem folgendem Befehl herunter. Wählen Sie Ihre Plattform in der folgenden Tabelle aus:

Linux

Linux 64-Bit:

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

macOS

Mac 64-Bit:

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

Windows

Windows 64-Bit:

curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/%VERSION%/apigeectl_windows_64.zip

Benennen Sie Ihr aktuelles apigeectl/-Verzeichnis in einen Backupverzeichnisnamen um. Beispiel:

Linux

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.10/

macOS

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.10/

Windows

rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.10

Extrahieren Sie die heruntergeladenen gzip-Dateiinhalte in Ihr Hybrid-Basisverzeichnis. Das Hybrid-Basisverzeichnis ist das Verzeichnis, in dem sich das umbenannte Verzeichnis apigeectl-v1.10 befindet:
Linux
```
tar xvzf filename.tar.gz -C ./
```
macOS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
Die TAR-Inhalte werden standardmäßig in einem Verzeichnis gezeigt, dessen Name die Version und Plattform enthält. Beispiel: ./apigeectl_1.11.2-xxxxxxx_linux_64. Benennen Sie dieses Verzeichnis mit dem folgenden Befehl in apigeectl um:
Linux
```
mv apigeectl_1.11.2-xxxxxxx_linux_64 apigeectl
```
macOS
```
mv apigeectl_1.11.2-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.11.2-xxxxxxx_windows_64 apigeectl
```
Wechseln Sie in das Verzeichnis apigeectl:
```
cd ./apigeectl
```
Dieses Verzeichnis ist das Basisverzeichnis apigeectl. Hier befindet sich der ausführbare Befehl apigeectl.
In dieser Anleitung wird die Umgebungsvariable $APIGEECTL_HOME für das Verzeichnis in Ihrem Dateisystem verwendet, in dem das Dienstprogramm apigeectl installiert ist. Wechseln Sie bei Bedarf in das Verzeichnis apigeectl und definieren Sie die Variable mit dem folgenden Befehl:
Linux
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
Prüfen Sie die Version von apigeectl mit dem Befehl version:
```
./apigeectl version
```
```
Version: 1.11.2
```
Erstellen Sie ein hybrid-base-directory/hybrid-files-Verzeichnis und verschieben Sie es in dieses Verzeichnis. Im Verzeichnis hybrid-files befinden sich Konfigurationsdateien wie die Überschreibungsdatei, Zertifikate und Dienstkonten. Beispiel:
Linux
```
mkdir $APIGEECTL_HOME/../hybrid-files
```
```
cd $APIGEECTL_HOME/../hybrid-files
```
macOS
```
mkdir $APIGEECTL_HOME/../hybrid-files
```
```
cd $APIGEECTL_HOME/../hybrid-files
```
Windows
```
mkdir %APIGEECTL_HOME%/../hybrid-files
```
```
cd %APIGEECTL_HOME%/../hybrid-files
```
Prüfen Sie mit dem folgenden Befehl, ob kubectl auf den richtigen Kontext eingestellt ist. Der aktuelle Kontext sollte auf den Cluster eingestellt werden, in dem Sie Apigee Hybrid aktualisieren.
```
kubectl config get-contexts | grep \*
```
Im Verzeichnis hybrid-files:
1. Aktualisieren Sie die folgenden symbolischen Links zu $APIGEECTL_HOME. Mit diesen Links können Sie den neu installierten Befehl apigeectl aus dem Verzeichnis hybrid-files ausführen:
```
ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
```
2. Prüfen Sie, ob die Symlinks ordnungsgemäß erstellt wurden. Führen Sie dazu den folgenden Befehl aus und achten Sie darauf, dass die Linkpfade auf die richtigen Speicherorte verweisen:
```
ls -l | grep ^l
```
Nehmen Sie die folgende Änderung an Ihrer overrides.yaml-Datei vor, damit der Operator und die Laufzeit das richtige Tag 1.11.2-hotfix.2 verwenden können:
```
ao:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-operators"
    tag: "1.11.2-hotfix.2"
runtime:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-runtime"
    tag: "1.11.2-hotfix.2"
```
Weitere Informationen finden Sie in den Versionshinweisen zu Apigee 1.11.2-hotfix.2.
Führen Sie eine Probelaufinitialisierung aus, um nach Fehlern zu suchen:
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
Dabei ist OVERRIDES_FILE der Name Ihrer Überschreibungsdatei, z. B. ./overrides/overrides.yaml.

Tipp: Sie können im obigen Codebeispiel OVERRIDES_FILE durch den Namen und den Pfad zur Überschreibungsdatei ersetzen. Jede Instanz auf dieser Seite wird ersetzt.
Wenn keine Fehler auftreten, initialisieren Sie Hybrid 1.11.2:
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
Hinweis: apigeectl installiert und konfiguriert das Apigee-Ingress-Gateway, wenn Sie apigeectl init ausführen.
Prüfen Sie den Initialisierungsstatus:
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
Bei Erfolg lautet die Ausgabe: All containers ready.
```
kubectl describe apigeeds -n apigee
```
Suchen Sie in der Ausgabe nach State: running.
Suchen Sie mit dem Probelauf des Befehls apply mit dem Flag --dry-run nach Fehlern:
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
Wenn keine Fehler vorhanden sind, wenden Sie die Überschreibungen an. Wählen Sie je nach Ihrer Installation die Anleitung für Produktionsumgebungen oder Nicht-Produktionsumgebungen und folgen Sie diesen.
Produktion

Aktualisieren Sie in Produktionsumgebungen jede Hybridkomponente einzeln und prüfen Sie den Status der aktualisierten Komponente, bevor Sie mit der nächsten Komponente fortfahren.
1. Sie müssen sich im Verzeichnis hybrid-files befinden.
2. Wenden Sie Ihre Überschreibungen an, um Upgrade von Cassandra durchzuführen:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
3. Abschluss prüfen:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  Tipp: Wenn check-ready fehlschlägt, können Sie mit folgendem Befehl weitere Informationen zu Ihren Pods abrufen:
  kubectl -n NAMESPACE get pods
  
  Dabei ist NAMESPACE Ihr Apigee Hybrid-Namespace.
  Fahren Sie mit dem nächsten Schritt nur fort, wenn die Pods bereit sind.
4. Wenden Sie Ihre Überschreibungen an, um Telemetriekomponenten zu aktualisieren, und prüfen Sie den Fortschritt:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
5. Richten Sie die Redis-Komponenten ein:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
6. Wenn Sie Ihre Überschreibungen an, um zu aktualisieren die Komponenten auf Organisationsebene (MART, Watcher, Apigee Connect) und prüfen Sie den Abschluss des Vorgangs:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
7. Nutzen Sie Überschreibungen, um Ihre Umgebungen zu aktualisieren. Sie haben zwei Möglichkeiten:
  - Jede Umgebung separat: Sie wenden die Überschreibungen auf eine einzelne Umgebung gleichzeitig an und prüfen den Fortschritt. Wiederholen Sie den Schritt für jede Umgebung:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    
    Dabei ist ENV_NAME der Name der Umgebung, die Sie aktualisieren.
  - Alle Umgebungen gleichzeitig: Sie können die Überschreibungen auf alle Umgebungen gleichzeitig anwenden und den Abschluss prüfen:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
8. Wenden Sie Ihre Überschreibungen an, um die virtualhosts-Komponenten zu aktualisieren, und prüfen Sie den Fortschritt:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
Non-prod

In den meisten Nicht-Produktionsumgebungen, Demo- und Testumgebungen können Sie die Überschreibungen auf alle Komponenten gleichzeitig anwenden. Wenn Ihre Nicht-Produktionsumgebung groß und komplex ist oder eine Produktionsumgebung nachahmt, können Sie die Anleitung zum Upgrade von Produktionsumgebungen verwenden.
1. Sie müssen sich im Verzeichnis hybrid-files befinden.
2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
3. Prüfen Sie den Status:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Rollback für Upgrade durchführen

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

Helm

Verwenden Sie die Diagramme und die Überschreibungsdatei aus der vorherigen Installation, um ein Rollback auf die vorherige Version durchzuführen.

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

Führen Sie ein Rollback für die Organisation durch:

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Führen Sie ein Rollback des Ingress-Managers durch:

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Führen Sie ein Rollback von Redis durch:

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace apigee \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Führen Sie ein Rollback von Apigee Telemetry durch:

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Führen Sie ein Rollback von Apigee Datastore (der Cassandra-Datenbankkomponente) durch:

helm upgrade datastore $PREVIOUS_HELM_CHARTS_HOME/apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

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

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

`apigeectl`

Bereinigen Sie abgeschlossene Jobs für den Namespace der Hybridlaufzeit. Dabei ist NAMESPACE der Namespace, der in der Überschreibungsdatei angegeben ist, wenn Sie einen Namespace angegeben haben. Wenn nicht, ist der Standard-Namespace apigee:
```
kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Bereinigen Sie abgeschlossene Jobs für den Namespace apigee-system:

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

Ändern Sie die Variable APIGEECTL_HOME so, dass sie auf das Verzeichnis verweist, das die ursprüngliche Version von apigeectl enthält. Beispiel:
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
Führen Sie die folgenden Befehle im Stammverzeichnis der Installation aus, zu der Sie ein Rollback durchführen möchten. Achten Sie darauf, die Original-Überschreibungsdatei für die Version zu verwenden, für die Sie ein Rollback durchführen möchten:
1. Führen Sie im Verzeichnis mit Hybriddateien apigeectl apply aus:
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
  Dabei ist ORIGINAL_OVERRIDES_FILE der relative Pfad und der Dateiname der Überschreibungsdatei für Ihre vorherige Version der Hybridinstallation, z. B. ./overrides/overrides1.10.yaml.
2. Prüfen Sie den Status der Pods:
```
kubectl -n NAMESPACE get pods
```
  Dabei ist NAMESPACE Ihr Apigee Hybrid-Namespace.
3. Prüfen Sie den Status von apigeeds:
```
kubectl describe apigeeds -n apigee
```
  Die Ausgabe sollte in etwa so aussehen:
```
Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running
```
  Fahren Sie nur mit dem nächsten Schritt fort, wenn der apigeeds-Pod ausgeführt wird.
4. Führen Sie den folgenden Befehl aus, um zu notieren, was die neuen Replikatwerte nach dem Upgrade für den Nachrichtenprozessor sein werden. Wenn diese Werte nicht mit dem zuvor festgelegten Wert übereinstimmen, ändern Sie die Werte in der Überschreibungsdatei entsprechend Ihrer vorherigen Konfiguration.
```
apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2
```
  Die Ausgabe sollte in etwa so aussehen:
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```
5. Führen Sie apigeectl init aus.
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```

Upgrade von Apigee Hybrid auf Version 1.11 ausführen

Upgrade auf Version 1.11.2 – Übersicht

Vorbereitung

Helm-Diagramme und apigeectl

Von v1.10 mit apigeectl zu Helm v1.11 migrieren

Upgrade auf Version 1.11 vorbereiten

Hybridinstallation sichern (empfohlen)

Helm

Linux

Mac OS

Windows

Prod

Non-prod

apigeectl

Linux

Mac OS

Windows

Aktualisieren Sie Ihre Kubernetes-Version

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

Komponenten

Angehängte Cluster

Hybrid 1.11.2-Laufzeit installieren

Helm

Upgrade auf Helm-Diagramme vorbereiten

Apigee Hybrid-Helm-Diagramme installieren

apigeectl

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

Mac OS

Windows

Linux

macOS

Windows

Produktion

Non-prod

Rollback für Upgrade durchführen

Helm

apigeectl

Helm-Diagramme und `apigeectl`

Von v1.10 mit `apigeectl` zu Helm v1.11 migrieren

`apigeectl`

`apigeectl`

`apigeectl`