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 (org) a un modello esistente in un cluster Kubernetes. In questa configurazione multiorganizzativa, entrambe le organizzazioni utilizzano e condividono lo stesso account Cassandra suonano. Ogni organizzazione può avere sono stati configurati più ambienti e gruppi di ambienti.

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 i limiti tecnici descritti 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 esistenti in contesti non di produzione, il team di assistenza Apigee continueranno a supportarli. Ti consigliamo di eseguire la migrazione di qualsiasi cluster di produzione a una nuova che utilizza un'organizzazione Apigee per cluster.

Limitazioni

È supportata una configurazione in più organizzazioni per cluster con le seguenti limitazioni:

Le metriche dei pod vengono inviate solo al primo progetto Google Cloud configurato. Questo è più evidente nello strumento Cloud Monitoring. Interessa solo le metriche del cluster; L'analisi delle API non è interessata. Le metriche per le altre organizzazioni Apigee non verranno inviate al progetto Google Cloud corrispondente.
Tutti i log dai 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 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 ibrido esegue l'upgrade dell'intero cluster contemporaneamente.
Il backup e ripristino viene eseguito come cluster e non può essere eseguito per un'organizzazione specifica.
La funzionalità di monitoraggio delle API Apigee (Timeline, Recenti, Indagine) funziona solo per il primo dell'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.

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 che uscirà. 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 e, se necessario, l'installazione ibrida. 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 seguenti, creerai un nuovo file di override e lo configurerai per nuova organizzazione. Un file overrides.yaml può supportare solo le informazioni di un'organizzazione. Pertanto, devi crea un nuovo file overrides.yaml e applicalo 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 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. Per 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 seguente tabella descrive tutti i valori della proprietà che devi specificare nel esegue l'override del file. 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 in questo cluster deve avere lo stesso ID istanza. Di conseguenza, deve corrispondere Voce `instanceID` nel file degli override dell'organizzazione originale. Per le installazioni multiregionali, 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 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 si trova il cluster originale di cui è stato eseguito il provisioning. 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 che hai specificato 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 usano lo stesso spazio dei nomi usato 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 .
`cert-file-name` e `key-file-name`	Il 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 .
`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
```
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 Cassandra job (utente e schema), Apigee Connect, Apigee Watcher e servizi MART:
```
apigeectl apply -f overrides/new-overrides.yaml --org
```
Installa l'ambiente. In questo passaggio vengono installati i componenti apigee-runtime, synchronousr 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 questa procedura passaggio per ogni ambiente.
Applica le modifiche al bilanciatore del carico. Questo passaggio configura il traffico in entrata per ascoltare il nuovo host virtuali per la seconda organizzazione:
Importante: non duplicare nomi host/nomi di dominio tra due organizzazioni, ad esempio ciò può causare percorsi imprevedibili.
```
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.