Questa pagina è stata tradotta dall'API Cloud Translation.

Aggiunta di più organizzazioni ibride a un cluster

Questo argomento descrive come aggiungere una seconda organizzazione Apigee hybrid a un cluster Kubernetes esistente. In questa configurazione multi-organizzazione, entrambe le organizzazioni utilizzano e condividono lo stesso anello Cassandra. Ogni organizzazione può avere più ambienti e gruppi di ambienti configurati.

Limitazioni

Una configurazione multi-organizzazione per cluster è supportata con le seguenti limitazioni. Finché queste limitazioni non vengono mitigate, non consigliamo di utilizzare questa configurazione:

Se prevedi di avere più istanze di Apigee Hybrid, ogni istanza deve avere il proprio cluster. Più istanze di Apigee Hybrid in esecuzione sullo stesso cluster Kubernetes possono causare problemi di instabilità che potrebbero causare tempi di inattività.
Tutti i log dei pod vengono inviati al primo progetto Google Cloud configurato. Questa limitazione è più evidente nello strumento Cloud Logging. I log delle altre organizzazioni Apigee non verranno inviati al progetto Google Cloud corrispondente. I log vengono ancora 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 nel cluster.
La procedura di upgrade ibrido 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, Analizza) funziona solo per la prima organizzazione configurata e di cui è stato eseguito il deployment. Non funzionerà per le altre organizzazioni in un cluster multi-organizzazione.

Opzioni multi-organizzazione

Questa sezione descrive come l'assistenza Apigee gestisce i cluster multi-organizzazione esistenti e i consigli per i deployment futuri:

Se hai cluster Kubernetes multiorganizzazione esistenti di cui è stato eseguito il deployment in contesti non di produzione e di produzione, l'assistenza Apigee continuerà a supportarli. Tuttavia, tieni presente le limitazioni tecniche descritte nella sezione successiva. Ti consigliamo di modificare le implementazioni di produzione future in modo da utilizzare un'organizzazione Apigee per cluster.
Se hai cluster multi-organizzazione esistenti in contesti non di produzione, il supporto Apigee continuerà a supportarli. Ti consigliamo di eseguire la migrazione di tutti i cluster di produzione a una nuova configurazione che utilizza un'organizzazione Apigee per cluster.

Prerequisiti

Prima di continuare, tieni presente quanto segue:

Devi disporre di 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 combini più organizzazioni in un singolo cluster, le versioni ibride devono corrispondere. Prima di aggiungere una seconda organizzazione a un cluster, esegui l'upgrade dell'installazione ibrida esistente, se necessario. Consulta 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 solo le informazioni di un'organizzazione. Pertanto, devi creare un nuovo file overrides.yaml e applicarlo al cluster Kubernetes esistente.

Crea service account da utilizzare con la nuova organizzazione. Vedi Creare service account.
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 tuo overrides.yaml esistente in un nuovo file da utilizzare come punto di partenza per configurare la tua 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.

multiOrgCluster: true ## Enables exporting metrics for this org to the Google Cloud Project named with gcp:projectID

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 di override. Per saperne di più, consulta Riferimento alle 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 di override per l'organizzazione originale. Per le installazioni multiregionali, ogni regione richiede il proprio cluster, perché i singoli cluster non si estendono su 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 stai aggiungendo questa organizzazione. Deve corrispondere alla voce `k8sCluster.name` nel file di override per il cluster originale.
`existing-cluster-analytics-region`	La regione in cui viene eseguito il provisioning del cluster originale. Deve corrispondere alla voce `k8sCluster.region` nel file di override per il cluster originale.
`new-project-id`	L'ID progetto del nuovo progetto. L'ID progetto e il nome dell'organizzazione sono uguali.
`new-project-default-location`	La regione di analisi che hai specificato 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 del certificato e della chiave TLS per il cluster che hai controllato 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 del account di servizio che hai creato per la nuova organizzazione.

Applica la configurazione

Applica la nuova configurazione dell'organizzazione al tuo cluster:

Esegui una prova di installazione per verificare la presenza di 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 servizi Cassandra (utente e schema), Apigee Connect, Apigee Watcher e 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 hai più ambienti nella nuova organizzazione, ripeti questo passaggio per ciascun ambiente.
Applica le modifiche al bilanciatore del carico. Questo passaggio configura l'ingresso in modo che ascolti i nuovi host virtuali per la seconda organizzazione:
Importante:non duplicare i nomi host/nomi di dominio tra due organizzazioni, in quanto potrebbe verificarsi 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 Attivazione dell'accesso al sincronizzatore.
Per impostazione predefinita, quando installi per la prima volta il runtime ibrido Apigee, il componente Telemetria è configurato con multiOrgCluster disattivato. Per attivare la telemetria multi-organizzazione per ogni organizzazione del cluster, segui questi passaggi:
1. Elimina il componente Telemetria esistente con i seguenti comandi:
  Esegui prima un dry run:
```
apigeectl delete -f path-to-first-org-overrides.yaml --telemetry --dry-run=client
```
  Se la simulazione è andata a buon fine, elimina il componente Telemetria:
```
apigeectl delete -f path-to-first-org-overrides.yaml --telemetry
```
  Nota:l'eliminazione del componente Telemetria interromperà l'esportazione delle metriche in Google Monitoring. Per riattivare le metriche, segui questi passaggi.
2. Aggiungi la seguente riga al file overrides.yaml per la tua organizzazione esistente.
```
multiOrgCluster: true
```
3. Applica le modifiche per installare il componente Telemetria per l'organizzazione.
  Esegui prima un dry run:
```
apigeectl apply -f path-to-first-org-overrides.yaml --telemetry --dry-run=client
```
  Se la simulazione va a buon fine, applica le modifiche e installa il componente di telemetria:
```
apigeectl apply -f path-to-first-org-overrides.yaml --telemetry
```
4. Assicurati che la seguente riga sia presente nel file overrides.yaml per ogni nuova organizzazione.
```
multiOrgCluster: true
```
5. Applica le modifiche per installare il componente Telemetria per ogni nuova organizzazione. Ripeti questa operazione per ogni nuova organizzazione nel cluster multiorganizzazione.
  Esegui prima un dry run:
```
apigeectl apply -f path-to-new-org-overrides.yaml --telemetry --dry-run=client
```
  Se la simulazione va a buon fine, applica le modifiche e installa il componente:
```
apigeectl apply -f path-to-new-org-overrides.yaml --telemetry
```