Questa pagina è stata tradotta dall'API Cloud Translation.

Aggiunta di più organizzazioni ibride a un cluster

Questo argomento illustra come aggiungere una seconda organizzazione ibrida Apigee (organizzazione) a una in un cluster Kubernetes. In questa configurazione multiorganizzativa, entrambe le organizzazioni utilizzano e condividono lo stesso account Cassandra suonano. Ogni organizzazione può avere configurati più ambienti e gruppi di ambienti.

Limitazioni

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

Se prevedi di avere più istanze ibride Apigee, ogni istanza deve avere il proprio cluster. Più istanze Apigee ibride in esecuzione nello stesso cluster Kubernetes possono causare problemi di instabilità che possono comportare tempi di riposo.
Tutti i log dai 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 inviate al progetto Google Cloud corrispondente. I log vengono comunque acquisiti a livello di pod può essere recuperato con i comandi kubectl. Tuttavia, non vengono inviati al team corretto progetto Cloud 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 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 (Cronologia, Recenti, Esamina) funziona solo per la prima organizzazione configurata e di cui è stato eseguito il deployment. Non funzionerà per le altre organizzazioni che fanno parte di più organizzazioni. in un cluster Kubernetes.

Opzioni per più organizzazioni

Questa sezione descrive in che modo l'assistenza Apigee gestisce i cluster multi-organizzazione esistenti e i suggerimenti per 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 presente le limitazioni tecniche descritte nella sezione successiva. Ti consigliamo di modificare qualsiasi deployment di produzione futuro in utilizza un'organizzazione Apigee per cluster.
Se disponi di cluster multi-organizzazione esistenti in contesti non di produzione, l'assistenza Apigee continuano 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. Vedi l'installazione ibrida istruzioni.
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: progetto e configurazione 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 in un cluster Kubernetes.

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 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 delle sostituzioni 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 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. Di conseguenza, deve corrispondere Voce `instanceID` nel file degli override per l'organizzazione originale. Per le installazioni in più regioni, ogni regione richiede la propria perché i singoli cluster non coprono le regioni. Pertanto, ogni cluster deve Avere un proprio ID istanza univoco condiviso da ogni organizzazione nel cluster.
`existing-cluster-name`	Il nome del cluster a cui aggiungi l'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 degli override 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 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. 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 a quelli di altre organizzazioni. Se utilizzi i grafici Helm per gestire Apigee hybrid, i nomi delle release per gli ambienti potrebbero essere gli stessi, il che difficile la gestione dei grafici.
`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 . Attenzione:i nomi di ambiente per la nuova organizzazione non devono gli stessi 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.

Applica la configurazione

Applica la nuova configurazione dell'organizzazione al cluster:

Esegui un'installazione di prova per verificare la presenza di eventuali problemi:

Helm

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml \
  --dry-run

`apigeectl`

$APIGEECTL_HOME/apigeectl apply -f NEW_OVERRIDES_FILE.yaml --org --dry-run=client

Se non ci sono problemi, applica i componenti a livello di organizzazione. Questo passaggio installa Cassandra job (utente e schema), Apigee Connect, Apigee Watcher e servizi MART:
Helm
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f NEW_OVERRIDES_FILE.yaml
```
apigeectl
```
$APIGEECTL_HOME/apigeectl apply -f NEW_OVERRIDES_FILE.yaml --org
```

Installa l'ambiente. In questo passaggio vengono installati i componenti apigee-runtime, synchronousr e UDCA, per ambiente:

Helm

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

`apigeectl`

$APIGEECTL_HOME/apigeectl apply -f NEW_OVERRIDES_FILE --env $ENV_NAME --dry-run=client

$APIGEECTL_HOME/apigeectl apply -f NEW_OVERRIDES_FILE --env $ENV_NAME

Applica le modifiche al bilanciatore del carico. Questo passaggio configura il traffico in entrata per ascoltare il nuovo host virtuali per la seconda organizzazione:

Helm

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

`apigeectl`

$APIGEECTL_HOME/apigeectl apply -f NEW_OVERRIDES_FILE --settings virtualhosts --dry-run=client

$APIGEECTL_HOME/apigeectl apply -f NEW_OVERRIDES_FILE --settings virtualhosts

Attiva l'accesso al sincronizzatore per la nuova organizzazione seguendo i passaggi descritti in Attivare l'accesso al sincronizzatore.
Per impostazione predefinita, alla prima installazione del runtime ibrido Apigee, viene configurato il componente Telemetry con multiOrgCluster disattivato. Per attivare la telemetria per più organizzazioni per ogni organizzazione nel cluster:
1. Elimina il componente di telemetria esistente con i seguenti comandi:
  Helm
  helm delete telemetry
  apigeectl
  
  Esegui prima una prova:
  $APIGEECTL_HOME/apigeectl delete -f FIRST_OVERRIDES_FILE.yaml --telemetry --dry-run=client
  Se il dry run ha esito positivo, elimina il componente Telemetry:
  $APIGEECTL_HOME/apigeectl delete -f FIRST_OVERRIDES_FILE.yaml --telemetry
  Nota: l'eliminazione del componente Telemetria interrompe 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 di telemetria per l'organizzazione.
  Esegui prima una prova:
  Helm
  helm upgrade telemetry apigee-telemetry/ \ --install \ --namespace apigee \ --atomic \ -f FIRST_OVERRIDES_FILE.yaml \ --dry-run
  apigeectl
  $APIGEECTL_HOME/apigeectl apply -f FIRST_OVERRIDES_FILE.yaml --telemetry --dry-run=client
  Se la prova simulata va a buon fine, applica le modifiche e installa il componente di telemetria:
  Helm
  helm upgrade telemetry apigee-telemetry/ \ --install \ --namespace apigee \ --atomic \ -f FIRST_OVERRIDES_FILE.yaml
  apigeectl
  $APIGEECTL_HOME/apigeectl apply -f FIRST_OVERRIDES_FILE.yaml --telemetry
4. Assicurati che la seguente riga sia nel file overrides.yaml di ogni nuova organizzazione.
```
multiOrgCluster: true
```
5. Applica le modifiche per installare il componente di telemetria per ogni nuova organizzazione. Ripeti l'operazione per ogni nuova organizzazione nel cluster multi-organizzazione.
  Esegui prima una prova:
  Helm
  helm upgrade telemetry apigee-telemetry/ \ --install \ --namespace apigee \ --atomic \ -f NEW_OVERRIDES_FILE.yaml \ --dry-run
  apigeectl
  $APIGEECTL_HOME/apigeectl apply -f NEW_OVERRIDES_FILE.yaml --telemetry --dry-run=client
  Se la prova simulata va a buon fine, applica le modifiche e installa il componente di telemetria:
  Helm
  helm upgrade telemetry apigee-telemetry/ \ --install \ --namespace apigee \ --atomic \ -f NEW_OVERRIDES_FILE.yaml
  apigeectl
  $APIGEECTL_HOME/apigeectl apply -f NEW_OVERRIDES_FILE.yaml --telemetry