Deployment in più aree geografiche su AKS

Questo argomento spiega come configurare un deployment in più aree geografiche per Apigee hybrid su Microsoft Azure Kubernetes Service (AKS).

Le topologie per il deployment in più aree geografiche includono:

• Attiva-attiva: quando le applicazioni sono state distribuite in più località geografiche e hai bisogno di una risposta API a bassa latenza per i deployment. Hai la possibilità di eseguire il deployment dell'ibrido in più località geografiche più vicine ai tuoi clienti. Ad esempio: costa occidentale degli Stati Uniti, costa occidentale degli Stati Uniti, Europa, APAC.
• Active-Passive: quando hai un'area geografica principale e un'area geografica di failover o di ripristino di emergenza.

Le aree geografiche in un deployment ibrido in più aree geografiche comunicano tramite Cassandra, come illustrato nella seguente immagine:

Prerequisiti

Prima di configurare un modello ibrido per più aree geografiche, devi completare i seguenti prerequisiti:

• Segui la guida all'installazione di hybrid per qualsiasi prerequisito, ad esempio GCP e la configurazione dell'organizzazione, prima di passare ai passaggi di configurazione del cluster.

Per informazioni dettagliate, consulta la documentazione di Kubernetes.

NOTA: Apigee consiglia di garantire che i tuoi server siano sincronizzati.

Diverse funzionalità, come la scadenza e la revoca del token, richiedono tempi di sistema accurati. Se ospiti i componenti di runtime in diversi data center, assicurati che gli orari di sistema siano sincronizzati.

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

Creare una rete virtuale in ogni area geografica

Crea una rete virtuale per il deployment su più aree geografiche. Ad esempio, i seguenti comandi di esempio creano reti nelle aree geografiche degli Stati Uniti centrali e degli Stati Uniti orientali.

NOTA: i passaggi di questa sezione sono forniti solo come esempi. Adattale in base alle tue esigenze.

Esegui questo comando per creare una rete virtuale nell'area geografica degli Stati Uniti orientali, con il nome my-hybrid-rg-vnet:

az network vnet create \
 --name my-hybrid-rg-vnet \
 --location eastus \
 --resource-group my-hybrid-rg \
 --address-prefixes 120.38.1.0/24 \
 --subnet-name my-hybrid-rg-vnet-subnet \
 --subnet-prefix 120.38.1.0/26

Esegui questo comando per creare una rete virtuale nell'area geografica degli Stati Uniti centrali, con il nome my-hybrid-rg-vnet-ext01:

az network vnet create \
 --name my-hybrid-rg-vnet-ext01 \
 --location centralus \
 --resource-group my-hybrid-rg \
 --address-prefixes 192.138.0.0/24 \
 --subnet-name my-hybrid-rg-vnet-ext01-subnet \
 --subnet-prefix 192.138.0.0/26

Crea peering di rete

Crea un peering di rete tra le reti virtuali.

NOTA: i passaggi di questa sezione sono forniti solo come esempi. Adattale in base alle tue esigenze.

Recuperare gli ID rete virtuale

I peering vengono stabiliti tra ID di rete virtuali. Ottieni l'ID di ogni rete virtuale con il comando az network vnet show e archivia l'ID in una variabile.

Ottieni l'ID della prima rete virtuale, quella denominata my-hybrid-rg-vnet:

vNet1Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet \
 --query id --out tsv)

Ottieni l'ID della seconda rete virtuale, quella denominata my-hybrid-rg-vnet-ext01:

vNet2Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet-ext01 \
 --query id \
 --out tsv)

Crea peering dalla prima alla seconda rete virtuale

Con gli ID rete virtuale, puoi creare un peering dalla prima rete virtuale (my-hybrid-rg-vnet) alla seconda (my-hybrid-rg-vnet-ext01), come mostrato negli esempi seguenti:

Se non specifichi il parametro --allow-vnet-access, viene stabilito un peering, ma nessuna comunicazione può passare attraverso di esso.

az network vnet peering create \
 --name my-hybrid-rg-vnet1-peering \     # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \         # The virtual network name.
 --remote-vnet $vNet2Id \                # Resource ID of the remote virtual network.
 --allow-vnet-access

Nell'output del comando, tieni presente che peeringState è Initiated (Avviato). Il peering rimane in stato Avviato finché non crei il peering dalla seconda rete virtuale alla prima.

{
  ...
  "peeringState": "Initiated",
  ...
}

Crea un peering dalla seconda rete virtuale alla prima

Comando di esempio:

az network vnet peering create \
 --name my-hybrid-rg-vnet2-peering \        # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet-ext01 \      # The virtual network name.
 --remote-vnet $vNet1Id \                   # Resource ID of the remote virtual network.
 --allow-vnet-access

Nell'output del comando, tieni presente che peeringState è Connected. Azure cambia anche lo stato del peering dal primo al secondo peering di rete virtuale a Connected (Connesso).

{
  ...
  "peeringState": "Connected",
  ...
}

Puoi anche confermare che lo stato del peering per my-hybrid-rg-vnet1-peering in my-hybrid-rg-vnet2-peering: il peering sia cambiato in Connected con il seguente comando:

az network vnet peering show \
 --name my-hybrid-rg-vnet1-peering \
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \
 --query peeringState

Output previsto:

Connected

Crea cluster per più aree geografiche

Configura i cluster Kubernetes in più aree geografiche con blocchi CIDR diversi. Vedi anche il Passaggio 1: crea un cluster. Utilizza le località e i nomi di rete virtuali che hai creato in precedenza.

Porte Cassandra aperte 7000 e 7001 tra i cluster Kubernetes in tutte le aree geografiche (7000 possono essere utilizzate come opzione di backup durante la risoluzione dei problemi)

Configura l'host seed multi-regione

Questa sezione descrive come espandere il cluster Cassandra esistente in una nuova area geografica. Questa configurazione consente alla nuova area geografica di eseguire il bootstrap del cluster e unire il data center esistente. Senza questa configurazione, i cluster Kubernetes in più aree geografiche non si conoscerebbero a vicenda.

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

   kubectl config use-context original-cluster-name

2. Esegui il seguente comando kubectl per identificare un indirizzo host di origine per Cassandra nell'area geografica corrente.

   Un indirizzo host origine consente a una nuova istanza di area geografica di trovare il cluster originale al primissimo avvio, per conoscere 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 quali IP restituiti dal comando precedente saranno l'host seed a più aree geografiche. In questo esempio, dove è in esecuzione un solo cluster di cassandra a nodi singoli, l'host seed è 120.38.1.9.
4. Nel data center 2, copia il file di override in un nuovo file il cui nome include il nome del cluster. Ad esempio, overrides_your_cluster_name.yaml.
5. Nel data center 2, configura cassandra.multiRegionSeedHost e cassandra.datacenter in 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: "centralus"
     rack: "ra-1"

6. Nel nuovo data center/nella nuova area geografica, prima di installare un modello ibrido, imposta gli stessi certificati TLS e le stesse credenziali di overrides_your_cluster_name.yaml nella prima area geografica.
   NOTA: assicurati di utilizzare nel secondo data center gli stessi certificati e le stesse credenziali di Cassandra TLS che hai fornito nel data center originale. Le credenziali che imposti nel file di override nel primo data center devono corrispondere a quelle specificate nel file di override nel secondo data center. Per maggiori dettagli, consulta la pagina Configurazione di TLS per Cassandra.

Configura la nuova regione

Dopo aver configurato l'host seed, puoi impostare la nuova area geografica.

Per configurare la nuova area geografica:

1. Copia il certificato dal cluster esistente a quello nuovo. La nuova radice CA è utilizzata da Cassandra e altri componenti ibridi per mTLS. Pertanto, è essenziale disporre di certificati 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 dello spazio dei nomi corrente in un file:

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

   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 area geografica:

      kubectl config use-context new-cluster-name

   5. Importa la configurazione dello spazio dei nomi nel nuovo cluster. Assicurati di aggiornare "&namet&namet"; nel file se stai utilizzando uno spazio dei nomi diverso nella nuova area geografica:

      kubectl apply -f apigee-namespace.yaml

   6. Importa il secret nel nuovo cluster:

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

2. Installa un modello ibrido nella nuova area geografica. Assicurati che il file overrides_your_cluster_name.yaml includa gli stessi certificati TLS configurati nella prima area geografica, come spiegato nella sezione precedente.

   Esegui i due comandi seguenti per installare la versione ibrida nella nuova area geografica:

   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 nel nuovo data center. Questa operazione potrebbe richiedere da qualche minuto a qualche ora, 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 dell'utente Cassandra JMX.

4. Verifica i processi di rigenerazione dai log. Inoltre, verifica la dimensione 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 voci di log di esempio:

   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 nuovamente la domanda.
   Gli host origine sono membri del cluster locale. Per avviare una nuova area geografica è richiesto un host seed esterno. Dopo l'avvio di un'area geografica, devi ripristinare gli host seed nei propri cluster locali in overrides.yaml e applicare nuovamente la configurazione.

   apigeectl apply -f overrides-DC_name.yaml