In diesem Thema wird erläutert, wie Sie eine zweite Apigee Hybrid-Organisation (org) zu einem vorhandenen Kubernetes-Cluster hinzufügen. In dieser Konfiguration mit mehreren Organisationen verwenden beide Organisationen denselben Cassandra-Ring. Für jede Organisation können mehrere Umgebungen und Umgebungsgruppen konfiguriert sein.
Beschränkungen
Eine Konfiguration mit mehrere Organisationen pro Cluster wird mit den folgenden Einschränkungen unterstützt: Wir empfehlen, diese Konfiguration nicht zu verwenden, bis diese Einschränkungen gemindert sind.
Wenn Sie mehrere Apigee Hybrid-Instanzen haben möchten, sollte jede Instanz einen eigenen Cluster haben. Mehrere Apigee Hybrid-Instanzen, die auf demselben Kubernetes-Cluster ausgeführt werden, können zu Instabilitäten führen, die möglicherweise zu Ausfallzeiten führen.
Pod-Messwerte werden nur an das erste konfigurierte Google Cloud-Projekt gesendet. Diese Einschränkung ist im Cloud Monitoring-Tool am deutlichsten erkennbar. Sie wirkt sich nur auf Clustermesswerte aus. API-Analysen sind nicht betroffen. Die Messwerte für die anderen Apigee-Organisationen werden nicht an das entsprechende Google Cloud-Projekt gesendet.
Das gesamte Logging aus den Pods wird an das erste konfigurierte Google Cloud-Projekt gesendet. Diese Einschränkung ist im Cloud Logging-Tool am deutlichsten erkennbar. Die Logs für die anderen Apigee-Organisationen werden nicht an das entsprechende Google Cloud-Projekt gesendet. Logs werden weiterhin auf Pod-Ebene erfasst und können mit kubectl-Befehlen abgerufen werden. Sie werden jedoch nicht über Cloud Logging an das richtige Cloud-Projekt gesendet.
Sie können Organisationsdaten in der Cassandra-Datenbank nicht nur für eine Organisation löschen. Dies bedeutet, dass sich Organisationen nicht selektiv entfernen lassen. Jede Änderung an der Datenbankkonfiguration wirkt sich auf alle Organisationen aus, die in diesem Cluster bereitgestellt werden.
Beim Hybrid-Upgrade wird der gesamte Cluster auf einmal aktualisiert.
Sicherungen und Wiederherstellungen werden als Cluster durchgeführt und können nicht für eine bestimmte Organisation ausgelöst werden.
Das Apigee API-Monitoring-Feature (Zeitachse, Zuletzt, Prüfen) funktioniert nur für die Organisation, die zuerst konfiguriert und bereitgestellt wurde. Es steht in einem Multi-Organisations-Cluster für die anderen Organisationen nicht zur Verfügung.
Optionen für Multi-Organisationen
In diesem Abschnitt wird beschrieben, wie der Apigee-Support vorhandene Cluster mit mehreren Organisationen sowie Empfehlungen für zukünftige Bereitstellungen verarbeitet:
Wenn Sie bereits Kubernetes-Cluster mit mehreren Organisationen in Nicht-Produktions- und Produktionskontexten bereitgestellt haben, werden diese vom Apigee-Support weiterhin unterstützt. Beachten Sie jedoch die im nächsten Abschnitt beschriebenen technischen Einschränkungen. Wir empfehlen Ihnen, alle zukünftigen Produktionsbereitstellungen so zu ändern, dass eine Apigee-Organisation pro Cluster verwendet wird.
Wenn Sie bereits Cluster mit mehreren Organisationen in Nicht-Produktionsumgebungen haben, werden diese vom Apigee-Support weiterhin unterstützt. Wir empfehlen, alle Produktionscluster zu einer neuen Konfiguration zu migrieren, die eine Apigee-Organisation pro Cluster verwendet.
Voraussetzungen
Beachten Sie Folgendes, bevor Sie fortfahren:
Sie müssen eine vorhandene Hybridorganisation mit einer oder mehreren Umgebungen haben, die in einem vorhandenen Kubernetes-Cluster installiert und konfiguriert sind. Weitere Informationen finden Sie in der Hybrid-Installationsanleitung.
Wenn Sie mehrere Organisationen in einem einzigen Cluster kombinieren, müssen die Hybridversionen übereinstimmen. Bevor Sie eine zweite Organisation zu einem Cluster hinzufügen, aktualisieren Sie bei Bedarf die vorhandene Hybridinstallation. Siehe Apigee Hybrid aktualisieren.
Organisation erstellen, die dem vorhandenen Cluster hinzugefügt werden soll
In den folgenden Schritten erstellen Sie eine neue Überschreibungsdatei und konfigurieren sie für die neue Organisation.
Eine overrides.yaml-Datei kann nur Informationen von einer Organisation unterstützen. Daher müssen Sie eine neue overrides.yaml-Datei erstellen und auf den vorhandenen Kubernetes-Cluster anwenden.
Notieren Sie sich die TLS-Zertifikatsdateien (.key und .pem) im Verzeichnis certs. Wenn Sie sie noch einmal erstellen müssen, folgen Sie der Anleitung unter TLS-Zertifikate erstellen.
Kopieren Sie die vorhandene overrides.yaml in eine neue Datei, um sie als Ausgangspunkt für die Konfiguration Ihrer neuen Organisation zu verwenden. Beispiel: new-overrides.yaml.
Bearbeiten Sie die neue Überschreibungsdatei mit den folgenden Konfigurationen:
In der folgenden Tabelle sind alle Attributwerte beschrieben, die Sie in der Überschreibungsdatei angeben müssen. Weitere Informationen finden Sie unter Referenz zu Konfigurationsattributen.
Variable
Beschreibung
new-org-name
Der Name Ihrer neuen Organisation.
instance-id
Alle Organisationen in diesem Cluster müssen dieselbe Instanz-ID haben. Daher muss dies mit dem Eintrag instanceID in der Überschreibungsdatei für Ihre ursprüngliche Organisation übereinstimmen.
existing-cluster-name
Der Name des Clusters, dem Sie diese Organisation hinzufügen. Sie muss mit dem k8sCluster.name-Eintrag in der Überschreibungsdatei für den ursprünglichen Cluster übereinstimmen.
existing-cluster-analytics-region
Die Region, in der der ursprüngliche Cluster bereitgestellt ist. Sie muss mit dem k8sCluster.region-Eintrag in der Überschreibungsdatei für den ursprünglichen Cluster übereinstimmen.
new-project-id
Die Projekt-ID Ihres Projekts. Die Projekt-ID und der Organisationsname sind identisch.
new-project-default-location
Die Analyseregion, die Sie beim Erstellen der neuen Organisation angegeben haben. Sie muss nicht mit der Region für die vorhandene Organisation übereinstimmen.
namespace
Alle Organisationen im Cluster müssen denselben Namespace verwenden. Achten Sie darauf, denselben Namespace zu verwenden, der für die ursprüngliche Organisation verwendet wurde. Der Standard-Namespace ist apigee.
new-environment-group-name
Die neue Umgebungsgruppe, die Sie für die neue Organisation erstellt haben.
cert-file-name und key-file-name
Die TLS-Zertifikats- und -Schlüsseldateien für den Cluster, den Sie in Schritt 1 in diesem Abschnitt geprüft oder erstellt haben.
new-environment-name
Der Name der Umgebung, die Sie für die neue Organisation erstellt haben.
new-service-accounts-directory
Das Verzeichnis, in dem sich die Dienstkonto-Schlüsseldateien befinden, die Sie für die neue Organisation erstellt haben.
Wenden Sie die Konfiguration an
Wenden Sie die neue Organisationskonfiguration auf Ihren Cluster an:
Führen Sie eine Probelaufinstallation aus, um auf Probleme zu prüfen:
Wenn keine Probleme auftreten, wenden Sie die Komponenten auf Organisationsebene an. Mit diesem Schritt werden die Cassandra-Jobs (Nutzer und Schema) sowie die Dienste Apigee Connect, Apigee Watcher und MART installiert:
Wenden Sie die Load-Balancer-Änderungen an. Mit diesem Schritt wird der Ingress so konfiguriert, dass er die neuen virtuellen Hosts für die zweite Organisation überwacht:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-28 (UTC)."],[[["\u003cp\u003eThis documentation explains how to add a second Apigee hybrid organization to an existing Kubernetes cluster, where both organizations share the same Cassandra ring and can have multiple environments and environment groups.\u003c/p\u003e\n"],["\u003cp\u003eWhile multi-org per cluster configurations are supported, they come with several limitations, such as pod metrics and logs only being sent to the first configured Google Cloud project, and the inability to selectively delete data for one org, which are strong reasons not to use them.\u003c/p\u003e\n"],["\u003cp\u003eApigee Support will continue to support existing multi-org clusters, but recommends migrating production clusters to a single-org-per-cluster configuration, and that future deployments should only use one Apigee org per cluster.\u003c/p\u003e\n"],["\u003cp\u003eAdding a new org to an existing cluster requires creating a new \u003ccode\u003eoverrides.yaml\u003c/code\u003e file with configurations specific to the new org, including a unique org name, a matching instance ID, the same cluster name and namespace, new project ID and environment details, all while making sure the hybrid version matches.\u003c/p\u003e\n"],["\u003cp\u003eAfter configuring the new overrides file, a sequence of \u003ccode\u003eapigeectl apply\u003c/code\u003e commands must be executed, first doing a dry run to find issues, then applying the org, the environments, and the load balancer changes to deploy the second org.\u003c/p\u003e\n"]]],[],null,["# Adding multiple hybrid orgs to a cluster\n\n| You are currently viewing version 1.9 of the Apigee hybrid documentation. **This version is end of life.** You should upgrade to a newer version. For more information, see [Supported versions](/apigee/docs/hybrid/supported-platforms#supported-versions).\n\n\nThis topic discusses how to add a second Apigee hybrid organization (org) to an existing\nKubernetes cluster. In this multi-org configuration, both orgs use and share the same Cassandra\nring. Each org can have\nmultiple environments and environment groups configured.\n| **Warning:** A multi-org per cluster configuration is supported with specific [limitations](#limitations). Until these limitations are mitigated, we do not recommend that you use this configuration.\n| **Note:** If you are already using multi-org clusters and would like to migrate the orgs to single org clusters, see [Migrating an org to another cluster](/apigee/docs/hybrid/v1.9/migrate-org).\n\nLimitations\n-----------\n\n\nA multi-org per cluster configuration is supported with the following limitations. **Until these\nlimitations are mitigated, we do not recommend that you use this configuration:**\n| **Note:** The maximum number of orgs that you can add to a single cluster is limited. See [Limits](/apigee/docs/api-platform/reference/limits) for details.\n\n- If you are going to have multiple Apigee hybrid instances, each instance should have its own cluster. Multiple Apigee hybrid instances running on the same kubernetes cluster can lead to issues of instability potentially causing downtime.\n- Pod metrics are only sent to the first Google Cloud project that was configured. This limitation is most apparent in the Cloud Monitoring tool. It only affects cluster metrics; API analytics are not affected. The metrics for the other Apigee orgs will not be sent to the matching Google Cloud project.\n- All logging from the pods are sent to the first Google Cloud project that was configured. This limitation is most apparent in the Cloud Logging tool. The logs for the other Apigee orgs will not be sent to the matching Google Cloud project. Logs are still captured at the pod level and can be retrieved with `kubectl` commands. However, they are not sent to the correct Cloud project through Cloud Logging.\n- You cannot delete org data in the Cassandra database for just one org. This means that you cannot remove orgs selectively. Any modification to the database configuration affects all orgs that are deployed to that cluster.\n- The hybrid upgrade procedure upgrades the entire cluster all at once.\n- Backup and restore is done as a cluster, and cannot be done for a specific org.\n- The Apigee API Monitoring feature (Timeline, Recent, Investigate) only works for the first org that was configured and deployed. It will not work for the other orgs in a multi-org cluster.\n\nMulti-org options\n-----------------\n\n\nThis section describes how Apigee Support handles existing multi-org clusters and recommendations\nfor future deployments:\n\n- If you have existing multi-org Kubernetes clusters deployed in non-production and production contexts, Apigee Support will continue to support them. However, note the technical limitations outlined in the next section. We recommend that you change any future production deployments to use one Apigee org per cluster.\n- If you have existing multi-org clusters in non-production contexts, Apigee Support will continue to support them. We recommend that you migrate any production clusters to a new configuration that uses one Apigee org per cluster.\n\nPrerequisites\n-------------\n\n\nBefore continuing, note the following:\n\n- You must have an existing hybrid org with one or more environments installed and configured in an existing Kubernetes cluster. See the [hybrid installation instructions](./precog-overview).\n- When combining multiple orgs in a single cluster, the hybrid versions must all match. Before adding a second org to a cluster, upgrade the existing hybrid installation, if necessary. See [Upgrading Apigee hybrid](/apigee/docs/hybrid/v1.9/upgrade).\n\nCreate an org to add to the existing cluster\n--------------------------------------------\n\n\nTo create the additional org, follow the steps in\n[Part 1: Project and org setup.](./precog-overview)\n| **Note:** If you have an existing org you want to add to your Apigee hybrid installation, you can skip to [Configure the new\n| org](#configuring).\n\nConfigure the new org\n---------------------\n\n\nIn the following steps, you will create a new overrides file and configure it for the\nnew org.\nAn `overrides.yaml` file can only support one org's information. Therefore, you must\ncreate a new `overrides.yaml` file and apply it to the existing Kubernetes cluster.\n\n1. Create service accounts for use with the new org. See [Create service accounts](./install-service-accounts).\n2. Make note of the TLS certificate files (`.key` and `.pem`) in your `certs` directory. If you need to create them again, you can follow the instructions in [Create TLS certificates](/apigee/docs/hybrid/v1.9/install-create-tls-certificates).\n3. Copy your existing `overrides.yaml` to a new file to use as a starting point for configuring your new org. For example: `new-overrides.yaml`.\n4. Edit the new overrides file with the following configurations: \n\n ```verilog\n org: \"\u003cvar translate=\"no\"\u003enew-org-name\u003c/var\u003e\"\n instanceID: \"\u003cvar translate=\"no\"\u003einstance-id\u003c/var\u003e\" ## Must match the instanceID of your existing org.\n\n k8sCluster:\n name: \"\u003cvar translate=\"no\"\u003eexisting-cluster-name\u003c/var\u003e\"\n region: \"\u003cvar translate=\"no\"\u003eexisting-cluster-analytics-region\u003c/var\u003e\"\n\n gcp:\n projectID: \"\u003cvar translate=\"no\"\u003enew-project-id\u003c/var\u003e\"\n name: \"\u003cvar translate=\"no\"\u003enew-project-id\u003c/var\u003e\"\n region: \"\u003cvar translate=\"no\"\u003enew-project-default-location\u003c/var\u003e\"\n\n namespace: namespace ## must be the same for both new and existing orgs\n\n virtualhosts:\n - name: new-environment-group-name\n sslCertPath: ./certs/cert-file-name # .crt or .pem\n sslKeyPath: ./certs/key-file-name # .key\n\n envs:\n - name: new-environment-name\n serviceAccountPaths:\n runtime: ./new-service-accounts-directory/new-project-id-apigee-runtime.json\n synchronizer: ./new-service-accounts-directory/new-project-id-apigee-synchronizer.json\n udca: ./new-service-accounts-directory/new-project-id-apigee-udca.json\n\n connectAgent:\n serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json\n\n mart:\n serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json\n\n metrics:\n serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-metrics.json\n\n watcher:\n serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-watcher.json\n ```\n\n\n The following table describes each of the property values that you must provide in the\n overrides file. For more information, see [Configuration property reference](./config-prop-ref).\n\nApply the configuration\n-----------------------\n\n\nApply the new org configuration to your cluster:\n\n1. Do a dry run installation to check for any problems: \n\n ```\n apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client\n ```\n | **Note:** It's a good practice to do a dry run before applying the configuration to determine if there are any issues.\n2. If there are no issues, apply the org-level components. This step installs the Cassandra jobs (user and schema), Apigee Connect, Apigee Watcher and MART services: \n\n ```\n apigeectl apply -f overrides/new-overrides.yaml --org\n ```\n3. Install the environment. This step installs apigee-runtime, synchronizer and UDCA components, per environment: \n\n ```\n apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME} --dry-run=client\n ``` \n\n ```\n apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME}\n ```\n | **Note:** If you have multiple environments in your new org, repeat this step for each environment.\n 4. Apply the load balancer changes. This step configures the ingress to listen to the new virtual host(s) for the second org: **Important:** Do not duplicate hostnames/domain names between two orgs, as it can result in unpredictable routing. \n\n ```\n apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client\n ``` \n\n ```\n apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts\n ```\n5. Enable synchronizer access for your new org following the steps in [Enable Synchronizer access](/apigee/docs/hybrid/v1.9/install-enable-synchronizer-access)."]]
