Questa pagina è stata tradotta dall'API Cloud Translation.

Aggiunta di più organizzazioni ibride a un cluster

Questo argomento illustra come aggiungere una seconda organizzazione (organizzazione) ibrida Apigee 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

È supportata una configurazione per più organizzazioni per cluster con le seguenti limitazioni. Fino a quando queste limitazioni non saranno attenuate, ti consigliamo di non utilizzare questa configurazione:

Se hai più istanze ibride Apigee, ogni istanza deve avere il proprio cluster. Più istanze ibride Apigee in esecuzione sullo stesso cluster Kubernetes possono causare problemi di instabilità che potrebbero causare tempi di inattività.
Tutti i log dai pod vengono inviati al primo progetto Google Cloud configurato. Questo limite è 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 inviate al progetto Cloud corretto tramite Cloud Logging.
Non puoi eliminare i dati dell'organizzazione nel database Cassandra solo per un'organizzazione. Ciò significa che non puoi rimuovere le organizzazioni in modo selettivo. Qualsiasi modifica alla configurazione del database interessa tutte le organizzazioni di cui viene eseguito il deployment nel cluster.
La procedura di upgrade ibrido esegue l'upgrade dell'intero cluster in una volta sola.
Il backup e ripristino viene eseguito come cluster e non può essere effettuato 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 funziona per le altre organizzazioni in un cluster con più organizzazioni.

Opzioni per più organizzazioni

Questa sezione descrive in che modo l'assistenza Apigee gestisce i cluster multi-organizzazione esistenti e i suggerimenti per i deployment futuri:

Se disponi di cluster Kubernetes multi-organizzazione di cui è stato eseguito il deployment in contesti non di produzione e di produzione, l'assistenza Apigee continuerà a supportarli. Tuttavia, tieni conto delle limitazioni tecniche descritte nella prossima sezione. Ti consigliamo di modificare eventuali deployment di produzione futuri in modo da utilizzare un'organizzazione Apigee per cluster.
Se disponi di cluster multi-organizzazione in contesti non di produzione, l'assistenza Apigee continuerà a supportarli. Ti consigliamo di eseguire la migrazione di qualsiasi cluster di produzione a una nuova configurazione che utilizza 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, 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 la pagina Upgrade di Apigee hybrid.

Crea un'organizzazione da aggiungere al cluster esistente

Per creare l'organizzazione aggiuntiva, segui i passaggi descritti in Parte 1: configurazione di progetti e organizzazioni.

Configura la nuova organizzazione

Nei passaggi seguenti, 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. Devi quindi creare un nuovo file overrides.yaml e applicarlo al cluster Kubernetes esistente.

Creare account di servizio da utilizzare con la nuova organizzazione. Vedi Creare account di servizio.
Prendi nota dei file dei certificati TLS (.key e .pem) nella directory certs. 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.

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 tutti i valori delle proprietà che devi fornire nel file di override. Per saperne di più, consulta 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. Di conseguenza, deve corrispondere alla voce `instanceID` nel file di override per l'organizzazione originale. Per le installazioni in più regioni, ogni regione richiede un proprio cluster, poiché i singoli cluster non coprono le regioni. Di conseguenza, ogni cluster deve avere il proprio ID istanza univoco condiviso da ogni organizzazione del 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 del nuovo progetto. L'ID progetto e il nome dell'organizzazione sono gli stessi.
`new-project-default-location`	La regione di analisi che hai specificato al momento della creazione della nuova organizzazione. Non deve essere necessariamente la stessa della 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. Lo spazio dei nomi per la maggior parte delle installazioni è `apigee`.
`new-environment-group-name`	Il nuovo gruppo di ambienti che hai creato per la nuova organizzazione. Attenzione: i nomi dei gruppi di ambienti per la nuova organizzazione non devono essere uguali ai nomi dei gruppi di ambienti di qualsiasi altra organizzazione. I nomi delle release di Helm per gli envs sarebbero gli stessi, il che renderebbe difficile la gestione dei grafici.
`cert-file-name` e `key-file-name`	I file del certificato TLS e della chiave per il cluster che hai controllato o creato nel passaggio 1 in questa sezione.
`new-environment-name`	Il nome dell'ambiente che hai creato per la nuova organizzazione. Attenzione: i nomi di ambiente della nuova organizzazione non devono essere uguali ai nomi di ambiente di qualsiasi altra 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.

Applicare la configurazione

Applica la nuova configurazione dell'organizzazione al cluster:

Esegui un'installazione di prova per verificare la presenza di eventuali problemi:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml \
  --dry-run
```
Nota: è buona norma eseguire una prova prima di applicare la configurazione per determinare se si sono verificati 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:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```

Installare l'ambiente. Questo passaggio installa i componenti apigee-runtime, sincronizzatore e UDCA per ambiente:

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f overrides.yaml \
  --dry-run

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f overrides.yaml

Applica le modifiche al bilanciatore del carico. Questo passaggio configura il traffico in entrata in modo che sia in ascolto dei nuovi host virtuali per la seconda organizzazione:

helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=NEW_ENV_GROUP_NAME \
  -f overrides.yaml \
  --dry-run

helm upgrade NEW_ENV_GROUP_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=NEW_ENV_GROUP_NAME \
  -f overrides.yaml

Per abilitare l'accesso del sincronizzatore per la nuova organizzazione, segui i passaggi descritti in Abilitare l'accesso al programma di sincronizzazione.
Per impostazione predefinita, la prima volta che installi il runtime ibrido di Apigee, il componente di telemetria è configurato con multiOrgCluster disabilitato. Segui questi passaggi per abilitare la telemetria di più organizzazioni per ciascuna organizzazione nel tuo cluster:
1. Elimina il componente Telemetria esistente con i seguenti comandi:
```
helm delete telemetry
```
  Nota: l'eliminazione del componente Telemetria interromperà l'esportazione delle metriche in Google Monitoring. Per riattivare le metriche, svolgi i passaggi che seguono.
2. Aggiungi la seguente riga al file overrides.yaml per la tua organizzazione esistente.
```
multiOrgCluster: true
```
3. Applica le modifiche per installare il componente Telemetry per l'organizzazione.
  Esegui prima una prova:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml \
  --dry-run
```
  Se la prova ha esito positivo, applica le modifiche e installa il componente Telemetria:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f FIRST_OVERRIDES_FILE.yaml
```
4. Assicurati che la riga seguente sia presente nel file overrides.yaml per ogni nuova organizzazione.
```
multiOrgCluster: true
```
5. Applica le modifiche per installare il componente Telemetry per ogni nuova organizzazione. Ripeti questa operazione per ogni nuova organizzazione nel tuo cluster multi-organizzazione.
  Esegui prima una prova:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml \
  --dry-run
```
  Se la prova ha esito positivo, applica le modifiche e installa il componente Telemetria:
```
helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```