Cet article explique comment ajouter une deuxième organisation Apigee hybrid à un cluster Kubernetes existant. Dans cette configuration multi-organisation par cluster, les deux organisations utilisent et partagent le même anneau Cassandra. Vous pouvez configurer plusieurs environnements et groupes d'environnement pour chaque organisation.
Limites
Une configuration multi-organisation par cluster est compatible avec les limitations suivantes. Tant que ces limitations ne sont pas corrigées, nous vous déconseillons d'utiliser cette configuration.
Si vous prévoyez de disposer de plusieurs instances Apigee hybrid, chaque instance doit avoir son propre cluster. Le fait d'exécuter plusieurs instances Apigee hybrid sur un même cluster Kubernetes peut entraîner des problèmes d'instabilité, ce qui peut entraîner des temps d'arrêt.
Les métriques des pods ne sont envoyées qu'au premier projet Google Cloud configuré. Cette limitation est plus évidente dans l'outil Cloud Monitoring. Elle ne concerne que les métriques de cluster. Les analyses d'API ne sont pas affectées. Les métriques des autres organisations Apigee ne seront pas envoyées au projet Google Cloud correspondant.
Toutes les journalisations des pods sont envoyées au premier projet Google Cloud configuré. Cette limitation est plus évidente dans l'outil Cloud Logging. Les métriques des autres organisations Apigee ne seront pas envoyées au projet Google Cloud correspondant. Les journaux sont toujours capturés au niveau du pod et peuvent être récupérés à l'aide des commandes kubectl. Ils ne sont toutefois pas envoyés au bon projet Cloud via Cloud Logging.
Vous ne pouvez pas supprimer les données d'organisation d'une seule organisation dans la base de données Cassandra. Cela signifie que vous ne pouvez pas supprimer les organisations de manière sélective. Toute modification de la configuration de la base de données affecte toutes les organisations déployées sur ce cluster.
La procédure de mise à niveau hybride met à niveau l'intégralité du cluster en une seule fois.
La sauvegarde et la restauration sont effectuées en tant que cluster et ne peuvent pas être effectuées pour une organisation spécifique.
La fonctionnalité Apigee API Monitoring (Chronologie, Récente, Examen) ne fonctionne que pour la première organisation configurée et déployée. Elle ne fonctionnera pas pour les autres organisations d'un cluster multi-organisation.
Options multi-organisation
Cette section décrit comment l'assistance Apigee gère les clusters multi-organisations existants et fournit des recommandations pour les déploiements ultérieurs :
Si vous avez déployé des clusters Kubernetes multi-organisations dans des contextes hors production et de production, l'assistance Apigee continuera à les prendre en charge. Notez toutefois les limites techniques décrites dans la section suivante. Nous vous recommandons de modifier vos déploiements de production futurs pour utiliser une organisation Apigee par cluster.
Si vous possédez des clusters multi-organisation existants dans des contextes hors production, l'assistance Apigee continuera à les prendre en charge. Nous vous recommandons de migrer tous les clusters de production vers une nouvelle configuration utilisant une organisation Apigee par cluster.
Prérequis
Avant de continuer, tenez compte des points suivants :
Vous devez disposer d'une organisation hybride existante avec un ou plusieurs environnements installés et configurés dans un cluster Kubernetes existant. Consultez les instructions d'installation de la solution hybride.
Lorsque vous combinez plusieurs organisations dans un seul cluster, les versions hybrides doivent toutes correspondre. Avant d'ajouter une deuxième organisation à un cluster, mettez à niveau l'installation hybride existante, si nécessaire. Consultez la page Mettre à niveau Apigee hybrid.
Créer une organisation à ajouter au cluster existant
Dans les étapes suivantes, vous allez créer un fichier de remplacement et le configurer pour la nouvelle organisation.
Un fichier overrides.yaml n'accepte que les informations d'une organisation. Par conséquent, vous devez créer un fichier overrides.yaml et l'appliquer au cluster Kubernetes existant.
Créez des comptes de service à utiliser avec la nouvelle organisation. Consultez la section Créer des comptes de service.
Notez les fichiers de certificat TLS (.key et .pem) dans votre répertoire certs. Si vous devez les recréer, vous pouvez suivre les instructions de la section Créer des certificats TLS.
Copiez le fichier overrides.yaml existant dans un nouveau fichier à utiliser comme point de départ pour configurer votre nouvelle organisation. Par exemple : new-overrides.yaml.
Modifiez le fichier de remplacement avec les configurations suivantes :
Toutes les organisations de ce cluster doivent avoir le même ID d'instance. Par conséquent, il doit correspondre à l'entrée instanceID du fichier de remplacement de votre organisation d'origine.
existing-cluster-name
Nom du cluster auquel vous ajoutez cette organisation. Il doit correspondre à l'entrée k8sCluster.name du fichier de remplacement de votre cluster d'origine.
existing-cluster-analytics-region
La région dans laquelle le cluster d'origine est provisionné. Il doit correspondre à l'entrée k8sCluster.region du fichier de remplacement de votre cluster d'origine.
new-project-id
ID de votre nouveau projet L'ID du projet et le nom de l'organisation sont identiques.
new-project-default-location
Région d'analyse que vous avez spécifiée lors de la création de la nouvelle organisation. Cet emplacement ne doit pas nécessairement être identique à celui de l'organisation existante.
namespace
Toutes les organisations du cluster doivent partager le même espace de noms. Veillez à utiliser le même espace de noms que celui utilisé pour l'organisation d'origine. Notez que l'espace de noms par défaut est apigee.
new-environment-group-name
Le groupe d'environnement que vous avez créé pour la nouvelle organisation.
cert-file-name et key-file-name
Les certificats TLS et les fichiers de clé pour le cluster que vous avez vérifié ou créé à l'étape 1 dans cette section.
new-environment-name
Nom de l'environnement que vous avez créé pour la nouvelle organisation.
new-service-accounts-directory
Répertoire où se trouvent les fichiers de clés du compte de service que vous avez créés pour la nouvelle organisation.
Appliquer la configuration
Appliquez la configuration de la nouvelle organisation à votre cluster :
Procédez à une installation de simulation pour détecter les problèmes éventuels :
Si aucun problème ne se produit, appliquez les composants au niveau de l'organisation. Cette étape installe les tâches Cassandra (utilisateur et schéma), Apigee Connect, Apigee Watcher et les services MART :
Appliquez les modifications de l'équilibreur de charge. Cette étape configure l'entrée pour écouter les nouveaux hôtes virtuels pour la deuxième organisation :
Activez l'accès au synchronisateur pour votre nouvelle organisation en suivant les étapes décrites dans la section Activer l'accès au synchronisateur.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/28 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/08/28 (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)."]]
