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 più ambienti e gruppi di ambienti configurati.
Limitazioni
È supportata una configurazione multi-organizzazione per cluster con le seguenti limitazioni. Fino a questi limitazioni sono ridotte, ti sconsigliamo di utilizzare questa configurazione.
- 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. L'analisi API non è interessata. 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. Questo
è più evidente nello strumento Cloud Logging. I log delle altre organizzazioni Apigee non
verranno inviate al progetto Google Cloud corrispondente. I log vengono comunque acquisiti a livello di pod e possono
recuperabile 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 tutti per le organizzazioni di cui è stato eseguito il deployment nel 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 (Cronologia, 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 disponi di cluster Kubernetes multiorganizzativi esistenti di cui è stato eseguito il deployment in ambienti non di produzione e di produzione contesti, l'assistenza Apigee continuerà a supportarli. Tuttavia, tieni presenti le limitazioni tecniche descritte nella sezione successiva. Ti consigliamo di modificare eventuali deployment di produzione futuri in modo da utilizzare un'organizzazione Apigee per cluster.
- Se disponi di cluster multi-organizzazione esistenti in contesti non di produzione, il team di assistenza Apigee continueranno 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 per l'installazione ibrida.
- Quando si combinano più organizzazioni in un unico cluster, devono corrispondere tutte. Prima di aggiungere una seconda organizzazione a un cluster, esegui l'upgrade dell'installazione ibrida esistente, se necessario. Vedi Upgrade di Apigee hybrid.
Crea un'organizzazione da aggiungere al cluster esistente
Per creare un'organizzazione aggiuntiva, segui i passaggi Parte 1. Configurazione del progetto e dell'organizzazione.
Configura la nuova organizzazione
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.
- Crea account di servizio da utilizzare con la nuova organizzazione. Vedi Creare account di servizio.
- Prendi nota dei file dei certificati TLS (
.key
e.pem
) nel tuo Directorycerts
. Se devi crearli di nuovo, puoi seguire le istruzioni in Creare certificati TLS. - Copia il tuo
overrides.yaml
esistente in un nuovo file da utilizzare come punto di partenza per configurare la nuova organizzazione. Ad esempio:new-overrides.yaml
. - Modifica il nuovo file di override con le seguenti configurazioni:
org: "new-org-name" instanceID: "instance-id" ## Must match the instanceID of your existing org. k8sCluster: name: "existing-cluster-name" region: "existing-cluster-analytics-region" gcp: projectID: "new-project-id" name: "new-project-id" region: "new-project-default-location" namespace: namespace ## must be the same for both new and existing orgs virtualhosts: - name: new-environment-group-name sslCertPath: ./certs/cert-file-name # .crt or .pem sslKeyPath: ./certs/key-file-name # .key envs: - name: new-environment-name serviceAccountPaths: runtime: ./new-service-accounts-directory/new-project-id-apigee-runtime.json synchronizer: ./new-service-accounts-directory/new-project-id-apigee-synchronizer.json udca: ./new-service-accounts-directory/new-project-id-apigee-udca.json connectAgent: serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json mart: serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-mart.json metrics: serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-metrics.json watcher: serviceAccountPath: ./new-service-accounts-directory/new-project-id-apigee-watcher.json
La tabella seguente descrive ciascuno dei valori delle proprietà che devi fornire nel file delle sostituzioni. Per maggiori informazioni, consulta Riferimento sulle 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 stai aggiungendo questa organizzazione. it deve corrispondere alla voce k8sCluster.name
nel file delle sostituzioni dell'originale in un cluster Kubernetes.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 l'organizzazione sono uguali. new-project-default-location La regione di analisi che hai specificato al momento ha creato la nuova organizzazione. Non deve essere necessariamente la stessa 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-nameIl certificato TLS e i file delle chiavi per il cluster che hai controllato o creato nel passaggio 1 di . new-environment-name Il nome dell'ambiente che hai creato per la nuova organization. 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 un'installazione dry run per verificare la presenza di eventuali problemi:
apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client
- 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:
apigeectl apply -f overrides/new-overrides.yaml --org
- Installa l'ambiente. Questo passaggio installa i componenti apigee-runtime, synchronizer e UDCA per ambiente:
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME} --dry-run=client
apigeectl apply -f overrides/new-overrides.yaml --env ${ENV_NAME}
- Applica le modifiche al bilanciatore del carico. Questo passaggio configura l'ingress per ascoltare i nuovi host virtuali per la seconda organizzazione:
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
- Abilita l'accesso del sincronizzatore per la nuova organizzazione seguendo i passaggi descritti in Abilitare l'accesso del sincronizzatore.