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 multiorganizzativa, 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 in più organizzazioni per cluster con le seguenti limitazioni. Finché queste limitazioni non saranno ridotte, ti consigliamo di non utilizzare questa configurazione:

  • Se hai più istanze ibride di Apigee, ogni istanza dovrebbe avere il proprio cluster. Più istanze ibride di Apigee in esecuzione sullo stesso cluster Kubernetes possono causare problemi di instabilità che potrebbero causare tempi di inattività.
  • Le metriche dei pod vengono inviate solo al primo progetto Google Cloud configurato. Questo limite è evidente nello strumento Cloud Monitoring. Influisce solo sulle 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 limite è più evidente nello strumento Cloud Logging. I log delle 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 interessa tutte le organizzazioni di cui viene 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, Analisi) funziona solo per la prima organizzazione configurata e di cui è stato eseguito il deployment. Non funzionerà per le altre organizzazioni in un cluster a 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 esistenti di cui è stato eseguito il deployment in contesti non di produzione e di produzione, 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 hai cluster multi-organizzazione esistenti 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 di 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. Vedi 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 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. Pertanto, devi creare un nuovo file overrides.yaml e applicarlo al cluster Kubernetes esistente.

  1. Crea account di servizio da utilizzare con la nuova organizzazione. Vedi Creare account di servizio.
  2. 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.
  3. Copia il tuo overrides.yaml esistente in un nuovo file da utilizzare come punto di partenza per la configurazione della nuova organizzazione. Ad esempio: new-overrides.yaml.
  4. 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 delle proprietà da fornire nel file degli override. Per maggiori informazioni, consulta Riferimento sulla 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 degli override per l'organizzazione originale.
    existing-cluster-name Il nome del cluster a cui stai aggiungendo questa organizzazione. Deve corrispondere alla voce k8sCluster.name nel file degli 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 degli override per il cluster originale.
    new-project-id L'ID del nuovo progetto. L'ID progetto e il nome dell'organizzazione sono uguali.
    new-project-default-location La regione di analisi specificata al momento della creazione della 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 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
    Il certificato TLS e i file delle chiavi 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 dell'account di servizio che hai creato per la nuova organizzazione.

Applica la configurazione

Applica la nuova configurazione dell'organizzazione al cluster:

  1. Esegui un'installazione dry run per verificare la presenza di eventuali problemi:
    apigeectl apply -f overrides/new-overrides.yaml --org --dry-run=client
  2. 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
  3. Installa l'ambiente. Questo passaggio installa i componenti apigee-runtime, syncr 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}
  4. Applica le modifiche al bilanciatore del carico. Questo passaggio configura il traffico in entrata per ascoltare i nuovi host virtuali per la seconda organizzazione:
    apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts --dry-run=client
    apigeectl apply -f overrides/new-overrides.yaml --settings virtualhosts
  5. Abilita l'accesso del sincronizzatore per la nuova organizzazione seguendo i passaggi descritti in Abilitare l'accesso del sincronizzatore.