Neue Installation und Verwaltung von Apigee Hybrid – Vorschau

Nutzerhandbuch zur Vorschau:
Vorschau der neuen Installations- und Verwaltungsverfahren für Apigee Hybrid v1.8.

In diesem Dokument:

Vorschau

Dieses Dokument richtet sich an Apigee-Operator-Identitäten (Nutzer, die Apigee Hybrid-Installationen installieren oder verwalten). Erfahrungen mit der Installation von Apigee Hybrid auf einer der unterstützten Kubernetes-Plattformen ist eine Voraussetzung für die Ausführung der Anleitung in diesem Dokument. Wir empfehlen Ihnen, eine Apigee-Evaluierungsorganisation zu erstellen, um die folgenden Schritte auszuführen.

Feedback

Senden Sie Feedback zu diesem Vorgang an Apigee-hybrid-install-preview@google.com.

Überblick

Die neue Apigee Hybrid-Installation installiert Apigee-Komponenten mithilfe von kubectl und integriert die Installation und Verwaltung von Apigee Hybrid in Kubernetes-Tools zur Konfigurationsorchestrierung wie Kustomize. Die erweiterte Validierung und Sichtbarkeit der installierten Komponenten verbessern die Debug-Fähigkeit und den gesamten Installationsprozess.

Das Installationsskript apigee-hybrid-setup.sh bietet ein einfaches Tool für die grundlegende Installation. Damit können Sie Ihre Hybrid-Installation erstellen und dann an Ihre Anforderungen mit kubectl anpassen oder Ihre Hybrid-Installation mit kubectl ganz neu erstellen. Alle Apigee Hybrid-Konfigurationsattribute werden in YAML-Dateien gespeichert – einer für jede Hauptkomponente. Dies ermöglicht eine genauere Kontrolle Ihrer Hybrid-Installation in Ihrer Kubernetes-Umgebung. Sie finden die Konfigurationsdateien und Installationsskripts im Repository in GitHub.

Änderungen im neuen Installationsprozess

Apigee ändert den Installationsprozess von Apigee Hybrid aus folgenden Gründen:

  • Die neue Methode zur Installation von Apigee Hybrid kann in vorhandene Kubernetes-CI/CD-Tools wie Argo, Flux oder Anthos Config Management eingebunden werden, die keine overrides.yaml-Konfigurationsdatei verwenden.
  • Apigee Hybrid bietet apigeectl, ein Tool für benutzerdefinierte Vorlagen, das (unter anderem) Kubernetes-Manifeste generiert, um Apigee Hybrid in Kubernetes-Clustern zu installieren und zu verwalten. Der neue Installations- und Verwaltungsprozess ähnelt dem von anderen Softwareanbietern.
  • Der neue Prozess ermöglicht eine schnelle Installation. Dafür werden automatisch Dienstkonten mit den erforderlichen Berechtigungen, TLS-Zertifikaten, vorab ausgefüllten Standardeinstellungen und anderen erforderlichen grundlegenden Elementen erstellt.

Vorbereitung

Bevor Sie diese Vorschauinstallation verwenden können, müssen Sie die folgenden Voraussetzungen erfüllen:

Vorschauversion

Diese Vorschau ist für die Apigee Hybrid-Version 1.8.x vorgesehen. Spätere Versionen von Apigee Hybrid werden nicht unterstützt.

Apigee Hybrid-Einrichtung

Bevor Sie mit der tatsächlichen Installation von Apigee Hybrid fortfahren, müssen Sie die Anleitung ausführen, die in den folgenden Abschnitten der Dokumentation aufgeführt ist:

  1. Projekt- und Organisationseinrichtung
  2. Einrichtung der Hybrid-Laufzeit

Tools

Außerdem müssen die folgenden Tools auf Ihre Workstation heruntergeladen und konfiguriert werden:

Gängige Variablen in dieser Anleitung

In diesem Leitfaden werden die folgenden Umgebungsvariablen in mehreren Schritten verwendet. Sie können sie in der Befehlszeile oder mithilfe eines Skripts definieren oder den Text in den Befehlen ersetzen, wenn Sie sie eingeben.

  • APIGEE_NAMESPACE: Ihr Apigee-Namespace. Der Standardwert ist apigee. Sie können aber auch einen anderen Namespace verwenden.
  • CLUSTER_NAME ist der Name des Clusters, in dem Sie Apigee Hybrid installieren. Dies ist der Cluster, den Sie in Schritt 1: Cluster erstellen erstellen.
  • CLUSTER_LOCATION: Die Region Ihres Clusters. Bei den Verfahren in dieser Anleitung wird davon ausgegangen, dass Sie einen regionalen Cluster verwenden. Wenn Sie einen zonalen Cluster verwenden, lesen Sie die Anleitung unter Schritt 1: Cluster erstellen.
  • ENV_GROUP: Der Name der Umgebungsgruppe für Ihre Apigee-Hybridinstallation. Dies ist die Umgebungsgruppe, die Sie in Schritt 3: Umgebungsgruppe erstellen erstellen. Sie können mehrere Umgebungsgruppen erstellen.
  • ENV_NAME: Der Name der Umgebungsgruppe für Ihre Apigee-Hybridinstallation. Dies ist die Umgebungsgruppe, die Sie in Schritt 3: Umgebungsgruppe erstellen erstellen. Sie können mehrere Umgebungsgruppen erstellen.
  • INSTALL_DIR: Das Verzeichnis, in dem Sie Apigee Hybrid installieren. Standardmäßig ist dies das Unterverzeichnis apigee-hybrid-install/ des Verzeichnisses, in das Sie das Installationsprogramm herunterladen, z. B. /myhybrid/apigee-hybrid-install/. Dies ist das Stammverzeichnis für die Dateistruktur, die unter Ordnerstruktur der Apigee Hybrid-Einrichtung dokumentiert ist.
  • INSTANCE_DIR: Das Verzeichnis für eine bestimmte Apigee Hybrid-Instanz. Standardmäßig hat die erste Instanz den Namen instance-1. Das Instanzverzeichnis ist ein Unterverzeichnis von ${INSTALL_DIR}/overlays/instances/. Sie können einen beliebigen Namen für Ihre Hybridinstanzen angeben. Siehe Installation mehrerer Instanzen.
  • ORG_NAME: Der Name Ihrer Apigee Hybrid-Organisation. Dieser muss mit Ihrer Google Cloud-Projekt-ID übereinstimmen. Weitere Informationen finden Sie unter Schritt 2: Organisation erstellen.

Grundlegende Installation von Apigee Hybrid

Um Apigee Hybrid ohne hohe Anpassung schnell zu installieren, können Sie das folgende zweistufige Verfahren verwenden.

  • Eine einzige Umgebung.
  • Eine einzige Umgebungsgruppe.
  • Ein einziges Google Cloud-Dienstkonto wird für alle einzelnen Komponenten erstellt und verwendet.
  • Standardwerte für alle Verschlüsselungsschlüssel und Passwörter.
  1. Einrichtungsdateien herunterladen
  2. Einrichtung ausführen

Einrichtungsdateien herunterladen

Laden Sie die Einrichtungsdateien herunter und bereiten Sie sie vor. Klonen Sie dazu das GitHub-Repository unter https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1:

  1. Klonen Sie das Repository:

    git clone https://github.com/apigee/apigee-hybrid-install.git

  2. Gehen Sie zum Verzeichnis für das geklonte Repository:

    cd apigee-hybrid-install

  3. Erstellen Sie einen Zweig aus dem Tag preview-1:

    git branch preview-1 preview-1
git checkout preview-1

  4. Machen Sie das Einrichtungsskript ausführbar:

    chmod +x ./tools/apigee-hybrid-setup.sh

    Das geklonte Repository hat eine Struktur, die der unter Ordnerstruktur für Apigee Hybrid-Einrichtung beschriebenen ähnelt.

Einrichtung ausführen

Führen Sie das Shell-Skript apigee-hybrid-setup.sh im Ordner tools/ aus.

./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION --org $ORG_NAME --setup-all

Wenn Fehler auftreten, führen Sie das Skript ein zweites Mal aus.

Folgende Optionen können Sie ebenfalls verwenden:

  • --env $ENV_NAME gibt den Namen der Apigee-Umgebung an.
  • --envgroup $ENV_GROUP gibt die Umgebungsgruppe an.
  • --ingress-domain $HOSTNAME gibt den Hostnamen an, den Sie für Ihre Umgebungsgruppe angegeben haben.
  • --gcp-project-id $PROJECT_ID gibt die ID Ihres Google Cloud-Projekts an.

Weitere Optionen finden Sie unter Grundlegendes zum Skript.

Alle Fehler, die während der Ausführung auftreten, werden an die Standardausgabe gesendet.

Sobald das Skript erfolgreich abgeschlossen wurde, haben Sie die grundlegende Hybrid-Installation abgeschlossen. Sie können Ihre Installation testen, indem Sie einen Beispielproxy erstellen, wie unter Neuen API-Proxy erstellen und bereitstellen beschrieben:

Angepasste Apigee Hybrid-Installation

Fortgeschrittene Nutzer, die die Installation genau steuern möchten, können diese Schritte ausführen. Bei vielen der unten aufgeführten Schritte können Sie den Schritt entweder manuell ausführen oder das Shell-Skript verwenden, um den jeweiligen Schritt zu automatisieren:

Einrichtungsdateien herunterladen

Laden Sie die Einrichtungsdateien herunter und bereiten Sie sie vor:

  1. Klonen Sie das GitHub-Repository unter https://github.com/apigee/apigee-hybrid-install/.

    Das geklonte Repository hat eine Struktur, die der unter Ordnerstruktur für Apigee Hybrid-Einrichtung beschriebenen ähnelt.

  2. Wechseln Sie mit cd zum Verzeichnis apigee-hybrid-install/.

  3. Machen Sie das Einrichtungsskript ausführbar:

    chmod +x ./tools/apigee-hybrid-setup.sh

Namespace erstellt

Erstellen Sie in Ihrem Cluster einen Kubernetes-Namespace, der alle Apigee-Clusterkomponenten enthalten soll.

kubectl create namespace apigee

Wenn Sie einen anderen Namen für den Namespace auswählen, können Sie eine der drei folgenden Optionen verwenden:

  • (Empfohlen) Verwenden Sie --namespace={YOUR_NAMESPACE_NAME} und geben Sie unter YAML-Ressourcendateien bearbeiten im Voraus Werte an.

  • Führen Sie die zwei Befehle aus:

    1. Verwenden Sie kpt, um den Apigee-Namespace anzugeben:

      kpt fn eval "${INSTALL_DIR}/overlays/" \
  --image gcr.io/kpt-fn/apply-setters:v0.2.0 -- \
  APIGEE_NAMESPACE="${APIGEE_NAMESPACE}"
# This is for replacing the namespace in istio discoveryAddress which cannot be
# achieved with kpt

    2. Verwenden Sie sed, um den Namespace in „istio DiscoveryAddress“ zu ersetzen:

      sed -i -E -e "s/(discoveryAddress: apigee-ingressgateway-manager\.).*(\.svc:15012)/\1${APIGEE_NAMESPACE}\2/" "${INSTALL_DIR}/overlays/controllers/istiod/apigee-istio-mesh-config.yaml"

  • Alternativ können Sie die Ressourcen, die im Namespace Ihrer Wahl erstellt werden sollen, manuell ändern.

Docker-Images aus privaten Repositories verwenden (optional)

Sie können sich dafür entscheiden, nicht die öffentlich gehosteten Images, sondern Images aus Ihren eigenen privaten Repositories zu verwenden:

  1. Im ersten Schritt werden alle Images in Ihr privates Repository übertragen. Dazu führen Sie die Schritte unterapigee-pull-push | Apigee X aus. Standardmäßig werden Images mit der Apigee Hybrid-Version gekennzeichnet, der sie entsprechen. Es wird empfohlen, diese Tags nicht zu bearbeiten. Wir empfehlen außerdem, die Image-Namen nicht zu bearbeiten, damit der endgültige Image-Pfad wie unter Image Hub erläutert erstellt werden kann.

  2. Legen Sie den Wert des Feldes imageHub in der Datei „apigee-hybrid-config.yaml“ auf den privaten Repository-Hostpfad fest. Weitere Informationen finden Sie unter Image-Hub.

    imageHub: "your.private.repo/apigee/hybrid"

Dadurch wird sichergestellt, dass alle Apigee Hybrid-Komponenten die Images aus Ihrem privaten Repository verwenden.

Darüber hinaus können Sie auch ein privates Image für den Controller und für Apigee-Ingress-Gateway verwenden. Dafür müssen Sie die Dateien apigee-controller-deployment.yaml und apigee-ingressgateway-manager-deployment.yaml bearbeiten und alle image-Felder durch das Image aus ihrem privaten Repository ersetzen.

imagePullSecrets konfigurieren (optional)

  1. Erstellen Sie ein Kubernetes-Secret mit den Anmeldedaten zur Authentifizierung bei den privaten Repositories. Informationen zum Erstellen des Secrets finden Sie unter Image aus einer privaten Registry abrufen.
  2. Nachdem das Secret erstellt wurde, müssen Sie lediglich auf dieses Secret verweisen. Dazu bearbeiten Sie die Datei „apigee-hybrid-config.yaml“, legen den Wert des Felds imagePullSecret auf den Namen des zuvor erstellten Secrets fest und aktivieren die Komponente imagePullSecret in der entsprechenden Datei kustomization.yaml.

Wenn Sie die imagePullSecrets an beiden Stellen angeben, hat das in der Datei „apigee-controller-manager.yaml“ vorhandene Vorrang.

Weiterleitungs-Proxy konfigurieren (optional)

Weiterleitungs-Proxys können konfiguriert werden, indem Sie das Feld forwardProxy zur Datei apigee-hybrid-config.yaml hinzufügen. Beispiel:

  forwardProxy: |
    scheme: HTTP
    host: 10.12.0.47
    port: 3128

Ingress-TLS-Zertifikate angeben

Skript verwenden

./tools/apigee-hybrid-setup.sh --create-ingress-tls-certs

Weitere Informationen zu diesem Flag finden Sie unter Grundlegendes zum Skript.

Manuell

Sie müssen TLS-Zertifikate bereitstellen, die für das Istio-Ingress-Gateway verwendet werden. Sie können:

Hier verwenden wir selbst signierte Zertifikate als Beispiel. Selbst signierte Zertifikate können so generiert werden (wenn DOMAIN korrekt festgelegt wurde und mit dem in Ihrer Umgebungsgruppe festgelegten Hostnamen übereinstimmt):

openssl req -nodes -new -x509 -keyout ./tls.key -out ./tls.crt -subj '/CN='$DOMAIN'' -days 3650

Dadurch werden zwei Dateien mit den Namen tls.key und tls.crt erstellt.

Dann müssen Sie ein Secret mit dem folgenden Format erstellen. Sie können kubectl create oder kubectl apply verwenden, wie unter „Benutzerdefiniertes Zertifikat/Schlüssel-Paar für die Zertifikatsignaturstelle verwenden (optional)“ beschrieben:

apiVersion: v1
kind: Secret
metadata:
  name: "{ORG_NAME}-{ENV_GROUP_NAME}"
  namespace: {$APIGEE_NAMESPACE}
type: Opaque
data:
  cert: |
    {BASE64_ENCODED_TLS_CRT}
  key: |
    {BASE64_ENCODED_TLS_KEY}

---

Beispiel für die Erstellung des Secrets mit kubectl create:

kubectl create secret tls {ORG_NAME}-{ENV_GROUP_NAME} \
  --cert="tls.crt" \
  --key="tls.key" \
  -n {$APIGEE_NAMESPACE}

Ingress-Deployment aktualisieren

Zum Erstellen/Ändern von Ingress-Deployments müssen Sie das Feld spec.components.ingressGateways in der benutzerdefinierten Ressource von ApigeeOrganization in bases/initialization/crds/customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml ändern.

Standardmäßig erstellen wir ein Ingress-Deployment mit Standardparametern (Standardwerte werden in den CR-Referenzdokumenten angezeigt):

ingressGateways:
- name: "prod-1"

Beispiele:

A. Ingress-Dienstfelder überschreiben

ingressGateways:
- name: "prod-1"
  serviceSpec:
    annotations:
      {KEY}: ${VALUE}
    loadBalancerIP: ${IP}

B. Min./Max. für Replikate ändern

ingressGateways:
- name: "prod-1"
  ​​autoScaler:
    minReplicas: 4
    maxReplicas: 10

C. Neues Ingress-Deployment hinzufügen

ingressGateways:
- name: "prod-1"
- name: "prod-2"

Benutzerdefinierte Google Cloud-Dienstkonten konfigurieren

Skript verwenden

./tools/apigee-hybrid-setup.sh --create-gcp-sa-and-secrets  --namespace APIGEE_NAMESPACE

Dabei ist APIGEE_NAMESPACE Ihr benutzerdefinierter Namespace. Der Standard-Namespace ist apigee.

Weitere Informationen zu den Flags finden Sie unter Grundlegendes zum Skript.

Manuell

Google Cloud-Dienstkontoschlüssel müssen als Secrets im Cluster gespeichert werden. Die Secret-YAML-Datei sollte die folgende Struktur haben:

apiVersion: v1
kind: Secret
metadata:
  name: "{NAME}"
  namespace: {APIGEE_NAMESPACE}
type: Opaque
data:
  client_secret.json: |
    {BASE64_ENCODED_SA_KEY}

Weitere Informationen zu den erforderlichen Dienstkonten und den Namen der Secrets finden Sie im Abschnitt Google Cloud-Dienstkonten.

Sie können für die Secrets einen anderen Namen auswählen, müssen dann aber eine entsprechende Änderung in der Komponente vornehmen, in der der Secret-Name verwendet wurde. Wenn Sie beispielsweise den Namen des Laufzeitdienstkonto-Secrets von apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME} in my-runtime-svc ändern, müssen Sie in der apigee-environment.yaml-Datei für diese Umgebung eine entsprechende Änderung vornehmen.

Workload Identitys verwenden

Entweder „Benutzerdefinierte Google Cloud-Dienstkonten konfigurieren“ oder „Workload Identitys verwenden“ ist obligatorisch.

Vorbereitung

Prüfen Sie vor der Verwendung von Workload Identitys, ob die Unterstützung Ihres GKE-Clusters aktiviert ist. Siehe Knotenpools aktualisieren | Apigee X.

Workload Identity aktivieren

Im Abschnitt Workload Identitys unter Kustomize und Komponenten finden Sie Details dazu, wie Sie Workload Identitys vor der Installation aktivieren können.

YAML-Ressourcendateien bearbeiten

Für einige Stellen in den Komponenten-YAML-Dateien müssen die richtigen Organisations-, Umgebungs- und Umgebungsgruppennamen vorhanden sein. Sie können diese Werte entweder manuell festlegen oder das Shell-Skript verwenden, um diese Werte automatisch auszufüllen.

Skript verwenden

./tools/apigee-hybrid-setup.sh --fill-values

Initialisierungsressourcen und Controller erstellen

#Additional steps for openshift
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/openshift
//apigee datastore
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/components/openshift-scc/scc.yaml
//telemetry
kubectl apply -f ${INSTANCE_DIR}/overlays/instances/${INSTANCE_DIR}/telemetry/components/openshift-scc/scc.yaml

#Create Apigee initialization kubernetes resources
kubectl apply -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/certificates
kubectl apply --server-side --force-conflicts -k ${INSTALL_DIR}/overlays/initialization/crds
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/webhooks
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/rbac
kubectl apply -k ${INSTALL_DIR}/overlays/initialization/ingress

# Create controller config and controller
kubectl apply -k ${INSTALL_DIR}/overlays/controllers

# Wait for the controllers to be available
kubectl wait deployment/apigee-controller-manager deployment/apigee-ingressgateway-manager -n "${APIGEE_NAMESPACE}" --for=condition=available --timeout=2m

# Create the datastore and redis secrets first and then the rest of the secrets.
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/redis/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/${ENV_NAME}/secrets.yaml
kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/organization/secrets.yaml

Synchronizer-Dienstkonto berechtigen, mit der Steuerungsebene zu interagieren

Führen Sie die Schritte in Schritt 8: Synchronizer-Zugriff aktivieren aus und ersetzen Sie den Namen des Dienstkontos, entweder apigee-non-prod oder apigee-synchronizer, durch apigee-all-sa durch den Namen. des Dienstkontos, das durch den neuen Installationsprozess erstellt wurde.

★ Wichtig: Ändern Sie in der Anleitung unter Synchronizer-Zugriff aktivieren den Namen des Dienstkontos. Andernfalls schlägt der Zugriff für Synchronizer fehl.

Komponenten der Apigee-Datenebene erstellen

Wenn Sie in den vorherigen Schritten die Namen einer der Ressourcen geändert haben, müssen Sie in anderen YAML-Dateien, in denen auf diese Ressource verwiesen wurde, eine entsprechende Änderung vornehmen. Danach verwenden Sie die Befehle im folgenden Beispiel:

# Create the rest of the resources.
kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}

um alle Komponenten zu installieren.

Warten, bis die Ressourcen gestartet wurden

kubectl wait "apigeedatastore/default" \
"apigeeredis/default" \
"apigeeenvironment/${ORG_NAME}-${ENV_NAME}" \
"apigeeorganization/${ORG_NAME}" \
"apigeetelemetry/apigee-telemetry" \
-n "${APIGEE_NAMESPACE}" --for="jsonpath=.status.state=running" --timeout=15m

Installation von cert-manager in einem benutzerdefinierten Namespace anpassen

Passen Sie den Namespace, in dem cert-manager ausgeführt wird, mit dem folgenden Verfahren an.

Wenn cert-manager in Ihrem Cluster in einem anderen Namespace als cert-manager installiert ist, müssen Sie den Namespace aktualisieren, der zum Erstellen des Apigee-Root-Zertifikats verwendet wurde.

  1. Bearbeiten Sie die Datei „customization.yaml“ für die Erstellung des Zertifikats: $INSTALL_DIR/overlays/initialization/certificates/kustomize.yaml

  2. Fügen Sie die folgenden Zeilen am Ende der Datei hinzu:

    - patch: |-
- op: replace
  path: /metadata/namespace
  value: "gk-cert-manager"
target:
group: cert-manager.io
version: v1
kind: Certificate
name: apigee-root-certificate

  3. Speichern Sie die Datei.

Kustomize und Komponenten

Übersicht

Die neue Hybrid-Installation übernimmt die Kustomize-Idologie der Strukturierung von YAML-Dateien in Form von Basen und Overlays.

  • Basen sind von Apigee bereitgestellte Dateien, die sich mit jedem neuen Hybrid-Release ändern können. Sie sollten diese Dateien nicht ändern. Diese Dateien enthalten einige Standardwerte, die von Apigee bereitgestellt werden. Alle Dateien im Ordner bases/ der obersten Ebene enthalten diese Basen.

  • Overlays enthalten die Nutzerkonfiguration und dienen als Mittel, mit dem Sie die in den Basen angegebenen Standardwerte ändern können. Alle Dateien im Ordner overlays/ der obersten Ebene enthalten diese Overlays.

Komponenten verwenden

Die Unterordner im Verzeichnis overlays/ der obersten Ebene wurden so strukturiert, dass Sie ein bestimmtes zusätzliches Feature aktivieren (oder deaktivieren) können, indem Sie bestimmte Zeilen in den kustomization.yaml-Dateien über Kommentarzeichen aktivieren oder deaktiveren.

Die Ordnerstruktur overlays/instances/{INSTANCE_NAME}/telemetry sieht beispielsweise so aus:

telemetry
├── components
│   ├── http-proxy
│   ├── imagepullsecret
│   ├── logger
│   ├── metrics
│   ├── nodeselector
│   ├── openshift-scc
│   ├── workload-identity-logger
│   └── workload-identity-metrics
├── apigee-telemetry.yaml
└── kustomization.yaml

So würden die telemetry/kustomization.yaml-Dateien wahrscheinlich standardmäßig aussehen:

resources:
- apigee-telemetry.yaml

components:
- ./components/metrics
# - ./components/workload-identity-metrics
# - ./components/logger
# - ./components/workload-identity-logger
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/openshift-scc

Wir können sehen, dass ./components/logger auskommentiert ist. Dies bedeutet, dass der Google Cloud-Logger nicht standardmäßig aktiviert wurde. Um dies zu aktivieren, können Sie die Kommentarzeichen für diese Zeile einfach entfernen:

components:

- ./components/logger

Zum Deaktivieren von Messwerten können Sie die Zeile ./components/metrics auskommentieren:

...
components:
...
# - ./components/metrics
…

In den folgenden Abschnitten werden all die verschiedenen Komponenten beschrieben, wann sie verwendet werden und wie sie konfiguriert werden können.

OpenShift

Nutzer, die Apigee Hybrid in einem OpenShift-Cluster installieren möchten, müssen möglicherweise einige Komponenten/Ressourcen aktivieren, bevor die Installation durchgeführt wird. Dies ist erforderlich, wenn Sie nicht das Skript für die Installation verwenden. Die Dateien, die geändert werden müssen, sind:

  • overlays/initialization/openshift/kustomization.yaml Entfernen Sie im Abschnitt resources: das Kommentarzeichen bei:

    # - ../../../bases/initialization/openshift/

  • overlays/instances/{INSTANCE_NAME}/datastore/kustomization.yaml. Entfernen Sie das Kommentarzeichen bei:

    # - ./components/openshift-scc

    und entfernen Sie das Kommentarzeichen beim Feld components:, wenn es noch auskommentiert ist.

  • overlays/instances/{INSTANCE_NAME}/telemetry/kustomization.yaml. Entfernen Sie das Kommentarzeichen bei:

    # - ./components/openshift-scc

    und entfernen Sie das Kommentarzeichen beim Feld components:, wenn es noch auskommentiert ist.

Sie können dann mit den Installationsschritten fortfahren.

imagepullsecret

Diese Komponente kann aktiviert werden, wenn Images in Ihrem privaten Repository gespeichert sind. Zum Abrufen von Images aus einem privaten Repository können Sie ein Kubernetes-Secret mit Ihren Authentifizierungsdetails erstellen und dann auf das Secret darin verweisen. Eine Anleitung finden Sie unter imagePullSecrets konfigurieren (optional). Weitere Informationen finden Sie unter Image aus einer privaten Registry abrufen | Kubernetes in der Kubernetes-Dokumentation.

Verfügbare Sprache:

  • overlays/controllers/apigee-controller
  • overlays/controllers/istiod
  • overlays/instances/{INSTANCE_NAME}/datastore
  • overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
  • overlays/instances/{INSTANCE_NAME}/organization
  • overlays/instances/{INSTANCE_NAME}/redis
  • overlays/instances/{INSTANCE_NAME}/telemetry

Aktivieren:

Entfernen Sie bei Bedarf das Kommentarzeichen der Zeile ./components/imagepullsecret/ in den entsprechenden kustomization.yaml-Dateien.

Erforderliche Änderungen:

  • components/imagepullsecret/patch.yaml
    • ERFORDERLICH: Fügen Sie der Liste in spec.template.spec.imagePullSecrets relevante Secret-Namen hinzu.

Verwendung:

  1. Wenn Sie Apigee Hybrid noch nicht installiert haben, können Sie mit den Installationsschritten fortfahren. Diese Änderungen werden im Prozess angewendet.

  2. Wenn Sie Apigee Hybrid bereits installiert haben, müssen Sie diese neuen Änderungen mit dem folgenden Befehl anwenden:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

nodeselector

Mit dieser Komponente können Sie Pods für eine Apigee-Ressource auf bestimmten Knoten planen. Weitere Informationen finden Sie unter Pods zu Knoten zuweisen | Kubernetes.

Verfügbare Sprache:

  • overlays/controllers/apigee-controller
  • overlays/controllers/istiod
  • overlays/instances/{INSTANCE_NAME}/datastore
  • overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
  • overlays/instances/{INSTANCE_NAME}/organization
  • overlays/instances/{INSTANCE_NAME}/redis
  • overlays/instances/{INSTANCE_NAME}/telemetry

Aktivieren:

Entfernen Sie bei Bedarf das Kommentarzeichen der Zeile ./components/nodeselector in den entsprechenden kustomization.yaml-Dateien.

Erforderliche Änderungen:

  • components/nodeselector/patch.yaml
    • OPTIONAL: Ändern Sie den Wert des Knotenselektorlabels von apigee-runtime oder apigee-data in den gewünschten Wert.

Verwendung:

  1. Wenn Sie Apigee Hybrid noch nicht installiert haben, können Sie mit den Installationsschritten fortfahren. Diese Änderungen werden im Prozess angewendet.

  2. Wenn Sie Apigee Hybrid bereits installiert haben, müssen Sie diese neuen Änderungen mit dem folgenden Befehl anwenden:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

workload-identity

Verschiedene Container in der Apigee Hybrid-Umgebung erfordern Berechtigungen für bestimmte API-Aufrufe an die Apigee-Steuerungsebene bzw. -Verwaltungsebene. Workload Identity ist eines der Elemente, die den Pods (und den darin enthaltenen Containern) diese Berechtigungen gewähren. Nützliche Ressourcen dazu: – Einführung in Workload Identity: Bessere Authentifizierung für Ihre GKE-Anwendungen | Google Cloud-Blog – Workload Identity verwenden | Kubernetes Engine-Dokumentation | Google Cloud

Verfügbare Sprache:

  • overlays/instances/{INSTANCE_NAME}/datastore
  • overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
  • overlays/instances/{INSTANCE_NAME}/organization
  • overlays/instances/{INSTANCE_NAME}/redis
  • overlays/instances/{INSTANCE_NAME}/telemetry

Voraussetzung:

Bevor Sie Workload Identity verwenden können, müssen Sie so die entsprechenden Berechtigungen in Ihrem Google Cloud-Projekt erteilen:

    gcloud iam service-accounts add-iam-policy-binding \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:${ORG_NAME}.svc.id.goog[${APIGEE_NAMESPACE}/${KSA_NAME}]" \
        ${GSA_NAME}@${ORG_NAME}.iam.gserviceaccount.com

Dabei gilt: – ${ORG_NAME}: Der Name Ihrer Apigee-Organisation. – ${APIGEE_NAMESPACE}: Der Kubernetes-Namespace, in dem Apigee-Komponenten installiert wurden. Dies ist normalerweise apigee, sofern der Nutzer dies während der Installation nicht explizit geändert hat. – ${KSA_NAME}: Der Name des Kubernetes-Namespace. Sie müssen diesen Befehl für jedes in Kubernetes-Dienstkonten erwähnte Kubernetes-Dienstkonto ausführen. - ${GSA_NAME}: Der Name des Google Cloud-Dienstkontos. Wenn Sie während der Installation keine Änderungen vorgenommen haben, hat dies den Wert apigee-all-sa. Wenn Sie mehrere Google Cloud-Dienstkonten für einzelne Komponenten einrichten, müssen Sie den KSA_NAME mit dem entsprechenden GSA_NAME abgleichen. Sie können die Tabellen in Google Cloud-Dienstkonten mit Kubernetes-Dienstkonten vergleichen, um die Entsprechungen zu finden.

Aktivieren:

Entfernen Sie bei Bedarf das Kommentarzeichen der Zeile ./components/workload-identity in den entsprechenden kustomization.yaml-Dateien. Beachten Sie, dass innerhalb der Telemetrie separate Workload Identity-Add-ons für die Komponenten metrics und logger vorhanden sind, die einzeln aktiviert werden können.

Verwendung:

  1. Wenn Sie Hybrid noch nicht installiert haben, können Sie die Workload Identity wie im vorherigen Abschnitt erwähnt aktivieren und mit der Installation fortfahren, die Workload Identity dann automatisch verwendet.

  2. Wenn Sie Apigee Hybrid bereits installiert haben, müssen Sie diese neuen Änderungen mit dem folgenden Befehl anwenden:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

http-proxy

Sie können in jeder der folgenden Komponenten einen Proxyserver konfigurieren, sodass der Traffic für diese Komponente den für diese Komponente konfigurierten HTTP-Proxy durchläuft. Sie können den Proxy für jede Apigee-Komponente einzeln konfigurieren.

Verfügbare Sprache:

  • overlays/instances/{INSTANCE_NAME}/datastore
  • overlays/instances/{INSTANCE_NAME}/environments/{ENV_NAME}
  • overlays/instances/{INSTANCE_NAME}/organization
  • overlays/instances/{INSTANCE_NAME}/telemetry

Aktivieren:

Entfernen Sie bei Bedarf das Kommentarzeichen der Zeile ./components/http-proxy/ in den entsprechenden kustomization.yaml-Dateien.

Erforderliche Änderungen:

  • components/http-proxy/patch.yaml Die folgenden Parameter können unter dem spec.httpForwardProxy konfiguriert werden:
    • scheme: ERFORDERLICH Entweder HTTP oder HTTPS
    • host: ERFORDERLICH Die Hostadresse Ihres Proxys
    • port: ERFORDERLICH Die Portnummer
    • username: OPTIONAL Der mit Ihrem Proxy verknüpfte Nutzername
    • password: OPTIONAL Das Passwort für den Zugriff auf den Proxy

Verwendung:

  1. Wenn Sie Apigee Hybrid noch nicht installiert haben, können Sie mit den Installationsschritten fortfahren. Diese Änderungen werden im Prozess angewendet.

  2. Wenn Sie Apigee Hybrid bereits installiert haben, müssen Sie diese neuen Änderungen mit dem folgenden Befehl anwenden:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

logger und metrics

Sie können „logger“ oder „metrics“ in „overlays/instances/{INSTANZNAME}/telemetry“ einzeln aktivieren oder deaktivieren. Standardmäßig ist „logger“ deaktiviert und „metrics“ sind aktiviert. Wenn Sie diese aktivieren oder deaktivieren möchten, entfernen Sie einfach die Kommentarzeichen in den Zeilen in der Datei „telemetry/kustomization.yaml“ bzw. fügen Sie welche hinzu.

gcs-backup und gcs-restore

Diese kustomize-Komponente kann verwendet werden, um eine Sicherung und Wiederherstellung für die Cassandra-Datenbank in Google Cloud Storage durchzuführen.

Verfügbare Sprache:

  • overlays/instances/{INSTANCE_NAME}/datastore

Voraussetzung:

  1. Laden Sie die Google Cloud-Dienstkontoschlüssel für ein Konto herunter, das die Rolle „Storage-Objekt-Administrator“ hat.

    • Wenn Sie das Skript für die Installation verwendet haben, aber keine Workload Identitys haben, können Sie die heruntergeladenen Schlüssel wiederverwenden, die im Ordner „service-accounts“ verfügbar sind, der vom Skript erstellt wird.

    • Sie können auch das Skript „create-service-account.sh“ verwenden, um ein neues Dienstkonto zu erstellen und dessen Schlüssel herunterzuladen:

      ./tools/create-service-accounts=.sh --env prod --profile apigee‑cassandra

  2. Nachdem die Schlüssel heruntergeladen wurden, müssen Sie ein Kubernetes-Secret mit dem Namen „apigee-cassandra-backup-and-restore-gcp-sa-key“ erstellen. Dazu verwenden Sie den folgenden Befehl:

    kubectl create secret generic "apigee-cassandra-backup-and-restore-gcp-sa-key" \
          --from-file="dbbackup_key.json=${PATH_TO_SA_KEY}" \
          -n "${APIGEE_NAMESPACE}"

    Wobei:

    • ${PATH_TO_SA_KEY}: Pfad zu der Datei, die die Dienstkontoschlüssel enthält.
    • ${APIGEE_NAMESPACE}: Kubernetes-Namespace, in dem Apigee-Komponenten installiert sind. Dies ist normalerweise „apigee“, sofern dies nicht während der Installation explizit geändert wurde

Alternativ können Sie die Vorlagendatei „templates/secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml“ verwenden, um dieses Secret zu erstellen.

Aktivieren:

  • Wenn Sie die Sicherung aktivieren möchten, entfernen Sie das Kommentarzeichen in der Zeile "./components/gcs-backup" in der Datenspeicher-Datei „kustomization.yaml“.
  • Wenn Sie eine Sicherung wiederherstellen möchten, entfernen Sie das Kommentarzeichen in der Zeile "./components/gcs-restore" in der Datenspeicher-Datei „kustomization.yaml“.

Änderungen nur für Sicherungen

  • components/gcs-backup/apigee-datastore-patch.yaml
    • ERFORDERLICH: Ändern Sie den Wert der Umgebungsvariablen DATABASE_STORAGE_BUCKET, der das Format gs://BUCKET-NAME hat und auf den Google Cloud Storage-Bucket verweist, in dem Daten gesichert werden müssen. Die Beschreibung entspricht dem hier beschriebenen dbStorageBucket-Element.
  • components/gcs-backup/cron-patch.yaml
    • ERFORDERLICH: Ändern Sie „spec.schedule“, um die Häufigkeit der Sicherung anzugeben. Das Feld akzeptiert das standardmäßige Crontab-Zeitplanformat. Die Beschreibung entspricht dem hier beschriebenen schedule-Element.
    • ERFORDERLICH: Ändern Sie den Wert der Umgebungsvariablen DATABASE_STORAGE_BUCKET, der das Format gs://BUCKET-NAME hat und auf den Google Cloud Storage-Bucket verweist, in dem Daten gesichert werden müssen. Die Beschreibung entspricht dem hier beschriebenen dbStorageBucket-Element.
    • OPTIONAL: Ändern Sie den Wert von HTTP_PROXY_URL so, dass er auf einen konfigurierten Proxy verweist. Das Format könnte so aussehen:
      • http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
      • https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
      • http://${HOST_IP_ADDRESS}:${HOST_PORT}
      • http://${HOST_IP_ADDRESS>:${HOST_PORT}

Sicherung durchführen

Sie können die Sicherung mit dem folgenden Befehl durchführen:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

So wenden Sie Änderungen an und aktivieren die Sicherung:

Änderungen nur zur Wiederherstellung

  • components/gcs-restore/apigee-datastore-patch.yaml
    • ERFORDERLICH: Ändern Sie den Wert der Umgebungsvariablen DATABASE_STORAGE_BUCKET, der das Format gs://BUCKET-NAME hat und auf den Google Cloud Storage-Bucket verweist, in dem Daten gesichert werden müssen. Die Beschreibung entspricht dem hier beschriebenen dbStorageBucket-Element.
  • components/gcs-restore/job-patch.yaml
    • ERFORDERLICH: Ändern Sie den Wert der Umgebungsvariablen DATABASE_STORAGE_BUCKET, der das Format gs://BUCKET-NAME hat und auf den Google Cloud Storage-Bucket verweist, in dem Daten gesichert werden müssen.
    • ERFORDERLICH: Ändern Sie den Wert der Umgebungsvariablen SERV_SNAPSHOT_TIMESTAMP. Die Beschreibung entspricht dem die beschriebenen restore:snapshotTimestamp-Element.
    • OPTIONAL: Ändern Sie den Wert von HTTP_PROXY_URL so, dass er auf einen konfigurierten Proxy verweist. Das Format könnte so aussehen:
      • http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
      • https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
      • http://${HOST_IP_ADDRESS}:${HOST_PORT}
      • http://${HOST_IP_ADDRESS}:${HOST_PORT}

Wiederherstellung durchführen:

Hintergrundinformationen zum Wiederherstellen von Sicherungen finden Sie unter Sicherungen wiederherstellen | Apigee X | Google Cloud.

  1. Erstellen Sie einen neuen Kubernetes-Cluster mit einem neuen Namespace, in dem das Deployment der Hybrid-Laufzeit wiederhergestellt wird. Sie können nicht den Cluster und Namespace verwenden, den Sie für die ursprüngliche Hybrid-Installation verwendet haben.

  2. Installieren Sie Hybrid zusätzlich zu den gewünschten Einstellungen mit den oben konfigurierten Einstellungen im Cluster:

    • Sie können entweder die grundlegende Installation verwenden und Hybrid im neuen Namespace installieren:
    ./tools/apigee-hybrid-setup.sh \
--cluster-name $CLUSTER_NAME \
--cluster-region $CLUSTER_LOCATION \
--namespace ${NEW_APIGEE_NAMESPACE}

  3. Nach Abschluss der Wiederherstellung können Sie alle Ressourcen im alten Namespace löschen und zum neuen Namespace wechseln.

Weitere Informationen finden Sie unter Sicherungen wiederherstellen.

non-gcs-backup und non-gcs-restore

Diese kustomize-Komponente kann verwendet werden, um eine Sicherung und Wiederherstellung für die Cassandra-Datenbank in Google Cloud Storage durchzuführen.

Verfügbare Sprache:

  • overlays/instances/{INSTANCE_NAME}/datastore

Voraussetzung:

  1. Die Schritte aus der bereits vorhandenen Dokumentation zum Einrichten des Servers und der SSH-Verbindung können verwendet werden.

  2. Aus den obigen Schritten müssen Sie den privaten SSH-Schlüssel verwenden, der in der Datei "ssh_key" verfügbar ist, die durch die vorherigen Schritte generiert wird. Anschließend erstellen wir ein Kubernetes-Secret mit dem Namen „apigee-cassandra-backup-and-restore-gcp-sa-key“, das diesen privaten SSH-Schlüssel enthält.

    Das Kubernetes-Secret kann mit dem folgenden Befehl erstellt werden:

    kubectl create secret generic "apigee-cassandra-backup-and-restore-key-file" \
        --from-file="key=${PATH_TO_SSH_PRIVATE_KEY}" \
        -n "${APIGEE_NAMESPACE}"

    Wobei:

    • ${PATH_TO_SSH_PRIVATE_KEY}: Pfad zur Datei mit dem privaten SSH-Schlüssel.
    • ${APIGEE_NAMESPACE}: Kubernetes-Namespace, in dem Apigee-Komponenten installiert sind. Dies ist normalerweise „apigee“, sofern dies nicht während der Installation explizit geändert wurde

    Alternativ können Sie die Vorlagendatei „templates/secret-apigee-cassandra-backup-and-restore-key-file.yaml“ verwenden, um dieses Secret zu erstellen.

Aktivieren:

  • Wenn Sie die Sicherung aktivieren möchten, entfernen Sie das Kommentarzeichen in der Zeile ./components/non-gcs-backup in der Datenspeicher-Datei „kustomization.yaml“.
  • Wenn Sie eine Sicherung wiederherstellen möchten, entfernen Sie das Kommentarzeichen in der Zeile ./components/non-gcs-restore in der Datenspeicher-Datei „kustomization.yaml“.

Änderungen nur für Sicherungen

  • components/non-gcs-backup/apigee-datastore-patch.yaml
  • components/non-gcs-backup/cron-patch.yaml
    • ERFORDERLICH: Ändern Sie „spec.schedule“, um die Häufigkeit der Sicherung anzugeben. Das Feld akzeptiert das standardmäßige Crontab-Zeitplanformat. Die Beschreibung entspricht dem hier beschriebenen schedule-Element.
    • ERFORDERLICH: Ändern Sie den Wert von SERV_SERVER_IP. Die Beschreibung stimmt mit dem hier beschriebenen BACKUP_SERVER_IP-Element überein.
    • ERFORDERLICH: Ändern Sie den Wert von SERV_STORAGE_DIR. Die Beschreibung stimmt mit dem hier beschriebenen BACKUP_STORAGE_DIR-Element überein.
    • OPTIONAL: Ändern Sie den Wert von HTTP_PROXY_URL so, dass er auf einen konfigurierten Proxy verweist. Das Format könnte so aussehen:
      • http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
      • https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
      • http://${HOST_IP_ADDRESS}:${HOST_PORT}
      • http://${HOST_IP_ADDRESS}:${HOST_PORT}

Sicherung durchführen

Sie können die Sicherung mit dem folgenden Befehl durchführen:

kubectl apply -k overlays/instances/{INSTANCE_NAME}

So wenden Sie Änderungen an und aktivieren die Sicherung:

Änderungen nur für Sicherungen

  • components/non-gcs-restore/apigee-datastore-patch.yaml
  • components/non-gcs-restore/job-patch.yaml
    • ERFORDERLICH: Ändern Sie den Wert der Umgebungsvariablen BACKUP_SNAPSHOT_TIMESTAMP. Die Beschreibung stimmt mit dem hier beschriebenen restore:snapshotTimestamp-Element überein.
    • ERFORDERLICH: Ändern Sie den Wert von BACKUP_SERVER_IP. Die Beschreibung stimmt mit dem hier beschriebenen BACKUP_SERVER_IP-Element überein.
    • ERFORDERLICH: Ändern Sie den Wert von BACKUP_STORAGE_DIR. Die Beschreibung stimmt mit dem hier beschriebenen BACKUP_STORAGE_DIR-Element überein.
    • OPTIONAL Ändern Sie den Wert von HTTP_PROXY_URL so, dass er auf einen konfigurierten Proxy verweist. Das Format könnte so aussehen:
      • http://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
      • https://${USERNAME}:${PASSOWORD}@${HOST_IP_ADDRESS}:${HOST_PORT}
      • http://${HOST_IP_ADDRESS}:${HOST_PORT}
      • http://${HOST_IP_ADDRESS}:${HOST_PORT}

Wiederherstellung durchführen:

Eine Übersicht über das Wiederherstellen von Sicherungen finden Sie unter Cassandra-Wiederherstellung – Übersicht.

  1. Erstellen Sie einen neuen Kubernetes-Cluster mit einem neuen Namespace, in dem das Deployment der Hybrid-Laufzeit wiederhergestellt wird. Sie können nicht den Cluster und Namespace verwenden, den Sie für die ursprüngliche Hybrid-Installation verwendet haben.

  2. Installieren Sie Hybrid zusätzlich zu den gewünschten Einstellungen mit den oben konfigurierten Einstellungen im Cluster: Sie können entweder die grundlegende Installation verwenden und Hybrid im neuen Namespace installieren:

    ./tools/apigee-hybrid-setup.sh \
  --cluster-name $CLUSTER_NAME \
  --cluster-region $CLUSTER_LOCATION \
  --namespace ${NEW_APIGEE_NAMESPACE}

    Oder Sie folgen der angepassten Hybrid-Installation, um Dinge nach Ihren Wünschen zu konfigurieren.

  3. Nach Abschluss der Wiederherstellung können Sie alle Ressourcen im alten Namespace löschen und zum neuen Namespace wechseln.

    Weitere Informationen finden Sie unter Sicherungen auf einem Remoteserver planen.

http-client

Eine Anleitung finden Sie unterHTTP-Clients aktivieren | Apigee.

Verfügbare Sprache:

  • overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}

Aktivieren:

Entfernen Sie das Kommentarzeichen aus der Zeile ./components/http-client in der entsprechenden Datei route-config/${ENV_GROUP}/kustomization.yaml.

Erforderliche Änderungen:

  • Es gibt keine obligatorischen Änderungen.

Verwendung:

  1. Wenn Sie Apigee Hybrid noch nicht installiert haben, können Sie mit den Installationsschritten fortfahren. Diese Änderungen werden im Prozess angewendet.

  2. Wenn Sie Apigee Hybrid bereits installiert haben, müssen Sie diese neuen Änderungen mit dem folgenden Befehl anwenden:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

non-sni-client

Entspricht dem bereits vorhandenen So konfigurieren Sie einen Nicht-SNI-Client | Apigee.

Verfügbare Sprache:

  • overlays/instances/${INSTANCE_NAME}/route-config/${ENV_GROUP}

Aktivieren:

Entfernen Sie das Kommentarzeichen aus der Zeile ./components/non-sni-client in der entsprechenden Datei route-config/${ENV_GROUP}/kustomization.yaml.

Erforderliche Änderungen:

Verwendung:

  1. Wenn Sie Apigee Hybrid noch nicht installiert haben, können Sie mit den Installationsschritten fortfahren. Diese Änderungen werden im Prozess angewendet.

  2. Wenn Sie Apigee Hybrid bereits installiert haben, müssen Sie diese neuen Änderungen mit dem folgenden Befehl anwenden:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

http-and-non-sni-client

Eine Anleitung finden Sie unter Unterstützung für Nicht-SNI- und HTTP-Clients aktivieren | Apigee.

Aktivieren:

Entfernen Sie das Kommentarzeichen aus der Zeile ./components/http-and-non-sni-client in der entsprechenden Datei route-config/${ENV_GROUP}/kustomization.yaml.

Erforderliche Änderungen:

Verwendung:

  1. Wenn Sie Apigee Hybrid noch nicht installiert haben, können Sie mit den Installationsschritten fortfahren. Diese Änderungen werden im Prozess angewendet.

  2. Wenn Sie Apigee Hybrid bereits installiert haben, müssen Sie diese neuen Änderungen mit dem folgenden Befehl anwenden:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

multiregional

Diese Komponente kann beim Konfigurieren eines multiregionalen Cassandra-Deployments verwendet werden. Weitere Informationen finden Sie unter Multiregions-Bereitstellung (GKE und GKE On-Prem).

Aktivieren:

Entfernen Sie das Kommentarzeichen aus der Zeile ./components/multi-region in der Datei datastore/kustomization.yaml.

Erforderliche Änderungen:

  • components/multi-region/cassandra-data-replication.yaml

    • ERFORDERLICH: source.region – Der Name des Cassandra-Rechenzentrums, das als Quelle für die Replikation der Daten verwendet wird. Kann mit dem folgenden Befehl im Quellcluster identifiziert werden:
    kubectl get apigeedatastore -n ${APIGEE_NAMESPACE} -o=jsonpath='{.items[*].spec.components.cassandra.properties.datacenter}'

  • components/multi-region/patch.yaml

    • ERFORDERLICH: spec.components.properties.multiRegionSeedHost – Die Pod-IP-Adresse eines beliebigen Cassandra-Quell-Pods. Wir können Folgendes verwenden:
    kubectl get pods -n ${APIGEE_NAMESPACE} -o wide
    • Verwenden Sie den folgenden Befehl, um alle Pods aufzulisten und die IP-Adresse eines beliebigen Cassandra-Pods abzurufen:
    kubectl get pods -o wide -n apigee

    Ihre Ausgabe sollte in etwa so aussehen:

    NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

Weitere Informationen finden Sie in den Voraussetzungen für GKE unter "Multiregionale Bereitstellung in GKE, GKE On-Prem und AKS":

Verwendung:

Die Verwendung dieser Komponente ist hauptsächlich sinnvoll, wenn Sie Apigee Hybrid in einem neuen Cluster einrichten und bereits eine andere funktionierende Einrichtung von Apigee Hybrid haben.

  1. Sowohl der neue als auch der vorhandene Cluster müssen dieselben TLS-Zertifikate verwenden, um eine ordnungsgemäße Kommunikation zwischen den Cassandra-Pods zu gewährleisten. Wir müssen also das Secret apigee-root-certificate aus dem vorhandenen Cluster kopieren und auch im neueren Cluster verwenden:

  2. Führen Sie den folgenden Befehl aus:

    kubectl config get-contexts
    • um eine Liste aller Kubernetes-Kontexte abzurufen, und führen Sie dann Folgendes aus:
    kubectl config use-context SOURCE_CLUSTER_CONTEXT

    Dabei ist SOURCE_CLUSTER_CONTEXT der Name des Kubernetes-Quellclusterkontexts.

  3. Speichern Sie das Secret des Root-Zertifikats in einer Datei:

    kubectl get secret/apigee-root-certificate -n cert-manager -o yaml > apigee-root-certificate.yaml

  4. Stellen Sie den Clusterkontext auf den neuen Cluster um, in dem Sie Apigee Hybrid installieren.

    kubectl config use-context ${NEW_CLUSTER_CONTEXT}

  5. Erstellen Sie das Root-Secret im neuen Cluster:

    kubectl -n cert-manager apply -f apigee-root-certificate.yaml

  6. Deaktivieren Sie die Erstellung eines neuen Root-Zertifikats. Dadurch wird sichergestellt, dass kein neues apigee-root-certificate erstellt und das im vorherigen Schritt erstellte nicht überschrieben wird.

  7. Entfernen Sie die Kommentarzeichen für die folgenden Zeilen in der Datei overlays/initialization/certificates/kustomization.yaml:

    # components:
# - ./components/disable-apigee-root-certificate-generation

  8. Fahren Sie mit de Rest der Apigee Hybrid-Installation fort, entweder mit der grundlegenden Apigee Hybrid-Installation oder der angepassten Apigee Hybrid-Installation. Beispielsweise können Sie nach der grundlegenden Apigee Hybrid-Installation Folgendes ausführen:

    ./tools/apigee-hybrid-setup.sh --cluster-name $CLUSTER_NAME --cluster-region $CLUSTER_LOCATION

  9. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.

    kubectl -n ${APIGEE_NAMESPACE} get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

  10. Prüfen Sie die Neuerstellungsprozesse in den Logs. Überprüfen Sie außerdem die Datenmenge mit dem nodetool-status-Befehl:

    kubectl logs apigee-cassandra-default-0 -f -n ${APIGEE_NAMESPACE}
kubectl exec apigee-cassandra-default-0 -n ${APIGEE_NAMESPACE}  -- nodetool -u ${JMX_USER} -pw ${JMX_PASSWORD} status

  11. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.

    kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

    Die Ergebnisse sollten in etwa so aussehen:

    {
"rebuildDetails": {
"apigee-cassandra-default-0": {
  "state": "complete",
  "updated": 1623105760
},
"apigee-cassandra-default-1": {
  "state": "complete",
  "updated": 1623105765
},
"apigee-cassandra-default-2": {
  "state": "complete",
  "updated": 1623105770
}
},
"state": "complete",
"updated": 1623105770
}

    Weitere Informationen finden Sie unter Multiregionale Bereitstellung.

  12. Entfernen der folgenden Zeilen aus components/multi-region/patch.yaml:

      properties:
    multiRegionSeedHost: {IP_ADDRESS} # To be modified. REQUIRED

  13. Änderungen anwenden:

    kubectl apply -k overlays/instances/{INSTANCE_NAME}

Konzepte

Image-Hub

Docker-Container-Images werden normalerweise im folgenden Format angegeben:

${REGISTRY_HOST_PATH}/${IMAGE_NAME}:${IMAGE_TAG}

oder in Formaten mit einer Digest-Darstellung wie der folgenden:

${REGISTRY_HOST_PATH}/${IMAGE_NAME}@${DIGEST}

Apigee verwendet das Konzept des "Image-Hubs", was in den die oben genannten Formate auf ${REGISTRY_HOST_PATH} verweist. Der Standardwert für den Image-Hub ist gcr.io/apigee-release/hybrid/.

(Images, die DIGEST verwenden, müssen in jeder Unterkomponente einzeln festgelegt werden.)

Apigee erstellt den endgültigen Image-Pfad, indem der Wert von Folgendem kombiniert wird:

  • "Image-Hub", was in apigee-hybrid-config.yaml überschrieben werden kann (detaillierte Informationen zum Überschreiben des Image-Hubs finden Sie im Abschnitt Docker-Images aus privaten Repositories verwenden).
  • Der Wert von IMAGE_TAG wird dem version-Feld entnommen, das in der yaml-Dateien für jede einzelne Komponente vorhanden ist (z. B. apigee-organization.yaml). Apigee kennzeichnet die Images mit der Apigee Hybrid-Version. Das bedeutet, dass IMAGE_TAG für die Apigee Hybrid-Version 1.8 den Wert 1.8 hat.
  • IMAGE_NAME wird implizit aus dem Namen des Containers bestimmt, in dem das Image verwendet wird. Für den Container apigee-runtime hat IMAGE_NAME beispielsweise den Wert "apigee-runtime".

Ein vollständiges Beispiel für einen Image-Pfad wäre also gcr.io/apigee-release/hybrid/apigee-runtime:1.8.0.

Auf diese Weise wird der endgültige Image-Pfad erstellt, der dann in jedem Container in den jeweiligen Pods verwendet wird.

Google Cloud-Dienstkonten

Google Cloud-Dienstkonten sind Konten, die von Anwendungen zum Ausführen autorisierter Aufrufe an Google APIs verwendet werden. Google Cloud-Dienstkontoschlüssel können heruntergeladen und dann für die Authentifizierung verwendet werden. Apigee erwartet, dass der Nutzer Dienstkontoschlüssel durch das Erstellen von Secrets bereitstellt. Im Folgenden finden Sie die Namen der Komponenten und den Standardnamen des Secrets, in dem nach Dienstkontoschlüsseln gesucht wird:

Komponente Unterkomponente Standardmäßiger Kubernetes-Secret-Name mit Dienstkontoschlüssel
Organisation
connectAgent apigee-connect-agent-gcp-sa-key-${ORG_NAME}
watcher apigee-watcher-gcp-sa-key-${ORG_NAME}
mart apigee-mart-gcp-sa-key-${ORG_NAME}
udca apigee-udca-gcp-sa-key-${ORG_NAME}
ingressGateways –
Umgebung
runtime apigee-runtime-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
udca apigee-udca-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
synchronizer apigee-synchronizer-gcp-sa-key-${ORG_NAME}-${ENV_NAME}
telemetry
Messwerte apigee-metrics-gcp-sa-key
containerLogs apigee-logger-gcp-sa-key

Kubernetes-Dienstkonten

Kubernetes-Dienstkonten bieten Identitäten für Pods in Ihrem Cluster. Standardmäßig erstellt der Apigee-Controller diese für Sie. Wenn Sie jedoch die Erstellung überschreiben möchten, z. B. wenn Sie Workload Identitys verwenden, können Sie das Feld podServiceAccountName in den verschiedenen Unterkomponenten angeben.

Liste der Komponenten und ihrer jeweiligen Unterkomponenten, in denen das Kubernetes-Dienstkonto angegeben werden kann, sowie der Standardname des k8s-Dienstkontos, wenn Sie den Workload Identity-Patch für sie aktivieren.

Komponente Unterkomponente Standardname (verfügbar, wenn Sie den Workload Identity-Patch aktiviert haben)
Organisation
connectAgent apigee-connect-agent-svc-account-${ORG_NAME}
watcher apigee-watcher-svc-account-${ORG_NAME}
mart apigee-mart-svc-account-${ORG_NAME}
udca apigee-udca-svc-account-${ORG_NAME}
Umgebung
synchronizer apigee-synchronizer-svc-account-${ORG_NAME}-${ENV_NAME}
udca apigee-udca-svc-account-${ORG_NAME}-${ENV_NAME}
runtime apigee-runtime-svc-account-${ORG_NAME}-${ENV_NAME}
datastore
cassandra apigee-datastore-svc-account
telemetry
metricsApp apigee-metricsApp-svc-account
metricsProxy apigee-metricsProxy-svc-account
metricsAdapter apigee-metricsAdapter-svc-account
containerLogs apigee-container-logs-svc-account

Workload Identitys

Workload Identitys ermöglichen Pods, die Kubernetes-Dienstkonten verwenden und in GKE ausgeführt werden, sich direkt bei Google Cloud APIs zu authentifizieren, ohne dass Google Cloud-Dienstkontoschlüssel erforderlich sind.

Neue Umgebung hinzufügen

.
├── ...
├── instances/instance1/components
│   ├── ...
│   ├── environments
│   │   ├── dev
│   │   │   └── apigee-environment.yaml
│   │   │   └── secrets.yaml
│   │   └── new-env-name (new)
│   │       └── apigee-environment.yaml (new)
│   │       └── secrets.yaml (new)
└── ...

Das Hinzufügen einer neuen Umgebung ist ganz einfach:

  1. Erstellen eines neuen Ordners im Umgebungsverzeichnis (oder im entsprechenden Verzeichnis je nach dem, wie Sie die Ordner strukturiert haben).
  2. Kopieren der Datei apigee-environment.yaml aus einer vorhandenen Umgebung in den neuen Ordner.
  3. Wenn Sie neue Dienstkonto- und Verschlüsselungsschlüssel für die neue Umgebung erstellen möchten, kopieren Sie die Datei secrets.yaml in den neuen Ordner und benennen Sie die Secrets entsprechend um, um sie von den anderen vorhandenen Umgebungen zu unterscheiden. Hierfür fügen Sie in der Regel den Namen des Umgebung als Suffix hinzu.
  4. Vornehmen der entsprechenden Änderungen an apigee-environment.yaml, z. B.:
    • Ändern des Namens der Umgebung.
    • Wenn neue Dienstkonten und Verschlüsselungsschlüssel erstellt werden, müssen sie in der YAML-Datei richtig referenziert werden.
  5. Anwenden der yaml-Dateien:
kubectl apply -f components/environments/new-env-name/secrets.yaml
kubectl apply -f components/environments/new-env-name/apigee-environment.yaml

Erzwungenes Löschen in Apigee Datastore verwenden

Wenn das Löschen des Datenspeichers aus irgendeinem Grund nicht fortgesetzt wird, kann der Apigee-Datenspeicher jetzt unabhängig vom aktuellen Status des Clusters das Löschen mit den folgenden Befehlen erzwingen.

  1. Löschen Sie apigeeds im Namespace apigee:

    Kubectl delete -n apigee apigeeds default

    Wenn dieser Schritt hängen bleibt, kommen Sie mit STRG + C da heraus.

  2. Bearbeiten Sie das neue apigeeds:

    Kubectl edit -n apigee apigeeds default

  3. Aktualisieren Sie das Feld "forceForce" in der Apigee-Datenspeicherspezifikation oder fügen Sie es hinzu.

    spec:
forceDelete: true

  4. Speichern Sie die Datei und schließen Sie sie.

Warten Sie nun, bis der Datenspeicher gelöscht wurde. Es kann einige Minuten dauern, bis alle Cassandra-Ressourcen gelöscht wurden.

Grundlegendes zum Skript

Das Skript apigee-hybrid-setup.sh führt einige grundlegende Validierungen aus. Es hilft dabei, die Schritte zu automatisieren, die Sie andernfalls ausführen müssten, wenn Sie eine detailliertere Anpassung wünschen, wie unter Angepasste Apigee Hybrid-Installation dokumentiert. Auch bei angepasster Installation können Sie das Skript weiterhin teilweise für bestimmte Aufgaben verwenden.

Sie können ./tools/apigee-hybrid-setup.sh --help ausführen, um eine Liste der unterstützten Flags aufzurufen und zusätzliche Hilfe zum Skript zu erhalten. Die folgenden Flags werden derzeit unterstützt:

  • --namespace: Standardmäßig installiert das Skript alle Komponenten im Namespace apigee. Sie können dieses Verhalten ändern, indem Sie mit diesem Flag den Namen des Namespace angeben.
  • --org: Wird verwendet, um den Namen der Apigee-Organisation anzugeben. Enthält standardmäßig das Google Cloud-Projekt, das derzeit in gcloud ausgewählt ist, wenn nichts anderes angegeben ist.
  • --envgroup: Wird verwendet, um den Namen der Umgebungsgruppe in Ihrer Organisation anzugeben. Wenn nicht angegeben, wird versucht, die APIs der Steuerungsebene abzufragen, um den Namen der Umgebungsgruppe zu ermitteln. Wenn mehrere Umgebungsgruppen gefunden werden, wird ein Fehler zurückgegeben und das Skript wird beendet.
  • --env: Wird verwendet, um den Namen der Umgebung in Ihrer Organisation anzugeben. Wenn keine Angabe erfolgt, wird versucht, die APIs der Steuerungsebene abzufragen, um den Namen der Umgebung zu ermitteln. Wenn mehrere Umgebungen gefunden werden oder die Umgebung nicht Teil der Umgebungsgruppe ist, wird ein Fehler zurückgegeben und das Skript wird beendet.
  • --cluster-name: Der Name des Kubernetes-Clusters.
  • --cluster-region: Die Region, in der sich der Kubernetes-Cluster befindet.
  • --gcp-project-id: Die Google Cloud-Projekt-ID, in der sich der Kubernetes-Cluster befindet.
  • --ingress-domain: Gibt den Hostnamen/Domainnamen an, der zum Generieren der selbst signierten TLS-Zertifikate für das Istio-Ingress-Gateway verwendet wird. Wenn keiner angegeben ist, wird versucht, den Wert zu ermitteln. Dazu wird eine Abfrage der APIs der Steuerungsebene durchgeführt, um den Wert aus der Umgebung zu abrufen. Wenn bei der Bestimmung der Umgebung Probleme aufgetreten sind oder mehrere Hostnamen für die Umgebung konfiguriert wurden, wird ein Fehler zurückgegeben und das Skript wird beendet.
  • --generate-internal-tls-certs: Dadurch wird ein Kubernetes-Secret namens „apigee-ca“ generiert, das ein von uns generiertes Zertifikat und Schlüsselpaar enthält.
  • --create-ingress-tls-certs: Dadurch wird ein Secret mit dem Namen {ORG_NAME}-{ENV_GROUP_NAME} (abgeleitet aus dem Namen der Organisation und der Umgebung) im Istio-System-Namespace generiert, das ein Zertifikat und ein Schlüsselpaar enthält, die für die TLS-Kommunikation verwendet werden. Der Domainname, der zum Generieren dieser Zertifikate verwendet wird, wird aus dem Wert in der Konfiguration der Umgebung abgeleitet. Bei Konflikten (z. B. wenn mehrere Domains gefunden werden) werden entsprechende Fehlermeldungen angezeigt.
  • --create-gcp-sa-and-secrets: Erstellt ein einzelnes Google Cloud-Dienstkonto im Google Cloud-Projekt, lädt die Schlüssel herunter und erstellt dann die Kubernetes-Secrets, die den Schlüssel enthalten. Die Namen der Secrets finden Sie in den Google Cloud-Dienstkonten.
  • --fill-values: Ersetzt die Werte der Namen von Organisation, Umgebung und Umgebungsgruppe sowie andere Namen, sofern sie in den verschiedenen YAML-Dateien erforderlich sind.
  • --apply-configuration: Dadurch werden die Zertifizierungsstellen, benutzerdefinierten Ressourcendefinitionen, Webhooks und Rollen sowie die Controller-Ressource erstellt. Ressourcen werden in der richtigen Reihenfolge erstellt und der Befehl wird blockiert, bis alle fehlerfrei sind.
  • -- rename-directories: Benennen Sie die Umgebung und die Umgebungsgruppe mit den Namen der richtigen Umgebung und Umgebungsgruppe um.
  • --verbose: Zeigt eine detaillierte Ausgabe für das Debugging an.
  • --help: Nutzungsinformationen anzeigen.
  • --setup-all: Dadurch werden alle Aufgaben ausgeführt, die von diesem Skript ausgeführt werden können.

Ordnerstruktur für Apigee Hybrid-Einrichtung

Der Ordner apigee-hybrid-setup hat standardmäßig die folgende hierarchische Struktur:

.
├── bases
│   ├── controllers
│   │   ├── apigee-controller
│   │   │   ├── apigee-controller-deployment.yaml
│   │   │   └── kustomization.yaml
│   │   └── apigee-ingressgateway-manager
│   │       ├── apigee-ingressgateway-manager-deployment.yaml
│   │       └── kustomization.yaml
│   ├── datastore
│   │   └── backup-and-restore
│   │       ├── backup
│   │       │   ├── cronjob.yaml
│   │       │   └── kustomization.yaml
│   │       ├── common
│   │       │   ├── kustomization.yaml
│   │       │   ├── rbac.yaml
│   │       │   └── tls-certificate.yaml
│   │       └── restore
│   │           ├── job.yaml
│   │           └── kustomization.yaml
│   └── initialization
│       ├── certificates
│       │   ├── certificates-and-issuers.yaml
│       │   └── kustomization.yaml
│       ├── crds
│       │   ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│       │   └── kustomization.yaml
│       ├── openshift
│       │   ├── kustomization.yaml
│       │   └── scc.yaml
│       ├── rbac
│       │   ├── apigee-controller
│       │   │   ├── kustomization.yaml
│       │   │   └── rbac.yaml
│       │   └── apigee-embedded-ingress-controller
│       │       ├── cluster-role-bindings.yaml
│       │       ├── cluster-roles.yaml
│       │       ├── kustomization.yaml
│       │       └── service-account.yaml
│       └── webhooks
│           ├── kustomization.yaml
│           ├── mutatingwebhookconfiguration.yaml
│           └── validatingwebhookconfiguration.yaml
├── CONTRIBUTING.md
├── docs
│   └── api_references
│       ├── v1alpha1.md
│       └── v1alpha2.md
├── kokoro
│   ├── build.sh
│   ├── common.cfg
│   ├── continuous.cfg
│   ├── presubmit.cfg
│   └── release.cfg
├── LICENSE
├── overlays
│   ├── controllers
│   │   ├── apigee-controller
│   │   │   ├── apigee-hybrid-config.yaml
│   │   │   ├── components
│   │   │   │   ├── imagepullsecret
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   └── patch.yaml
│   │   │   │   └── nodeselector
│   │   │   │       ├── kustomization.yaml
│   │   │   │       └── patch.yaml
│   │   │   └── kustomization.yaml
│   │   ├── apigee-ingressgateway-manager
│   │   │   ├── apigee-ingressgateway-manager-deployment-patch.yaml
│   │   │   ├── apigee-istio-mesh-config.yaml
│   │   │   ├── components
│   │   │   │   ├── imagepullsecret
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   └── patch.yaml
│   │   │   │   └── nodeselector
│   │   │   │       ├── kustomization.yaml
│   │   │   │       └── patch.yaml
│   │   │   └── kustomization.yaml
│   │   └── kustomization.yaml
│   ├── initialization
│   │   ├── certificates
│   │   │   ├── apigee-ingressgateway-manager-certificate-patch.yaml
│   │   │   ├── apigee-serving-cert-patch.yaml
│   │   │   ├── components
│   │   │   │   └── disable-apigee-root-certificate-generation
│   │   │   │       └── kustomization.yaml
│   │   │   └── kustomization.yaml
│   │   ├── crds
│   │   │   └── kustomization.yaml
│   │   ├── ingress
│   │   │   ├── envoyfilter-1.11.yaml
│   │   │   └── kustomization.yaml
│   │   ├── namespace.yaml
│   │   ├── openshift
│   │   │   ├── kustomization.yaml
│   │   │   └── scc.yaml
│   │   ├── rbac
│   │   │   ├── apigee-controller
│   │   │   │   └── kustomization.yaml
│   │   │   ├── apigee-ingressgateway-manager
│   │   │   │   └── kustomization.yaml
│   │   │   └── kustomization.yaml
│   │   └── webhooks
│   │       ├── kustomization.yaml
│   │       ├── mutatingwebhookconfiguration.yaml
│   │       └── validatingwebhookconfiguration.yaml
│   └── instances
│       └── instance1
│           ├── datastore
│           │   ├── apigee-datastore.yaml
│           │   ├── components
│           │   │   ├── gcs-backup
│           │   │   │   ├── apigee-datastore-patch.yaml
│           │   │   │   ├── cron-patch.yaml
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── tls-certificate-patch.yaml
│           │   │   ├── gcs-restore
│           │   │   │   ├── apigee-datastore-patch.yaml
│           │   │   │   ├── job-patch.yaml
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── tls-certificate-patch.yaml
│           │   │   ├── http-proxy
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── multi-region
│           │   │   │   ├── cassandra-data-replication.yaml
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── non-gcs-backup
│           │   │   │   ├── apigee-datastore-patch.yaml
│           │   │   │   ├── cron-patch.yaml
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── tls-certificate-patch.yaml
│           │   │   ├── non-gcs-restore
│           │   │   │   ├── apigee-datastore-patch.yaml
│           │   │   │   ├── job-patch.yaml
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── tls-certificate-patch.yaml
│           │   │   ├── openshift-scc
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── scc.yaml
│           │   │   └── workload-identity
│           │   │       ├── kustomization.yaml
│           │   │       ├── patch.yaml
│           │   │       └── service-accounts.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── environments
│           │   ├── kustomization.yaml
│           │   └── test
│           │       ├── apigee-environment.yaml
│           │       ├── components
│           │       │   ├── http-proxy
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   ├── imagepullsecret
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   ├── nodeselector
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   └── workload-identity
│           │       │       ├── kustomization.yaml
│           │       │       ├── patch.yaml
│           │       │       └── service-accounts.yaml
│           │       ├── kustomization.yaml
│           │       └── secrets.yaml
│           ├── kustomization.yaml
│           ├── organization
│           │   ├── apigee-organization.yaml
│           │   ├── components
│           │   │   ├── http-proxy
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   └── workload-identity
│           │   │       ├── kustomization.yaml
│           │   │       ├── patch.yaml
│           │   │       └── service-accounts.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── redis
│           │   ├── apigee-redis.yaml
│           │   ├── components
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   └── workload-identity
│           │   │       ├── kustomization.yaml
│           │   │       ├── patch.yaml
│           │   │       └── service-accounts.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── route-config
│           │   ├── kustomization.yaml
│           │   └── test-envgroup
│           │       ├── apigee-route-config.yaml
│           │       ├── components
│           │       │   ├── http-and-non-sni-client
│           │       │   │   ├── apigee-route.yaml
│           │       │   │   └── kustomization.yaml
│           │       │   ├── http-client
│           │       │   │   ├── apigee-route.yaml
│           │       │   │   └── kustomization.yaml
│           │       │   └── non-sni-client
│           │       │       ├── apigee-route.yaml
│           │       │       └── kustomization.yaml
│           │       └── kustomization.yaml
│           └── telemetry
│               ├── apigee-telemetry.yaml
│               ├── components
│               │   ├── http-proxy
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── imagepullsecret
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── logger
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── metrics
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── nodeselector
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── openshift-scc
│               │   │   ├── kustomization.yaml
│               │   │   └── scc.yaml
│               │   ├── workload-identity-logger
│               │   │   ├── kustomization.yaml
│               │   │   ├── patch.yaml
│               │   │   └── service-accounts.yaml
│               │   └── workload-identity-metrics
│               │       ├── kustomization.yaml
│               │       ├── patch.yaml
│               │       └── service-accounts.yaml
│               └── kustomization.yaml
├── README.md
├── templates
│   ├── certificate-org-envgroup.yaml
│   ├── secret-apigee-cassandra-backup-and-restore-gcp-sa-key.yaml
│   ├── secret-apigee-cassandra-backup-and-restore-key-file.yaml
│   ├── secret-gcp-sa-key.yaml
│   └── secret-ingress-tls-cert-key.yaml
└── tools
    ├── apigee-hybrid-setup.sh
    ├── apigee-pull-push.sh
    ├── common.sh
    ├── create-service-account.sh
    └── dump_kubernetes.sh

Eine Version der obigen Dateien finden Sie im Tag „preview-1“ des GitHub-Repositorys unter: https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.

Der obige Ordner enthält Kubernetes-Manifeste für die Apigee Hybrid-Laufzeit und verwendet Kustomize für die Konfigurationsverwaltung. Die Manifeste sind nach dem Konzept der Kustomize-Basen und -Overlays organisiert. Der Ordner „bases“ enthält die minimal erforderliche Konfiguration für jede Apigee-Komponente. Der Ordner „overlays“ enthält mehrere zusätzliche Features (Konfigurationen), die als Komponenten definiert sind. Zum Aktivieren einer Komponente können Sie das Kommentarzeichen bei der Komponentenreferenz in der Datei „kustomization.yaml“ entfernen.

Beispiel: Zum Aktivieren von gcs-backup für den Apigee-Datenspeicher wurde das Kommentarzeichen für die Komponente gcs-backup in der folgenden Datei „customization.yaml“ entfernt.

Pfad: ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/kustomization.yaml

namespace: "apigee" # kpt-set: ${APIGEE_NAMESPACE}

resources:
- apigee-datastore.yaml

components:
# - ./components/http-proxy
# - ./components/nodeselector/
# - ./components/imagepullsecret
# - ./components/workload-identity
# - ./components/openshift-scc
- ./components/gcs-backup (uncommented)
# - ./components/gcs-restore
# - ./components/non-gcs-backup
# - ./components/non-gcs-restore

Jeder Wert, der Anpassungen erfordert, muss in der entsprechenden Datei „patch.yaml“ für gcs-backup festgelegt werden. In der folgenden Datei muss der Wert von CLOUD_STORAGE_BUCKET_PATH vom Nutzer festgelegt werden.

Pfad: $INSTALL_DIR/overlays/instances/$INSTANCE_DIR/datastore/components/gcs-backup/cron-patch.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: apigee-cassandra-backup
  namespace: apigee
spec:
  schedule: "${YOUR_BACKUP_SCHEDULE_CODE}" # To be modified
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: apigee-cassandra-backup
            env:
            - name: APIGEE_CLOUDPROVIDER
              value: "GCP"
            - name: DATABASE_STORAGE_BUCKET
              value: "${CLOUD_STORAGE_BUCKET_PATH}" # To be modified. REQUIRED
            volumeMounts:
            - name: apigee-cassandra-backup
              mountPath: /var/secrets/google
          volumes:
          - name: apigee-cassandra-backup
            secret:
              secretName: "apigee-cassandra-backup-and-restore-svc-account"

Ebenso können Sie jedes Feature bzw. jede Konfiguration, die Anpassungen erfordert, aktivieren, indem Sie das Kommentarzeichen bei der Komponente in der Datei „kustomization.yaml“ der Apigee-Komponente entfernen. Außerdem müssen die entsprechenden Werte für die Felder in der Datei "patch.yaml" der Komponente entsprechend festgelegt werden.

Kurze Erläuterung der Ordner und Dateien:

bases

Dieser Ordner enthält die Vorlagen mit minimaler Konfiguration, die für jede Apigee-Komponente erforderlich ist. Sie müssen die Manifeste in diesem Ordner nicht ändern.

overlays

Dieser Ordner enthält die Vorlagen für die Kustomize-Komponenten für die zusätzlichen Konfigurationen.

initialization

namespaces.yaml

Der Namespace, in dem Komponenten der Apigee-Datenebene installiert werden. Der Standardname des Namespace lautet apigee.

Zertifikate

Enthält die Ressourcen Issuer und Certificate, die zum Ausstellen von Zertifikaten für die Webhooks verwendet werden. Enthält auch den Issuer, der zum Ausstellen von Zertifikaten für verschiedene Pods für die TLS-Kommunikation verwendet wird.

rbac

Enthält die Role, die ClusterRole, das RoleBinding und das ClusterRoleBinding, die von verschiedenen Komponenten verwendet werden.

crds
    Contains the definition of all the CRDs which are used by Apigee.
webhooks

Enthält ValidatingWebhookConfiguration und MutatingWebhookConfiguration, die zum Validieren der benutzerdefinierten Ressourcen verwendet werden.

Eingehend

Enthält eine Konfiguration, die für alle Ingress-PODs gilt. z. B. Gängige Header-Änderung, Systemdiagnose usw.

openshift

Enthält die Definition von openshift-SecurityContextConstraints.

Controller

apigee-controller
apigee-hybrid-config.yaml

Enthält eine ConfigMap, die als Eingabe in apigee-controller-manager.yaml bereitgestellt wird. Diese ConfigMap enthält u. a. Konfigurationen wie imageHub, imagePullSecrets und forwardProxy.

apigee-controller-deployment.yaml

Enthält zwei Services für Controller und Webhook und das Deployment für den Controller. Wenn Sie ein privates Image für den Controller verwenden möchten, müssen Sie die entsprechende Änderung hier vornehmen.

istiod

Apigee-istio-mesh-config.yaml Enthält die Mesh-Netzwerk-Konfiguration für Istio, die von Apigee verwendet wird. Dies gilt nicht für andere Installationen von ASM/Istio im Cluster.

apigee-ingressgateway-manager-deployment-patch.yaml

Enthält einen Service und ein Deployment von Istiod. Dies ist ein privates Istiod, das nur für Apigee-Anwendungsfälle verwendet wird.

instances/{instanceName}

datastore
apigee-datastore.yaml

Enthält die benutzerdefinierte ApigeeDatastore-Ressource, die Cassandra verwaltet.

secrets.yaml

Enthält Standardanmeldedaten für den Datenspeicher.

redis
apigee-redis.yaml

Enthält die benutzerdefinierte ApigeeRedis-Ressource, die Redis verwaltet.

secrets.yaml

Enthält Standardanmeldedaten für den Datenspeicher.

Organisation
apigee-organization.yaml

Enthält die benutzerdefinierte ApigeeOrganization-Ressource, die andere Unterkomponenten wie connectAgent, watcherAndSynchronizer, MART, UDCA und Ingress verwaltet.

secrets.yaml

Enthält die Secrets, auf die in apigee-organization.yaml verwiesen wird. Einige Secrets werden auskommentiert, wenn sie vom Skript generiert werden. Wenn Sie deren Generierung deaktivieren, müssen Sie sie manuell erstellen.

environments

Enthält die gesamte Umgebung in Ihrer Organisation. Sie sollten für jede Umgebung einen separaten Ordner erstellen. Kopieren Sie dazu den bereits bereitgestellten Ordner und konfigurieren Sie ihn gemäß den Anforderungen.

dev
apigee-environment.yaml

Enthält die benutzerdefinierte ApigeeEnvironment-Ressource, die andere Unterkomponenten wie die Laufzeit verwaltet.

secrets.yaml

Enthält die Secrets, auf die in apigee-environment.yaml verwiesen wird. Einige Secrets werden auskommentiert, wenn sie vom Skript generiert werden. Wenn Sie deren Generierung deaktivieren, müssen Sie sie manuell erstellen.

telemetry
apigee-telemetry.yaml

Enthält die benutzerdefinierte ApigeeTelemetry-Ressource.

secrets.yaml

Enthält die Secrets, auf die in apigee-telemetry.yaml verwiesen wird. Einige Secrets werden auskommentiert, wenn sie vom Skript generiert werden. Wenn Sie deren Generierung deaktivieren, müssen Sie sie manuell erstellen.

route-config
dev-envgroup
apigee-route-config.yaml

Enthält die benutzerdefinierte ApigeeRouteConfig-Ressource.

secrets.yaml

Enthält ein Secret, auf das in apigee-route-config.yaml verwiesen wird. Es ist auskommentiert, da es automatisch vom Skript „apigee-hybrid-setup.sh“ generiert wird, und wird dort gespeichert, um ein Beispiel für das Secret zu bieten, falls Sie es manuell erstellen möchten.

diagnostic

diagnostic-collector.yaml

Ressourcen, die zum Erstellen der Diagnosebereitstellung verwendet werden.

tools

apigee-hybrid-setup.sh
apigee-create-service-account.sh
dump-kubernetes.sh
apigee-pull-push.sh

Dienstkontoschlüssel in externen Vaults speichern

Vault (von HashiCorp) ist ein beliebtes Secret-Verwaltungssystem mit mehreren Integrationen mit Secret-Speichern, die von Google, Azure, AWS und anderen bereitgestellt werden. Mit Hashicorp Vault können Sie Secrets aus einer externen Quelle abrufen und dann in Kubernetes-Ressourcen verwenden. Es gibt verschiedene Möglichkeiten, Vault zum Abrufen von Secrets zu verwenden. Die folgenden Schritte dienen als einfaches Beispiel dafür, wie Sie mit dem Vault-CSI-Anbieter Google Cloud-Dienstkontoschlüssel bereitstellen, die in einer von Vault bereitgestellten Secret-Engine gespeichert sind.

  1. Wir verwenden Helm, um Vault-bezogene Ressourcen in Ihrem Cluster zu installieren. Führen Sie die Schritte unter Helm installieren aus, um zu erfahren, wie Sie Helm in Ihrem System einrichten.

  2. Führen Sie diese Schritte unter Vault-Helm-Diagramm installieren aus:

    1. Hashicorp-Repository zu Helm hinzufügen

      helm repo add hashicorp https://helm.releases.hashicorp.com

    2. Helm-Repositories aktualisieren

      helm repo update

    3. Vault installieren

      helm install vault hashicorp/vault \
--set "server.dev.enabled=true" \
--set "injector.enabled=false" \
--set "csi.enabled=true"

  3. Jetzt speichern wir das Secret in Vault.

    1. Shell im Vault-Entwicklungs-Pod abrufen

      kubectl exec -it vault-0 -- /bin/sh
 ```

    2. In diesem Beispiel verwenden wir die Schlüssel/Wert-Paar-Secret-Engine, um Daten zu speichern.

      vault kv put secret/runtime-gcp-sa-key key="${BASE_64_ENCODED_KEY}"

    3. So prüfen Sie, ob der Schlüssel erfolgreich gespeichert wurde:

      vault kv get secret/runtime-gcp-sa-key

  4. Richten Sie die Authentifizierung ein, damit der Laufzeit-Pod den Schlüssel abrufen kann. Wie unter Kubernetes-Dienstkonten erläutert, bieten Kubernetes-Dienstkonten die Identität für Pods und ermöglichen deren Authentifizierung bei anderen Systemen.

    1. Shell im Vault-Entwicklungs-Pod abrufen

      kubectl exec -it vault-0 -- /bin/sh

    2. Kubernetes-Authentifizierungsmethode aktivieren

      vault auth enable kubernetes

    3. Authentifizierungskonfiguration schreiben

      vault write auth/kubernetes/config \
issuer="https://kubernetes.default.svc.cluster.local" \
token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
disable_iss_validation=true

    4. Authentifizierungsrichtlinie erstellen

      vault policy write apigee-runtime-app - <<EOF
path "secret/data/runtime-gcp-sa-key" {
capabilities = ["read"]
}
EOF

    5. Richtlinie an das Dienstkonto binden

      vault write auth/kubernetes/role/apigee-runtime-role \
bound_service_account_names=apigee-runtime-sa \
bound_service_account_namespaces=${APIGEE_NAMESPACE} \
policies=apigee-runtime-app \
ttl=20m

    Hier wird davon ausgegangen, dass sich das Dienstkonto im Apigee-Namespace befindet. Wenn Sie einen anderen Namespace für die Installation von Apigee haben, verwenden Sie dessen Namen.

    1. Shell in vault-0 beenden

      exit

  5. CSI-Treiber für Secrets-Speicher installieren

    # Add repo to helm
helm repo add secrets-store-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/secrets-store-csi-driver/master/charts
# Install driver in cluster
helm install csi secrets-store-csi-driver/secrets-store-csi-driver

  6. Erstellen Sie die Kubernetes-Ressource SecretProviderClass, die auf das Secret verweist, das Sie in Vault erstellt haben.

    cat > spc-vault.yaml <<EOF
apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
name: vault-apigee-runtime-gcp-sa-key
spec:
provider: vault
parameters:
  vaultAddress: "http://vault.default:8200"
  roleName: "apigee-runtime-role"
  objects: |
    - objectName: "client_secret.json"
      secretPath: "secret/data/runtime-gcp-sa-key"
      secretKey: "key"
EOF

  7. Wenden Sie die yaml Datei an.

    kubectl apply -f spc-vault.yaml

  8. Erstellen Sie das Kubernetes-Dienstkonto, dem wir die Berechtigungen in Schritt 4.e zugewiesen haben.

    kubectl create serviceaccount -n ${APIGEE_NAMESPACE} apigee-runtime-sa

  9. Ändern Sie die Datei apigee-environment.yaml für die Umgebung und fügen Sie die folgenden Zeilen hinzu:

    apiVersion: apigee.cloud.google.com/v1alpha2
kind: ApigeeEnvironment
# existing content
spec:
name: {ENV_NAME}
organizationRef: {ORG_NAME}
components:
 runtime:
# existing content
   pod
   containers:
   - name: apigee-runtime
     podServiceAccountName: apigee-runtime-sa
# existing content
     volumeMounts:
     - name: secrets-store-inline
       mountPath: "/opt/apigee/sa"
       readOnly: true
   volumes:
   - name: secrets-store-inline
     csi:
       driver: secrets-store.csi.k8s.io
       readOnly: true
       volumeAttributes:
         secretProviderClass: "vault-apigee-runtime-gcp-sa-key"

  10. Änderungen anwenden:

    kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/environments/$ENV_NAME

Apigee Hybrid-Upgrade

Sie müssen alle in Vorbereitung genannten Anforderungen erfüllt haben. Es wird außerdem empfohlen, einen rollierenden Neustart aller Komponenten durchzuführen, um zu prüfen, ob der Cluster fehlerfrei ist. Die Reihenfolge der Neustarts ist Cassandra, Redis, ApigeeOrganization und ApigeeEnvironment.

Back-up erstellen

  1. Erstellen Sie eine Sicherungskopie der aktuellen Hybrid-Einrichtung. Die Sicherung ist erforderlich, falls Sie ein Rollback auf die aktuelle Version durchführen müssen.

    tar -czvf apigee-hybrid-install.v-X.Y.Z.tar.gz $HYBRID_INSTALL_BASE_DIR

  2. Erstellen Sie eine Sicherung der Cassandra-Datenbank. Cassandra-Sicherungen sind ein wichtiger Schutz vor Notfallszenarien.

Kubernetes-Plattform bei Bedarf upgraden

Dieser Schritt ist nicht jedes Mal erforderlich, aber Sie müssen die Kubernetes-Plattform wie Kubernetes, Openshift und Komponenten wie Cert-Manager, Cassandra usw. aktualisieren, wenn sie nicht mehr von einer neueren Version von Apigee Hybrid unterstützt werden. Die Dokumentation enthält unterstützte Versionen von Plattformen und Komponenten.

Einrichtungsdateien herunterladen

Laden Sie das Repository herunter und ersetzen Sie die Ordner bases und tools in der vorhandenen Apigee Hybrid-Einrichtung durch einen neueren:

  1. Klonen Sie das Tag „GitHub-repository preview-1“ unter https://github.com/apigee/apigee-hybrid-install/releases/tag/preview-1.

    Das geklonte Repository hat eine Struktur, die der unter Ordnerstruktur für Apigee Hybrid-Einrichtung beschriebenen ähnelt.

  2. Ersetzen Sie die Ordner „initialization“, „tools“ und „controller“ in der vorhandenen Apigee Hybrid-Einrichtung.

    export HYBRID_INSTALL_HOME=PATH_TO_PREVIOUS_HYBRID_INSTALL_DIRECTORY
mv -f bases $HYBRID_INSTALL_HOME/bases
mv -f tools $HYBRID_INSTALL_HOME/tools

Dienstkontoberechtigungen bei Bedarf aktualisieren

Dieser Schritt ist auch nicht jedes Mal erforderlich, aber Sie müssen bei Bedarf ein neues Dienstkonto erstellen oder die Berechtigungen vorhandener Dienstkonten aktualisieren. Im Leitfaden zum Upgrade finden Sie Details dazu, welche Dienstkonten geändert oder erstellt werden müssen und welche Rollen hinzugefügt werden müssen.

  • Wenn Sie die Berechtigungen vorhandener Dienstkonten ändern müssen, verwenden Sie den entsprechenden gcloud-Befehl. Das Upgrade-Handbuch enthält detaillierte Befehle und Rollen, die hinzugefügt werden müssen.

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

  • Wenn die neuere Apigee-Hybridversion für die neuen/vorhandenen Komponenten möglicherweise ein zusätzliches Dienstkonto benötigt, müssen Sie diese erstellen. Sie können das im Toolordner enthaltene Skript apigee-create-service-account.sh verwenden, um neue Dienstkonten zu erstellen. Da das Skript bereits im Rahmen von Schritt 4 aktualisiert wird, enthält es Details und ein neues Profil für ein neues Dienstkonto, das erstellt werden muss.

    Auf den neu erstellten Dienstkontonamen muss in der entsprechenden Komponente-CR verwiesen werden.

    ./tools/create-service-account --env prod --profile apigee-component

Controller upgraden

Ändern Sie die Versionsfelder für die in ${INSTALL_DIR}/overlays/instances/$INSTANCE_DIR/kustomization.yaml aufgeführten Komponenten in die entsprechende Hybrid-Version.

Hier ist ein Beispiel für die Datei „$INSTALL_DIR/overlays/instances/$INSTANCE_DIR/kustomization.yaml“. Der Wert des Versionsfelds muss auf die entsprechende Version aktualisiert werden.

resources:
- datastore/
- environments/
- organization/
- redis/
- route-config/
- telemetry/

patches:
- target:
    group: apigee.cloud.google.com
    version: v1alpha1
    kind: ApigeeDatastore
  patch: |-
    - op: add
      path: /spec/version
      value: 1-6-1 (Modify the version)
- target:
    group: apigee.cloud.google.com
    version: v1alpha2
    kind: ApigeeEnvironment
  patch: |-
    - op: add
      path: /spec/version
      value: 1-6-1 (Modify the version)

Führen Sie die gleichen Schritte aus, die unter Initialisierungsressourcen und Controller erstellen im Apigee-Hybrid-Installationsworkflow beschrieben werden. Sie können das Skript verwenden oder die bereitgestellten manuellen Schritte ausführen, um Initialisierungsressourcen und Controller zu aktualisieren.

Apigee Kubernetes-Komponenten aktualisieren

Sie müssen folgende Änderungen vornehmen: – Bei Architekturänderungen oder der Einführung neuer oder der Einstellung alter Felder müssen Sie die CRs gemäß der Anleitung im Upgrade-Leitfaden ändern. – Sie müssen zumindest die Versionsfelder in CRs (geben die installierte Apigee Hybrid-Version an) auf die neuere Apigee Hybrid-Version aktualisieren.

Wenden Sie die Änderungen für Apigee-CRs an. In einer Nicht-Produktionsumgebung können Sie alle Änderungen gleichzeitig auf Apigee-Komponenten anwenden.

kubectl apply -f ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}

Apigee Hybrid-Rollback

  1. apigee-hybrid-setup wiederherstellen

    Wechseln Sie in das Verzeichnis, das die vorherige Version der Apigee Hybrid-Einrichtung enthält. Wenn nicht verfügbar, stellen Sie sie aus der ZIP-Datei wieder her, die in Schritt 1 während des Apigee Hybrid-Upgrades erstellt wurde.

  2. Rollback von Kubernetes-Komponenten durchführen

    Änderungen für Apigee-CRs anwenden

    kubectl apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}

  3. Rollback des Controllers durchführen

    Führen Sie die gleichen Schritte aus, die unter Initialisierungsressourcen und Controller erstellen im Apigee-Hybrid-Installationsworkflow beschrieben werden. Sie können das Skript verwenden oder die bereitgestellten manuellen Schritte ausführen, um ein Rollback der Initialisierungsressourcen und des Controllers durchzuführen.

  4. Bereinigen

    Sie müssen alle zusätzlichen Ressourcen bereinigen, die während des Upgrades erstellt wurden, z. B. neue Komponenten oder Dienstkonten, die in der neueren Hybrid-Version eingeführt wurden. Alle Ressourcen, die bereinigt werden müssen, und die Schritte zur Bereinigung finden Sie im Upgrade-Leitfaden.

Umgebung löschen

Führen Sie die folgenden Schritte aus, um alle Ressourcen, die sich auf eine Umgebung beziehen, aus Ihrem Kubernetes-Cluster zu löschen:

  1. Rufen Sie den Namen der Umgebung-CR ab. Dazu können Sie alle Umgebungen abrufen:

    kubectl get env -n ${APIGEE_NAMESPACE}

    Speichern Sie den Ressourcennamen in der Umgebungsvariable APIGEE_ENV.

  2. Löschen Sie die Umgebungsverschlüsselungsschlüssel. Wenn Sie beispielsweise den Namen der Verschlüsselungsschlüssel nicht geändert haben, können Sie sie mit folgendem Befehl löschen:

    kubectl delete secret -n ${APIGEE_NAMESPACE} $APIGEE_ENV-encryption-keys

  3. Löschen Sie die Google Cloud-Dienstkonto-Secrets:

    kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}')

  4. Löschen Sie Kubernetes-Dienstkonten:

    kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get env $APIGEE_ENV -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')

  5. Löschen Sie die benutzerdefinierte Ressource der Apigee-Umgebung:

    kubectl -n ${APIGEE_NAMESPACE} delete env $APIGEE_ENV

Hybrid-Einrichtung löschen

Führen Sie die folgenden Schritte aus, um alle Ressourcen im Zusammenhang mit Apigee Hybrid aus Ihrem Kubernetes-Cluster zu löschen:

  1. Sie müssen Apigee-Nutzereinrichtungs- und Schemaeinrichtungsjobs löschen.

    # To list all jobs in ${APIGEE_NAMESPACE}
kubectl -n ${APIGEE_NAMESPACE} get jobs
# To delete all jobs in ${APIGEE_NAMESPACE}
kubectl -n ${APIGEE_NAMESPACE} delete jobs $(kubectl -n ${APIGEE_NAMESPACE} get jobs -o custom-columns=':.metadata.name')

  2. Sie müssen die bereitgestellten Komponenten der Apigee Hybrid-Datenebene löschen. Verwenden Sie den folgenden Befehl, um alle Komponenten zu löschen:

    kubectl delete -k ${INSTALL_DIR}/overlays/instances/$INSTANCE_NAME

  3. Dieser Schritt ist nur erforderlich, wenn Sie nicht den Standardnamen für Kubernetes-Dienstkonto-Secrets, Google Cloud-Dienstkonto-Secrets usw. verwendet haben. Wenn Sie Standardnamen verwendet haben, werden sie im nächsten Schritt gelöscht. Andernfalls müssen sie mit den folgenden Befehlen manuell gelöscht werden:

    kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.appServiceAccountSecretName}')
kubectl delete secret -n ${APIGEE_NAMESPACE} $(kubectl get ${APIGEE_COMPONENT} ${APIGEE_COMPONENT_NAME} -n ${APIGEE_NAMESPACE} -o=jsonpath='{.spec.components.*.podServiceAccountName}')

  4. Im Fall von Openshift müssen Sie SCCs (Security Context Constraints) löschen, die während der Installation von Apigee Hybrid erstellt wurden.

    kubectl delete scc ${SECURITY_CONTEXT_CONSTRAINTS_NAME}

  5. Führen Sie den folgenden Befehl aus, um Rollen, Rollenbindungen, CRDs, Controller-Deployments usw. zu löschen.

    kubectl delete -k ${INSTALL_DIR}/overlays/initialization/ingress
kubectl delete -k ${INSTALL_DIR}/overlays/initialization/rbac
kubectl delete -k ${INSTALL_DIR}/overlays/initialization/webhooks
kubectl delete -k ${INSTALL_DIR}/overlays/initialization/crds
kubectl delete -k ${INSTALL_DIR}/overlays/initialization/certificates

  6. Führen Sie den folgenden Befehl aus, um den Apigee-Namespace zu löschen:

    kubectl delete -f ${INSTALL_DIR}/overlays/initialization/namespace.yaml

    Alternativ können Sie den folgenden Befehl verwenden:

    kubectl delete $APIGEE_NAMESPACE

Installation mehrerer Instanzen

Die Einrichtung mehrerer Instanzen bezieht sich auf die Hybrid-Einrichtung, die sich über mehrere Regionen oder innerhalb derselben Regionen erstrecken kann. Apigee empfiehlt, die Konfigurationen der zweiten Instanz in einer separaten Verzeichnisstruktur zu organisieren, da sich die Umgebungskonfigurationen (Replikate usw.) zwischen Instanzen unterscheiden. Die Konfigurationen der einzelnen Instanzen werden entkoppelt und unabhängig in ihren jeweiligen Ordnerstrukturen organisiert.

Beispiel: Bei der Aktiv-Passiv-Einrichtung in einem Szenario mit mehreren Regionen möchten Sie möglicherweise eine zweite Region in einem Warm-Standby mit unterschiedlichen Größen und Konfigurationen konfigurieren.

In der Ordnerstruktur unten können Sie eine Kopie des Verzeichnisses instance1 namens instance2 erstellen und die Datenspeicher- und Ingress-Konfigurationen nach Bedarf ändern.

apigee-hybrid-setup-Ordnerstruktur für die Einrichtung mehrerer Instanzen.

.
├── bases
│   ├── controllers
│   │   ├── apigee-controller
│   │   │   ├── apigee-controller-deployment.yaml
│   │   │   └── kustomization.yaml
│   │   └── istiod
│   │       ├── apigee-ingressgateway-manager-deployment.yaml
│   │       └── kustomization.yaml
│   └── initialization
│       ├── certificates
│       │   ├── certificates-and-issuers.yaml
│       │   └── kustomization.yaml
│       ├── crds
│       │   ├── customresourcedefinition-apigeedatastores.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeedeployments.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeenvironments.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeorganizations.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeredis.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeerouteconfigs.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeeroutes.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-apigeetelemetries.apigee.cloud.google.com.yaml
│       │   ├── customresourcedefinition-cassandradatareplications.apigee.cloud.google.com.yaml
│       │   └── kustomization.yaml
│       ├── ingress
│       │   ├── envoyfilter-1.11.yaml
│       │   └── kustomization.yaml
│       ├── openshift
│       │   ├── kustomization.yaml
│       │   └── scc.yaml
│       ├── rbac
│       │   ├── apigee-controller
│       │   │   ├── kustomization.yaml
│       │   │   └── rbac.yaml
│       │   └── apigee-embedded-ingress-controller
│       │       ├── cluster-role-bindings.yaml
│       │       ├── cluster-roles.yaml
│       │       ├── kustomization.yaml
│       │       └── service-account.yaml
│       └── webhooks
│           ├── kustomization.yaml
│           ├── mutatingwebhookconfiguration.yaml
│           └── validatingwebhookconfiguration.yaml
├── instances
│   └── instance1 (Add the 2nd instance under instances directory similar to instance1)
│       ├── datastore
│       │   ├── apigee-datastore.yaml
│       │   ├── components
│       │   │   ├── http-proxy
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   ├── imagepullsecret
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   ├── nodeselector
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   └── workload-identity
│       │   │       ├── apigee-workload-identities.yaml
│       │   │       ├── kustomization.yaml
│       │   │       └── patch.yaml
│       │   ├── kustomization.yaml
│       │   └── secrets.yaml
│       ├── environments
│       │   ├── kustomization.yaml
│       │   └── test
│       │       ├── apigee-environment.yaml
│       │       ├── components
│       │       │   ├── http-proxy
│       │       │   │   ├── kustomization.yaml
│       │       │   │   └── patch.yaml
│       │       │   ├── imagepullsecret
│       │       │   │   ├── kustomization.yaml
│       │       │   │   └── patch.yaml
│       │       │   ├── nodeselector
│       │       │   │   ├── kustomization.yaml
│       │       │   │   └── patch.yaml
│       │       │   └── workload-identity
│       │       │       ├── apigee-workload-identities.yaml
│       │       │       ├── kustomization.yaml
│       │       │       └── patch.yaml
│       │       ├── kustomization.yaml
│       │       └── secrets.yaml
│       ├── kustomization.yaml
│       ├── organization
│       │   ├── apigee-organization.yaml
│       │   ├── components
│       │   │   ├── http-proxy
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   ├── imagepullsecret
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   ├── nodeselector
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   └── workload-identity
│       │   │       ├── apigee-workload-identities.yaml
│       │   │       ├── kustomization.yaml
│       │   │       └── patch.yaml
│       │   ├── kustomization.yaml
│       │   └── secrets.yaml
│       ├── redis
│       │   ├── apigee-redis.yaml
│       │   ├── components
│       │   │   ├── imagepullsecret
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   ├── nodeselector
│       │   │   │   ├── kustomization.yaml
│       │   │   │   └── patch.yaml
│       │   │   └── workload-identity
│       │   │       ├── apigee-workload-identities.yaml
│       │   │       ├── kustomization.yaml
│       │   │       └── patch.yaml
│       │   ├── kustomization.yaml
│       │   └── secrets.yaml
│       ├── route-config
│       │   ├── kustomization.yaml
│       │   └── test-env-group
│       │       ├── apigee-route-config.yaml
│       │       ├── components
│       │       │   ├── http-and-non-sni-client
│       │       │   │   ├── apigee-route.yaml
│       │       │   │   └── kustomization.yaml
│       │       │   ├── http-client
│       │       │   │   ├── apigee-route.yaml
│       │       │   │   └── kustomization.yaml
│       │       │   └── non-sni-client
│       │       │       ├── apigee-route.yaml
│       │       │       └── kustomization.yaml
│       │       └── kustomization.yaml
│       └── telemetry
│           ├── apigee-telemetry.yaml
│           ├── components
│           │   ├── http-proxy
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   ├── imagepullsecret
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   ├── logger
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   ├── metrics
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   ├── nodeselector
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   ├── workload-identity-logger
│           │   │   ├── apigee-workload-identities.yaml
│           │   │   ├── kustomization.yaml
│           │   │   └── patch.yaml
│           │   └── workload-identity-metrics
│           │       ├── apigee-workload-identities.yaml
│           │       ├── kustomization.yaml
│           │       └── patch.yaml
│           └── kustomization.yaml
├── overlays
│   ├── controllers
│   │   ├── apigee-controller
│   │   │   ├── apigee-hybrid-config.yaml
│   │   │   ├── components
│   │   │   │   ├── imagepullsecret
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   └── patch.yaml
│   │   │   │   └── nodeselector
│   │   │   │       ├── kustomization.yaml
│   │   │   │       └── patch.yaml
│   │   │   └── kustomization.yaml
│   │   ├── istiod
│   │   │   ├── apigee-ingressgateway-manager-deployment-patch.yaml
│   │   │   ├── apigee-istio-mesh-config.yaml
│   │   │   ├── components
│   │   │   │   ├── imagepullsecret
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   └── patch.yaml
│   │   │   │   └── nodeselector
│   │   │   │       ├── kustomization.yaml
│   │   │   │       └── patch.yaml
│   │   │   └── kustomization.yaml
│   │   └── kustomization.yaml
│   ├── initialization
│   │   ├── certificates
│   │   │   ├── apigee-ingressgateway-manager-certificate.yaml
│   │   │   └── kustomization.yaml
│   │   ├── crds
│   │   │   └── kustomization.yaml
│   │   ├── ingress
│   │   │   └── kustomization.yaml
│   │   ├── namespace.yaml
│   │   ├── openshift
│   │   │   ├── kustomization.yaml
│   │   │   └── scc.yaml
│   │   ├── rbac
│   │   │   ├── apigee-controller
│   │   │   │   └── kustomization.yaml
│   │   │   ├── apigee-embedded-ingress-controller
│   │   │   │   └── kustomization.yaml
│   │   │   └── kustomization.yaml
│   │   └── webhooks
│   │       ├── kustomization.yaml
│   │       ├── mutatingwebhookconfiguration.yaml
│   │       └── validatingwebhookconfiguration.yaml
│   └── instances
│       └── instance1
│           ├── datastore
│           │   ├── apigee-datastore.yaml
│           │   ├── components
│           │   │   ├── http-proxy
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── openshift-scc
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── scc.yaml
│           │   │   └── workload-identity
│           │   │       ├── apigee-workload-identities.yaml
│           │   │       ├── kustomization.yaml
│           │   │       └── patch.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── environments
│           │   ├── kustomization.yaml
│           │   └── test
│           │       ├── apigee-environment.yaml
│           │       ├── components
│           │       │   ├── http-proxy
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   ├── imagepullsecret
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   ├── nodeselector
│           │       │   │   ├── kustomization.yaml
│           │       │   │   └── patch.yaml
│           │       │   └── workload-identity
│           │       │       ├── apigee-workload-identities.yaml
│           │       │       ├── kustomization.yaml
│           │       │       └── patch.yaml
│           │       ├── kustomization.yaml
│           │       └── secrets.yaml
│           ├── kustomization.yaml
│           ├── organization
│           │   ├── apigee-organization.yaml
│           │   ├── components
│           │   │   ├── http-proxy
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   └── workload-identity
│           │   │       ├── apigee-workload-identities.yaml
│           │   │       ├── kustomization.yaml
│           │   │       └── patch.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── redis
│           │   ├── apigee-redis.yaml
│           │   ├── components
│           │   │   ├── imagepullsecret
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   ├── nodeselector
│           │   │   │   ├── kustomization.yaml
│           │   │   │   └── patch.yaml
│           │   │   └── workload-identity
│           │   │       ├── apigee-workload-identities.yaml
│           │   │       ├── kustomization.yaml
│           │   │       └── patch.yaml
│           │   ├── kustomization.yaml
│           │   └── secrets.yaml
│           ├── route-config
│           │   ├── kustomization.yaml
│           │   └── test-envgroup
│           │       ├── apigee-route-config.yaml
│           │       ├── components
│           │       │   ├── http-and-non-sni-client
│           │       │   │   ├── apigee-route.yaml
│           │       │   │   └── kustomization.yaml
│           │       │   ├── http-client
│           │       │   │   ├── apigee-route.yaml
│           │       │   │   └── kustomization.yaml
│           │       │   └── non-sni-client
│           │       │       ├── apigee-route.yaml
│           │       │       └── kustomization.yaml
│           │       └── kustomization.yaml
│           └── telemetry
│               ├── apigee-telemetry.yaml
│               ├── components
│               │   ├── http-proxy
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── imagepullsecret
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── logger
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── metrics
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── nodeselector
│               │   │   ├── kustomization.yaml
│               │   │   └── patch.yaml
│               │   ├── openshift-scc
│               │   │   ├── kustomization.yaml
│               │   │   └── scc.yaml
│               │   ├── workload-identity-logger
│               │   │   ├── apigee-workload-identities.yaml
│               │   │   └── kustomization.yaml
│               │   └── workload-identity-metrics
│               │       ├── apigee-workload-identities.yaml
│               │       ├── kustomization.yaml
│               │       └── patch.yaml
│               └── kustomization.yaml
├── README.md
├── templates
│   ├── ingress-certificate.yaml
│   ├── ingress-cert-secret.yaml
│   └── service-account-key-secret.yaml
└── tools
    ├── apigee-hybrid-setup.sh
    ├── common.sh
    ├── create-service-account.sh
    └── dump_kubernetes.sh

Einrichtung mehrerer Instanzen in GKE

Vorbereitung

Bevor mehrere Instanzen von Hybrid konfiguriert werden, müssen Sie folgende Voraussetzungen erfüllen:

  • Kubernetes-Cluster in mehreren Regionen (gleiche oder unterschiedliche) mit unterschiedlichen CIDR-Blöcken einrichten
  • Regionenübergreifende Kommunikation
  • Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen öffnen (7000 kann bei der Fehlerbehebung als Sicherungsoption verwendet werden). Siehe auch Ports konfigurieren.

Mit einem Tool wie ntpdate können Sie prüfen, ob die Serverzeiten synchronisiert sind.

Seed-Host für mehrere Regionen konfigurieren

  1. Erstellen Sie eine Kopie des Ordners $INSTANCE_NAME aus Ihrer vorhandenen Instanz und fügen Sie sie unter dem Ordner „instances“ hinzu.
  2. Ändern Sie den Wert des Namespace-Felds, wenn er sich vom instance1-Namespace unterscheidet.
  3. Folgen Sie der Anleitung unter Ingress-TLS-Zertifikate angeben, um die Ingress-Konfiguration für die andere Instanz zu ändern.

  4. Informationen zum Konfigurieren der Load-Balancer-IP für die andere Instanz finden Sie unter Apigee-Ingress-Gateway verwalten.

  5. Legen Sie den kubectl-Kontext auf den ursprünglichen Cluster fest, bevor Sie den Seed-Namen abrufen:

    kubectl config use-context original-cluster-name

  6. Führen Sie den folgenden kubectl-Befehl aus, um eine Seed-Hostadresse für Cassandra in der aktuellen Region zu identifizieren.

    kubectl get pods -o wide -n apigee -l app=apigee-cassandra

  7. Jede Pod-IP-Adresse, die vom vorherigen Befehl zurückgegeben wurde, kann als multiregionaler Seed-Host betrachtet werden.

  8. Konfigurieren Sie in der zweiten Instanz den Wert von multiRegionSeedHost in der Apigee-Datenspeicher-CR unter ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore/apigee-datastore.yaml.

Neue Instanz einrichten

  1. Legen Sie den vorhandenen Cluster als Kontext fest:

    kubectl config use-context existing-cluster-name

  2. Apigee-CA-Secret in eine Datei exportieren:

    kubectl -n cert-manager get secret apigee-root-certificate -o yaml > apigee-root-certificate.yaml

  3. Legen Sie für den Kontext den Clusternamen der neuen Region fest:

    kubectl config use-context NEW_CLUSTER_NAME

  4. Importieren Sie das Secret in den neuen Cluster:

    kubectl -n cert-manager apply -f apigee-root-certificate.yaml

  5. Installieren Sie Hybrid in der neuen Instanz (Region), indem Sie die Schritte unter Initialisierungsressourcen und Controller erstellen ausführen.

  6. Richten Sie Cassandra auf allen Pods in den neuen Rechenzentren ein. Rufen Sie mit dem folgenden Befehl apigeeorg aus dem Cluster ab:

    kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name"

  7. Erstellen Sie eine benutzerdefinierte Cassandra-Ressourcendatei (YAML) für die Datenreplikation. Die Datei kann einen beliebigen Namen haben. In den folgenden Beispielen hat die Datei den Namen „datareplication.yaml“. Die Datei muss Folgendes enthalten:

    apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
name: REGION_EXPANSION
namespace: NAMESPACE
spec:
organizationRef: APIGEEORG_VALUE
force: false
source:
  region: SOURCE_REGION

    Wobei:

    • REGION_EXPANSION ist der Name, den Sie diesen Metadaten geben. Sie können einen Namen wie "cassandra-data-replication" auswählen.
    • NAMESPACE ist der gleiche Namespace, der für die zweite Instanz ausgewählt wurde. Dies ist normalerweise "apigee".
    • APIGEEORG_VALUE ist die Wertausgabe des Befehls „kubectl get apigeeorg -n apigee -o json | jq ".items[].metadata.name" im vorherigen Schritt.
    • SOURCE_REGION ist der Wert des Cassandra-Rechenzentrums aus dem nodetool-Status aus dem Quellcluster.

  8. Wenden Sie die CassandraDataReplication mit dem folgenden Befehl an:

    kubectl apply -f datareplication.yaml

  9. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.

    kubectl -n apigee get apigeeds -o json | jq ".items[].status.cassandraDataReplication"

    Das Ergebnis sollte ungefähr so aussehen:

    {
"rebuildDetails": {
  "apigee-cassandra-default-0": {
    "state": "complete",
    "updated": 1623105760
  },
  "apigee-cassandra-default-1": {
    "state": "complete",
    "updated": 1623105765
  },
  "apigee-cassandra-default-2": {
    "state": "complete",
    "updated": 1623105770
  }
},
"state": "complete",
"updated": 1623105770
}

  10. Prüfen Sie die Neuerstellungsprozesse in den Logs. Überprüfen Sie außerdem die Datenmenge mit dem nodetool-status-Befehl:

    kubectl logs apigee-cassandra-default-0 -f -n apigee

    Siehe „datastore/secrets.yaml“ für JMX_user und JMX_password:

    kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

  11. Entfernen Sie multiRegionSeedHost aus der Apigee-Datenspeicher-CR und führen Sie den folgenden Befehl aus, um die Änderung anzuwenden:

    kubectl apply k apply -k ${INSTALL_DIR}/overlays/instances/${INSTANCE_DIR}/datastore

  12. Cassandra-Clusterstatus prüfen

    Mit dem folgenden Befehl können Sie ersehen, ob die Clustereinrichtung in zwei Rechenzentren erfolgreich verläuft. Der Befehl überprüft den nodetool-Status für beide Regionen.

    kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status


    Datacenter: us-central1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          100.0%               a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%               9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%               1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

Fehlerbehebung

Leitfaden zu Support, Diagnose und Fehlerbehebung

https://cloud.google.com/apigee/docs/api-platform/troubleshoot/playbooks/troubleshooting-apigee-hybrid.

Manuelle Bereinigung nach Verwendung von "forceDelete" in multiregionaler Apigee Hybrid-Einrichtung

  • Im folgenden Beispiel gibt es zwei Regionen: us-east1 und us-west1.
  • In der Region us-west1 wurde der Apigee-Datenspeicher durch erzwungenes Löschen gelöscht.
  • In der Region us-east1 wird Cassandra noch ausgeführt.

  • Prüfen Sie mit dem folgenden Befehl, ob apigeeds gelöscht wurde:

    kubectl get apigeeds -n apigee
No resources found in apigee namespace.

  • Ändern Sie den kubectl-Kontext in die andere Region, in der der Cassandra-Cluster noch ausgeführt wird (hier us-east1).

  • Prüfen Sie, ob der Datenspeicher ausgeführt wird:

    kubectl get apigeeds -n apigee
NAME      STATE     AGE
default      running    23h

  • Ausführung in einem der Cassandra-Pods in der Region (hier us-east1):

    kubectl exec -it -n apigee apigee-cassandra-default-0 -- bash
apigee@apigee-cassandra-default-0:~$

  • Prüfen Sie den nodetool-Status. Er zeigt alle Knoten in der gelöschten Region an (hier us-west1).

    apigee@apigee-cassandra-default-0:~$ nodetool -u ${APIGEE_JMX_USER} -pw ${APIGEE_JMX_PASSWORD} status

    Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--     Address         Load           Tokens   Owns    Host ID                                                           Rack
UN  10.52.0.212   685.01 KiB  256          ?         e1aa61e3-4eae-4549-9b58-506d495d87ab   ra-1
UN  10.52.0.72     606.75 KiB  256          ?         477dfc03-f93e-40ea-810a-d15769822ad5     ra-1
UN  10.52.0.104   648.3 KiB    256          ?         a8854cff-c2e3-4f0c-a342-e692787efcab        ra-1
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--     Address         Load             Tokens   Owns     Host ID                                                           Rack
DN  10.60.0.143   567.06 KiB    256          ?           355d6ace-ab77-42cb-8138-9993bfd62d0e    ra-1
DN  10.60.0.40     535.99 KiB    256          ?           4ed2c903-ff56-40fa-a15e-80a3de3cb22d      ra-1
DN  10.60.0.17     573.08 KiB    256          ?           f9a50d19-c04a-4d0d-a088-612384bed9f5     ra-1

  • Entfernen Sie alle Knoten in der gelöschten Region (hier us-west1).

    apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 355d6ace-ab77-42cb-8138-9993bfd62d0e
apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode 4ed2c903-ff56-40fa-a15e-80a3de3cb22d
apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode f9a50d19-c04a-4d0d-a088-612384bed9f5

  • Prüfen Sie, ob noch Knoten in der gelöschten Region übrig sind (hier us-west1).

    apigee@apigee-cassandra-default-0:~$ nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status


    Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--     Address         Load             Tokens  Owns   Host ID                                                           Rack
UN  10.52.0.212   699.71 KiB    256          ?        e1aa61e3-4eae-4549-9b58-506d495d87ab  ra-1
UN  10.52.0.72     586.77 KiB    256          ?        477dfc03-f93e-40ea-810a-d15769822ad5    ra-1
UN  10.52.0.104   623.6 KiB      256          ?        a8854cff-c2e3-4f0c-a342-e692787efcab       ra-1

  • Löschen Sie zum Schluss den Nutzereinrichtungsjob in der Region (hier us-east1). Der Job wird innerhalb weniger Sekunden automatisch neu erstellt.

    kubectl get jobs -n apigee


    ​​NAME                                                                                    COMPLETIONS   DURATION   AGE
apigee-cassandra-schema-setup-apigee--0d2504c                    0/1           5m54s      5m54s
apigee-cassandra-user-setup--apigee--0d2504c                          0/1            7s         7s


    kubectl delete job apigee-cassandra-user-setup--apigee--0d2504c

  • Auf Abschluss des Nutzereinrichtungsjobs warten.

    kubectl get jobs -n apigee

    ​​NAME                                                                                    COMPLETIONS   DURATION   AGE
apigee-cassandra-schema-setup-apigee--0d2504c                    1/1           5m54s      5m54s
apigee-cassandra-user-setup--apigee--0d2504c                      1/1           7m                7m

  • Achten Sie darauf, dass die Schlüsselbereiche nicht die gelöschte Region haben.

  • Cassandra-Debugging-Pod erstellen.

    • Folgen Sie der Hybrid-Version 1.5 und höher, folgen Sie der Anleitung zur Fehlerbehebung für Cassandra (z. B. für Hybrid 1.5, Hybrid 1.6) und führen Sie dann im erstellten Pod aus.

  • Melden Sie sich mit dem folgenden Befehl bei "cqlsh" im Debugging-Pod an.

    apigee@cassandra-debug-client:~$ cqlsh apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local -u ddl_user --ssl
Password:

  • Prüfen Sie, ob die Region us-west1 aus allen Schlüsselbereichen entfernt wurde.

    ddl_user@cqlsh> SELECT * FROM system_schema.keyspaces;

    keyspace_name              | durable_writes | replication
---------------------------+----------------+-----------------------------------------------------------------------------------
cache_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
  rtc_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
                system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
              system_schema |           True |                            {'class': 'org.apache.cassandra.locator.LocalStrategy'}
quota_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
  kms_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
         system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
                     system |           True |                            {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                     perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
  kvm_prince_hybrid_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
              system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'us-east1': '3'}
(11 rows)