Esegui il deployment di un gateway multi-cluster esterno

Questo documento ti guida attraverso un esempio pratico per eseguire il deployment di un gateway multi-cluster esterno per instradare il traffico internet a un'applicazione che viene eseguita in due cluster GKE diversi.

I gateway multi-cluster offrono un modo efficace per gestire il traffico per i servizi di cui è stato eseguito il deployment in più cluster GKE. Utilizzando l'infrastruttura di bilanciamento del carico globale di Google, puoi creare un unico punto di accesso per le tue applicazioni, semplificando la gestione e migliorando l'affidabilità.

In questo tutorial utilizzerai un'applicazione store di esempio per simulare uno scenario reale in cui un servizio di acquisti online è di proprietà e gestito da team separati e viene eseguito il deployment in un parco risorse di cluster GKE condivisi.

Questo esempio mostra come configurare il routing basato su percorso per indirizzare il traffico a cluster diversi.

Prima di iniziare

I gateway multi-cluster richiedono una certa preparazione dell'ambiente prima di poter essere implementati. Prima di procedere, segui i passaggi descritti in Preparare l'ambiente per i gateway multi-cluster:

  1. Esegui il deployment dei cluster GKE.

  2. Registra i cluster in un parco risorse (se non sono già registrati).

  3. Abilita i controller del servizio multi-cluster e del gateway multi-cluster.

Infine, esamina le limitazioni e i problemi noti del controller GKE Gateway prima di utilizzarlo nel tuo ambiente.

Gateway esterno multi-cluster e multiregionale

In questo tutorial, creerai un gateway multi-cluster esterno che gestisce il traffico esterno in un'applicazione in esecuzione in due cluster GKE.

store.example.com viene eseguito il deployment in due cluster GKE ed esposto a internet utilizzando un gateway multi-cluster

Nei seguenti passaggi:

  1. Esegui il deployment dell'applicazione di esempio store nei cluster gke-west-1 e gke-east-1.
  2. Configura i servizi su ogni cluster da esportare nel tuo parco risorse (servizi multi-cluster).
  3. Esegui il deployment di un gateway multicluster esterno e di un HTTPRoute nel cluster di configurazione (gke-west-1).

Dopo il deployment delle risorse dell'applicazione e del gateway, puoi controllare il traffico nei due cluster GKE utilizzando il routing basato sul percorso:

  • Le richieste a /west vengono instradate ai pod store nel cluster gke-west-1.
  • Le richieste a /east vengono instradate ai pod store nel cluster gke-east-1.
  • Le richieste a qualsiasi altro percorso vengono instradate a uno dei due cluster, in base alla sua integrità, capacità e vicinanza al client richiedente.

Deployment dell'applicazione demo

  1. Crea il deployment e lo spazio dei nomi store in tutti e tre i cluster di cui è stato eseguito il deployment in Prepara l'ambiente per i gateway multi-cluster:

    kubectl apply --context gke-west-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml
kubectl apply --context gke-west-2 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml
kubectl apply --context gke-east-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml

    Vengono implementate le seguenti risorse in ogni cluster:

    namespace/store created
deployment.apps/store created

    Tutti gli esempi in questa pagina utilizzano l'app di cui è stato eseguito il deployment in questo passaggio. Assicurati che l'app sia distribuita in tutti e tre i cluster prima di provare uno dei passaggi rimanenti. Questo esempio utilizza solo i cluster gke-west-1 e gke-east-1, mentre gke-west-2 viene utilizzato in un altro esempio.

Servizi multi-cluster

I servizi sono il modo in cui i pod vengono esposti ai client. Poiché il controller gateway di GKE utilizza il bilanciamento del carico nativo del container, non utilizza il bilanciamento del carico ClusterIP o Kubernetes per raggiungere i pod. Il traffico viene inviato direttamente dal bilanciatore del carico agli indirizzi IP dei pod. Tuttavia, i servizi svolgono ancora un ruolo fondamentale come identificatore logico per il raggruppamento dei pod.

Multi-cluster Services (MCS) è uno standard API per i servizi che si estendono ai cluster e il relativo controller GKE fornisce il Service Discovery tra i cluster GKE. Il controller Gateway multicluster utilizza le risorse dell'API MCS per raggruppare i pod in un servizio indirizzabile su più cluster.

L'API multi-cluster Services definisce le seguenti risorse personalizzate:

  • ServiceExports esegue il mapping a un servizio Kubernetes, esportando gli endpoint di questo servizio in tutti i cluster registrati nel parco risorse. Quando un servizio ha un ServiceExport corrispondente, significa che il servizio può essere indirizzato da un gateway multicluster.
  • Le risorse ServiceImports vengono generate automaticamente dal controller del servizio multi-cluster. ServiceExport e ServiceImport vengono forniti in coppia. Se nel parco risorse esiste un ServiceExport, viene creato un ServiceImport corrispondente per consentire l'accesso al servizio mappato a ServiceExport da tutti i cluster.

L'esportazione dei servizi funziona nel seguente modo. Esiste un servizio di archiviazione in gke-west-1 che seleziona un gruppo di pod in quel cluster. Un ServiceExport viene creato nel cluster, consentendo ai pod in gke-west-1 di diventare accessibili dagli altri cluster nel parco risorse. ServiceExport esegue il mapping ed espone i servizi che hanno lo stesso nome e lo stesso spazio dei nomi della risorsa ServiceExport.

apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: store

Il seguente diagramma mostra cosa succede dopo il deployment di un ServiceExport. Se esiste una coppia ServiceExport e Service, il controller di servizio multi-cluster esegue il deployment di un ServiceImport corrispondente in ogni cluster GKE del parco risorse. ServiceImport è la rappresentazione locale del servizio store in ogni cluster. In questo modo, il pod client in gke-east-1 può utilizzare ClusterIP o servizi headless per raggiungere i pod store in gke-west-1. Se utilizzati in questo modo, i servizi multicluster forniscono il bilanciamento del carico est-ovest tra i cluster senza richiedere un servizio LoadBalancer interno. Per utilizzare i servizi multi-cluster per il bilanciamento del carico da cluster a cluster, vedi Configurazione dei servizi multi-cluster.

I servizi multi-cluster esportano i servizi tra i cluster, consentendo la comunicazione da cluster a cluster

Anche i gateway multi-cluster utilizzano ServiceImport, ma non per il bilanciamento del carico tra cluster. I gateway utilizzano invece ServiceImport come identificatori logici per un servizio che esiste in un altro cluster o che si estende su più cluster. La seguente HTTPRoute fa riferimento a un ServiceImport anziché a una risorsa Service. Facendo riferimento a un ServiceImport, indica che sta inoltrando il traffico a un gruppo di pod di backend in esecuzione in uno o più cluster.

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-route
  namespace: store
  labels:
    gateway: multi-cluster-gateway
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: external-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store
      port: 8080

Il seguente diagramma mostra come HTTPRoute indirizza il traffico store.example.com ai pod store su gke-west-1 e gke-east-1. Il bilanciatore del carico li tratta come un unico pool di backend. Se i pod di uno dei cluster diventano non integri, non raggiungibili o non hanno capacità di traffico, il carico di traffico viene bilanciato sui pod rimanenti nell'altro cluster. È possibile aggiungere o rimuovere nuovi cluster con il servizio store e ServiceExport. In questo modo vengono aggiunti o rimossi in modo trasparente i pod di backend senza modifiche esplicite alla configurazione del routing.

Risorsa MCS

Servizi di esportazione

A questo punto, l'applicazione è in esecuzione su entrambi i cluster. Successivamente, esponi ed esporti le applicazioni eseguendo il deployment di servizi e ServiceExport in ogni cluster.

  1. Applica il seguente manifest al cluster gke-west-1 per creare i servizi e i ServiceExport store e store-west-1:

    cat << EOF | kubectl apply --context gke-west-1 -f -
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: store
---
apiVersion: v1
kind: Service
metadata:
  name: store-west-1
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-west-1
  namespace: store
EOF

  2. Applica il seguente manifest al cluster gke-east-1 per creare i servizi e le ServiceExport store e store-east-1:

    cat << EOF | kubectl apply --context gke-east-1 -f -
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: store
---
apiVersion: v1
kind: Service
metadata:
  name: store-east-1
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-east-1
  namespace: store
EOF

  3. Verifica che nei cluster siano stati creati i ServiceExport corretti.

    kubectl get serviceexports --context CLUSTER_NAME --namespace store

    Sostituisci CLUSTER_NAME con gke-west-1 e gke-east-1. L'output è simile al seguente:

    # gke-west-1
NAME           AGE
store          2m40s
store-west-1   2m40s

# gke-east-1
NAME           AGE
store          2m25s
store-east-1   2m25s

    L'output mostra che il servizio store contiene store pod in entrambi i cluster, mentre i servizi store-west-1 e store-east-1 contengono solo store pod nei rispettivi cluster. Questi servizi sovrapposti vengono utilizzati per scegliere come target i pod in più cluster o un sottoinsieme di pod in un singolo cluster.

  4. Dopo qualche minuto, verifica che le ServiceImport associate siano state create automaticamente dal controller multi-cluster Services in tutti i cluster del parco risorse.

    kubectl get serviceimports --context CLUSTER_NAME --namespace store

    Sostituisci CLUSTER_NAME con gke-west-1 e gke-east-1. L'output dovrebbe essere simile al seguente:

    # gke-west-1
NAME           TYPE           IP                  AGE
store          ClusterSetIP   ["10.112.31.15"]    6m54s
store-east-1   ClusterSetIP   ["10.112.26.235"]   5m49s
store-west-1   ClusterSetIP   ["10.112.16.112"]   6m54s

# gke-east-1
NAME           TYPE           IP                  AGE
store          ClusterSetIP   ["10.72.28.226"]    5d10h
store-east-1   ClusterSetIP   ["10.72.19.177"]    5d10h
store-west-1   ClusterSetIP   ["10.72.28.68"]     4h32m

    Ciò dimostra che tutti e tre i servizi sono accessibili da entrambi i cluster nel parco risorse. Tuttavia, poiché esiste un solo cluster di configurazione attivo per parco progetti, puoi eseguire il deployment solo di gateway e HTTPRoute che fanno riferimento a questi ServiceImport in gke-west-1. Quando un HTTPRoute nel cluster di configurazione fa riferimento a questi ServiceImport come backend, il gateway può inoltrare il traffico a questi servizi indipendentemente dal cluster da cui vengono esportati.

Deployment di Gateway e HTTPRoute

Una volta eseguito il deployment delle applicazioni, puoi configurare un gateway utilizzando gke-l7-global-external-managed-mc GatewayClass. Questo gateway crea un bilanciatore del carico delle applicazioni esterno configurato per distribuire il traffico tra i cluster di destinazione.

  1. Applica il seguente manifest del gateway al cluster di configurazione, gke-west-1 in questo esempio:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http
  namespace: store
spec:
  gatewayClassName: gke-l7-global-external-managed-mc
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
EOF

    Questa configurazione del gateway esegue il deployment delle risorse del bilanciatore del carico delle applicazioni esterno con la seguente convenzione di denominazione: gkemcg1-NAMESPACE-GATEWAY_NAME-HASH.

    Le risorse predefinite create con questa configurazione sono:

    • 1 bilanciatore del carico: gkemcg1-store-external-http-HASH
    • 1 indirizzo IP pubblico: gkemcg1-store-external-http-HASH
    • 1 regola di forwarding: gkemcg1-store-external-http-HASH
    • 2 servizi di backend:
      • Servizio di backend 404 predefinito: gkemcg1-store-gw-serve404-HASH
      • Servizio di backend 500 predefinito: gkemcg1-store-gw-serve500-HASH
    • 1 Controllo di integrità:
      • Controllo di integrità 404 predefinito: gkemcg1-store-gw-serve404-HASH
    • 0 regole di instradamento (URLmap è vuoto)

    In questa fase, qualsiasi richiesta a GATEWAY_IP:80 genera una pagina predefinita che mostra il seguente messaggio: fault filter abort.

  2. Applica il seguente manifest HTTPRoute al cluster di configurazione, gke-west-1 in questo esempio:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: public-store-route
  namespace: store
  labels:
    gateway: external-http
spec:
  hostnames:
  - "store.example.com"
  parentRefs:
  - name: external-http
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /west
    backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store-west-1
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /east
    backendRefs:
      - group: net.gke.io
        kind: ServiceImport
        name: store-east-1
        port: 8080
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store
      port: 8080
EOF

    In questa fase, qualsiasi richiesta a GATEWAY_IP:80 genera una pagina predefinita che mostra il seguente messaggio: fault filter abort.

    Dopo il deployment, questa HTTPRoute configura il seguente comportamento di routing:

    • Le richieste a /west vengono instradate ai pod store nel cluster gke-west-1, perché i pod selezionati da ServiceExport store-west-1 esistono solo nel cluster gke-west-1.
    • Le richieste a /east vengono instradate ai pod store nel cluster gke-east-1, perché i pod selezionati da store-east-1 ServiceExport esistono solo nel cluster gke-east-1.
    • Le richieste a qualsiasi altro percorso vengono indirizzate ai pod store in uno dei due cluster, in base alla loro integrità, capacità e vicinanza al client richiedente.
    • Le richieste a GATEWAY_IP:80 restituiscono una pagina predefinita che mostra il seguente messaggio: fault filter abort.

    HTTPRoute consente il routing a diversi sottoinsiemi di cluster utilizzando servizi sovrapposti

    Tieni presente che se tutti i pod di un determinato cluster non sono integri (o non esistono), il traffico verso il servizio store verrà inviato solo ai cluster che hanno effettivamente pod store. L'esistenza di un ServiceExport e di un Service su un determinato cluster non garantisce che il traffico venga inviato a quel cluster. I pod devono esistere e rispondere in modo affermativo al controllo di integrità del bilanciatore del carico, altrimenti il bilanciatore del carico invia il traffico solo ai pod store integri in altri cluster.

    Vengono create nuove risorse con questa configurazione:

    • 3 servizi di backend:
      • Il servizio di backend store: gkemcg1-store-store-8080-HASH
      • Il servizio di backend store-east-1: gkemcg1-store-store-east-1-8080-HASH
      • Servizio di backend store-west-1: gkemcg1-store-store-west-1-8080-HASH
    • 3 controlli di integrità:
      • Il controllo di integrità store: gkemcg1-store-store-8080-HASH
      • Il controllo di integrità store-east-1: gkemcg1-store-store-east-1-8080-HASH
      • Il controllo di integrità store-west-1: gkemcg1-store-store-west-1-8080-HASH
    • 1 regola di instradamento in URLmap:
      • La regola di instradamento store.example.com:
      • 1 Host: store.example.com
      • Più matchRules per il routing ai nuovi servizi di backend

Il seguente diagramma mostra le risorse che hai eseguito il deployment in entrambi i cluster. Poiché gke-west-1 è il cluster di configurazione del gateway, è il cluster in cui il controller del gateway monitora il gateway, le HTTPRoute e le ServiceImport. Ogni cluster ha un ServiceImport store e un altro ServiceImport specifico per quel cluster. Entrambi puntano agli stessi pod. In questo modo, HTTPRoute specifica esattamente dove deve andare il traffico: ai pod store su un cluster specifico o ai pod store su tutti i cluster.

Questo è il modello di risorse Gateway e Servizio multi-cluster in entrambi i cluster

Tieni presente che si tratta di un modello di risorse logico, non di una rappresentazione del flusso di traffico. Il percorso del traffico va direttamente dal bilanciatore del carico ai pod di backend e non ha alcuna relazione diretta con il cluster di configurazione.

Convalida del deployment in corso…

Ora puoi inviare richieste al nostro gateway multi-cluster e distribuire il traffico su entrambi i cluster GKE.

  1. Verifica che Gateway e HTTPRoute siano stati implementati correttamente esaminando lo stato e gli eventi di Gateway.

    kubectl describe gateways.gateway.networking.k8s.io external-http --context gke-west-1 --namespace store

    Dovresti vedere un output simile al seguente:

    Name:         external-http
Namespace:    store
Labels:       <none>
Annotations:  networking.gke.io/addresses: /projects/PROJECT_NUMBER/global/addresses/gkemcg1-store-external-http-laup24msshu4
              networking.gke.io/backend-services:
                /projects/PROJECT_NUMBER/global/backendServices/gkemcg1-store-gw-serve404-80-n65xmts4xvw2, /projects/PROJECT_NUMBER/global/backendServices/gke...
              networking.gke.io/firewalls: /projects/PROJECT_NUMBER/global/firewalls/gkemcg1-l7-default-global
              networking.gke.io/forwarding-rules: /projects/PROJECT_NUMBER/global/forwardingRules/gkemcg1-store-external-http-a5et3e3itxsv
              networking.gke.io/health-checks:
                /projects/PROJECT_NUMBER/global/healthChecks/gkemcg1-store-gw-serve404-80-n65xmts4xvw2, /projects/PROJECT_NUMBER/global/healthChecks/gkemcg1-s...
              networking.gke.io/last-reconcile-time: 2023-10-12T17:54:24Z
              networking.gke.io/ssl-certificates:
              networking.gke.io/target-http-proxies: /projects/PROJECT_NUMBER/global/targetHttpProxies/gkemcg1-store-external-http-94oqhkftu5yz
              networking.gke.io/target-https-proxies:
              networking.gke.io/url-maps: /projects/PROJECT_NUMBER/global/urlMaps/gkemcg1-store-external-http-94oqhkftu5yz
API Version:  gateway.networking.k8s.io/v1
Kind:         Gateway
Metadata:
  Creation Timestamp:  2023-10-12T06:59:32Z
  Finalizers:
    gateway.finalizer.networking.gke.io
  Generation:        1
  Resource Version:  467057
  UID:               1dcb188e-2917-404f-9945-5f3c2e907b4c
Spec:
  Gateway Class Name:  gke-l7-global-external-managed-mc
  Listeners:
    Allowed Routes:
      Kinds:
        Group:  gateway.networking.k8s.io
        Kind:   HTTPRoute
      Namespaces:
        From:  Same
    Name:      http
    Port:      80
    Protocol:  HTTP
Status:
  Addresses:
    Type:   IPAddress
    Value:  34.36.127.249
  Conditions:
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:               The OSS Gateway API has deprecated this condition, do not depend on it.
    Observed Generation:   1
    Reason:                Scheduled
    Status:                True
    Type:                  Scheduled
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:
    Observed Generation:   1
    Reason:                Programmed
    Status:                True
    Type:                  Programmed
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:               The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
    Observed Generation:   1
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Listeners:
    Attached Routes:  1
    Conditions:
      Last Transition Time:  2023-10-12T07:00:41Z
      Message:
      Observed Generation:   1
      Reason:                Programmed
      Status:                True
      Type:                  Programmed
      Last Transition Time:  2023-10-12T07:00:41Z
      Message:               The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
      Observed Generation:   1
      Reason:                Ready
      Status:                True
      Type:                  Ready
    Name:                    http
    Supported Kinds:
      Group:  gateway.networking.k8s.io
      Kind:   HTTPRoute
Events:
  Type    Reason  Age                    From                   Message
  ----    ------  ----                   ----                   -------
  Normal  UPDATE  35m (x4 over 10h)      mc-gateway-controller  store/external-http
  Normal  SYNC    4m22s (x216 over 10h)  mc-gateway-controller  SYNC on store/external-http was a success

  2. Una volta eseguito il deployment del gateway, recupera l'indirizzo IP esterno dal gateway external-http.

    kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}" --context gke-west-1 --namespace store

    Sostituisci VIP nei passaggi successivi con l'indirizzo IP che ricevi come output.

  3. Inviare traffico al percorso principale del dominio. In questo modo, il bilanciamento del carico distribuisce il traffico verso l'oggetto ServiceImport store, che si trova nei cluster gke-west-1 e gke-east-1. Il bilanciatore del carico invia il traffico alla regione più vicina a te e potresti non visualizzare le risposte dell'altra regione.

    curl -H "host: store.example.com" http://VIP

    L'output conferma che la richiesta è stata gestita dal pod del cluster gke-east-1:

    {
  "cluster_name": "gke-east-1",
  "zone": "us-east1-b",
  "host_header": "store.example.com",
  "node_name": "gke-gke-east-1-default-pool-7aa30992-t2lp.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-dg22z",
  "pod_name_emoji": "⏭",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:32:51"
}

  4. Poi invia il traffico al percorso /west. In questo modo, il traffico viene instradato alla risorsa ServiceImport store-west-1, che ha solo pod in esecuzione nel cluster gke-west-1. Un ServiceImport specifico per il cluster, come store-west-1, consente a un proprietario dell'applicazione di inviare esplicitamente il traffico a un cluster specifico, anziché lasciare che sia il bilanciatore del carico a prendere la decisione.

    curl -H "host: store.example.com" http://VIP/west

    L'output conferma che la richiesta è stata gestita dal pod del cluster gke-west-1:

    {
  "cluster_name": "gke-west-1", 
  "zone": "us-west1-a", 
  "host_header": "store.example.com",
  "node_name": "gke-gke-west-1-default-pool-65059399-2f41.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-d25m5",
  "pod_name_emoji": "🍾",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:39:15",
}

  5. Infine, invia traffico al percorso /east.

    curl -H "host: store.example.com" http://VIP/east

    L'output conferma che la richiesta è stata gestita dal pod del cluster gke-east-1:

    {
  "cluster_name": "gke-east-1",
  "zone": "us-east1-b",
  "host_header": "store.example.com",
  "node_name": "gke-gke-east-1-default-pool-7aa30992-7j7z.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-hz6mw",
  "pod_name_emoji": "🧜🏾",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:40:48"
}

Esegui la pulizia

Dopo aver completato gli esercizi descritti in questo documento, segui questi passaggi per rimuovere le risorse ed evitare addebiti indesiderati sul tuo account:

  1. Elimina i cluster.

  2. Annulla la registrazione dei cluster dal parco risorse se non devono essere registrati per un altro scopo.

  3. Disattiva la funzionalità multiclusterservicediscovery:

    gcloud container fleet multi-cluster-services disable

  4. Disabilita Ingress multi-cluster:

    gcloud container fleet ingress disable

  5. Disabilita le API:

    gcloud services disable \
    multiclusterservicediscovery.googleapis.com \
    multiclusteringress.googleapis.com \
    trafficdirector.googleapis.com \
    --project=PROJECT_ID

Risoluzione dei problemi

Nessun upstream integro

Sintomo:

Il seguente problema potrebbe verificarsi quando crei un gateway, ma non riesci ad accedere ai servizi di backend (codice di risposta 503):

no healthy upstream

Motivo:

Questo messaggio di errore indica che il probe di controllo di integrità non riesce a trovare servizi di backend integri. È possibile che i servizi di backend siano integri, ma potrebbe essere necessario personalizzare i controlli di integrità.

Soluzione temporanea:

Per risolvere il problema, personalizza il controllo di integrità in base ai requisiti della tua applicazione (ad esempio /health) utilizzando un HealthCheckPolicy.

Passaggi successivi