Deployment multiregionale su AKS

Stai visualizzando la versione 1.5 di Documentazione di Apigee hybrid. This version is end of life. You should upgrade to a newer version. Per ulteriori informazioni, vedi Versioni supportate.

Version 1.5 (unsupported)

Versioni supportate:

• v1.12 (più recente)                        
• v1.11                         
• v1.10                                        
• Elenco delle versioni supportate

Versioni non supportate:

• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Questo argomento spiega come configurare un deployment multiregionale per Apigee hybrid su Microsoft® Servizio Azure Kubernetes (AKS).

Le topologie per il deployment in più regioni includono quanto segue:

• Attivo-Attivo: quando è stato eseguito il deployment delle applicazioni in più aree geografiche da più località e hai bisogno di una risposta API a bassa latenza per i tuoi deployment. Puoi eseguire il deployment di ambienti ibridi dalle sedi più vicine ai tuoi clienti. Ad esempio: costa occidentale degli Stati Uniti, costa orientale degli Stati Uniti, Europa, APAC.
• Attivo-passivo: in presenza di una regione principale e di un failover o un'emergenza regione di ripristino.

Le regioni in un deployment ibrido multiregionale comunicano tramite Cassandra, come nell'immagine seguente mostra:

Prerequisiti

Prima di configurare il servizio ibrido per più regioni, devi completare i seguenti prerequisiti:

• Segui l'installazione ibrida guida per eventuali prerequisiti, come Google Cloud e la configurazione dell'organizzazione. prima di andare ai passaggi di configurazione del cluster.
• Requisiti di Cassandra per più regioni:
  • Se lo spazio dei nomi della rete dei pod non dispone di connettività tra i pod in cluster diversi (i cluster sono in esecuzione in "modalità di rete delle isole", il caso predefinito nelle installazioni AKS), abilita la funzionalità hostNetwork di Kubernetes impostando cassandra.hostNetwork: true nel file degli override per tutte le regioni in la tua installazione ibrida di Apigee in più regioni.
  • Abilita hostNetwork sui cluster esistenti prima di espandere da più regioni a nuove regioni.
  • Se hostNetwork è abilitato, assicurati che i nodi worker possano eseguire l'inversione ricerca DNS. Apigee Cassandra utilizza la ricerca DNS diretta e inversa per ottenere l'host IP all'avvio.
    Suggerimento: se la risoluzione DNS non funziona, prova questa soluzione alternativa.

    Aggiungi una voce host statica nel file /etc/hosts di ciascun nodo worker Cassandra simile al seguente:

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    o

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • Apri le porte Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni per che permettono ai nodi worker di comunicare tra regioni e data center. Vedi Configurare le porte.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

NOTA: Apigee consiglia di assicurare che i tuoi server gli orari sono sincronizzati.

Diverse funzionalità, come la scadenza e la revoca del token si basano su orari di sistema precisi. Se i componenti di runtime sono ospitati in diversi data center, assicurati che gli orari del sistema siano sincronizzati.

Puoi utilizzare uno strumento come ntpdate per verificare che gli orari del server siano sincronizzati.

Crea una rete virtuale in ogni regione

Segui Azure documentazione di Kubernetes Service (AKS) per:

• Crea una rete virtuale in ogni regione.
• Stabilisci il peering di rete tra le regioni.
• Verifica il peering di rete.

Crea cluster multiregionali

Configurare cluster Kubernetes in più regioni con blocchi CIDR diversi. Consulta anche il Passaggio 1: crea un cluster. Utilizza la di località e nomi di reti virtuali creati in precedenza.

Apri le porte Cassandra 7000 e 7001 tra i cluster Kubernetes in tutte le regioni (7000 potrebbe essere utilizzata come opzione di backup durante la risoluzione dei problemi)

Configura l'host seed per più regioni

Questa sezione descrive come espandere il cluster Cassandra esistente a una nuova regione. Questa configurazione consente alla nuova regione di eseguire il bootstrap del cluster e di unire la regione esistente data center. Senza questa configurazione, i cluster Kubernetes multiregionali che non conoscerebbero.

1. Imposta il contesto kubectl sul cluster originale prima di recuperare il nome seed:

   kubectl config use-context original-cluster-name

2. Esegui questo comando kubectl per identificare un indirizzo host di origine per Cassandra in la regione corrente.

   Un indirizzo host di origine consente a una nuova istanza regionale di trovare originale alla primissima startup a scoprire la topologia del cluster. L'indirizzo host di origine è designato come punto di contatto nel cluster.

   kubectl get pods -o wide -n apigee | grep apigee-cassandra
   
   apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
   

3. Decidi quale IP restituito dal comando precedente sarà il seed multiregionale . In questo esempio, in cui è in esecuzione un solo cluster Cassandra a nodo, l'host di origine è 120.38.1.9.
4. Nel data center 2, copia il file degli override in un nuovo file il cui nome include il cluster . Ad esempio, overrides_your_cluster_name.yaml.
5. Nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter a overrides_your_cluster_name.yaml, dove multiRegionSeedHost è uno degli IP restituiti dal comando precedente:

   cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name

   Ad esempio:

   cassandra:
     multiRegionSeedHost: 120.38.1.9
     datacenter: "dc-1"
     rack: "ra-1"

6. Nel nuovo data center/nella nuova regione, prima di installare l'ibrido, imposta gli stessi certificati TLS e credenziali in overrides_your_cluster_name.yaml impostate nella prima regione.
   NOTA: assicurati di utilizzare gli stessi certificati TLS e credenziali di Cassandra nella seconda quello fornito nel data center originale. Le credenziali che hai impostato il file degli override nel primo data center devono corrispondere a quelli specificati nel il file degli override nel secondo data center. Per maggiori dettagli, vedi Configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host di origine, puoi configurare la nuova regione.

Per configurare la nuova regione:

1. Copia il tuo certificato dal cluster esistente a quello nuovo. La nuova radice dell'autorità di certificazione è utilizzata da Cassandra e da altri componenti ibridi per mTLS. Pertanto, è essenziale avere coerenti in tutto il cluster.
   1. Imposta il contesto sullo spazio dei nomi originale:

      kubectl config use-context original-cluster-name

   2. Esporta la configurazione attuale dello spazio dei nomi in un file:

      $ kubectl get namespace apigee -o yaml > apigee-namespace.yaml

      apigee è lo spazio dei nomi predefinito.

   3. Esporta il secret apigee-ca in un file:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Imposta il contesto sul nome del cluster della nuova regione:

      kubectl config use-context new-cluster-name

   5. Importa la configurazione dello spazio dei nomi nel nuovo cluster. Assicurati di aggiornare lo "spazio dei nomi" nel file se utilizzi uno spazio dei nomi diverso nella nuova regione:

      kubectl apply -f apigee-namespace.yaml

   6. Importa il secret nel nuovo cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Installa il modello ibrido nella nuova regione. Assicurati che overrides_your_cluster_name.yaml include gli stessi certificati TLS configurati nella prima regione, come spiegate nella sezione precedente.

   Esegui questi due comandi per installare il modello ibrido nella nuova regione:

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

3. Esegui nodetool rebuild in sequenza su tutti i nodi del nuovo data center. Questo può richiedere da pochi minuti ad alcune ore, a seconda delle dimensioni dei dati.

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1

   Dove JMX_user e JMX_password sono il nome utente e la password per Utente Cassandra JMX.

4. Verifica i processi di ricreazione dai log. Verifica inoltre le dimensioni dei dati utilizzando il comando nodetool status:

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

   L'esempio seguente mostra esempi di voci di log:

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

5. Aggiorna gli host di origine. Rimuovi multiRegionSeedHost: 10.0.0.11 da overrides-DC_name.yaml e invia di nuovo la richiesta.
   Gli host di origine sono membri del cluster locale. Per avviare un nuova regione è obbligatorio un host di origine esterno. Una volta avviata la regione, devi per riportare gli host di origine ai propri cluster locali in overrides.yaml e poi e applicare nuovamente la configurazione.

   apigeectl apply -f overrides-DC_name.yaml