Topik ini menjelaskan cara menambahkan organisasi campuran Apigee (org) kedua ke cluster Kubernetes yang ada. Dalam konfigurasi multi-organisasi per cluster ini, kedua organisasi menggunakan dan berbagi ring Cassandra yang sama. Setiap organisasi dapat memiliki beberapa lingkungan dan grup lingkungan yang dikonfigurasi.
Batasan
Konfigurasi multi-organisasi per cluster didukung dengan batasan berikut. Sampai keterbatasan ini
dimitigasi, sebaiknya Anda tidak menggunakan konfigurasi ini.
Jika Anda akan memiliki beberapa instance hybrid Apigee, setiap instance harus memiliki
clusternya sendiri. Beberapa instance hybrid Apigee yang berjalan di cluster kubernetes yang sama dapat
menyebabkan masalah ketidakstabilan yang berpotensi menyebabkan periode nonaktif.
Metrik pod hanya dikirim ke project Google Cloud pertama yang dikonfigurasi. Batasan ini paling terlihat di alat Cloud Monitoring. Hal ini hanya memengaruhi metrik cluster; analitik API tidak terpengaruh. Metrik untuk organisasi Apigee lainnya tidak akan dikirim ke project Google Cloud yang cocok.
Semua logging dari pod dikirim ke project Google Cloud pertama yang dikonfigurasi. Batasan ini paling jelas terlihat di alat Cloud Logging. Log untuk organisasi Apigee lainnya tidak akan
dikirim ke project Google Cloud yang cocok. Log masih diambil di tingkat pod dan dapat
diambil dengan perintah kubectl. Namun, log tersebut tidak dikirim ke project Cloud yang benar melalui Cloud Logging.
Anda tidak dapat menghapus data organisasi di database Cassandra hanya untuk satu organisasi. Artinya,
Anda tidak dapat menghapus organisasi secara selektif. Setiap modifikasi pada konfigurasi database akan memengaruhi semua organisasi yang di-deploy ke cluster tersebut.
Prosedur upgrade campuran mengupgrade seluruh cluster sekaligus.
Pencadangan dan pemulihan dilakukan sebagai cluster, dan tidak dapat dilakukan untuk organisasi tertentu.
Fitur Pemantauan API Apigee (Linimasa, Terbaru, Selidiki) hanya berfungsi untuk organisasi pertama
yang dikonfigurasi dan di-deploy. Tindakan ini tidak akan berfungsi untuk organisasi lain dalam cluster multi-organisasi.
Opsi multi-organisasi
Bagian ini menjelaskan cara Dukungan Apigee menangani cluster multi-organisasi yang ada dan rekomendasi untuk deployment mendatang:
Jika Anda sudah memiliki cluster Kubernetes multi-organisasi yang di-deploy dalam konteks non-produksi dan produksi, Dukungan Apigee akan terus mendukungnya. Namun, perhatikan batasan teknis yang diuraikan
di bagian berikutnya. Sebaiknya Anda
mengubah deployment produksi mendatang untuk menggunakan satu organisasi Apigee per cluster.
Jika Anda sudah memiliki cluster multi-organisasi dalam konteks non-produksi, Dukungan Apigee
akan terus mendukungnya. Sebaiknya migrasikan cluster produksi ke konfigurasi baru yang menggunakan satu organisasi Apigee per cluster.
Prasyarat
Sebelum melanjutkan, perhatikan hal berikut:
Anda harus memiliki organisasi campuran yang ada dengan satu atau beberapa lingkungan yang diinstal dan dikonfigurasi di cluster Kubernetes yang ada. Lihat petunjuk penginstalan campuran.
Saat menggabungkan beberapa organisasi dalam satu cluster, semua versi
campuran harus cocok. Sebelum menambahkan organisasi kedua ke cluster, upgrade penginstalan hibrida yang ada, jika perlu. Lihat Mengupgrade Apigee Hybrid.
Membuat organisasi untuk ditambahkan ke cluster yang ada
Pada langkah-langkah berikut, Anda akan membuat file penggantian baru dan mengonfigurasinya untuk organisasi baru.
File overrides.yaml hanya dapat mendukung informasi satu organisasi. Oleh karena itu, Anda harus
membuat file overrides.yaml baru dan menerapkannya ke cluster Kubernetes yang ada.
Buat akun layanan untuk digunakan dengan organisasi baru. Lihat Membuat akun layanan.
Catat file sertifikat TLS (.key dan .pem) di direktori certs Anda. Jika perlu membuatnya lagi, Anda dapat mengikuti petunjuk di
Membuat sertifikat TLS.
Salin overrides.yaml yang ada ke file baru untuk digunakan sebagai titik awal
untuk mengonfigurasi organisasi baru. Misalnya: new-overrides.yaml.
Edit file penggantian baru dengan konfigurasi berikut:
Tabel berikut menjelaskan setiap nilai properti yang harus Anda berikan dalam
file penggantian. Untuk mengetahui informasi selengkapnya, lihat Referensi properti konfigurasi.
Variabel
Deskripsi
new-org-name
Nama organisasi baru Anda.
instance-id
Semua organisasi dalam
cluster ini harus memiliki ID instance yang sama. Oleh karena itu, nilai ini harus cocok dengan
entri instanceID dalam file penggantian untuk organisasi asli Anda.
existing-cluster-name
Nama cluster tempat Anda menambahkan organisasi ini. Nilai ini harus cocok dengan entri k8sCluster.name dalam file penggantian untuk cluster asli Anda.
existing-cluster-analytics-region
Region tempat cluster asli disediakan. Nilai ini harus cocok dengan entri k8sCluster.region dalam file penggantian untuk cluster asli Anda.
new-project-id
Project ID project baru Anda. Project ID dan nama organisasi sama.
new-project-default-location
Wilayah analisis yang Anda tentukan saat membuat organisasi baru. Region ini tidak harus sama dengan region untuk organisasi yang ada.
namespace
Semua organisasi di cluster harus memiliki namespace yang sama. Pastikan untuk menggunakan namespace yang sama dengan yang digunakan untuk organisasi asli. Perhatikan bahwa namespace defaultnya adalah
apigee.
new-environment-group-name
Grup lingkungan baru yang Anda buat untuk organisasi baru.
cert-file-name dan key-file-name
File kunci dan sertifikat TLS untuk
cluster yang Anda periksa atau buat di langkah 1 di bagian
ini.
new-environment-name
Nama lingkungan yang Anda buat untuk organisasi baru.
new-service-accounts-directory
Direktori tempat file kunci akun layanan yang Anda buat untuk organisasi baru berada.
Terapkan konfigurasi:
Terapkan konfigurasi organisasi baru ke cluster Anda:
Lakukan penginstalan uji coba untuk memeriksa masalah apa pun:
Jika tidak ada masalah, terapkan komponen tingkat organisasi. Langkah ini menginstal tugas Cassandra (pengguna dan skema), layanan Apigee Connect, Apigee Watcher, dan MART:
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-05 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)."]]
