Upgrade von Apigee Hybrid auf Version 1.16 ausführen

Dieses Verfahren behandelt das Upgrade von der Apigee Hybrid-Version 1.15.x auf die Apigee Hybrid-Version 1.16.0.

Änderungen von Apigee Hybrid v1.15

Bitte beachten Sie die folgenden Änderungen:

  • Seccomp-Profile: Ab Version 1.16 bietet Apigee Hybrid die Möglichkeit, Seccomp-Profile auf Ihre Laufzeitkomponenten anzuwenden. Dadurch wird die Sicherheit Ihrer Bereitstellung erheblich verbessert. Mit dieser Funktion können Apigee-Administratoren und Sicherheitsteams die Systemaufrufe einschränken, die ein containerisierter Prozess an den Kernel des Hosts senden kann. Wenn Sie einen Container auf die erforderlichen Systemaufrufe beschränken, können Sie Folgendes erreichen:
    • Sicherheit erhöhen: Das Risiko von Container-Breakouts und Rechteausweitungen verringern.
    • Prinzip der geringsten Berechtigung erzwingen: Stellen Sie sicher, dass Komponenten nur Zugriff auf die Systemaufrufe haben, die für ihren Betrieb erforderlich sind.
    • Compliance-Anforderungen erfüllen: Bietet eine wichtige Kontrollfunktion, um strenge Sicherheits-Compliance-Anforderungen zu erfüllen.
    Weitere Informationen finden Sie unter Seccomp-Profile für die Pod-Sicherheit konfigurieren.
  • Entfernung von UDCA in Apigee Hybrid: In Apigee Hybrid Version 1.16 wurde die UDCA-Komponente (Unified Data Collection Agent) entfernt. Die Verantwortung für das Senden von Analyse-, Trace- und Bereitstellungsstatusdaten an die Apigee-Steuerungsebene wird jetzt über eine Google Cloud Pub/Sub-basierte Datenpipeline übernommen. Die Pub/Sub-basierte Datenpipeline ist seit Apigee Hybrid Version 1.14.0 der Standardmechanismus für die Datenerfassung.
  • apigee-guardrails-Dienstkonto: In Version 1.16.0 wird in Apigee Hybrid ein apigee-guardrails-Google-IAM-Dienstkonto eingeführt. Dies wird vom apigee-operator-Diagramm während der Installation verwendet, um zu prüfen, ob alle erforderlichen APIs in Ihrem Projekt aktiviert sind.

    Weitere Informationen:

  • Unterstützung für Cert Manager-Release 1.18 und 1.19: Apigee Hybrid v1.16 unterstützt Cert Manager-Release 1.18 und Release 1.19. In cert-manager-Version 1.18 wurde der Standardwert von Certificate.Spec.PrivateKey.rotationPolicy geändert. Das kann sich auf den Traffic auswirken. Wenn Sie ein Upgrade von einer früheren Version von Apigee Hybrid durchführen und auf cert-manager-Version 1.18 oder höher aktualisieren, folgen Sie der Anleitung unter cert-manager aktualisieren in diesem Leitfaden.

Weitere Informationen zu den Funktionen in Hybrid-Version 1.16 finden Sie in den Versionshinweisen zu Apigee Hybrid v1.16.0.

Vorbereitung

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

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

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

    Diese Funktion ist ausschließlich im Abo 2024 verfügbar und unterliegt den Berechtigungen, die im Rahmen dieses Abos gewährt werden. Weitere Informationen zu dieser Funktion finden Sie unter Erweiterte Proxylimits pro Umgebung.

  • Das Upgrade auf Apigee Hybrid-Version 1.16 erfordert möglicherweise Ausfallzeiten.

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

    Apigee empfiehlt, alle Cluster so schnell wie möglich zu aktualisieren, um Auswirkungen auf die Produktion zu reduzieren. Es gibt keine zeitliche Begrenzung dafür, wann nach dem ersten Cluster alle weiteren Cluster aktualisiert werden müssen. Bis zur Aktualisierung aller verbleibenden Cluster funktioniert die Cassandra-Sicherung und -Wiederherstellung jedoch nicht mit gemischten Versionen. Beispielsweise kann eine Sicherung von Hybrid 1.15 nicht zum Wiederherstellen einer Hybrid 1.16-Instanz verwendet werden.

  • Änderungen an der Verwaltungsebene müssen während eines Upgrades nicht vollständig angehalten werden. Alle erforderlichen vorübergehenden Änderungen an der Verwaltungsebene sind unten in der Upgradeanleitung aufgeführt.

Upgrade auf Version 1.16.0 – Übersicht

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

  1. Bereiten Sie das Upgrade vor..
  2. Installieren Sie die Hybrid-Laufzeitversion 1.16.0.

Upgrade auf Version 1.16 vorbereiten

Hybridinstallation sichern

  1. 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%
  2. Erstellen Sie eine Sicherungskopie Ihres $APIGEE_HELM_CHARTS_HOME/-Verzeichnisses der Version 1.15. 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.15-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
  3. Sichern Sie Ihre Cassandra-Datenbank entsprechend der Anleitung unter Cassandra-Sicherung und -Wiederherstellung.
  4. Achten Sie darauf, dass sich Ihr TLS-Zertifikat und die Schlüsseldateien (.crt, .key und/oder .pem) im Verzeichnis $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/ befinden.

Aktualisieren Sie Ihre Kubernetes-Version

Prüfen Sie die Version Ihrer Kubernetes-Plattform und führen Sie bei Bedarf ein Upgrade Ihrer Kubernetes-Plattform auf eine Version durch, die sowohl von Hybrid 1.15 als auch von Hybrid 1.16 unterstützt wird. Weitere Informationen finden Sie in der Dokumentation der Plattform.

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

kustomization.yaml für einen benutzerdefinierten Apigee-Namespace bearbeiten

Wenn Ihr Apigee-Namespace nicht apigee ist, bearbeiten Sie die apigee-operator/etc/crds/default/kustomization.yaml-Datei und ersetzen Sie den namespace-Wert durch Ihren Apigee-Namespace.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: APIGEE_NAMESPACE

Wenn Sie apigee als Namespace verwenden, müssen Sie die Datei nicht bearbeiten.

  • Installieren Sie die aktualisierten Apigee-CRDs:

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

    2. 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
    3. Prüfen Sie die Installation mit dem kubectl get crds-Befehl: 
      kubectl get crds | grep apigee

      Ihre Ausgabe sollte in etwa so aussehen:

      apigeedatastores.apigee.cloud.google.com                    2024-08-21T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2024-08-21T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2024-08-21T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2024-08-21T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2024-08-21T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2024-08-21T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2024-08-21T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2024-08-21T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2024-08-21T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2024-08-21T14:48:35Z

  • Prüfen Sie die Labels auf den Clusterknoten. Standardmäßig plant Apigee Daten-Pods auf Knoten mit dem Label cloud.google.com/gke-nodepool=apigee-data und Laufzeit-Pods auf Knoten mit dem Label cloud.google.com/gke-nodepool=apigee-runtime. Sie können die Knotenpoollabels in der Datei overrides.yaml anpassen.

    Weitere Informationen finden Sie unter Dedizierte Knotenpools konfigurieren.

    • apigee-guardrails-Dienstkonto einrichten

    Ab Hybrid v1.16 ist das Dienstkonto apigee-guardrails erforderlich, um das apigee-operator-Diagramm zu aktualisieren.

    Wählen Sie im folgenden Verfahren den Typ der Dienstkonto-Authentifizierung aus, die Sie verwenden.

    1. Prüfen Sie, ob Sie create-service-account ausführen können. Wenn Sie gerade die Diagramme heruntergeladen haben, befindet sich die Datei create-service-account möglicherweise nicht in einem ausführbaren Modus. Führen Sie im Verzeichnis APIGEE_HELM_CHARTS_HOME den folgenden Befehl aus: 
      ./apigee-operator/etc/tools/create-service-account --help

      Wenn in der Ausgabe permission denied angegeben ist, müssen Sie die Datei ausführbar machen, z. B. mit chmod in Linux, MacOS oder UNIX oder im Windows Explorer oder mit dem Befehl icacls in Windows. Beispiel: 

      chmod +x ./apigee-operator/etc/tools/create-service-account
    2. Erstellen Sie das apigee-guardrails-Dienstkonto:

      Kubernetes-Secrets

      ./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts

      Mit diesem Befehl wird das Dienstkonto apigee-guardrails erstellt und der Schlüssel in das Verzeichnis service-accounts/ heruntergeladen.

      JSON-Dateien

      ./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir ./apigee-operator/

      Mit diesem Befehl wird das Dienstkonto apigee-guardrails erstellt und der Schlüssel in das Diagrammverzeichnis apigee-operator/ heruntergeladen.

      Vault

      ./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts

      Mit diesem Befehl wird das Dienstkonto apigee-guardrails erstellt und der Schlüssel in das Verzeichnis service-accounts/ heruntergeladen.

      WIF für GKE

      ./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts

      Mit diesem Befehl wird das Dienstkonto apigee-guardrails erstellt und der Schlüssel in das Verzeichnis apigee-operator/etc/tools/service-accounts/ heruntergeladen. Sie benötigen die heruntergeladene Schlüsseldatei nicht und können sie löschen.

      WIF auf anderen Plattformen

      ./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts

      Mit diesem Befehl wird das Dienstkonto apigee-guardrails erstellt und der Schlüssel in das Verzeichnis service-accounts/ heruntergeladen.
    3. Authentifizierung für das apigee-guardrails-Dienstkonto einrichten:

      Kubernetes-Secrets

      Erstellen Sie das Kubernetes-Secret mit der Dienstkontoschlüsseldatei apigee-guardrails im Verzeichnis service-accounts/:

      kubectl create secret generic apigee-guardrails-svc-account \
    --from-file="client_secret.json=$APIGEE_HELM_CHARTS_HOME/service-accounts/$PROJECT_ID-apigee-guardrails.json" \
    -n $APIGEE_NAMESPACE

      Fügen Sie der Datei overrides.yaml Folgendes hinzu:

      guardrails:
  serviceAccountRef: apigee-guardrails-svc-account

      JSON-Dateien

      Fügen Sie Ihrer Datei overrides.yaml Folgendes hinzu und verwenden Sie dabei den Pfad zur Dienstkontoschlüsseldatei apigee-guardrails im Verzeichnis apigee-operator/:

      guardrails:
  serviceAccountPath: $PROJECT_ID-apigee-guardrails.json

      Vault

      1. Aktualisieren Sie das Vault-Secret secret/data/apigee/orgsakeys, um einen guardrails-Eintrag mit dem Inhalt der Dienstkontoschlüsseldatei apigee-guardrails hinzuzufügen. 
        vault kv patch secret/apigee/orgsakeys guardrails="$(cat ./service-accounts/hybrid115-apigee-guardrails.json)"
      2. Das Kubernetes-Dienstkonto (Kubernetes service account, KSA) für Guardrails hat den Namen apigee-operator-guardrails-sa. Fügen Sie den organisationsspezifischen Dienstkonten, die an die Rolle apigee-orgsakeys in Vault gebunden sind, die KSA für Guardrails hinzu.
        1. Aktuelle Liste der KSA-Bindungen abrufen: 
          vault read auth/kubernetes/role/apigee-orgsakeys

          Die Ausgabe sollte das folgende Format haben:

          Key                                         Value
---                                         -----
alias_name_source                           serviceaccount_uid
bound_service_account_names                 BOUND_SERVICE_ACCOUNT_NAMES
bound_service_account_namespace_selector    n/a
bound_service_account_namespaces            APIGEE_NAMESPACE

          In der Ausgabe ist BOUND_SERVICE_ACCOUNT_NAMES eine Liste mit durch Kommas getrennten Dienstkontonamen. Fügen Sie apigee-operator-guardrails-sa der Liste der Namen hinzu, z. B. (ohne die zur besseren Lesbarkeit eingefügten Zeilenumbrüche):

          apigee-manager,apigee-cassandra-default,apigee-cassandra-backup-sa,
apigee-cassandra-restore-sa,apigee-cassandra-schema-setup-myhybrido
rg-5b044c1,apigee-cassandra-schema-val-myhybridorg-5b044c1,apigee-c
assandra-user-setup-myhybridorg-5b044c1,apigee-mart-myhybridorg-5b0
44c1,apigee-mint-task-scheduler-myhybridorg-5b044c1,apigee-connect-
agent-myhybridorg-5b044c1,apigee-watcher-myhybridorg-5b044c1,apigee
-metrics-apigee-telemetry,apigee-open-telemetry,apigee-synchronizer
-myhybridorg-dev-ee52aca,apigee-runtime-telemetry-collector-apigee-
telemetry,apigee-logger-apigee-e-myhybrridorg-dev-ee52aca,apigee-sy
nchronizer-myhybridog-prod-2d0221c,apigee-runtime-myhybridorg-prod-
2d0221c,apigee-operator-guardrails-sa
        2. Aktualisieren Sie die Bindungen an die Rolle apigee-orgsakeys mit der aktualisierten Liste der Dienstkontonamen: 
          vault write auth/kubernetes/role/apigee-orgsakeys \
  bound_service_account_names=UPDATED_BOUND_SERVICE_ACCOUNT_NAMES \
  bound_service_account_namespaces=APIGEE_NAMESPACE \
  policies=apigee-orgsakeys-auth \
  ttl=1m
      3. „Guardrails“ für die SecretProviderClass hinzufügen
        1. Bearbeiten Sie die Datei spc-org.yaml.
        2. Fügen Sie unter spec.parameters.objects einen Eintrag für wichtige Informationen hinzu: 
                - objectName: "guardrails"
        secretPath: ""
        secretKey: ""
        3. So aktualisieren Sie Ihr SecretProviderClass: 
          kubectl -n APIGEE_NAMESPACE apply -f spc-org.yaml

      WIF für GKE

      Das Kubernetes-Dienstkonto (Kubernetes service account, KSA) für Guardrails hat den Namen apigee-operator-guardrails-sa. Erstellen Sie die Bindung für das apigee-guardrails-Google-Dienstkonto (GSA) mit dem folgenden Befehl:

      gcloud iam service-accounts add-iam-policy-binding apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:$PROJECT_ID.svc.id.goog[$APIGEE_NAMESPACE/apigee-operator-guardrails-sa]" \
    --project $PROJECT_ID

      Fügen Sie der Datei overrides.yaml Folgendes hinzu:

      guardrails:
  gsa: apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com

      WIF auf anderen Plattformen

      Das Kubernetes-Dienstkonto (Kubernetes service account, KSA) für Guardrails hat den Namen apigee-operator-guardrails-sa. Sie müssen dem KSA für die Guardrails Zugriff zum Identitätswechsel des apigee-guardrails-Google-Dienstkontos (GSA) gewähren und Ihre Überschreibungen so konfigurieren, dass eine Datei mit Anmeldedaten verwendet wird.

      1. Gewähren Sie dem KSA mit dem folgenden Befehl Zugriff, um die Identität des GSA zu übernehmen:

        Vorlage

        gcloud iam service-accounts add-iam-policy-binding \
  apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
  --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/system:serviceaccount:APIGEE_NAMESPACE:apigee-operator-guardrails-sa" \
  --role=roles/iam.workloadIdentityUser

        Beispiel

        gcloud iam service-accounts add-iam-policy-binding \
  apigee-guardrails@my-project.iam.gserviceaccount.com \
  --member="principal://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/my-pool/subject/system:serviceaccount:apigee:apigee-operator-guardrails-sa" \
  --role=roles/iam.workloadIdentityUser

        Wobei:

        • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
        • PROJECT_NUMBER ist die Projektnummer des Projekts, in dem Sie den Workload Identity-Pool erstellt haben.
        • POOL_ID ist die ID des Workload Identity-Pools.
        • APIGEE_NAMESPACE: Der Namespace, in dem Apigee Hybrid installiert ist.
      2. Erstellen Sie eine Konfigurationsdatei für Anmeldedaten für das Dienstkonto apigee-guardrails: 
        gcloud iam workload-identity-pools create-cred-config \
  projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
  --service-account=apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
  --credential-source-file=/var/run/service-account/token \
  --credential-source-type=text \
  --output-file=apigee-guardrails-credential-configuration.json

        Dabei ist WORKLOAD_PROVIDER_ID die ID Ihres Workload Identity-Poolanbieters.

      3. Konfigurieren Sie apigee-guardrails für die Verwendung der Identitätsföderation von Arbeitslasten mit einer der folgenden Methoden:

        WIF: secrets

        1. Erstellen Sie für jede Konfigurationsdatei mit Anmeldedaten mit der Anmeldedaten-Quelldatei ein neues Kubernetes-Secret. 
          kubectl create secret -n APIGEE_NAMESPACE generic guardrails-workload-identity-secret --from-file="client_secret.json=./apigee-guardrails-credential-configuration.json"
        2. Ersetzen Sie den Wert von serviceAccountRef durch das neue Secret: 
          guardrails:
  serviceAccountRef: guardrails-workload-identity-secret

        WIF: Dateien

        Verschieben Sie die generierte Datei apigee-guardrails-credential-configuration.json in Ihr Diagrammverzeichnis apigee-operator/.

        Fügen Sie der Datei overrides.yaml Folgendes hinzu:

        guardrails:
  serviceAccountPath: apigee-guardrails-credential-configuration.json

        WIF: Vault

        Aktualisieren Sie den Dienstkontoschlüssel für guardrails in Vault mit der entsprechenden Anmeldedaten-Quelldatei: 

        SAKEY=$(cat .apigee-guardrails-credential-configuration.json); kubectl -n APIGEE_NAMESPACE exec vault-0 -- vault kv patch secret/apigee/orgsakeys guardrails="$SAKEY"

        Weitere Informationen finden Sie unter Storing service account keys in Hashicorp Vault.

    Cert Manager aktualisieren

    Apigee Hybrid v1.16 unterstützt Cert Manager-Releases 1.16 bis 1.19. In cert-manager 1.18 wurde eine Änderung vorgenommen, die zu Problemen mit Ihrem Traffic führen kann. In cert-manager-Version 1.18 wurde der Standardwert von Certificate.Spec.PrivateKey.rotationPolicy von Never in Always geändert. Bei aktualisierten Apigee Hybrid-Installationen kann dies zu Problemen mit Ihrem Traffic führen. Wenn Sie ein Upgrade auf Hybrid-Version 1.16 von einer früheren Version ausführen, müssen Sie entweder Ihr apigee-ca-Zertifikat bearbeiten, um diese Änderung zu berücksichtigen, oder Ihre Version von cert-manager auf Release 1.17.x oder niedriger beibehalten.

    Bevor Sie ein Upgrade von cert-manager auf Version 1.18 oder 1.19 durchführen, bearbeiten Sie das apigee-ca-Zertifikat, um den Wert von Certificate.Spec.PrivateKey.rotationPolicy auf Never festzulegen.

    1. Prüfen Sie den Inhalt Ihres apigee-ca-Zertifikats, um zu sehen, ob rotationPolicy festgelegt ist: 
      kubectl get certificate apigee-ca -n cert-manager -o yaml

      Suchen Sie in der Ausgabe nach den Werten unter spec.privateKey:

      ...
spec:
  commonName: apigee-hybrid
  duration: 87600h
  isCA: true
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: apigee-root-certificate-issuer
  privateKey:
    algorithm: ECDSA
    # Note: rotationPolicy would appear here if it is set.
    size: 256
  secretName: apigee-ca
...
    2. Wenn rotationPolicy nicht oder auf Always festgelegt ist, bearbeiten Sie das apigee-ca-Zertifikat, um den Wert von rotationPolicy auf Never festzulegen:
      1. Führen Sie zuerst einen Probelauf aus: 
        kubectl patch Certificate \
  --dry-run=server \
  -n cert-manager \
  --type=json \
  -p='[{"op": "replace", "path": "/spec/privateKey/rotationPolicy", "value": "Never"}]' \
  -o=yaml \
  apigee-ca
      2. Patchen Sie das Zertifikat: 
        kubectl patch Certificate \
  -n cert-manager \
  --type=json \
  -p='[{"op": "replace", "path": "/spec/privateKey/rotationPolicy", "value": "Never"}]' \
  -o=yaml \
  apigee-ca
    3. Prüfen Sie, ob der Wert von rotationPolicy jetzt auf Never gesetzt ist: 
      kubectl get certificate apigee-ca -n cert-manager -o yaml

      Die Ausgabe sollte in etwa so aussehen:

      ...
spec:
  commonName: apigee-hybrid
  duration: 87600h
  isCA: true
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: apigee-root-certificate-issuer
  privateKey:
    algorithm: ECDSA
    rotationPolicy: Never
    size: 256
  secretName: apigee-ca
...
    4. Aktualisieren Sie Cert Manager. Mit dem folgenden Befehl wird cert-manager v1.19.2 heruntergeladen und installiert: 
      kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml

      Eine Liste der unterstützten Versionen finden Sie unter Unterstützte Plattformen und Versionen: cert-manager.

    Weitere Informationen:

    Hybrid 1.16.0-Laufzeit installieren

    1. 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.
    2. Aktualisieren Sie den Apigee-Operator/-Controller:

      Probelauf:

      helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

      Aktualisieren Sie das Diagramm:

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

      Prüfen Sie die Installation des Apigee-Operators:

      helm ls -n APIGEE_NAMESPACE

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

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

      kubectl -n APIGEE_NAMESPACE get deploy apigee-controller-manager

      NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h
    3. Aktualisieren Sie den Apigee-Datenspeicher:

      Probelauf:

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

      Aktualisieren Sie das Diagramm:

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

      Prüfen Sie dessen Status, um sicherzustellen, dassapigeedatastore aktiv ist.

      kubectl -n APIGEE_NAMESPACE get apigeedatastore default

      NAME      STATE       AGE
default   running    2d
    4. Aktualisieren Sie die Apigee-Telemetrie:

      Probelauf:

      helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

      Aktualisieren Sie das Diagramm:

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

      Prüfen Sie den Status, um sicherzustellen, dass dieses Element aktiv ist:

      kubectl -n APIGEE_NAMESPACE get apigeetelemetry apigee-telemetry

      NAME               STATE     AGE
apigee-telemetry   running   2d
    5. Führen Sie ein Upgrade von Apigee Redis durch:

      Probelauf:

      helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

      Aktualisieren Sie das Diagramm:

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

      Prüfen Sie den Status, um sicherzustellen, dass dieses Element aktiv ist:

      kubectl -n APIGEE_NAMESPACE get apigeeredis default

      NAME      STATE     AGE
default   running   2d
    6. Aktualisieren Sie den Apigee-Ingress-Manager:

      Probelauf:

      helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

      Aktualisieren Sie das Diagramm:

      helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

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

      kubectl -n APIGEE_NAMESPACE get deployment apigee-ingressgateway-manager

      NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d
    7. Führen Sie ein Upgrade der Apigee-Organisation durch:

      Probelauf:

      helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

      Aktualisieren Sie das Diagramm:

      helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

      Prüfen Sie den Status der entsprechenden Organisation, um sicherzustellen, dass sie aktiv ist:

      kubectl -n APIGEE_NAMESPACE get apigeeorg

      NAME                      STATE     AGE
apigee-my-org-my-env      running   2d
    8. Führen Sie einen Upgrade für die Umgebung aus.

      Sie dürfen jeweils nur eine Umgebung installieren. Geben Sie die Umgebung mit --set env=ENV_NAME an.

      Probelauf:

      helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
      • ENV_RELEASE_NAME ist ein Name, der verwendet wird, um Installationen und Upgrades des Diagramms apigee-env nachzuverfolgen. Dieser Name muss sich von den anderen Helm-Release-Namen in Ihrer Installation unterscheiden. Normalerweise entspricht dies ENV_NAME. Wenn Ihre Umgebung jedoch denselben Namen wie Ihre Umgebungsgruppe hat, müssen Sie unterschiedliche Release-Namen für die Umgebung und die Umgebungsgruppe verwenden, z. B. dev-env-release und dev-envgroup-release. Weitere Informationen zu Releases in Helm finden Sie in der Helm-Dokumentation unter Three big concepts.
      • ENV_NAME ist der Name der Umgebung, die Sie aktualisieren.
      • OVERRIDES_FILE ist die neue Überschreibungsdatei für Version 1.16.0.

      Aktualisieren Sie das Diagramm:

      helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE

      Prüfen Sie, ob sie aktiv ist, indem Sie den Status der entsprechenden Umgebung prüfen:

      kubectl -n APIGEE_NAMESPACE get apigeeenv

      NAME                          STATE       AGE   GATEWAYTYPE
apigee-my-org-my-env          running     2d
    9. Führen Sie ein Upgrade der Umgebungsgruppen (virtualhosts) durch.
      1. Sie dürfen jeweils nur eine Umgebungsgruppe (virtualhost) upgraden. Geben Sie die Umgebungsgruppe mit --set envgroup=ENV_GROUP_NAME an: Wiederholen Sie folgende Befehle für alle Umgebungsgruppen, die in der Datei overrides.yaml erwähnt werden:

        Probelauf:

        helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server

        ENV_GROUP_RELEASE_NAME ist der Name, mit dem Sie zuvor das Diagramm apigee-virtualhost installiert haben. Normalerweise ist es ENV_GROUP_NAME.

        Aktualisieren Sie das Diagramm:

        helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
      2. Prüfen Sie den Status der ApigeeRoute (AR).

        Durch die Installation von virtualhosts wird ApigeeRouteConfig (ARC) erstellt. Dieses Element erstellt intern ApigeeRoute (ARC), nachdem der Apigee-Watcher die Umgebungsgruppendetails aus der Steuerungsebene abgerufen hat. Prüfen Sie daher, ob die entsprechende AR ausgeführt wird: 

        kubectl -n APIGEE_NAMESPACE get arc

        NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
         
        kubectl -n APIGEE_NAMESPACE get ar

        NAME                                        STATE     AGE
apigee-org1-dev-egroup-123abc               running   2d
    10. Nachdem Sie überprüft haben, dass alle Installationen erfolgreich aktualisiert wurden, löschen Sie die ältere apigee-operator-Version aus dem apigee-system-Namespace.
      1. Deinstallieren Sie den alten operator-Release: 
        helm delete operator -n apigee-system
      2. Löschen Sie den Namespace apigee-system: 
        kubectl delete namespace apigee-system
    11. Führen Sie noch einmal ein Upgrade von operator in Ihrem Apigee-Namespace durch, um die gelöschten Ressourcen mit Clusterbereich neu zu installieren: 
      helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

    Rollback zu einer vorherigen Version durchführen

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

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

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

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

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

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

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

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

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

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

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

      helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.15_OVERRIDES_FILE
    2. Erstellen Sie den Namespace apigee-system. 
      kubectl create namespace apigee-system
    3. Patchen Sie die Ressourcenannotation zurück auf den Namespace apigee-system. 
      kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-namespace='apigee-system'
    4. Wenn Sie auch den Release-Namen geändert haben, aktualisieren Sie die Annotation mit dem Release-Namen operator. 
      kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='operator'
    5. Installieren Sie apigee-operator wieder im Namespace apigee-system. 
      helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.15_OVERRIDES_FILE
    6. Machen Sie die CRDs rückgängig, indem Sie die älteren CRDs neu installieren. 
      kubectl apply -k apigee-operator/etc/crds/default/ \
  --server-side \
  --force-conflicts \
  --validate=false
    7. Bereinigen Sie die apigee-operator-Version aus dem APIGEE_NAMESPACE-Namespace, um das Rollback abzuschließen. 
      helm uninstall operator -n APIGEE_NAMESPACE
    8. Einige Ressourcen auf Clusterebene, z. B. clusterIssuer, werden gelöscht, wenn operator deinstalliert wird. Installieren Sie sie mit dem folgenden Befehl neu: 
      helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.15_OVERRIDES_FILE