Neste tópico, discutimos como adicionar uma segunda organização híbrida da Apigee (org) a um
cluster atual do Kubernetes. Nessa configuração multi-org, as duas organizações usam e compartilham o mesmo anel
Cassandra. Cada organização pode ter vários ambientes e grupos de ambientes configurados.
Limitações
Uma configuração de várias organizações por cluster é compatível com as limitações a seguir. Até que essas
limitações sejam reduzidas, não recomendamos que você use esta configuração:
Se você tiver várias instâncias da Apigee híbrida, cada uma precisará ter o próprio cluster. Várias instâncias da Apigee híbrida em execução no mesmo cluster do Kubernetes podem
levar a problemas de instabilidade que podem causar inatividade.
As métricas do pod são enviadas apenas para o primeiro projeto do Google Cloud configurado. Essa
limitação é mais aparente na ferramenta Cloud Monitoring. Isso só afeta as métricas do cluster.
A análise da API não é afetada. As métricas das outras organizações da Apigee não serão enviadas
para o projeto correspondente do Google Cloud.
Todos os registros dos pods são enviados para o primeiro projeto do Google Cloud configurado. Essa
limitação é mais aparente na ferramenta Cloud Logging. As métricas das outras organizações da Apigee não serão enviadas para o projeto correspondente do Google Cloud. Os registros ainda são capturados no nível do pod e
podem ser recuperados com comandos kubectl. No entanto, eles não são enviados para o projeto do Cloud correto por meio do Cloud Logging.
Não é possível excluir dados da organização no banco de dados do Cassandra para apenas uma organização. Isso significa que
não é possível remover organizações de maneira seletiva. Qualquer modificação na configuração do banco de dados afeta todas as
organizações implantadas no cluster.
O procedimento de upgrade híbrido atualiza todo o cluster de uma só vez.
O backup e a restauração são feitos como um cluster e não podem ser feitos para uma organização específica.
O recurso de monitoramento da API Apigee (linha do tempo, recente, investigar) só funciona para a primeira
organização que foi configurada e implantada. Ele não vai funcionar para as outras organizações em um cluster de várias
organizações.
Opções de várias organizações
Nesta seção, descrevemos como o suporte da Apigee lida com clusters e recomendações de várias organizações
para implantações futuras:
Se você tiver clusters do Kubernetes de várias organizações implantados em contextos de não
produção e produção, o suporte da Apigee continuará a oferecer suporte a eles. No entanto, observe as limitações técnicas
descritas na próxima seção. Recomendamos que você
mude todas as implantações de produção futuras para usar uma organização da Apigee por cluster.
Se você tiver clusters de várias organizações em contextos de não produção, o suporte da Apigee
continuará a oferecer suporte a eles. Recomendamos que você migre todos os clusters de produção para uma nova
configuração que use uma organização da Apigee por cluster.
Pré-requisitos
Antes de continuar, observe o seguinte:
É necessário ter uma organização híbrida com um ou mais ambientes instalados e configurados
em um cluster do Kubernetes. Consulte as instruções de instalação híbrida.
Ao combinar várias organizações em um único cluster, todas as versões híbridas precisam ser correspondentes. Antes de adicionar uma segunda organização a um cluster, faça o upgrade da
instalação híbrida atual, se necessário. Consulte Como fazer upgrade da Apigee híbrida.
Criar uma organização para adicionar ao cluster atual
Nas etapas a seguir, você vai criar um novo arquivo de modificações que vai ser configurado para a
nova organização.
Um arquivo overrides.yaml é compatível apenas com informações de uma organização. Portanto, você precisa
criar um novo arquivo overrides.yaml e aplicá-lo ao cluster atual do Kubernetes.
Crie contas de serviço para usar com a nova organização. Veja mais informações em Criar contas de serviço.
Anote os arquivos de certificado TLS (.key e .pem) no
diretório certs. Se precisar criá-los novamente, siga as instruções em
Criar certificados TLS.
Copie o overrides.yaml atual em um novo arquivo para usar como ponto de partida
para configurar a nova organização. Por
exemplo: new-overrides.yaml.
Edite o novo arquivo de modificações com as seguintes configurações:
A tabela a seguir descreve cada um dos valores de propriedade que você precisa fornecer no
arquivo de modificações. Para mais informações, consulte Referência da propriedade de configuração.
Variável
Descrição
new-org-name
O nome da nova organização.
instance-id
Todas
as organizações nesse cluster precisam ter o mesmo ID de instância. Portanto, ela precisa corresponder à
entrada instanceID no arquivo de modificações da organização original.
No caso de instalações multirregionais, cada região requer
o próprio cluster. Os clusters individuais não abrangem regiões.
existing-cluster-name
O nome do cluster ao qual você está adicionando esta organização. Ele
precisa corresponder à entrada k8sCluster.name no arquivo de modificações do
cluster original.
existing-cluster-analytics-region
A região onde o cluster original é
provisionado. Ele precisa corresponder à entrada k8sCluster.region no arquivo de modificações
do cluster original.
new-project-id
O ID do seu novo projeto. O ID do projeto e o nome da
organização são os mesmos.
new-project-default-location
A região de análise que você especificou ao criar
a nova organização. Ele não precisa ser o mesmo da região da organização atual.
namespace
Todas as organizações no cluster precisam compartilhar o mesmo namespace. Use o mesmo
namespace usado para a organização original. O namespace padrão é
apigee.
new-environment-group-name
O novo grupo de ambiente que você criou para a nova
organização.
cert-file-name e key-file-name
Os arquivos de certificado e de
chave TLS do cluster que você verificou ou criou na etapa 1
nesta seção.
new-environment-name
O nome do ambiente que você criou para a nova
organização.
new-service-accounts-directory
O diretório em que os arquivos de chave da conta de serviço que você criou para a nova organização estão localizados.
Aplique a configuração
Aplique a nova configuração da organização ao cluster:
Faça uma instalação de simulação para verificar se há problemas:
Se não houver problemas, aplique os componentes no nível da organização. Esta etapa instala os jobs do
Cassandra (usuário e esquema), Apigee Connect, Apigee Watcher e MART:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
