Esegui la migrazione al networking multi-cluster con i cluster Autopilot e Standard di Google Kubernetes Engine (GKE)

Last reviewed 2022-02-17 UTC

Il networking multi-cluster è uno strumento prezioso che consente casi d'uso come disponibilità elevata, vicinanza agli utenti distribuita a livello globale per minore latenza, e l'isolamento organizzativo tra i team. Google Kubernetes Engine (GKE) offre funzionalità integrate per il networking multi-cluster che puoi abilitare e utilizzarli su larga scala in un parco risorse di cluster GKE. Questa funzionalità consente inoltre di combinare o migrare l'infrastruttura di cui è stato eseguito il deployment GKE Standard e Autopilot per soddisfare le esigenze dell'architettura di ogni applicazione.

Questo documento illustra queste funzionalità attraverso diverse topologie di deployment. Imparerai a eseguire il deployment di un'applicazione in un unico cluster GKE ed eseguirne la migrazione a un deployment multi-cluster su GKE standard e Autopilot. Utilizzi GKE Servizi multi-cluster per il traffico da est a ovest Gateway multi-cluster per abilitare il networking nord-sud multi-cluster.

Il documento è rivolto ai cloud architect e ai team operativi che utilizzano o pianificano per il deployment, GKE per eseguire il deployment di servizi in più cluster. In questo documento si presuppone che tu abbia familiarità con Kubernetes

GKE Standard e GKE Autopilot

GKE fornisce un deployment Kubernetes gestito 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à, vedi Scegli una modalità operativa del cluster.

Servizi multi-cluster e gateway multi-cluster

Kubernetes può essere eseguito utilizzando un unico piano di controllo in diverse zone cloud offrono resilienza e 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 in più cluster con un IP virtuale, che corrisponde al comportamento di un servizio ClusterIP accessibili in un cluster. Questo approccio offre i seguenti vantaggi:

  • Il bilanciamento del carico dei servizi può avvenire in più cluster nella stessa regione oppure regioni diverse (traffico da est a ovest).
  • Le opzioni per l'alta disponibilità del servizio tra regioni sono realizzabili.
  • È 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. Il gateway consente a GKE di eseguire il deployment dei bilanciatori del carico Google Cloud forniscono il routing del traffico in entrata (nord-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 dei bilanciatori del carico per instradare il traffico tra i cluster.

Per ulteriori informazioni, vedi 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 stateless del traffico che vuoi spostare ad Autopilot in virtù del suo costo più efficiente model.

In alternativa, potresti voler posizionare i frontend dell'applicazione più vicino agli utenti. Questo fornisce una latenza minore e una memorizzazione nella cache, che migliora l'applicazione le prestazioni 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,

Questo documento utilizza Negozio online i microservizi cloud dimostrano l'applicazione per dimostrare un pattern multi-cluster che può essere utilizzata per migliorare il deployment della demo a zona singola. Inizi con un una versione a zona singola dell'applicazione. Poi aggiungi elementi di alta la disponibilità e la resilienza mediante servizi multi-cluster i gateway e ridurre il lavoro manuale sfruttando Autopilot.

Deployment iniziale su cluster singolo

Nel diagramma seguente, viene eseguito inizialmente il deployment dell'applicazione Online Boutique in un singolo cluster in modalità 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, creerai altre due di cluster e il deployment dei servizi stateless in altre regioni. Tu crea due cluster GKE Autopilot denominati auto-east e auto-central in due regioni distinte dalla singola std-west GKE Standard e registra i cluster il Il parco risorse Google Cloud.

I parchi risorse sono un concetto di Google Cloud per l'organizzazione logica dei cluster e di altri e ti consentono di utilizzare e gestire funzionalità multi-cluster e applicare in modo coerente in tutti i sistemi.

Esporti cartservice nel cluster std-west in onlineboutique dello spazio dei nomi ai nuovi cluster del parco risorse ServiceExport. Esegui il deployment del servizio frontend di Online Boutique su tutti e tre i cluster ed esponi attraverso una ClusterIP completamente gestito di Google Cloud. Quindi esporterai il servizio nel parco risorse utilizzando ServiceExports. Servizi come il livello middleware di Online Boutique (come productcatalog, shipping e adservice) viene implementato in tutti e tre cluster.

Un Pod eseguito in qualsiasi cluster nel parco risorse può accedere a un Service esportato inviando una richiesta all'URI ClusterSet di quel servizio. La richiesta a un endpoint che supporta il servizio.

Il servizio frontend può utilizzare i servizi middleware (come 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. L'architettura Viene eseguito il deployment del servizio frontend in tre cluster e nel backend stateful Il deployment di cartservice 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 multi-cluster vengono eseguiti su tre cluster GKE, ma il traffico è comunque diretto 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.

Al parco risorse viene aggiunto un quarto cluster denominato config-central per ospitare e gestire la configurazione Gateway e HTTPRoute di risorse create come parte di questa configurazione. HTTPRoute La risorsa mappa il prefisso / al frontend ServiceImport: Il traffico per il frontend di Online Boutique viene inviato a un stato integro in una delle regioni disponibili. Questo approccio aggiunge elementi di la disponibilità dell'architettura dell'applicazione Online Boutique.

Nel diagramma seguente, il gateway multi-cluster esegue il deployment di una Bilanciatore del carico che instrada il traffico esterno al servizio frontend stateless di cui è stato eseguito il deployment in ciascuno dei tre cluster di applicazioni nel parco risorse.

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.

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). Non rientra nell'ambito di questo documento, questo approccio ti offre l'opportunità futura di aumentare la resilienza e l'alta disponibilità al livello dei 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.
  • Abilita e configura i gateway multi-cluster.
  • Testa il comportamento delle applicazioni multiregionali.

Costi

In questo documento vengono utilizzati 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 che siano soddisfatti i seguenti requisiti:

  • Ti consigliamo di usare un nuovo progetto per questa guida, in quanto per ripulire il progetto 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, vedi Utilizzo sicuro di IAM e Gestire identità e accesso.
  • 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 dà accesso alla riga di comando nel 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 viene visualizzata immediatamente.

  1. Nella console Google Cloud, attiva Cloud Shell.

    Attiva 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 questo documento:

    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 Google Cloud come Cloud DNS, regole firewall e Cloud Service Mesh, pertanto anche queste API devono abilitare l'accesso privato. Per ulteriori informazioni, vedi Panoramica di Cloud Service Mesh.

    L'output è simile all'esempio seguente:

    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, vedi il sezione relativa alla risoluzione dei problemi della documentazione di MCS.

Crea e configura cluster GKE

Per dimostrare il pattern multi-cluster in questa guida, utilizza tre cluster di applicazioni in tre regioni cloud separate e un cluster per ospitare la configurazione per le risorse del gateway. Puoi registrare tutti i cluster con parco risorse associato al tuo progetto. Un progetto Google Cloud può avere solo associati a un'unica flotta. Questo progetto è noto come host del parco risorse progetto.

  1. Crea GKE Standard e Autopilot cluster:

    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 cluster STATUS per passare da PROVISIONING a RUNNING. Questa procedura può richiedere fino a 10 minuti. Puoi monitorare l'avanzamento per usare un cinturino quando prendi una tazza di caffeina o fai un po' di luce esercizi di stretching prima di procedere con il resto del documento:

    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"

    Puoi utilizzare la federazione delle identità per i carichi di lavoro per GKE per concedere al servizio MCS l'accesso in lettura 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 all'esempio seguente:

    - 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. Consulta Registrazione di un cluster per ulteriori dettagli. 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 voci 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

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

    Fetching cluster endpoint and auth data.
kubeconfig entry generated for std-west.

  7. Rinominare i contesti per i cluster in modo da agevolarne l'utilizzo nel parte restante di questo documento:

    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. Sebbene puoi fornire nomi alternativi, i passaggi rimanenti di questa guida utilizzano i nomi utilizzati in questo passaggio.

Esegui il deployment di Boutique online su GKE Standard

Nel primo passaggio del deployment dimostrativo, esegui il deployment dell'intero set dei servizi delle applicazioni Online Boutique al singolo cluster GKE Cluster 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 all'esempio seguente:

    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. Questa procedura crea Deployments Services per tutti i microservizi di Online Boutique e include una 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 all'esempio seguente:

    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 a zona singola di Online Boutique in esecuzione in us-west1-a. Puoi anche utilizzare un browser web per accedere all'IP esterno assegnato al frontend-external LoadBalancer Servizio per accedere all'applicazione e osservare il suo 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.

Esporta 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 a 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 pattern multi-cluster

In questa sezione vengono applicati due manifest selezionati per il deployment dell'architettura multi-cluster pattern. Questi manifest contengono parti selezionate kubernetes-manifests.yaml che hai applicato in precedenza a std-west cluster:

  • 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 eseguito in qualsiasi cluster nel parco risorse può accedere a un Service esportato inviando una richiesta all'URI ClusterSet di quel servizio in formato SERVICE_NAME.NAMESPACE.svc.clusterset.local. Ad esempio, il frontend Deployments in tutti e tre i cluster di esempio sono in grado di utilizzare cartservice, nello spazio dei nomi onlineboutique, effettuando 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 comporterebbe HTTP Status 500 errori sui cluster in cui una versione locale di cartservice non è disponibile e causa lo stato non integro dei pod del frontend.

  1. Imposta una variabile di ambiente per il repository GitHub che contiene la classe manifests:

    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 a tutti e tre i carichi di lavoro cluster:

    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, le sorgenti il traffico viene comunque instradato solo verso Service in esecuzione nel cluster iniziale in us-west1, come mostrato nel seguente diagramma:

I servizi multi-cluster vengono eseguiti su tre cluster GKE, ma il traffico è comunque diretto 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). Questo documento segue le indicazioni per la configurazione di una rete multicanale come descritto in Abilitazione dei gateway multi-cluster.

In questa guida 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'output di esempio seguente mostra che tutti i cluster sono stati correttamente registrato:

    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 di risorsa personalizzata dell'API Gateway in config-central cluster:

    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 Risorse GatewayClass, Gateway e HTTPRoute. La risorsa personalizzata le definizioni sono gestite dall'amministratore Gruppo di interesse speciale della rete. Dopo l'installazione, puoi utilizzare il controller gateway GKE.

  3. Abilita Ingress multi-cluster per il tuo parco risorse se non lo hai già fatto. 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 all'esempio seguente:

    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 nel cluster config-central:

    kubectl get gatewayclasses --context=config-central

    L'output è simile all'esempio seguente:

    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 ulteriori 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 Cloud Load Balancing esterno ed espone l'applicazione multi-cluster

  6. Esegui il deployment di HTTPRoute denominato public-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 creato un livello esterno 7 Cloud Load Balancing ed espone il frontend ServiceImport supportato dai servizi frontend eseguiti nei sistemi 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 IP esterno di cui è stato eseguito il provisioning prima di procedere con il passaggio successivo. L'operazione potrebbe richiedere fino a 10 minuti l'indirizzo IP da assegnare. Puoi monitorare i progressi usando un orologio ciclo. Il bilanciatore del carico ha un nome nel pattern simile a 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 questo comando Cloud Shell per esportare l'indirizzo IP esterno del bilanciatore del carico creato mediante l'applicazione di external-http-gateway.yaml e Manifest 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 forniti dal servizio frontend. Ad esempio: poiché hai configurato la risorsa HTTPRoute per mappare la store.example.com per il frontend ServiceImport, devi fornisci 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 del routing multiregionale 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. Creare tre piccoli pod, uno in ciascuno dei cluster di gestione (std-west, auto-east e auto-central), che puoi utilizzare per inviare richieste HTTP al bilanciatore del carico endpoint. 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. Quando i pod sono in esecuzione, utilizza un comando curl per inviare una richiesta al carico endpoint del bilanciatore del carico dal client Pod nel cluster std-west ed esaminare 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 osserveremo 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é questo è un cluster Autopilot, potrebbe essere necessario eseguire il provisioning del cluster 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 nelle regioni in questione. Osservazione 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 Deployment frontend 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 Deployments frontend rimanenti situata 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 dimostrativo, hai aggiunto elementi di resilienza e la 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. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi