Upgrade von Apigee Hybrid auf Version 1.3.6 ausführen

Upgrade auf Version 1.3.6 – Übersicht.

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

Vorbereitung

Erstellen und aktualisieren Sie Dienstkonten.
Planen Sie Umgebungsgruppen.
Kopieren und aktualisieren Sie die Überschreibungsdatei.

Aktualisieren Sie Istio und Cert Manager.
Installieren Sie die Hybrid-Laufzeitversion 1.3.
bereinigen.

Voraussetzung

Apigee Hybrid Version 1.2 Wenn Sie eine Aktualisierung von einer früheren Version ausführen, lesen Sie die Anleitung unter Upgrade von Apigee Hybrid auf Version 1.2 ausführen.

Vorbereitung

Empfohlen: Erstellen Sie eine Sicherungskopie Ihres $APIGEECTL_HOME/-Verzeichnisses der Version 1.2. Beispiel:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.2-backup.tar.gz $APIGEECTL_HOME
```
Empfohlen: Sichern Sie Ihre Cassandra-Datenbank entsprechend der Anleitung unter Cassandra-Sicherung und -Wiederherstellung.

So führen Sie ein Upgrade Ihrer Kubernetes-Plattform durch: Weitere Informationen finden Sie in der Dokumentation der Plattform:

Plattform	Auf Version aktualisieren
GKE	1.15.x
Anthos	1.5
AKS	1.16.x mit an Anthos angehängten Clustern

Wenn Sie Apigee Connect nicht in Ihrer Hybrid-Installation verwenden, aktivieren Sie Apigee Connect.

Prüfen Sie, ob die Apigee Connect API bereits aktiviert ist:

gcloud services list | grep apigeeconnect

apigeeconnect.googleapis.com         Apigee Connect API

Aktivieren Sie andernfalls die API:
```
gcloud services enable apigeeconnect.googleapis.com --project $PROJECT_ID
```
Dabei ist $PROJECT_ID Ihre Google Cloud-Projekt-ID.
Rufen Sie in der Befehlszeile Ihre gcloud-Authentifizierungsdaten ab, wie im folgenden Beispiel gezeigt:
```
TOKEN=$(gcloud auth print-access-token)
```
Um zu prüfen, ob Ihr Token ausgefüllt wurde, verwenden Sie echo wie im folgenden Beispiel:
```
echo $TOKEN
```
Das Token sollte als codierter String angezeigt werden.

Weitere Informationen finden sich in der Übersicht über das gcloud-Befehlszeilentool.

Prüfen Sie, ob Apigee Connect für Ihre Organisation aktiviert ist:

curl -H "Authorization: Bearer $TOKEN" \
  "https://apigee.googleapis.com/v1/organizations/$ORG_NAME"

Dabei ist $ORG_NAME die ID Ihrer Organisation.

Wenn die Ausgabe Folgendes enthält:

      "name" : "features.mart.connect.enabled",
      "value" : "true"

Apigee Connect ist aktiviert.

Wenn Apigee Connect nicht aktiviert ist, weisen Sie dem MART-Dienstkonto die Rolle "Apigee Connect Agent" zu:
```
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member serviceAccount:apigee-mart@$PROJECT_ID.iam.gserviceaccount.com \
  --role roles/apigeeconnect.Agent
```
Tipp: Wenn Sie die E-Mail-Adresse Ihres MART-Dienstkontos abrufen müssen, führen Sie den folgenden Befehl aus:
```
gcloud iam service-accounts list | grep mart
```

Aktivieren Sie Apigee Connect mit folgendem Befehl:

curl -H "Authorization: Bearer $TOKEN" -X PUT \
  -H "Content-Type: application/json" \
  -d '{
    "name" : "'"$ORG_NAME"'",
    "properties" : {
      "property" : [ {
        "name" : "features.hybrid.enabled",
        "value" : "true"
      }, {
        "name" : "features.mart.connect.enabled",
        "value" : "true"
      } ]
    }
  }' \
  "https://apigee.googleapis.com/v1/organizations/$ORG_NAME"

Wenn die Ausgabe die folgenden beiden Attribute enthält, wurde Apigee Connect erfolgreich aktiviert:

      {
        "name": "features.mart.connect.enabled",
        "value": "true"
      },
      {
        "name": "features.hybrid.enabled",
        "value": "true"
      }

Erstellen Sie das Dienstkonto apigee-watcher. Apigee Watcher ist ein neues Dienstkonto, das in Version 1.3 eingeführt wurde. Der Synchronisation wird für Änderungen auf Organisationsebene wird überwacht und diese Änderungen werden zur Konfiguration des Istio-Ingress angewendet.
Führen Sie in Ihrem Haupt-Hybridverzeichnis folgende Schritte aus:
```
./tools/create-service-account apigee-watcher ./service-accounts
```
Weisen Sie dem Watcher-Dienstkonto die Rolle "Apigee Runtime-Agent" zu:
```
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member serviceAccount:apigee-watcher@$PROJECT_ID.iam.gserviceaccount.com \
  --role roles/apigee.runtimeAgent
```
Dabei ist PROJECT_ID Ihre Google Cloud-Projekt-ID. Wenn die E-Mail-Adressen Ihres Dienstkontos von diesem Muster abweichen, ersetzen Sie sie entsprechend.
Tipp: Wenn Sie die E-Mail-Adresse Ihres Watcher-Dienstkontos abrufen möchten, führen Sie den folgenden Befehl aus:
```
gcloud iam service-accounts list | grep watcher
```
Die Ausgabe sollte eine Liste aller Dienstkonten und deren Rollen enthalten, darunter:
```
  ...
- members:
  - serviceAccount:apigee-watcher@hybrid13rc5.iam.gserviceaccount.com
  role: roles/apigee.runtimeAgent
  ...
```
Planen Sie Ihre Umgebungsgruppen für das Routing. Apigee Hybrid 1.3 verwaltet das Basispfadrouting mit Umgebungsgruppen anstelle von routingRules. Wenn Sie routingRules in Ihrer Hybridkonfiguration verwenden, entwerfen Sie Umgebungsgruppen, um das Routing zu replizieren.
Sie müssen mindestens eine Umgebungsgruppe erstellen.

Siehe Informationen zu Umgebungsgruppen.
Klicken Sie hier, um ein Beispiel für die Verwendung von Umgebungsgruppen als Ersatz für routingRules zu sehen.

In diesem Beispiel leitet die folgende routingRules in der Datei overrides.yaml Anfragen an die API-Proxys foo und bar in der Umgebung prod-env-1 und an den Proxy foo-test in der Umgebung test-env weiter:
```
virtualhosts:
  - name: default
    hostAliases:
      - "*.acme.com"
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
    routingRules:
      - paths:
        - /foo
        - /bar
      - env: prod-env-1
      - paths:
        - foo-test
      -env: test-env
```
So duplizieren Sie dies in Hybrid-Version 1.3.6:
1. Stellen Sie die Proxys foo und bar in der Umgebung prod-env-1 bereit.
2. Stellen Sie den Proxy foo-test und bar in der Umgebung test-env bereit.
3. Erstellen Sie eine Umgebungsgruppe mit einem Hostalias für die Proxys, z. B. api.acme.com.
  Tipp: Erstellen Sie eine Umgebungsgruppe mit dem Namen des Virtualhosts, den Sie in Version 1.2 verwendet haben.
4. Überarbeiten Sie die virtualhosts-Stanza in overrides.yaml in
  - Ersetzen Sie virtualhosts:name durch den Namen der Umgebungsgruppe.
  - Entfernen Sie virtualhosts:routingRules.
  Beispiel:
```
virtualhosts:
  - name: default # environment group name
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
```
Aktualisieren Sie die Überschreibungsdatei:

Erstellen Sie eine Kopie der Überschreibungsdatei.

Aktualisieren Sie die gcp- und k8sCluster-Stanzas.

In der Hybrid-Version 1.3 wurden die folgenden Konfigurationsattribute ersetzt:

gcpRegion wurde durch gcp:region ersetzt
gcpProjectID wurde durch gcp:projectID ersetzt
gcpProjectIDRuntime wurde durch gcp:gcpProjectIDRuntime ersetzt
k8sClusterName wurde durch k8s:clusterName ersetzt
k8sClusterRegion wurde durch k8s:clusterRegion ersetzt

Ersetzen Sie beispielsweise die folgende Struktur:

gcpRegion: gcp region
gcpProjectID: gcp project ID
gcpProjectIDRuntime: gcp project ID

k8sClusterName: name
k8sClusterRegion: region

with:

gcp:
 projectID: gcp project ID
 region: gcp region
 gcpProjectIDRuntime: gcp project ID # optional. This is only required if you
                                       # want logger/metrics data to be sent in
                                       # different gcp project.

k8sCluster:
 name: gcp project ID
 region: gcp region

Wenn die Überschreibungsdatei noch keine eindeutige Instanzkennung enthält, fügen Sie eine hinzu:
```
# unique identifier for this installation. 63 chars length limit
instanceID: ID
```
Dabei ist ID eine eindeutige Kennung für diese Hybrid-Installation, z. B. "my-hybrid-131-installation" oder "acmecorp-hybrid-131".

Fügen Sie der Überschreibungsdatei das Watcher-Dienstkonto (apigee-watcher) hinzu:

# Note: the SA should have the "Apigee Runtime Agent" role
watcher:
 serviceAccountPath: "service account file"

Fügen Sie der Überschreibungsdatei das Metrics-Dienstkonto (apigee-metrics) hinzu:
```
metrics:
 serviceAccountPath: "service account file"
```
Aktualisieren Sie virtualhosts:-Stanza, um routingRules durch Ihre Umgebungsgruppe zu ersetzen.
1. -name: Ersetzen Sie den Namen durch den Namen der Umgebungsgruppe. Sie können mehrere Nameneinträge haben, einen für jede Umgebungsgruppe.
2. hostAliases:[] Löschen Sie diese Zeile.
3. Behalten Sie die Einträge sslCertPath: und sslKeyPath: bei (oder fügen Sie sie hinzu).
4. Löschen Sie alle routingRules-Einträge.
Beispiel:
```
virtualhosts:
  - name: default
    hostAliases:
      - "*.acme.com"
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
    routingRules:
      - paths:
        - /foo
        - /bar
      - env: my-environment
```
wird zu
```
virtualhosts:
  - name: example-env-group
    sslCertPath: ./certs/keystore.pem
    sslKeyPath: ./certs/keystore.key
```
Aktualisieren Sie die mart- und connectAgent:-Stanzas.
Hinweis: Wenn Sie Apigee Connect nicht in Ihrer Hybrid 1.3-Installation verwenden möchten, überspringen Sie diesen Schritt und folgen Sie dem Tipp in Schritt 5 nach dem Upgrade in Apigee Connect.
1. Entfernen Sie unter mart: die Einträge hostAlias:, sslCertPath: und sslKeyPath:.
2. Fügen Sie eine connectAgent:-Stanza hinzu.
3. Fügen Sie unter connectAgent: einen serviceAccountPath:-Eintrag hinzu und geben Sie den Pfad zu der Dienstkontodatei an, der die Rolle "Apigee Connect-Agent" zugewiesen ist (normalerweise das MART-Dienstkonto).
Beispiel:
```
mart:
  hostAlias: "mart.apigee-hybrid-docs.net"
  serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json
  sslCertPath: ./certs/fullchain.pem
  sslKeyPath: ./certs/privkey.key
```
wird zu
```
mart:
  serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json

connectAgent:
  serviceAccountPath: ./service-accounts/hybrid-project-apigee-mart.json
```

Istio und Cert Manager aktualisieren

Die Apigee Hybrid-Version 1.3 erfordert Cert Manager 0.14.2 zur Verwaltung und Überprüfung der Zertifikate. Außerdem ist die Istio-Distribution der Anthos Service Mesh (ASM)-Version 1.5.7 (oder neuer) zum Erstellen und Verwalten des Laufzeit-Gateways für eingehenden Traffic erforderlich.

Upgrade von Istio 1.4.6 auf ASM 1.5.7 oder höher ausführen

Für eine möglichst geringe Ausfallzeit müssen Istio-Bereitstellungen und HPAs mindestens zwei Replikate enthalten. Führen Sie die folgenden Befehle aus, um die Anzahl der Replikate zu ermitteln:
```
kubectl -n istio-system get deployments # list of deployments
kubectl -n istio-system get hpa # list of hpa
```
Bearbeiten Sie jede Bereitstellung mit nur einem Replikat und erhöhen Sie replicas: auf 2 oder mehr:
```
kubectl -n istio-system edit deployment name
```
Beispiel:
```
spec:
  progressDeadlineSeconds: 600
  replicas: 2
```
Bearbeiten Sie jedes HPA, das nur ein Replikat hat, und erhöhen Sie minReplicas: auf 2 oder mehr:
```
kubectl -n istio-system edit hpa name
```
Beispiel:
```
spec:
  maxReplicas: 5
  minReplicas: 2
```
Laden Sie ASM gemäß der Installationsanleitung unter ASM herunterladen und installieren herunter und installieren Sie es.

Führen Sie nach der Installation den Befehl „version” aus, um sicherzustellen, dass 1.5.x ordnungsgemäß installiert ist:

./bin/istioctl version

client version: 1.5.8-asm.0
apigee-mart-ingressgateway version:
citadel version: 1.4.6
galley version: 1.4.6
ingressgateway version: 1.5.8-asm.0
pilot version: 1.4.6
policy version: 1.4.6
sidecar-injector version: 1.4.6
telemetry version: 1.4.6
pilot version: 1.5.8-asm.0
data plane version: 1.4.6 (1 proxies), 1.5.8-asm.0 (2 proxies)

Cert Manager aktualisieren

Löschen Sie die aktuelle Bereitstellung von Cert Manager:

kubectl delete -n cert-manager deployment cert-manager cert-manager-cainjector cert-manager-webhook

Prüfen Sie Ihre Kubernetes-Version:
```
kubectl version
```

Führen Sie den folgenden Befehl aus, um Cert Manager von Jetstack zu installieren:

kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.14.2/cert-manager.yaml

Hybrid-Laufzeit installieren

Speichern Sie die neueste Versionsnummer in einer Variable:

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

Prüfen Sie, ob die Variable mit einer Versionsnummer gefüllt wurde. Wenn Sie eine andere Version verwenden möchten, können Sie diese stattdessen in der Umgebungsvariablen speichern. Beispiel:
```
echo $VERSION
  1.3.6
```

Laden Sie das Release-Paket für Ihr Betriebssystem herunter:

Mac 64-Bit:

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

Linux 64-Bit:

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

Mac 32-Bit:

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

Linux 32-Bit:

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

Benennen Sie Ihr aktuelles apigeectl/-Verzeichnis in einen Backupverzeichnisnamen um. Beispiel:
```
mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.2/ 
```
Extrahieren Sie die heruntergeladenen gzip-Dateiinhalte in Ihr Hybrid-Basisverzeichnis. Beispiel:
```
tar xvzf filename.tar.gz -C hybrid-base-directory
```
cd zum Basisverzeichnis.
Die TAR-Inhalte werden standardmäßig in ein Verzeichnis mit der Version und der Plattform in ihrem Namen erweitert. Beispiel: ./apigeectl_1.0.0-f7b96a8_linux_64. Benennen Sie dieses Verzeichnis in apigeectl um:
```
mv apigeectl_1.0.0-f7b96a8_linux_64 apigeectl
```
Löschen Sie den Job apigee-resources-install aus apigee-system:
```
kubectl -n apigee-system delete job apigee-resources-install
```

Löschen Sie das ältere CRD:

kubectl delete crd apigeetelemetries.apigee.cloud.google.com

Aktualisieren Sie die cassandra:-Stanza in Ihrer Überschreibungsdatei mit dem Attribut externalSeedHost. Dieses Attribut sorgt dafür, dass Ihre neue Hybrid-Version 1.3.6 denselben Kubernetes-Cluster wie Ihre Version 1.2-Installation verwendet. Dies ist ein einmaliger Schritt, der nur für das Upgrade von Hybrid-Version 1.2 auf Version 1.3.6 (oder neuer) erforderlich ist.
1. Suchen Sie eine der IP-Adressen des vorhandenen Cassandra in demselben Kubernetes-Cluster, auf dem Sie die 1.2.0-Installation ausführen.
```
kubectl -n namespace get pods -o wide
```
  Dabei ist namespace Ihr Apigee Hybrid-Namespace.
  
  Notieren Sie sich die IP-Adresse eines Cassandra-Knotens. Beispiel:
```
kubectl -n apigee get pods -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP          NODE
apigee-cassandra-0    1/1     Running   0          33d   10.68.8.24   gke-example-cluster-rc5-apigee-data-c8bf1234-09kc
apigee-cassandra-1    1/1     Running   0          16d   10.68.8.33   gke-example-cluster-rc5-apigee-data-c9221ee7-10kc
apigee-cassandra-2    1/1     Running   0          23h   10.68.9.11   gke-example-cluster-rc5-apigee-data-d123e456-11kc
```
2. Fügen Sie den Wert für das Attribut externalSeedHost hinzu:
```
cassandra:
 externalSeedHost: Cassandra_node_IP
```
  Dabei ist Cassandra_node_IP die IP-Adresse des Cassandra-Knotens (10.68.8.24 im vorherigen Beispiel).
  Hinweis: Sie entfernen das Attribut externalSeedHost in einem späteren Schritt, nachdem Ihr neues Cassandra ausgeführt und verifiziert wurde.
Führen Sie im neuen apigeectl/-Verzeichnis apigeectl init, apigeectl apply und apigeectl check-ready aus:
1. Initialisieren Sie Hybrid 1.3.6:
```
apigeectl init -f overrides_1.3.yaml
```
  Dabei ist overrides_1.3.yaml die bearbeitete overrides.yaml-Datei.
2. In Hybrid-Version 1.3 hängt die Syntax des Flags --dry-run von der Version von kubectl ab, die Sie ausführen. Prüfen Sie die Version von kubectl:
```
gcloud version
```
3. Suchen Sie mit einem Probelauf nach Fehlern:
  kubectl-Version 1.17 und niedriger:
```
apigeectl apply -f overrides_1.3.yaml --dry-run=true
```
  Ab kubectl-Version 1.18:
```
apigeectl apply -f overrides_1.3.yaml --dry-run=client
```
4. Wenden Sie Ihre Überschreibungen an. Wählen Sie je nach Ihrer Installation die Anleitung für Produktionsumgebungen oder Demo-/experimentelle Umgebungen aus und folgen Sie diesen.
  Während des Upgrades wird für jede Komponente ein rollierender Neustart durchgeführt. In Produktionsumgebungen ist es daher am besten, das Upgrade immer nur auf eine Komponente auf einmal anzuwenden.
  ProduktionDemo/Experimentell
  In Produktionsumgebungen sollten Sie jede Hybridkomponente einzeln aktualisieren und den Status der aktualisierten Komponente prüfen, bevor Sie mit der nächsten Komponente fortfahren.
  1. Wenden Sie Ihre Überschreibungen an, um Upgrade von Cassandra durchzuführen:
    apigeectl apply -f overrides_1.3.yaml --datastore
  2. Abschluss prüfen:
    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.
  3. Wenden Sie Ihre Überschreibungen an, um Telemetriekomponenten zu aktualisieren, und prüfen Sie den Fortschritt:
    apigeectl apply -f overrides_1.3.yaml --telemetry
    
    kubectl -n namespace get pods
  4. 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 apply -f overrides_1.3.yaml --org
    
    kubectl -n namespace get pods
  5. Nutzen Sie Überschreibungen, um Ihre Umgebungen zu aktualisieren. Sie haben zwei Möglichkeiten:
    
    Wenden Sie Ihre Überschreibungen auf je eine Umgebung an und prüfen Sie den Fortschritt. Wiederholen Sie den Schritt für jede Umgebung:
    apigeectl apply -f overrides_1.3.yaml --env env_name
    
    kubectl -n namespace get pods
    
    Dabei ist env_name der Name der Umgebung, die Sie aktualisieren.
    
    Wenden Sie Ihre Überschreibungen auf alle Umgebungen gleichzeitig an und prüfen Sie den Abschluss:
    apigeectl apply -f overrides_1.3.yaml --all-envs
    
    kubectl -n namespace get pods
  In den meisten Demo- oder experimentellen Umgebungen können Sie die Überschreibungen auf alle Komponenten gleichzeitig anwenden. Wenn Ihre Demo-/experimentelle Umgebung groß und komplex ist oder eine Produktionsumgebung genau nachahmt, sollten Sie die Anleitung zur Aktualisierung von Produktionsumgebungen verwenden.
  1. apigeectl apply -f overrides_1.3.yaml
  2. Prüfen Sie den Status:
    apigeectl check-ready -f overrides_1.3.yaml
  Weitere Informationen finden Sie unter GKE Hybrid-Einrichtung – Schritt 5: Hybrid in GKE installieren.
5. Sobald hybrid 1.3 eingerichtet und ausgeführt wurde, prüfen Sie, ob alle Cassandra-Knoten (alt und neu) zum selben Cassandra-Cluster gehören. Führen Sie den folgenden Befehl auf einem der Cassandra-Knoten aus:
```
kubectl -n namespace get pods
kubectl -n namespace exec old Cassandra pod -- nodetool status
```
  In der folgenden Beispielausgabe stammt 10.68.8.24 von Version 1.2.0 und ist die Knoten-IP, die Sie als externalSeedHost verwendet haben. 10.68.7.11 stammt von Version 1.3.6:
```
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.68.8.24  379.41 KiB  256          50.8%             11bbd43b-af64-464b-a96d-0d6dd0521de1  ra-1
UN  10.68.7.11  1.35 MiB    256          49.2%             0b4d9e08-f353-413a-b4a9-7d18a8d07e58  ra-1
```
  Wenn sie nicht im selben Cluster sind, prüfen Sie den externalSeedHost-Wert.
6. Wenn alle Pods ausgeführt werden, entfernen Sie externalSeedHost aus der Überschreibungsdatei und führen Sie apigeectl apply mit der Option --datastore noch einmal aus:
```
apigeectl apply --datastore -f overrides_1.3.6.yaml
```
Bereinigen

Nachdem Sie geprüft haben, ob alle Pods fehlerfrei sind und die ASM-Endpunkte für die neue Installation gültig sind, können Sie Folgendes bereinigen:
- Hybrid 1.2-Ressourcen.
- Die ältere Cassandra-Instanz
- Istio 1.4.6-Ressourcen
Hybrid 1.2.0-Ressourcen löschen
Hinweis: Für diese Verfahren ist der apigeectl-Version 1.2-Befehl in Ihrem gesicherten Verzeichnis erforderlich. Wenn Sie eine weitere Kopie von apigeectl-Version 1.2 herunterladen müssen, können Sie den folgenden Befehl verwenden:
```
curl -LO \
    https://storage.googleapis.com/apigee-public/apigee-hybrid-setup/1.2.0/apigeectl_your_system.tar.gz
```
Dabei steht your_system für linux_32, linux_64, mac_32 oder mac_64.
1. Entfernen Sie die Angaben für das Virtualhost-Routing 1.2.0:
```
$APIGEECTL_HOME-v1.2/apigeectl delete -s virtualhost -f 1.2.0_overrides.yaml
```
  Dabei ist $APIGEECTL_HOME-v1.2 das Verzeichnis, in dem Sie das Verzeichnis der apigeectl-Version 1.2 gesichert haben:
2. Wenn der Endpunkt weiterhin wie erwartet funktioniert und Sie bestätigt haben, dass alle 1.3.0-Komponenten funktionieren, führen Sie den folgenden Befehl aus, um die Ressourcen der Hybrid-Version 1.2.0 zu löschen:
```
$APIGEECTL_HOME-v1.2/apigeectl delete -c "mart,connect-agent,synchronizer,runtime,udca,metrics,logger" \
  -f 1.2.0_overrides.yaml
```
Ältere Cassandra-Instanz deaktivieren
1. cd in das neu installierte Verzeichnis apigeectl.
2. Führen Sie das Skripttools/cas_cleanup.sh aus:
  Dieses Skript legt den alten Cassandra-Pod aus dem Cassandra-Ring still, löscht alte STS und löscht die PVCs.
```
bash cas_cleanup.sh Apigee namespace
```
Istio-Version 1.4.6-Ressourcen löschen

Hinweis: Durch das Löschen der Istio-Version 1.4.6 wird auch der MART-Ingress gelöscht. Der MART-Ingress wird in Apigee Hybrid Version 1.3 durch Apigee Connect ersetzt.
1. Führen Sie den folgenden Befehl aus, um die neuesten Istio-Ressourcen der Version 1.1.4.6 zu löschen:
```
kubectl delete all -n istio-system --selector \
  'app in (apigee-mart-istio-ingressgateway, galley, security, istio-nodeagent, istio-mixer, sidecarInjectorWebhook, istio-mixer)'
```
2. Führen Sie die folgenden Befehle aus, um ältere Jobs aus der Istio 1.4.6-Installation zu löschen:
```
kubectl -n istio-system delete job istio-init-crd-10-1.4.6
kubectl -n istio-system delete job istio-init-crd-11-1.4.6
kubectl -n istio-system delete job istio-init-crd-14-1.4.6
```
Das wars! Sie haben erfolgreich ein Upgrade auf die Apigee Hybrid-Version 1.3.6 ausgeführt.

Upgrade von Apigee Hybrid auf Version 1.3.6 ausführen

Upgrade auf Version 1.3.6 – Übersicht.

Voraussetzung

Vorbereitung

Klicken Sie hier, um ein Beispiel für die Verwendung von Umgebungsgruppen als Ersatz für routingRules zu sehen.

Istio und Cert Manager aktualisieren

Upgrade von Istio 1.4.6 auf ASM 1.5.7 oder höher ausführen

Cert Manager aktualisieren

Hybrid-Laufzeit installieren

Bereinigen

Hybrid 1.2.0-Ressourcen löschen

Ältere Cassandra-Instanz deaktivieren

Istio-Version 1.4.6-Ressourcen löschen

Klicken Sie hier, um ein Beispiel für die Verwendung von Umgebungsgruppen als Ersatz für `routingRules` zu sehen.