Esegui la migrazione alla rete multi-cluster con i cluster Google Kubernetes Engine (GKE) Autopilot e standard

Last reviewed 2022-02-17 UTC

La rete multicluster è uno strumento prezioso che consente casi d'uso come l'alta disponibilità a livello regionale, la vicinanza agli utenti distribuita a livello globale per una latenza inferiore e l'isolamento organizzativo tra i team. Google Kubernetes Engine (GKE) offre funzionalità integrate per il networking multi-cluster che puoi attivare e utilizzare su larga scala in un parco di cluster GKE. Questa funzionalità consente inoltre di combinare o eseguire la migrazione dell'infrastruttura di cui è stato eseguito il deployment tra GKE Standard e Autopilot per soddisfare le esigenze di architettura di ogni applicazione.

Questa pagina mostra queste funzionalità tramite diverse topologie di deployment. Scopri come eseguire la migrazione di un'applicazione di cui è stato eseguito il deployment in un singolo cluster GKE a un deployment multi-cluster nei cluster GKE Standard e Autopilot. Utilizza Servizi multi-cluster GKE per il traffico est-ovest e gateway multi-cluster per abilitare il networking nord-sud multi-cluster.

Questa pagina è rivolta agli architetti cloud e ai team operativi che utilizzano o prevedono di utilizzare GKE per eseguire il deployment di servizi su più cluster Kubernetes. Prima di leggere questa pagina, assicurati di conoscere Kubernetes.

GKE Standard e GKE Autopilot

GKE offre un deployment Kubernetes gestito con una un set di caratteristiche che include un piano di controllo per l'alta disponibilità. GKE possono essere avviati rapidamente e scalare fino a 15.000 nodi. Con GKE Pilota automatico cluster, Google gestisce l'infrastruttura, compresi il piano di controllo tra i nodi. Se invece vuoi configurare e gestire i nodi, GKE fornisce Modalità Standard.

Per ulteriori informazioni sulle differenze tra le modalità, consulta Scegliere una modalità di funzionamento del cluster.

Servizi multi-cluster e gateway multi-cluster

Kubernetes può essere eseguito utilizzando un unico piano di controllo in zone cloud diverse per fornire resilienza e una maggiore disponibilità per i tuoi servizi. GKE fa un ulteriore passo in questa GKE Servizi multi-cluster (MCS) che fornisce un meccanismo di rilevamento e Service Discovery tra cluster. I servizi che utilizzano questa funzionalità sono rilevabili e accessibili tra i cluster con un indirizzo IP virtuale, che corrisponde al comportamento di un servizio ClusterIP accessibile in un cluster. Questo approccio offre i seguenti vantaggi:

  • I servizi possono essere bilanciati su più cluster nella stessa regione o in regioni diverse (traffico est-ovest).
  • Sono possibili opzioni di alta disponibilità dei servizi tra regioni.
  • È possibile eseguire il deployment dei carichi di lavoro stateful e stateless e gestirli in cluster.
  • I servizi condivisi sono disponibili in tutti i cluster.

Per scoprire di più su come eseguire il deployment di MCS, consulta Configurazione di servizi multi-cluster.

GKE fornisce un'implementazione dell'API Kubernetes Gateway che utilizza Controller gateway GKE. Gateway consente a GKE di eseguire il deployment di bilanciatori del carico Google Cloud per fornire il routing del traffico in entrata (da nord a sud) per i servizi di cui è stato eseguito il deployment su GKE. GKE offre inoltre Gateway multi-cluster (MCG) che estendono il controller gateway GKE per eseguire il provisioning del carico bilanciatori che instradano il traffico a servizi di cui è stato eseguito il deployment cluster GKE.

Il seguente diagramma mostra come, quando combini MCS e MCG, puoi gestire gli aspetti complementari del deployment del servizio e dell'instradamento del traffico di un singolo piano di controllo:

I servizi multi-cluster facilitano la comunicazione tra i servizi in un cluster e il gateway multi-cluster esegue il deployment di bilanciatori del carico per instradare il traffico tra i cluster.

Per saperne di più, consulta Eseguire il deployment di gateway multi-cluster.

Panoramica della migrazione

Le funzionalità di networking multi-cluster GKE sono vantaggiosi per i carichi di lavoro vari profili. Ad esempio, potresti avere componenti senza stato con traffico picchiettato che vuoi spostare in Autopilot a causa del suo modello di costo più efficiente.

In alternativa, ti consigliamo di posizionare i frontend dell'applicazione più vicino agli utenti. Questo approccio offre una latenza e una memorizzazione nella cache inferiori che migliorano le prestazioni dell'applicazione e l'esperienza utente. Allo stesso tempo, è possibile che alcuni su cui si basa la tua applicazione e che possono risiedere in una sola posizione. Questa configurazione richiede il bilanciamento del carico multi-cluster nord-sud per inviare il traffico client al cluster corretto in quella località. Hai bisogno anche di est-ovest, il bilanciamento del carico multi-cluster per inviare il traffico tra i cluster e raggiungere componenti stateful,

Questa pagina utilizza l'applicazione demo dei microservizi cloud Online Boutique per dimostrare un pattern multi-cluster che può essere utilizzato per migliorare il deployment della demo a zona singola. Inizia con una versione monozona dell'applicazione. Aggiungi poi elementi di alta disponibilità e resilienza utilizzando servizi e gateway multi-cluster e riduci la complessità operativa sfruttando Autopilot.

Deployment iniziale su cluster singolo

Nel diagramma seguente, viene eseguito inizialmente il deployment dell'applicazione Online Boutique in un singolo cluster GKE Standard denominato std-west ed è esposto utilizzando un servizio LoadBalancer:

Un singolo cluster GKE in modalità Standard che esegue tutti i servizi esposti utilizzando un normale servizio LoadBalancer esterno HTTP.

Esegui la migrazione ai servizi multi-cluster

Nel passaggio intermedio successivo, crei altri due cluster e i servizi senza stato vengono di cuipiati in altre regioni. Puoi creare due cluster GKE Autopilot denominati auto-east e auto-central in due regioni distinte dal singolo cluster GKE Standard std-west e registrarli nel parco risorse Google Cloud.

I parchi risorse sono un concetto di Google Cloud per l'organizzazione logica dei cluster e di altre risorse; ti consentono di utilizzare e gestire le funzionalità multi-cluster e di applicare criteri coerenti in tutti i tuoi sistemi.

Esporti cartservice nel cluster std-west nello spazio dei nomi onlineboutique nei nuovi cluster di parchi utilizzando ServiceExport. Esegui il deployment del servizio frontend di Online Boutique su tutti e tre i cluster e espostolo tramite un servizio ClusterIP. Poi esporti il servizio nel parco utilizzando ServiceExports. Servizi come il livello middleware di Online Boutique (come productcatalog, shipping e adservice) viene implementato in tutti e tre cluster.

Un Pod in esecuzione in qualsiasi cluster del parco risorse può accedere a un Service estratto inviando una richiesta all'URI ClusterSet del servizio. La richiesta a un endpoint che supporta il servizio.

Il servizio frontend è in grado di utilizzare i servizi middleware (ad esempio productcatalogservice o currencyservice) localmente nello stesso cluster. Questa architettura consente di mantenere le richieste in entrata locali nelle regioni il cui il frontend risponde alla richiesta ed evita una rete tra regioni non necessaria addebiti sul traffico.

Il seguente diagramma illustra i due servizi multi-cluster. Il servizio frontend stateless viene eseguito in tre cluster e il servizio cartservice stateful viene eseguito in un cluster. Il diagramma mostra anche che in questo passaggio intermedio, il traffico in entrata per il servizio frontend rimane instradato verso il cluster GKE Standard originale in us-west1 utilizzando un bilanciatore del carico di rete passthrough esterno creato Servizio LoadBalancer:

I servizi multicluster vengono eseguiti su tre cluster GKE, ma il traffico viene comunque indirizzato a un singolo cluster utilizzando un normale servizio LoadBalancer esterno HTTP.

Esegui la migrazione a un gateway multi-cluster

Nel passaggio finale, instrada il traffico in entrata per il frontend Servizio proveniente da richieste di client esterni a servizi in più cluster nel un parco risorse utilizzando un gateway multi-cluster.

Un quarto cluster denominato config-central viene aggiunto al parco per ospitare e gestire la configurazione delle risorse Gateway e HTTPRoute create nell'ambito di questa configurazione. La risorsa HTTPRoute mappa il prefisso / al frontend ServiceImport. Il traffico per il frontend della boutique online viene inviato a un endpoint funzionante in una delle regioni disponibili. Questo approccio aggiunge elementi di la disponibilità dell'architettura dell'applicazione Online Boutique.

Nel diagramma seguente, il gateway multicluster esegue il deployment di un bilanciatore del carico Cloud globale che instrada il traffico esterno al servizio frontend stateless di cui è stato eseguito il deployment su ciascuno dei tre cluster di applicazioni del parco.

I servizi multi-cluster vengono eseguiti su tre cluster GKE e il traffico ora viene distribuito tra i servizi frontend in tutti i cluster utilizzando un gateway esterno multi-cluster.

Nello stato finale, questo modello "guidato" dimostra un basso accoppiamento tra le parti stateful (cartservice e redis-cart) e stateless di l'applicazione (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice e adservice). Anche se non rientra nell'ambito di questa pagina, questo approccio ti offre in futuro l'opportunità di aggiungere resilienza e alta disponibilità al livello di servizi stateful.

Obiettivi

  • Crea e configura GKE Standard Autopilot.
  • Esegui il deployment di Online Boutique su un GKE Standard a livello di zona in un cluster Kubernetes.
  • Esporta multi-cluster Services.
  • Esegui il deployment dei manifest nei cluster Standard e Autopilot.
  • Attiva e configura i gateway multi-cluster.
  • Testa il comportamento delle applicazioni multiregionali.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Prima di iniziare

I vincoli di sicurezza definiti dalla tua organizzazione potrebbero impedirti di completare i passaggi seguenti. Per informazioni sulla risoluzione dei problemi, vedi Sviluppare applicazioni in un ambiente Google Cloud vincolato.

Prima di iniziare, assicurati di soddisfare i seguenti requisiti:

  • Ti consigliamo di usare un nuovo progetto per questa guida, in quanto per eseguire la pulizia consiste nell'eliminare il progetto al termine.
  • Questa guida presuppone che tu abbia il ruolo IAM proprietario per progetto Google Cloud. Per la produzione o ambientazioni reali, è meglio di modificare l'ambito delle autorizzazioni in base al privilegio minimo. Per ulteriori informazioni, consulta Utilizzare IAM in modo sicuro e Gestire identità e accessi.
  • Acquisisci familiarità con le Negozio online di microservizi dimostrano l'architettura dell'applicazione.

prepara l'ambiente

In questa guida, utilizzi Cloud Shell per inserire comandi. Cloud Shell ti consente di accedere alla riga di comando nella console Google Cloud e include Google Cloud SDK e altri strumenti, come Google Cloud CLI. Cloud Shell viene visualizzato come finestra nella parte inferiore nella console Google Cloud. L'inizializzazione può richiedere diversi minuti, ma la finestra viene visualizzata immediatamente.

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

  2. In Cloud Shell, definisci le variabili di ambiente utilizzate in questa guida. Sostituisci PROJECT_ID con il tuo ID progetto:

    export PROJECT=PROJECT_ID
    gcloud config set project ${PROJECT}
    
  3. Abilita i servizi richiesti per i passaggi in questa pagina:

    gcloud services enable \
        gkehub.googleapis.com \
        multiclusteringress.googleapis.com \
        dns.googleapis.com \
        trafficdirector.googleapis.com \
        cloudresourcemanager.googleapis.com \
        multiclusterservicediscovery.googleapis.com \
        container.googleapis.com
    
    gcloud container fleet multi-cluster-services enable
    

    I servizi multi-cluster gestiscono componenti di Google Cloud come Cloud DNS, regole firewall e Cloud Service Mesh, pertanto anche queste API devono essere attivate. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

    L'output è simile al seguente esempio:

    Operation "operations/acf.p2-822685001869-ee4ebe78-6dd8-465e-b0fd-3b0e5f964bad"
    finished successfully.
    
    Waiting for Feature Multi-cluster Services to be created...done.
    
  4. Verifica che i servizi multi-cluster mostrino lo stato ATTIVO:

    gcloud container fleet multi-cluster-services describe
    

    L'output è simile all'esempio seguente:

    createTime: '2021-11-30T21:59:25.245190894Z'
    name: projects/PROJECT_ID/locations/global/features/multiclusterservicediscovery
    resourceState:
      state: ACTIVE
    spec: {}
    updateTime: '2021-11-30T21:59:27.459063070Z'
    

    Se il valore di state non è ACTIVE, consulta i dettagli sulla risoluzione dei problemi relativi ai servizi multicluster.

Crea e configura i cluster GKE

Per dimostrare il pattern multi-cluster in questa guida, vengono utilizzati tre cluster di applicazioni in tre regioni cloud separate e un cluster per ospitare la configurazione per le risorse del gateway. Registra tutti i cluster nel parco risorse associato al tuo progetto. Un progetto Google Cloud può avere associato un solo parco risorse. Questo progetto è noto come host del parco risorse progetto.

  1. Crea cluster GKE standard e Autopilot:

    gcloud container clusters create std-west \
        --zone us-west1-a \
        --num-nodes=6 \
        --enable-ip-alias \
        --release-channel regular \
        --workload-pool=${PROJECT}.svc.id.goog \
        --async
    
    gcloud container clusters create-auto auto-east \
        --region us-east1 \
        --release-channel regular \
        --async
    
    gcloud container clusters create-auto auto-central \
        --region us-central1 \
        --release-channel regular \
        --async
    
    gcloud container clusters create config-central \
        --region us-central1 \
        --num-nodes=1 \
        --enable-ip-alias \
        --release-channel regular \
        --workload-pool=${PROJECT}.svc.id.goog \
        --async
    

    La federazione delle identità per i carichi di lavoro per GKE è abilitata per impostazione predefinita su GKE Autopilot in modo da non dover usare --workload-pool quando crei i cluster come fai con di cluster GKE Standard.

  2. Attendi che i dati dei cluster STATUS per passare da PROVISIONING a RUNNING. Questa procedura può richiedere fino a 10 minuti. Puoi monitorare l'avanzamento utilizzando un loop di visualizzazione:

    watch -n 20 --difference=permanent "gcloud container clusters list"
    

    L'output è simile all'esempio seguente:

    NAME: auto-central
    LOCATION: us-central1
    MASTER_VERSION: 1.21.5-gke.1802
    MASTER_IP: 107.178.213.138
    MACHINE_TYPE: e2-medium
    NODE_VERSION: 1.21.5-gke.1802
    NUM_NODES: 3
    STATUS: PROVISIONING
    
    NAME: config-central
    LOCATION: us-central1
    MASTER_VERSION: 1.21.5-gke.1802
    MASTER_IP:
    MACHINE_TYPE: e2-medium
    NODE_VERSION: 1.21.5-gke.1802
    NUM_NODES: 9
    STATUS: PROVISIONING
    
    NAME: auto-east
    LOCATION: us-east1
    MASTER_VERSION: 1.21.5-gke.1802
    MASTER_IP: 35.229.88.209
    MACHINE_TYPE: e2-medium
    NODE_VERSION: 1.21.5-gke.1802
    NUM_NODES: 3
    STATUS: PROVISIONING
    
    NAME: std-west
    LOCATION: us-west1-a
    MASTER_VERSION: 1.21.5-gke.1802
    MASTER_IP: 35.197.93.113
    MACHINE_TYPE: e2-medium
    NODE_VERSION: 1.21.5-gke.1802
    NUM_NODES: 6
    STATUS: PROVISIONING
    
  3. Quando tutti i cluster sono nello stato IN ESECUZIONE, premi CTRL-C per e interrompere il comando.

  4. Aggiungi un'associazione di criteri IAM (Identity and Access Management) per concedere all'host del parco risorse all'account di servizio MCS del progetto il ruolo Utente di rete per il proprio progetto:

    gcloud projects add-iam-policy-binding ${PROJECT} \
        --member "serviceAccount:${PROJECT}.svc.id.goog[gke-mcs/gke-mcs-importer]" \
        --role "roles/compute.networkViewer"
    

    Utilizza la federazione delle identità per i carichi di lavoro per GKE per concedere al servizio MCS l'accesso in lettura alla configurazione della rete VPC del progetto. Di conseguenza, l'oggetto MCS del progetto host del parco risorse L'account di servizio Importatore GKE richiede questo ruolo.

    L'output è simile al seguente esempio:

    - members:
      - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]
      role: roles/compute.networkViewer
    [...]
    
  5. Registra GKE Standard e Autopilot al parco risorse del tuo progetto. Per ulteriori dettagli, consulta la sezione Registrazione di un cluster. Questo passaggio può richiedere fino a 5 minuti:

    gcloud container fleet memberships register std-west \
        --gke-cluster us-west1-a/std-west \
        --enable-workload-identity \
        --project=${PROJECT}
    
    gcloud container fleet memberships register auto-east \
        --gke-cluster us-east1/auto-east \
        --enable-workload-identity \
        --project=${PROJECT}
    
    gcloud container fleet memberships register auto-central \
        --gke-cluster us-central1/auto-central \
        --enable-workload-identity \
        --project=${PROJECT}
    
    gcloud container fleet memberships register config-central \
        --gke-cluster us-central1/config-central \
        --enable-workload-identity \
        --project=${PROJECT}
    

    L'output di ogni comando è simile all'esempio seguente:

    Waiting for membership to be created...done.
    Created a new membership [projects/PROJECT_ID/locations/global/memberships/std-west] for the cluster [std-west]
    Generating the Connect Agent manifest...
    Deploying the Connect Agent on cluster [std-west] in namespace [gke-connect]...
    Deployed the Connect Agent on cluster [std-west] in namespace [gke-connect].
    Finished registering the cluster [std-west] with the Hub.
    
  6. Connettiti ai cluster e genera le voci di kubeconfig:

    gcloud container clusters get-credentials std-west \
        --zone us-west1-a --project $PROJECT
    
    gcloud container clusters get-credentials auto-east \
        --region us-east1 --project $PROJECT
    
    gcloud container clusters get-credentials auto-central \
        --region us-central1 --project $PROJECT
    
    gcloud container clusters get-credentials config-central \
        --region us-central1 --project $PROJECT
    

    Per ogni comando, l'output è simile al seguente esempio:

    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for std-west.
    
  7. Rinomina i contesti per i cluster in modo da facilitarne l'utilizzo nel resto di questa pagina:

    kubectl config rename-context \
        gke_${PROJECT}_us-west1-a_std-west \
        std-west
    
    kubectl config rename-context \
        gke_${PROJECT}_us-east1_auto-east \
        auto-east
    
    kubectl config rename-context \
        gke_${PROJECT}_us-central1_auto-central \
        auto-central
    
    kubectl config rename-context \
        gke_${PROJECT}_us-central1_config-central \
        config-central
    

    In questa guida, i contesti sono denominati in base alla loro posizione. Anche se puoi fornire nomi alternativi, i passaggi rimanenti di questa guida utilizzano i nomi utilizzati in questo passaggio.

Esegui il deployment di Online Boutique su GKE Standard

Nel primo passaggio del deployment di dimostrazione, esegui il deployment dell'insieme completo di servizi dell'applicazione Online Boutique nell'unico cluster GKE standard std-west in us-west1.

  1. Crea lo spazio dei nomi onlineboutique su std-west:

    kubectl create namespace onlineboutique --context std-west
    

    L'output è simile al seguente esempio:

    namespace/onlineboutique created
    
  2. Clona il repository GitHub di Online Boutique e imposta una variabile WORKDIR:

    cd ~
    
    git clone --branch release/v0.4.1 \
        https://github.com/GoogleCloudPlatform/microservices-demo.git
    
    cd microservices-demo/release && export WORKDIR=`pwd`
    
  3. Esegui il deployment di Online Boutique su std-west. Questo processo crea Deployments e Services per tutti i microservizi di Online Boutique e include un servizio di tipo LoadBalancer che espone esternamente il servizio frontend di Online Boutique:

    cd $WORKDIR
    
    kubectl apply -f kubernetes-manifests.yaml \
        -n onlineboutique --context=std-west
    
  4. Attendi che il servizio LoadBalancer ottenga un IP esterno:

    watch -n 20 --difference=permanent \
         "kubectl get svc frontend-external -n onlineboutique --context=std-west"
    

    Inizialmente, l'output è simile al seguente esempio:

    NAME                TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
    frontend-external   LoadBalancer   10.60.5.62   <pending>     80:30359/TCP   43s
    

    Quando Service è pronto, la colonna EXTERNAL-IP visualizza l'IP pubblico. del bilanciatore del carico.

  5. Quando Service è pronto, ottieni l'indirizzo IP esterno del carico e utilizzare curl per verificare che il frontend sia pronto. Se questo curl restituisce un errore, attendi qualche istante prima di riprovare:

      curl $(kubectl get svc frontend-external \
          -n onlineboutique --context=std-west \
          -o=jsonpath="{.status.loadBalancer.ingress[0].ip}") | \
            grep -e Cluster -e Zone -e Pod
    

    L'output corretto del comando curl è simile al seguente esempio:

    <b>Cluster: </b>std-west<br/>
    <b>Zone: </b>us-west1-a<br/>
    <b>Pod: </b>frontend-b7bddcc97-wdjsk
    

Ora hai una versione monozona di Online Boutique in esecuzione in us-west1-a. Puoi anche utilizzare un browser web per accedere all'IP esterno assegnato al servizio LoadBalancer frontend-external per accedere all'applicazione e osservarne il comportamento. Questo singolo deployment iniziale è mostrato nel seguente diagramma:

Un singolo cluster GKE in modalità Standard che esegue tutti i servizi esposti tramite un normale servizio LoadBalancer esterno HTTP.

Esportare cartservice come servizio multi-cluster

In questa sezione, inizierai ad aggiungere elementi di alta disponibilità al un'applicazione. Esporta il backend cartservice come servizio multi-cluster ai cluster GKE Autopilot.

  1. Crea lo spazio dei nomi onlineboutique sui cluster rimanenti:

    kubectl create namespace onlineboutique --context auto-east
    
    kubectl create namespace onlineboutique --context auto-central
    
    kubectl create namespace onlineboutique --context config-central
    

    L'output di ogni comando è simile all'esempio seguente:

    namespace/onlineboutique created
    
  2. Esporta cartservice dal cluster std-west in tutti gli altri cluster in ClusterSet. L'oggetto ServiceExport registra il servizio cartservice. Servizio, con i servizi multi-cluster GKE, per l'esportazione in Tutti i cluster nel parco risorse che presentano lo spazio dei nomi onlineboutique. Per ulteriori dettagli, vedi registrare un servizio per l'esportazione.

    cat <<EOF>> $WORKDIR/cartservice-export.yaml
    kind: ServiceExport
    apiVersion: net.gke.io/v1
    metadata:
     namespace: onlineboutique
     name: cartservice
    
    EOF
    
    kubectl apply -f $WORKDIR/cartservice-export.yaml \
        -n onlineboutique --context=std-west
    

Applica i manifest dell'applicazione per il pattern multi-cluster

In questa sezione applichi due manifest selezionati per eseguire il deployment del pattern multi-cluster. Questi manifest contengono parti selezionate di kubernetes-manifests.yaml che hai applicato in precedenza al cluster std-west:

  • Il primo manifest viene utilizzato per il frontend Deployment, Service e ServiceExport.
  • Il secondo manifest viene utilizzato per il deployment del middleware Services (emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice e adservice) in tutte le regioni in cui è in esecuzione un frontend. Se mantieni un locale in una regione per il più a lungo possibile, eviterai inutili per il traffico di rete tra regioni.

Un Pod in esecuzione in qualsiasi cluster del parco risorse può accedere a un Service esportato inviando una richiesta all'URI ClusterSet per quel servizio nel formato SERVICE_NAME.NAMESPACE.svc.clusterset.local. Ad esempio, il frontend Deployments in tutti e tre i cluster di esempio è in grado di utilizzare il servizio cartservice nello spazio dei nomi onlineboutique inviando una richiesta a cartservice.onlineboutique.svc.clusterset.local.

Per questo motivo, in ogni manifest, il nome host per cartservice è stato aggiornato all'URI ClusterSet. Questo passaggio è fondamentale. Se il nome host di questo servizio non viene aggiornato, il servizio di frontend chiederà a kube-dns cartservice anziché cartservice.onlineboutique.svc.clusterset.local. Questo comportamento causerebbe errori HTTP Status 500 nei cluster in cui non è disponibile una versione locale di cartservice e i pod frontend non sarebbero in stato di salute.

  1. Imposta una variabile di ambiente per il repository GitHub contenente i manifest:

    export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migration
    
  2. Applica i manifest per eseguire il deployment del livello di frontend a tutti e tre i carichi di lavoro cluster:

    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \
        -n onlineboutique --context=std-west
    
    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \
        -n onlineboutique --context=auto-east
    
    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \
        -n onlineboutique --context=auto-central
    
  3. Applica i manifest per eseguire il deployment del livello middleware in tutti e tre i cluster di workload:

    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
        -n onlineboutique --context=std-west
    
    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
        -n onlineboutique --context=auto-east
    
    kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
        -n onlineboutique --context=auto-central
    

Ora hai il frontend Deployment, Service e ServiceExport attivo nei cluster std-west, auto-east e auto-central. Hai anche a disposizione che eseguono i servizi middleware Online Boutique in ogni cluster. Tuttavia, il traffico esterno viene comunque indirizzato solo al Service in esecuzione nel cluster iniziale in us-west1, come mostrato nel seguente diagramma:

I servizi multicluster vengono eseguiti su tre cluster GKE, ma il traffico viene comunque indirizzato a un singolo cluster utilizzando un normale servizio LoadBalancer esterno HTTP.

Abilita e configura gateway multi-cluster

In questa sezione, instrada il traffico a e bilancia il carico del traffico esterno in tutti e tre i cluster. Per ottenere questa configurazione, utilizza gateway multi-cluster (MCG). Questi passaggi per configurare il gruppo di gateway multi-cluster seguono le indicazioni descritte in modo più dettagliato nell'articolo Attivare i gateway multi-cluster.

In questi passaggi, utilizzerai il cluster config-central per ospitare la configurazione per le risorse del gateway.

  1. Verifica che tutti i cluster siano stati registrati correttamente nel parco risorse:

    gcloud container fleet memberships list --project=$PROJECT
    

    L'esempio di output seguente mostra che tutti i cluster sono stati registrati correttamente:

    NAME: auto-central
    EXTERNAL_ID: 21537493-32ea-4a41-990d-02be2c1b319f
    
    NAME: config-central
    EXTERNAL_ID: 4369423e-ea7b-482d-a0eb-93b560e67b98
    
    NAME: std-west
    EXTERNAL_ID: 7fcb048b-c796-476b-9698-001a00f91ab3
    
    NAME: auto-east
    EXTERNAL_ID: aae2d2ff-b861-4a38-bcaf-612f14810012
    
  2. Installa la definizione della risorsa personalizzata dell'API Gateway nel cluster config-central:

    kubectl --context=config-central kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0" \
        | kubectl apply -f -
    

    Questo passaggio installa le definizioni delle risorse personalizzate dell'API Gateway, tra cui le risorse GatewayClass, Gateway e HTTPRoute. Le definizioni di risorse personalizzate sono gestite dal Network Special Interest Group di Kubernetes. Una volta installato, puoi utilizzare il controller GKE Gateway.

  3. Se non l'hai ancora fatto, abilita Ingress multi-cluster per il tuo parco risorse. L'attivazione di questa funzionalità abilita anche il controller gateway multi-cluster.

    gcloud container fleet ingress enable \
        --config-membership=config-central \
        --project=$PROJECT
    
    gcloud container fleet ingress describe --project=$PROJECT
    

    L'output è simile al seguente esempio:

    createTime: '2021-12-08T23:10:52.505888854Z'
    name: projects/PROJECT_ID/locations/global/features/multiclusteringress
    resourceState:
      state: ACTIVE
    spec:
      multiclusteringress:
        configMembership: projects/zl-mcs-expf61cbd13/locations/global/memberships/config-central
    state:
      state:
        code: OK
        description: Ready to use
        updateTime: '2021-12-08T23:11:37.994971649Z'
    updateTime: '2021-12-08T23:11:38.098244178Z'
    

    Se il valore di state non è ACTIVE, consulta Risoluzione dei problemi e operazioni per Ingress multi-cluster.

  4. Verifica che GatewayClasses siano disponibili sul cluster config-central:

    kubectl get gatewayclasses --context=config-central
    

    L'output è simile al seguente esempio:

    NAME                                  CONTROLLER                  AGE
    gke-l7-global-external-managed        networking.gke.io/gateway   18s
    gke-l7-global-external-managed-mc     networking.gke.io/gateway   19s
    gke-l7-regional-external-managed      networking.gke.io/gateway   18s
    gke-l7-regional-external-managed-mc   networking.gke.io/gateway   19s
    gke-l7-gxlb                           networking.gke.io/gateway   74s
    gke-l7-gxlb-mc                        networking.gke.io/gateway   16s
    gke-l7-rilb                           networking.gke.io/gateway   74s
    gke-l7-rilb-mc                        networking.gke.io/gateway   16s
    

    Risorse GatewayClass diverse hanno funzionalità diverse. Per maggiori informazioni informazioni su quando utilizzare quale tipo, consulta Funzionalità GatewayClass.

  5. Esegui il deployment della risorsa gateway di external-http in config-central:

    cat <<EOF>> $WORKDIR/external-http-gateway.yaml
    kind: Gateway
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: external-http
      namespace: onlineboutique
    spec:
      gatewayClassName: gke-l7-global-external-managed-mc
      listeners:
      - protocol: HTTP
        port: 80
        name: http
    EOF
    
    kubectl apply -f external-http-gateway.yaml \
        -n onlineboutique --context=config-central
    

    Come indicato dal campo gatewayClassName, questa risorsa è GatewayClass gke-l7-global-external-managed-mc che gestisce il livello 7 esterno Cloud Load Balancing ed espone l'applicazione multi-cluster

  6. Esegui il deployment della HTTPRoutepublic-frontend-route su config-central:

    cat <<EOF>> $WORKDIR/public-frontend-route.yaml
    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: public-frontend-route
      namespace: onlineboutique
    spec:
      parentRefs:
      - name: "external-http"
      hostnames:
      - "store.example.com"
      rules:
      - matches:
        - path:
            type: PathPrefix
            value: /
        backendRefs:
        - name: frontend
          group: net.gke.io
          kind: ServiceImport
          port: 80
    EOF
    
    kubectl apply -f public-frontend-route.yaml \
        -n onlineboutique --context=config-central
    

    Quando esegui il deployment della risorsa HTTPRoute, viene creata una risorsa di bilanciamento del carico Cloud di livello 7 esterno ed esposto il frontend ServiceImport supportato dai servizi frontend in esecuzione nei cluster std-west, auto-east e auto-central.

    Il seguente diagramma mostra come, dopo che il gateway multi-cluster viene di cui è stato eseguito il deployment, il traffico può essere instradato verso qualsiasi cluster multi-cluster frontend Servizi su uno qualsiasi dei tre cluster di applicazioni:

    I servizi multi-cluster vengono eseguiti su tre cluster GKE e il traffico è ora distribuito tra i servizi frontend in tutti i cluster utilizzando un gateway esterno multi-cluster.

  7. Attendi che il bilanciatore del carico sia pronto con un indirizzo IP esterno provisionato prima di procedere con il passaggio successivo. L'assegnazione dell'indirizzo IP può richiedere fino a 10 minuti. Puoi monitorare l'avanzamento utilizzando un loop di monitoraggio. Il bilanciatore del carico ha un nome nel pattern come gkemcg-onlineboutique-external-http-k09mfhk74gop:

    watch -n 20 --difference=permanent \
        "gcloud compute forwarding-rules list \
            | grep -A 5 NAME..*external-http"
    

    L'output è simile all'esempio seguente:

    NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop
    REGION:
    IP_ADDRESS: 34.149.29.176
    IP_PROTOCOL: TCP
    TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gop
    
  8. Quando il bilanciatore del carico è pronto, esegui il seguente comando in Cloud Shell per esportare l'indirizzo IP esterno del bilanciatore del carico creato tramite l'applicazione dei manifest external-http-gateway.yaml e public-frontend-route.yaml:

    export EXTERNAL_LB_IP=$(kubectl --context=config-central \
                                -n onlineboutique get gateway external-http \
                                -o=jsonpath='{.status.addresses[0].value}')
    
  9. Quando invii una richiesta al bilanciatore del carico con le intestazioni appropriate, restituisce i contenuti HTML pubblicati dal servizio frontend. Ad esempio, poiché hai configurato la risorsa HTTPRoute per mappare il nome host store.example.com al frontend ServiceImport, devi fornire l'intestazione HOST quando effettui la richiesta HTTP. Se: L'esempio di curl restituisce un errore. Attendi qualche minuto e riprova:

    curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
        grep -e Cluster -e Zone -e Pod
    

    L'output corretto del comando curl è simile al seguente esempio:

    <b>Cluster: </b>auto-central<br/>
    <b>Zone: </b>us-central1-f<br/>
    <b>Pod: </b>frontend-7c7d596ddc-jdh8f
    

Testa il comportamento di routing multi-regione dell'applicazione

Una delle potenti funzionalità offerte dai servizi multi-cluster in un gateway multi-cluster è che le richieste esterne vengono instradate dal cluster geografico più vicino.

Per testare il comportamento dell'applicazione in più regioni, genera traffico che ha origine da le varie regioni in cui è stato eseguito il deployment dei cluster. Crea tre piccoli pod, uno in ciascuno dei cluster di servizio (std-west, auto-east e auto-central), che puoi utilizzare per inviare richieste HTTP all'endpoint del bilanciatore del carico. I risultati ti consentono di vedere quale frontend Pod risponde.

  1. Crea i pod del client:

    kubectl run --context=std-west \
                --image=radial/busyboxplus:curl client-west \
                -- sh -c 'while sleep 3600; do :; done'
    
    kubectl run --context=auto-east \
                --image=radial/busyboxplus:curl client-east \
                -- sh -c 'while sleep 3600; do :; done'
    
    kubectl run --context=auto-central \
                --image=radial/busyboxplus:curl client-central \
                -- sh -c 'while sleep 3600; do :; done'
    
  2. Una volta che i pod sono in esecuzione, utilizza un comando curl per inviare una richiesta all'endpoint del bilanciatore del carico dal client Pod nel cluster std-west ed esamina la risposta:

    kubectl exec -it --context=std-west client-west \
        -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
               grep -e Cluster -e Zone -e Pod
    

    L'output corretto del comando curl è simile al seguente esempio:

    <b>Cluster: </b>std-west<br/>
    <b>Zone: </b>us-west1-a<br/>
    <b>Pod: </b>frontend-7cf48b79cf-trzc4
    
  3. Esegui la stessa richiesta curl dal client Pod nel cluster auto-east e controlla la risposta:

    kubectl exec -it --context=auto-east client-east \
        -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
               grep -e Cluster -e Zone -e Pod
    

    L'output corretto del comando curl è simile al seguente esempio:

    <b>Cluster: </b>auto-east<br/>
    <b>Zone: </b>us-east1-d<br/>
    <b>Pod: </b>frontend-6784b6df98-scdws
    

    Poiché si tratta di un cluster Autopilot, potrebbe essere necessario eseguire il provisioning di risorse aggiuntive per pianificare Pod. Se vedi un output simile nell'esempio seguente, attendi un istante e riprova:

     Error from server (BadRequest): pod client-east does not have a host assigned
    
  4. Esegui il comando curl dal client Pod nel cluster auto-central e controlla la risposta:

    kubectl exec -it --context=auto-central client-central \
        -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
            grep -e Cluster -e Zone -e Pod
    

    L'output corretto del comando curl è simile al seguente esempio:

    <b>Cluster: </b>auto-central<br/>
    <b>Zone: </b>us-central1-b<br/>
    <b>Pod: </b>frontend-6784b6df98-x2fv4
    

    Questi risultati confermano che il traffico viene indirizzato ai pod corrispondenti in località più vicine alla richiesta di origine.

Testa la resilienza multiregionale dell'applicazione

Oltre a un routing efficiente del traffico, l'esecuzione dei servizi in più offre resilienza nel raro, ma ancora possibile, caso un guasto dell'infrastruttura.

Verifica il comportamento eliminando il frontend Deployments in cluster specifici e riprova a eseguire il comando curl dal client Pod in quelle regioni. Verifica che l'applicazione sia ancora disponibile e controlla la posizione del Pod che risponde alla richiesta.

  1. Esegui il comando curl da client-west Pod nel cluster std-west, e vediamo che il risultato proviene dal frontend in us-west1:

    kubectl exec -it --context=std-west client-west \
        -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP  | \
               grep -e Cluster -e Zone -e Pod
    

    L'output corretto del comando curl è simile al seguente esempio:

    <b>Cluster: </b>std-west<br/>
    <b>Zone: </b>us-west1-a<br/>
    <b>Pod: </b>frontend-7cf48b79cf-trzc4
    
  2. Elimina il frontend Deployment nel cluster std-west:

    kubectl delete deploy frontend \
        -n onlineboutique --context=std-west
    

    L'output è simile all'esempio seguente:

    deployment.apps "frontend" deleted
    
  3. Invia un'altra richiesta da Pod client-west nel cluster std-west. Dovresti vedere una risposta da uno dei frontend Deployments rimanenti situati nei cluster auto-east o auto-central:

    kubectl exec -it --context=std-west client-west \
        -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
               grep -e Cluster -e Zone -e Pod
    

    Un output simile all'esempio seguente indica la posizione del Pod integro che risponde a questa richiesta:

    <b>Cluster: </b>auto-central<br/>
    <b>Zone: </b>us-central1-b<br/>
    <b>Pod: </b>frontend-6784b6df98-x2fv4
    

    o

    <b>Cluster: </b>auto-east<br/>
    <b>Zone: </b>us-east1-d<br/>
    <b>Pod: </b>frontend-6784b6df98-scdws
    

    Esegui il comando più volte per visualizzare risultati alternati.

Con questo deployment di dimostrazione, hai aggiunto elementi di resilienza e distribuzione geografica all'applicazione Online Boutique utilizzando servizi e gateway multi-cluster. Le richieste vengono indirizzate al più vicino regione geografica e anche se i servizi frontend o middleware in una regione problemi, l'utente finale è comunque in grado di utilizzare un'applicazione.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi