Questo argomento spiega come aggiungere una seconda organizzazione (org) Apigee hybrid a un cluster Kubernetes esistente. In questa configurazione multi-organizzazione per cluster, entrambe le organizzazioni utilizzano e condividono lo stesso anello Cassandra. Ogni organizzazione puรฒ avere configurati piรน ambienti e gruppi di ambienti.
Limitazioni
ร supportata una configurazione multi-organizzazione per cluster con le seguenti limitazioni. Fino a quando queste limitazioni non verranno mitigate, sconsigliamo di utilizzare questa configurazione.
Se prevedi di avere piรน istanze ibride Apigee, ogni istanza deve avere il proprio cluster. Piรน istanze ibride Apigee in esecuzione nello stesso cluster Kubernetes possono
causare problemi di instabilitร che potrebbero causare tempi di riposo.
Le metriche dei pod vengono inviate solo al primo progetto Google Cloud configurato. Questa limitazione รจ piรน evidente nello strumento Cloud Monitoring. Riguarda solo le metriche del cluster.
Le analisi API non sono interessate. Le metriche per le altre organizzazioni Apigee non verranno inviate al progetto Google Cloud corrispondente.
Tutti i log dei pod vengono inviati al primo progetto Google Cloud configurato. Questa limitazione รจ piรน evidente nello strumento Cloud Logging. I log per le altre organizzazioni Apigee non verranno inviati al progetto Google Cloud corrispondente. I log vengono comunque acquisiti a livello di pod e possono essere recuperati con i comandi kubectl. Tuttavia, non vengono inviati al progetto Cloud corretto tramite Cloud Logging.
Non puoi eliminare i dati dell'organizzazione nel database Cassandra per una sola organizzazione. Ciรฒ significa che
non puoi rimuovere le organizzazioni in modo selettivo. Qualsiasi modifica alla configurazione del database influisce su tutte le organizzazioni di cui รจ stato eseguito il deployment in quel cluster.
La procedura di upgrade ibrida esegue l'upgrade dell'intero cluster contemporaneamente.
Il backup e il ripristino vengono eseguiti come cluster e non possono essere eseguiti per un'organizzazione specifica.
La funzionalitร di monitoraggio delle API Apigee (Timeline, Recenti, Esamina) funziona solo per la prima
organizzazione configurata e di cui รจ stato eseguito il deployment. Non funzionerร per le altre organizzazioni in un cluster di piรน organizzazioni.
Opzioni per piรน organizzazioni
Questa sezione descrive in che modo l'assistenza Apigee gestisce i cluster multi-organizzazione esistenti e i consigli per i deployment futuri:
Se hai giร implementato cluster Kubernetes multi-organizzazione in contesti di produzione e non di produzione, l'assistenza Apigee continuerร a supportarli. Tuttavia, tieni presenti le limitazioni tecniche descritte
nella sezione successiva. Ti consigliamo di cambiare gli eventuali futuri deployment di produzione in modo da utilizzare un'organizzazione Apigee per cluster.
Se hai giร cluster multi-organizzazione in contesti non di produzione, l'assistenza Apigee continuerร a supportarli. Ti consigliamo di eseguire la migrazione di eventuali cluster di produzione a una nuova configurazione che utilizzi un'organizzazione Apigee per cluster.
Prerequisiti
Prima di continuare, tieni presente quanto segue:
Devi avere un'organizzazione ibrida esistente con uno o piรน ambienti installati e configurati
in un cluster Kubernetes esistente. Consulta le istruzioni di installazione ibrida.
Quando combini piรน organizzazioni in un unico cluster, le versioni ibride devono corrispondere tutte. Prima di aggiungere una seconda organizzazione a un cluster, esegui l'upgrade dell'installazione ibrida esistente, se necessario. Consulta Eseguire l'upgrade di Apigee hybrid.
Crea un'organizzazione da aggiungere al cluster esistente
Nei passaggi successivi, creerai un nuovo file di override e lo configurerai per la nuova organizzazione.
Un file overrides.yaml puรฒ supportare le informazioni di una sola organizzazione. Pertanto, devi
creare un nuovo file overrides.yaml e applicarlo al cluster Kubernetes esistente.
Prendi nota dei file del certificato TLS (.key e .pem) nella directory certs. Se devi ricrearli, puoi seguire le istruzioni riportate in Creare certificati TLS.
Copia il file overrides.yaml esistente in un nuovo file da utilizzare come punto di partenza per la configurazione della nuova organizzazione. Ad esempio: new-overrides.yaml.
Modifica il nuovo file delle sostituzioni con le seguenti configurazioni:
La tabella seguente descrive ciascuno dei valori delle proprietร che devi fornire nel
file delle sostituzioni. Per ulteriori informazioni, consulta il riferimento per le proprietร di configurazione.
Variabile
Descrizione
new-org-name
Il nome della nuova organizzazione.
instance-id
Tutte le organizzazioni in questo cluster devono avere lo stesso ID istanza. Pertanto, deve corrispondere alla voce
instanceID nel file delle sostituzioni per l'organizzazione originale.
existing-cluster-name
Il nome del cluster a cui aggiungi l'organizzazione. Deve corrispondere alla voce k8sCluster.name nel file delle sostituzioni per il cluster originale.
existing-cluster-analytics-region
La regione in cui รจ stato eseguito il provisioning del cluster originale. Deve corrispondere alla voce k8sCluster.region nel file delle sostituzioni
per il cluster originale.
new-project-id
L'ID del nuovo progetto. L'ID progetto e il nome dell'organizzazione
sono gli stessi.
new-project-default-location
La regione di analisi specificata quando
hai creato la nuova organizzazione. Non deve necessariamente corrispondere alla regione dell'organizzazione esistente.
namespace
Tutte le organizzazioni nel cluster devono condividere lo stesso spazio dei nomi. Assicurati di
utilizzare lo stesso spazio dei nomi utilizzato per l'organizzazione originale. Tieni presente che lo spazio dei nomi predefinito รจ
apigee.
new-environment-group-name
Il nuovo gruppo di ambienti che hai creato per la nuova
organizzazione.
cert-file-name e key-file-name
I file della chiave e del certificato TLS per
il cluster che hai selezionato o creato nel passaggio 1 di questa
sezione.
new-environment-name
Il nome dell'ambiente che hai creato per la nuova
organizzazioni.
new-service-accounts-directory
La directory in cui si trovano i file delle chiavi dell'account di servizio che hai creato per la nuova organizzazione.
Applica la configurazione
Applica la nuova configurazione dell'organizzazione al cluster:
Esegui una prova di installazione per verificare la presenza di eventuali problemi:
Se non ci sono problemi, applica i componenti a livello di organizzazione. Questo passaggio installa i job Cassandra (utente e schema), Apigee Connect, Apigee Watcher e i servizi MART:
Applica le modifiche al bilanciatore del carico. Questo passaggio configura l'ingress per ascoltare i nuovi host virtuali per la seconda organizzazione:
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema รจ stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-03 UTC."],[[["\u003cp\u003eThis document explains how to add a second Apigee hybrid organization to an existing Kubernetes cluster, which shares the same Cassandra ring with the initial organization.\u003c/p\u003e\n"],["\u003cp\u003eA multi-org per cluster configuration has limitations, such as issues with pod metrics and logging being sent only to the first configured Google Cloud project, and no selective deletion, upgrade or backup/restore of a single org is possible.\u003c/p\u003e\n"],["\u003cp\u003eThe recommendation is to use one Apigee organization per cluster for production deployments, and it is advised to migrate existing multi-org production clusters to this single-org setup.\u003c/p\u003e\n"],["\u003cp\u003eAdding a new organization involves creating a new \u003ccode\u003eoverrides.yaml\u003c/code\u003e file with specific configurations, including a new organization name, matching the instance ID, cluster name, and namespace with the existing organization.\u003c/p\u003e\n"],["\u003cp\u003eApplying the new configuration requires running \u003ccode\u003eapigeectl\u003c/code\u003e commands to deploy the org, its environments, and update the load balancer, and synchronizer access must also be enabled for the new org.\u003c/p\u003e\n"]]],[],null,["# Adding multiple hybrid orgs to a cluster\n\n| You are currently viewing version 1.8 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 explains how to add a second Apigee hybrid organization (org) to an existing\nKubernetes cluster. In this multi-org per cluster configuration, both orgs use and share the same Cassandra\nring. Each org can have multiple 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.8/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.8/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.8/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.8/install-enable-synchronizer-access)."]]
