Questa pagina è stata tradotta dall'API Cloud Translation.

Aggiunta di più organizzazioni ibride a un cluster

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 saranno mitigate, 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. 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 implementazioni 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

Per creare l'organizzazione aggiuntiva, segui i passaggi descritti nella Parte 1: configurazione di progetto e 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 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:

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 della 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. Per le installazioni multi-regione, ogni regione richiede il proprio cluster, perché i singoli cluster non coprono più regioni. Pertanto, ogni cluster deve avere il proprio ID istanza univoco condiviso da ogni organizzazione nel cluster.
`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 organizzazione.
`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:
```
apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client
```
Nota: è buona norma eseguire una prova prima di applicare la configurazione per determinare se ci sono 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:
```
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}
```
Nota: se nella nuova organizzazione sono presenti più ambienti, ripeti questo passaggio per ogni ambiente.
Applica le modifiche al bilanciatore del carico. Questo passaggio configura l'ingress per ascoltare i nuovi host virtuali per la seconda organizzazione:
Importante: non duplicare i nomi host/di dominio tra due organizzazioni, poiché ciò può comportare un routing imprevedibile.
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
```
```
apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
```
Attiva l'accesso al sincronizzatore per la nuova organizzazione seguendo i passaggi descritti in Attivare l'accesso al sincronizzatore.