Upgrade von Apigee Hybrid auf Version 1.9 ausführen

Dieses Verfahren behandelt das Upgrade von der Apigee Hybrid-Version 1.8.x auf die Apigee Hybrid-Version 1.9.4 und von früheren Releases der Hybrid-Version 1.9.x auf Version 1.9.4.

Verwenden Sie dieselben Verfahren für Upgrades von Nebenversionen (z. B. Version 1.8 auf 1.9) und Patch-Upgrades (z. B. 1.9.0 bis 1.9.4).

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

Ab Version 1.9.0 unterstützt Apigee Hybrid nur das Apigee-Ingress-Gateway als Ingress-Ebene.

Upgrade auf Version 1.9.4 – Übersicht

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

Beim Upgrade des Apigee-Controllers auf Version 1.9.4 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 die Auswirkungen auf die Produktion zu reduzieren. Es gibt kein Zeitlimit dafür, wann alle verbleibenden Cluster nach dem Upgrade 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.8 nicht zum Wiederherstellen einer Hybrid 1.9-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.9.4.

Vorbereitung

In dieser Upgrade-Anleitung wird davon ausgegangen, dass Sie die Apigee Hybrid-Version 1.8.x installiert haben und ein Upgrade auf Version 1.9.4 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.8 ausführen.
In der Apigee Hybrid-Version 1.8 wurde das Apigee Ingress-Gateway als alternative Ingress-Ebene zu Anthos Service Mesh eingeführt. Ab Version 1.9.0 erfordert Apigee Hybrid das Apigee-Ingress-Gateway und unterstützt nicht mehr Anthos Service Mesh für eingehenden Traffic. Wenn die Installation, von der Sie ein Upgrade durchführen, Anthos Service Mesh verwendet, müssen Sie zuerst zum Apigee Ingress-Gateway migrieren, bevor Sie ein Upgrade auf Version 1.9.4 durchführen.
Das Ingress-Gateway von Apigee verwendet eine kleine Teilmenge von Anthos Service Mesh-Features für das Ingress-Gateway. Die Verwaltung und Upgrades dieser Features werden automatisch von Apigee Hybrid übernommen. Sie benötigen daher keine Kenntnisse über Anthos Service Mesh, um das Apigee Hybrid-Ingress-Gateway zu installieren, zu aktualisieren und zu verwalten.

Eine Anleitung dazu finden Sie in der Dokumentation zu Hybrid v1.8 unter Zum Apigee-Ingress-Gateway migrieren.

Upgrade auf Version 1.9 vorbereiten

Hybridinstallation sichern (empfohlen)

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
```
macOS
```
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.8. Beispiel:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.8-backup.tar.gz $APIGEECTL_HOME
```
Sichern Sie Ihre Cassandra-Datenbank entsprechend der Anleitung unter Cassandra-Sicherung und -Wiederherstellung.

Fügen Sie dem Dienstkonto für die Apigee-Laufzeit die Rolle Cloud Trace Agent hinzu. (Optional)

Optional: Wenn Sie Cloud Trace verwenden möchten und die Rolle Cloud Trace Agent nicht zu Ihrer Hybrid-v1.8-Installation hinzugefügt haben, achten Sie darauf, dass Ihr Dienstkonto für Ihre Apigee-Laufzeitdienste die Cloud IAM-Rolle Cloud Trace-Agent (roles/cloudtrace.agent) hat.

In Produktionsumgebungen lautet das Laufzeitdienstkonto apigee-runtime. In Nicht-Produktionsumgebungen das Laufzeitdienstkonto apigee-non-prod.

Sie können die Rolle in der Benutzeroberfläche Cloud Console > IAM und Verwaltung > Dienstkonten oder mit den folgenden Befehlen hinzufügen:

Rufen Sie die E-Mail-Adresse Ihres Dienstkontos mit dem folgenden Befehl ab:
Produktion
```
gcloud iam service-accounts list --filter "apigee-runtime"
```
Wenn die E-Mail-Adresse dem Muster apigee-runtime@$ORG_NAME.iam.gserviceaccount.com entspricht, können Sie dieses Muster im nächsten Schritt verwenden.
Non-prod
```
gcloud iam service-accounts list --filter "apigee-non-prod"
```
Wenn es mit dem Muster apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com übereinstimmt, können Sie dieses Muster im nächsten Schritt verwenden.

Weisen Sie dem Dienstkonto die Rolle Cloud Trace-Agent zu:

Produktion

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Non-prod

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Beispiel

gcloud projects add-iam-policy-binding hybrid-example-project \
    --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Dabei gilt: $PROJECT_ID ist der Name des Google Cloud-Projekts, in dem Apigee Hybrid installiert ist.

Hinweis: Wenn Ihre Installation einen benutzerdefinierten Namen für das Dienstkonto verwendet, ersetzen Sie diesen Namen durch apigee-runtime oder apigee-non-prod im Befehl.

Apigee Ingress-Gateway installieren, wenn Ihre Installation Anthos Service Mesh verwendet

Ab Version 1.9 unterstützt Apigee Hybrid die Verwendung von Anthos Service Mesh für eingehenden Traffic nicht mehr. Wenn Ihre Hybridinstallation Anthos Service Mesh verwendet, müssen Sie Ihre aktuelle Installation zum Apigee Ingress-Gateway migrieren, bevor Sie die Hybrid-Version 1.9 installieren.

Fügen Sie der Überschreibungsdatei das Attribut ingressGateways hinzu.
Syntax
```
  ingressGateways:
  - name: INGRESS_NAME
    replicaCountMin: REPLICAS_MIN
    replicaCountMax: REPLICAS_MAX
    resources:
      requests:
        cpu: CPU_COUNT_REQ
        memory: MEMORY_REQ
      limits:
        cpu: CPU_COUNT_LIMIT
        memory: MEMORY_LIMIT
    svcAnnotations:  # optional. See Known issue 243599452.
      SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
    svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional
```
Beispiel
```
  ingressGateways:
  - name: prod1
    replicaCountMin: 2
    replicaCountMax: 100
    resources:
      requests:
        cpu: 1
        memory: 1Gi
      limits:
        cpu: 2
        memory: 2Gi
    svcAnnotations:  # optional. See Known issue 243599452.
      networking.gke.io/load-balancer-type: "Internal"
    svcLoadBalancerIP: 198.252.0.123 
```
- INGRESS_NAME ist der Name des Ingress-Deployments. Dies kann ein beliebiger Name sein, der die folgenden Anforderungen erfüllt:
  - Darf maximal 17 Zeichen lang sein
  - Darf nur kleingeschriebene, alphanumerische Zeichen enthalten, "-" oder ".".
  - Muss mit einem alphanumerischen Zeichen beginnen.
  - Muss mit einem alphanumerischen Zeichen enden.
  Siehe ingressGateways[].name in der Referenz zu Konfigurationsattributen.
- REPLICAS_MIN und REPLICAS_MAX sind die minimalen und maximalen Replikatzahlen für das Apigee-Ingress-Gateway in Ihrer Installation. Weitere Informationen und Standardeinstellungen finden Sie unter ingressGateways[].replicaCountMin und ingressGateways[].replicaCountMax in der Referenz zu Konfigurationsattributen.
- CPU_COUNT_REQ und MEMORY_REQ sind die CPU- und Speicheranforderungen für jedes Replikat des Apigee Ingress-Gateways in Ihrer Installation.
  Legen Sie diese Attribute fest, wenn Sie sie zuvor für Ihr Anthos Service Mesh-Ingress-Gateway festgelegt haben, z. B. in Ihrer overlay.yaml-Datei.
  
  Weitere Informationen und Standardeinstellungen finden Sie unter ingressGateways[].resources.requests.cpu und ingressGateways[].resources.requests.memory in der Referenz zu Konfigurationsattributen.
- CPU_COUNT_LIMIT und MEMORY_LIMIT: die maximalen CPU- und Arbeitsspeicherlimits für jedes Replikat des Apigee Ingress-Gateways in Ihrer Installation.
  Legen Sie diese Attribute fest, wenn Sie sie zuvor für Ihr Anthos Service Mesh-Ingress-Gateway festgelegt haben, z. B. in Ihrer overlay.yaml-Datei.
  
  Weitere Informationen und Standardeinstellungen finden Sie unter ingressGateways[].resources.limits.cpu und ingressGateways[].resources.limits.memory in der Referenz zu Konfigurationsattributen.
- SVC_ANNOTATIONS_KEY SVC_ANNOTATIONS_VALUE (optional):
  Hinweis: Das Feld ingressGateways[].svcAnnotations in overrides.yaml funktioniert nicht wie erwartet. Siehe Bekanntes Problem 243599452
  
  Dies ist ein Schlüssel/Wert-Paar, das Annotationen für Ihren Standarddienst für eingehenden Traffic bereitstellt. Annotationen werden von Ihrer Cloud Platform verwendet, um Ihre Hybridinstallation zu konfigurieren, z. B. um den Load-Balancer-Typ auf intern oder extern festzulegen. Beispiel:
```
ingressGateways:
    svcAnnotations:
      networking.gke.io/load-balancer-type: "Internal"
```
  Annotationen variieren je nach Plattform. Erforderliche und vorgeschlagene Annotationen finden Sie in der Dokumentation Ihrer Plattform.
  
  Hinweis:Annotations Sie müssen nicht festlegen, wenn Sie einen eigenen Kubernetes-Dienst für das Deployment von eingehendem Traffic erstellen, wie in Apigee-Ingress-Gateway freigeben dokumentiert.
  Siehe ingressGateways[].svcAnnotations in der Referenz zu Konfigurationsattributen.
- SVC_LOAD_BALANCER_IP (optional): Ermöglicht das Zuweisen einer statischen IP-Adresse für Ihren Load-Balancer. Auf Plattformen, die die Angabe der IP-Adresse des Load-Balancers unterstützen, wird der Load-Balancer mit dieser IP-Adresse erstellt. Auf Plattformen, auf denen Sie die IP-Adresse des Load-Balancers nicht angeben können, wird dieses Attribut ignoriert.
  Wenn Sie Ihrem Load-Balancer keine statische IP-Adresse zugewiesen haben, lassen Sie dieses Attribut in der Überschreibungsdatei weg.
  
  Achtung: Geben Sie nicht dieselbe IP-Adresse wie das aktuelle Istio-Ingress-Gateway an. Dies kann zu Problemen führen, während sich dieser Dienst noch auf dem Cluster befindet.
  
  Hinweis: Sie müssen LoadBalancerIP nicht festlegen, wenn Sie einen eigenen Kubernetes-Dienst für das Deployment von eingehendem Traffic erstellen, wie in Apigee-Ingress-Gateway freigeben dokumentiert.
  Siehe ingressGateways[].svcLoadBalancerIP in der Referenz zu Konfigurationsattributen.
Wenden Sie mit den folgenden Befehlen die Änderungen an, um das Apigee Ingress-Gateway zu installieren:
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml
```
Geben Sie das Apigee Ingress-Gateway frei. Folgen Sie den Schritten unter Apigee-Ingress-Gateway freigeben.
Neues Ingress-Gateway durch Aufrufen eines Proxys testen Testen Sie idealerweise alle wichtigen Proxys, die derzeit bereitgestellt sind.
Aktualisieren Sie zum Ändern des Traffics Ihre DNS-Einträge so, dass sie auf die IP-Adresse für Ihr neues Apigee Ingress-Gateway verweisen. Je nach DNS-Anbieter können Sie den Traffic möglicherweise schrittweise zum neuen Endpunkt verschieben.
Tipp: Sie finden die externe IP-Adresse des Apigee Ingress-Gateways mit dem folgenden Befehl:
```
kubectl get svc -n apigee -l app=apigee-ingressgateway
```
Die Ausgabe sollte in etwa so aussehen:
```
NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h
```
Überwachen Sie die Dahsboards, um zu prüfen, ob der gesamte Laufzeittraffic funktioniert. Fahren Sie nur mit dem nächsten Schritt fort, wenn alles wie erwartet funktioniert. Achten Sie darauf, dass kein Traffic über Ihr altes Ingress-Gateway (Anthos Service Mesh) geleitet wird, da die DNS-Aktualisierung aufgrund von DNS-Caching möglicherweise nur langsam übernommen wird.
Wenn Sie die Konfiguration von Apigee für Anthos Service Mesh beenden möchten, führen Sie die Schritte unter Konfiguration für ASM beenden im Leitfaden zum Verwalten von Apigee Ingress-Gateway aus.
Testen sie erneut und überwachen Sie den API-Proxy-Traffic.
Folgen Sie der Anleitung in der Anthos Service Mesh-Dokumentation, um Anthos Service Mesh aus dem Cluster zu deinstallieren.

Hybrid 1.9.4-Laufzeit installieren

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/1.9.4/apigeectl_linux_64.tar.gz

macOS

Mac 64-Bit:

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

Windows

Windows 64-Bit:

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

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

Linux

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.8/

macOS

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.8/

Windows

rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.8

Extrahieren Sie die heruntergeladenen gzip-Dateiinhalte in Ihr Hybrid-Basisverzeichnis. Das Hybrid-Basisverzeichnis ist das Verzeichnis, in dem sich das umbenannte Verzeichnis apigeectl-v1.8 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.9.4-xxxxxxx_linux_64. Benennen Sie dieses Verzeichnis mit dem folgenden Befehl in apigeectl um:
Linux
```
mv apigeectl_1.9.4-xxxxxxx_linux_64 apigeectl
```
macOS
```
mv apigeectl_1.9.4-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.9.4-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
```
macOS
```
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.9.4
```
Wechseln Sie zum Verzeichnis hybrid-base-directory/hybrid-files. Im Verzeichnis hybrid-files befinden sich Konfigurationsdateien wie die Überschreibungsdatei, Zertifikate und Dienstkonten. Beispiel:
```
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
```
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.9.4:
```
$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

`1.9.4-hotfix.1` installieren

Führen Sie die folgenden Schritte aus, um den Hotfix-Release 1.9.4-hotfix.1 zu installieren:

Bevor Sie diese Schritte ausführen, benötigen Sie die Apigee Hybrid-Version 1.9.4 oder höher. Wenn Sie nicht Version 1.9.4 oder höher verwenden, führen Sie ein Upgrade auf 1.9.4 durch, bevor Sie fortfahren.
Öffnen Sie Ihre overrides.yaml-Datei.

Ändern Sie in der istiod-Stanza die Version des Image-Tags (falls vorhanden) in Version 1.17.7. Beispiel:

istiod:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-asm-istiod"
    tag: "1.17.7-asm.0-distroless"

Je nachdem, wie Sie Apigee Hybrid installiert haben, haben Sie möglicherweise eine ingressGateway- oder ingressGateways-Stanza. Suchen Sie die Stanza, die in der Überschreibungsdatei angezeigt wird, und ändern Sie die Version des Image-Tags (falls vorhanden) in Version 1.17.7. Wenn Sie beispielsweise eine ingressGateway-Stanza haben:

ingressGateway:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
    tag: "1.17.7-asm.0-distroless"

oder, wenn Sie eine ingressGateways-Stanza haben:

ingressGateways:
  - name: gateway1
    image:
      url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
      tag: "1.17.7-asm.0-distroless"
    ...
  - name: gateway2
    image:
      url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
      tag: "1.17.7-asm.0-distroless"
    ...

Speichern Sie die Datei.

Führen Sie den folgenden Befehl aus, um die Komponente istiod zu initialisieren:

$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE

$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Führen Sie den folgenden Befehl aus, um Änderungen auf die Apigee Ingress-Komponente(n) anzuwenden. Wenn Sie mehr als eine Organisation haben, wiederholen Sie diesen Befehl für jede Organisation:
```
$APIGEECTL_HOME/apigeectl apply --org -f OVERRIDES_FILE
```
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```

Prüfen Sie den Status Ihrer Pods:

kubectl get pods -n YOUR_APIGEE_NAMESPACE

Aktualisieren Sie Ihre Kubernetes-Version

Aktualisieren Sie Ihre Kubernetes-Plattform auf die von Hybrid 1.9 unterstützten Versionen. Weitere Informationen finden Sie in der Dokumentation der Plattform.

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

	Hybrid-Versionen von Apigee
Plattformen	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8 ⁽³⁾	1.9	1.10
Anthos (Google Cloud – GKE)	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
Anthos (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 1.13.x 1.25⁽¹³⁾	1.12.x 1.13.x 1.25⁽¹³⁾	1.13.x 1.25⁽¹³⁾ 1.26⁽¹³⁾
Anthos (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.15.x
Anthos (lokal - 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	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
Anthos (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 1.15.x 1.16.x
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.9.2)}	1.24.x 1.25.x 1.26.x
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
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
Rancher Kubernetes Engine (RKE)⁽⁷⁾	–	–	–	1.3.8	v1.26.2+rke2r1
Komponenten	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8	1.9	1.10
Anthos Service Mesh (ASM)	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⁽¹¹⁾
JDK	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
Cassandra	3.11.10	3.11.10	3.11.10	3.11.10	3.11.10
⁽¹⁾ Folgen Sie bei der Anthos-Version 1.8, 1.9 und 1.10 der Anleitung in diesen Dokumenten, um Konflikte mit `cert-manager` zu vermeiden: Anthos 1.8.2 oder höher: Konflikt mit `cert-manager` beim Upgrade auf Version 1.8.2 oder höher. Anthos 1.9: Konflikt mit `cert-manager` beim Upgrade auf Version 1.9.0 oder 1.9.1. Anthos 1.10 oder höher: Konflikt mit `cert-manager`-Installation. ⁽²⁾ Support ab Apigee Hybrid-Version 1.7.2 verfügbar. ⁽³⁾ Die offiziellen EOL-Daten für Apigee Hybrid-Versionen 1.8 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. ⁽⁴⁾ Anthos on Bare Metal- und VMWare-Versionen 1.12 und früher werden nicht mehr unterstützt. See the Anthos on Bare Metal Version Support Policy and the Anthos clusters on VMware versions. ⁽⁵⁾Anthos on Bare Metal and VMWare benötigt ASM 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 ASM nicht mehr auf Ihrem Hybridcluster installieren müssen. ⁽⁶⁾ Support ab Apigee Hybrid-Version 1.8.4 verfügbar. ⁽⁷⁾ Verbundene Cluster sind nicht erforderlich für die Verwendung von Apigee Hybrid v1.8 und höher mit Apigee Ingress Gateway. ⁽⁸⁾ 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. ⁽¹¹⁾ ASM wird automatisch mit Apigee Hybrid 1.9 und höher installiert. ⁽¹²⁾ Support ab Apigee Hybrid-Version 1.9.2 verfügbar. ⁽¹³⁾ Die Anthos-Cluster auf AWS-Versionsnummern (Multi-Cloud) spiegeln jetzt die Kubernetes-Versionen wider. Weitere Informationen für Versionsdetails und empfohlene Patches finden Sie im Abschnitt Unterstützung für Anthos-Versionen und -Upgrades.

Angehängte Cluster

Für Apigee Hybrid-Versionen 1.7.x und niedriger müssen Sie angehängte 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 (ASM) messen. Registrierung des Drittanbieter-Clusters ist optional. Registrieren Sie sich nur, wenn Sie den angehängten Cluster in der Google Cloud Console ansehen möchten. Weitere Informationen finden Sie unter Drittanbieter-Kubernetes-Cluster an Google Cloud anhängen.

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

Rollback für Upgrade durchführen

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

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 im Stammverzeichnis der Installation, zu der Sie ein Rollback machen möchten, apigeectl apply aus, prüfen Sie den Status Ihrer Pods und führen Sie dann apigeectl init aus. 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.8.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.9 ausführen

Upgrade auf Version 1.9.4 – Übersicht

Vorbereitung

Upgrade auf Version 1.9 vorbereiten

Hybridinstallation sichern (empfohlen)

Linux

macOS

Windows

Fügen Sie dem Dienstkonto für die Apigee-Laufzeit die Rolle Cloud Trace Agent hinzu. (Optional)

Produktion

Non-prod

Produktion

Non-prod

Beispiel

Apigee Ingress-Gateway installieren, wenn Ihre Installation Anthos Service Mesh verwendet

Syntax

Beispiel

Hybrid 1.9.4-Laufzeit installieren

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Linux

macOS

Windows

Produktion

Non-prod

1.9.4-hotfix.1 installieren

Aktualisieren Sie Ihre Kubernetes-Version

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

Plattformen

Komponenten

Angehängte Cluster

Rollback für Upgrade durchführen

`1.9.4-hotfix.1` installieren