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 in esecuzione in due cluster GKE diversi.

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

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

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

Prima di iniziare

Prima di poter eseguire il deployment dei gateway multi-cluster, è necessario preparare l'ambiente. Prima di procedere, segui i passaggi descritti in Preparare l'ambiente per i gateway multi-cluster Gateways:

  1. Esegui il deployment dei cluster GKE.

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

  3. Abilita i controller dei servizi multi-cluster e dei gateway multi-cluster.

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

Gateway esterno multi-cluster e multi-regione

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

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

Nei passaggi seguenti:

  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 in modo che vengano esportati nel parco risorse (servizi multi-cluster).
  3. Esegui il deployment di un gateway multi-cluster esterno e di una risorsa HTTPRoute nel cluster di configurazione (gke-west-1).

Dopo aver eseguito il deployment dell'applicazione e delle risorse del gateway, puoi controllare il traffico tra i 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.

Eseguire il 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 Preparare 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

    Esegue il deployment delle 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 di cui sia stato eseguito il deployment in tutti e tre i cluster prima di provare i 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 dei gateway GKE utilizza il bilanciamento del carico nativo del container, non utilizza ClusterIP o il bilanciamento del carico di 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.

I servizi multi-cluster (MCS) sono uno standard API per i servizi che si estendono su più cluster e il relativo controller GKE fornisce Service Discovery tra i cluster GKE. Il controller dei gateway multi-cluster utilizza le risorse dell'API MCS per raggruppare i pod in un servizio indirizzabile su più cluster.

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

  • Le ServiceExports vengono mappate a un servizio Kubernetes, esportando gli endpoint di quel servizio in tutti i cluster registrati nel parco risorse. Quando un servizio ha una ServiceExport corrispondente, significa che il servizio può essere indirizzato da un gateway multi-cluster.
  • Le ServiceImports vengono generate automaticamente dal controller dei servizi multi-cluster. ServiceExport e ServiceImport sono in coppia. Se esiste una ServiceExport nel parco risorse, viene creata una ServiceImport corrispondente per consentire l'accesso al servizio mappato alla ServiceExport da tutti i cluster.

L'esportazione dei servizi funziona nel seguente modo. Esiste un servizio di negozio in gke-west-1 che seleziona un gruppo di pod in quel cluster. Viene creata una ServiceExport nel cluster che consente ai pod in gke-west-1 di diventare accessibili dagli altri cluster nel parco risorse. La ServiceExport esegue il mapping ed espone i servizi che hanno lo stesso nome e 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 una ServiceExport. Se esiste una coppia di ServiceExport e Service, il controller dei servizi multi-cluster esegue il deployment di una ServiceImport corrispondente in ogni cluster GKE nel parco risorse. La ServiceImport è la rappresentazione locale del servizio store in ogni cluster. In questo modo, il pod client in gke-east-1 può utilizzare i servizi ClusterIP o headless per raggiungere i pod store in gke-west-1. Se utilizzati in questo modo, i servizi multi-cluster 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, consulta Configurare i servizi multi-cluster.

I servizi multi-cluster esportano i servizi tra i cluster, il che consente la comunicazione da cluster a cluster.

Anche i gateway multi-cluster utilizzano le ServiceImport, ma non per il bilanciamento del carico da cluster a cluster. I gateway utilizzano invece le ServiceImport come identificatori logici per un servizio che esiste in un altro cluster o che si estende su più cluster. La seguente risorsa HTTPRoute fa riferimento a una ServiceImport anziché a una risorsa Service. Il riferimento a una ServiceImport indica che il traffico viene inoltrato a un gruppo di pod di backend in esecuzione su 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 la risorsa HTTPRoute instrada 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, irraggiungibili o non hanno capacità di traffico, il carico di traffico viene bilanciato sui pod rimanenti dell'altro cluster. È possibile aggiungere o rimuovere nuovi cluster con il servizio store e la risorsa ServiceExport. In questo modo, i pod di backend vengono aggiunti o rimossi in modo trasparente senza modifiche esplicite alla configurazione del routing.

Risorsa MCS

Esportare i servizi

A questo punto, l'applicazione è in esecuzione su entrambi i cluster. Poi, esponi ed esporta 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 le 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 le ServiceExport corrette siano state create nei cluster.

    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 pod store in entrambi i cluster, mentre i servizi store-west-1 e store-east-1 contengono solo pod store nei rispettivi cluster. Questi servizi sovrapposti vengono utilizzati per indirizzare i pod su più cluster o un sottoinsieme di pod su un singolo cluster.

  4. Dopo qualche minuto, verifica che le ServiceImports associate siano state create automaticamente dal controller dei servizi multi-cluster 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

    Questo 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 risorse, puoi eseguire il deployment di gateway e risorse HTTPRoute che fanno riferimento a queste ServiceImport solo in gke-west-1. Quando una risorsa HTTPRoute nel cluster di configurazione fa riferimento a queste ServiceImport come backend, il gateway può inoltrare il traffico a questi servizi indipendentemente dal cluster da cui vengono esportati.

Eseguire il deployment del gateway e della risorsa HTTPRoute

Dopo aver eseguito il deployment delle applicazioni, puoi configurare un gateway utilizzando la classe Gateway gke-l7-global-external-managed-mc. 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 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 routing (la mappa di URL è vuota)

    A questo punto, 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

    A questo punto, qualsiasi richiesta a GATEWAY_IP:80 genera una pagina predefinita che mostra il seguente messaggio: fault filter abort.

    Dopo il deployment, questa risorsa 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 dalla risorsa 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 dalla risorsa ServiceExport store-east-1 esistono solo nel cluster gke-east-1.
    • Le richieste a qualsiasi altro percorso vengono instradate ai pod store in uno dei due cluster, in base alla sua integrità, capacità e vicinanza al client richiedente.
    • Le richieste a GATEWAY_IP:80 generano 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 una risorsa ServiceExport e di un servizio in 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.

    Con questa configurazione vengono create nuove risorse:

    • 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
      • Il 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 routing nella mappa di URL:
      • La regola di routing store.example.com:
      • 1 host: store.example.com
      • Più matchRules per il routing ai nuovi servizi di backend

Il seguente diagramma mostra le risorse di cui hai eseguito il deployment in entrambi i cluster. Poiché gke-west-1 è il cluster di configurazione del gateway, è il cluster in cui il controller dei gateway monitora il gateway, le risorse HTTPRoute e le ServiceImport. Ogni cluster ha una risorsa ServiceImport store e un'altra risorsa ServiceImport specifica per quel cluster. Entrambe puntano agli stessi pod. In questo modo, la risorsa HTTPRoute può specificare 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 Multi-cluster Service in entrambi i cluster

Tieni presente che questo è un modello di risorse logiche, non 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.

Convalidare il deployment

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

  1. Verifica che il deployment del gateway e della risorsa HTTPRoute sia andato a buon fine esaminando lo stato e gli eventi del 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 seguenti con l'indirizzo IP che ricevi come output.

  3. Invia traffico al percorso principale del dominio. In questo modo, il traffico viene bilanciato del carico alla risorsa 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 vedere 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 traffico al percorso /west. In questo modo, il traffico viene instradato alla risorsa ServiceImport store-west-1 che ha solo pod in esecuzione sul cluster gke-west-1. Una risorsa ServiceImport specifica del cluster, come store-west-1, consente al proprietario di un'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"
}

Libera spazio

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. Disabilita 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 prober del 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 dell'applicazione (ad esempio, /health) utilizzando una HealthCheckPolicy.

Passaggi successivi