Esegui il deployment di un gateway multi-cluster interno

Questo documento ti guida attraverso un esempio pratico per eseguire il deployment di un gateway multicluster interno per instradare il traffico all'interno della tua rete VPC a un'applicazione che viene eseguita 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 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 shopping online è di proprietà e gestito da team separati e viene implementato in una flotta di cluster GKE condivisi.

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

Prima di iniziare

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

  1. Esegui il deployment dei cluster GKE.

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

  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.

Esegui il deployment di un gateway multi-cluster interno in più regioni

Puoi eseguire il deployment di gateway multi-cluster che forniscono il bilanciamento del carico interno di livello 7 nei cluster GKE in più regioni. Questi gateway utilizzano GatewayClass gke-l7-cross-regional-internal-managed-mc. Questa GatewayClass esegue il provisioning di un bilanciatore del carico delle applicazioni interno tra regioni gestito da Google Cloud e che abilita VIP interni a cui possono accedere i client all'interno della rete VPC. Questi gateway possono essere esposti dai frontend nelle regioni di tua scelta, semplicemente utilizzando il gateway per richiedere indirizzi in queste regioni. Il VIP interno può essere un singolo indirizzo IP oppure indirizzi IP in più regioni, con un indirizzo IP per regione specificato nel gateway. Il traffico viene indirizzato al cluster GKE di backend integro più vicino in grado di gestire la richiesta.

Prerequisiti

  1. Configura il progetto e la shell configurando l'ambiente gcloud con il tuo ID progetto:

    export PROJECT_ID="YOUR_PROJECT_ID"
gcloud config set project ${PROJECT_ID}

  2. Crea cluster GKE in regioni diverse.

    Questo esempio utilizza due cluster: gke-west-1 in us-west1 e gke-east-1 in us-east1. Assicurati che l'API Gateway sia abilitata (--gateway-api=standard) e che i cluster siano registrati in un parco risorse.

    gcloud container clusters create gke-west-1 \
    --location=us-west1-a \
    --workload-pool=${PROJECT_ID}.svc.id.goog \
    --project=${PROJECT_ID} \
    --enable-fleet \
    --gateway-api=standard

gcloud container clusters create gke-east-1 \
    --location=us-east1-c \
    --workload-pool=${PROJECT_ID}.svc.id.goog \
    --project=${PROJECT_ID} \
    --enable-fleet \
    --gateway-api=standard

    Rinomina i contesti per accedervi più facilmente:

    gcloud container clusters get-credentials gke-west-1 \
  --location=us-west1-a \
  --project=${PROJECT_ID}

gcloud container clusters get-credentials gke-east-1 \
  --location=us-east1-c \
  --project=${PROJECT_ID}
kubectl config rename-context gke_${PROJECT_ID}_us-west1-a_gke-west-1 gke-west1
kubectl config rename-context gke_${PROJECT_ID}_us-east1-c_gke-east-1 gke-east1

  3. Abilita i servizi multi-cluster (MCS) e Ingress multi-cluster (MCI/gateway):

    gcloud container fleet multi-cluster-services enable --project=${PROJECT_ID}

# Set the config membership to one of your clusters (e.g., gke-west-1)
# This cluster will be the source of truth for multi-cluster Gateway and Route resources.
gcloud container fleet ingress enable \
    --config-membership=projects/${PROJECT_ID}/locations/us-west1/memberships/gke-west-1 \
    --project=${PROJECT_ID}

  4. Configura le subnet solo proxy. È necessaria una subnet solo proxy in ogni regione in cui si trovano i cluster GKE e in cui opererà il bilanciatore del carico. I bilanciatori del carico delle applicazioni interni tra regioni richiedono che lo scopo di questa subnet sia impostato su GLOBAL_MANAGED_PROXY.

    # Proxy-only subnet for us-west1
gcloud compute networks subnets create us-west1-proxy-only-subnet \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=us-west1 \
    --network=default \
    --range=10.129.0.0/23 # Choose an appropriate unused CIDR range

# Proxy-only subnet for us-east1
gcloud compute networks subnets create us-east1-proxy-only-subnet \
    --purpose=GLOBAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=us-east1 \
    --network=default \
    --range=10.130.0.0/23 # Choose an appropriate unused CIDR range

    Se non utilizzi la rete predefinita, sostituisci default con il nome della tua rete VPC. Assicurati che gli intervalli CIDR siano unici e non si sovrappongano.

  5. Esegui il deployment delle applicazioni demo, ad esempio store, in entrambi i cluster. Il file di esempio store.yaml di gke-networking-recipes crea uno spazio dei nomi store e un deployment.

    kubectl apply --context gke-west1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml
kubectl apply --context gke-east1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml

  6. Esporta i servizi da ogni cluster creando risorse Service e ServiceExport di Kubernetes in ogni cluster, in modo che i servizi siano rilevabili in tutto il parco risorse. L'esempio seguente esporta un servizio store generico e servizi specifici per regione (store-west-1, store-east-1) da ogni cluster, il tutto all'interno dello spazio dei nomi store.

    Applica a gke-west1:

    cat << EOF | kubectl apply --context gke-west1 -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 # Specific to this cluster
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-west-1 # Exporting the region-specific service
  namespace: store
EOF

    Applica a gke-east1:

    cat << EOF | kubectl apply --context gke-east1 -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 # Specific to this cluster
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-east-1 # Exporting the region-specific service
  namespace: store
EOF

  7. Controlla ServiceImports: Verifica che le risorse ServiceImport siano create in ogni cluster all'interno dello spazio dei nomi store. La loro creazione potrebbe richiedere alcuni minuti. bash kubectl get serviceimports --context gke-west1 -n store kubectl get serviceimports --context gke-east1 -n store Dovresti visualizzare store, store-west-1 e store-east-1 (o le voci pertinenti in base alla propagazione).

Configura un gateway multiregionale interno

Definisci una risorsa Gateway che fa riferimento a GatewayClass gke-l7-cross-regional-internal-managed-mc. Applica questo manifest al cluster di configurazione designato, ad esempio gke-west-1.

Il campo spec.addresses consente di richiedere indirizzi IP temporanei in regioni specifiche o di utilizzare indirizzi IP statici preassegnati.

  1. Per utilizzare gli indirizzi IP temporanei, salva il seguente manifest Gateway come cross-regional-gateway.yaml:

    # cross-regional-gateway.yaml
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: internal-cross-region-gateway
  namespace: store # Namespace for the Gateway resource
spec:
  gatewayClassName: gke-l7-cross-regional-internal-managed-mc
  addresses:
  # Addresses across regions. Address value is allowed to be empty or matching
  # the region name.
  - type: networking.gke.io/ephemeral-ipv4-address/us-west1
    value: "us-west1"
  - type: networking.gke.io/ephemeral-ipv4-address/us-east1
    value: "us-east1"
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute # Only allow HTTPRoute to attach

    L'elenco seguente definisce alcuni dei campi nel file YAML precedente:

    • metadata.namespace: lo spazio dei nomi in cui viene creata la risorsa Gateway, ad esempio store.
    • spec.gatewayClassName: il nome di GatewayClass. Deve essere gke-l7-cross-regional-internal-managed-mc.
    • spec.listeners.allowedRoutes.kinds: i tipi di oggetti Route che possono essere collegati, ad esempio HTTPRoute.
    • spec.addresses:
      • type: networking.gke.io/ephemeral-ipv4-address/REGION: richiede un indirizzo IP temporaneo.
      • value: specifica la regione dell'indirizzo, ad esempio "us-west1" o "us-east1".

  2. Applica il manifest al cluster di configurazione, ad esempio gke-west1:

    kubectl apply --context gke-west1 -f cross-regional-gateway.yaml

Collega HTTPRoute al gateway

Definisci le risorse HTTPRoute per gestire il routing del traffico e applicale al cluster di configurazione.

  1. Salva il seguente manifest HTTPRoute come store-route.yaml:

    # store-route.yaml
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-route
  namespace: store
  labels:
    gateway: cross-regional-internal
spec:
  parentRefs:
  - name: internal-cross-region-gateway
    namespace: store # Namespace where the Gateway is deployed
  hostnames:
  - "store.example.internal" # Hostname clients will use
  rules:
  - matches: # Rule for traffic to /west
    - path:
        type: PathPrefix
        value: /west
    backendRefs:
    - group: net.gke.io # Indicates a multi-cluster ServiceImport
      kind: ServiceImport
      name: store-west-1 # Targets the ServiceImport for the west cluster
      port: 8080
  - matches: # Rule for traffic to /east
    - path:
        type: PathPrefix
        value: /east
    backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store-east-1 # Targets the ServiceImport for the east cluster
      port: 8080
  - backendRefs: # Default rule for other paths (e.g., /)
    - group: net.gke.io
      kind: ServiceImport
      name: store # Targets the generic 'store' ServiceImport (any region)
      port: 8080

    L'elenco seguente definisce alcuni dei campi nel file YAML precedente:

    • spec.parentRefs: collega questa route a internal-cross-region-gateway nello spazio dei nomi store.
    • spec.hostnames: rappresenta il nome host utilizzato dai client per accedere al servizio.
    • spec.rules: definisce la logica di routing. Questo esempio utilizza il routing basato su percorso:
      • Il traffico /west viene indirizzato a ServiceImport store-west-1.
      • Il traffico /east viene indirizzato a ServiceImport store-east-1.
      • Tutto il resto del traffico, ad esempio /, viene indirizzato all'importazione di servizi store generica.
    • backendRefs:
      • group: net.gke.io e kind: ServiceImport hanno come target i servizi multi-cluster.

  2. Applica il manifest HTTPRoute al cluster di configurazione:

    kubectl apply --context gke-west1 -f store-route.yaml

Verifica lo stato del gateway e della route

  1. Controlla lo stato del gateway:

    kubectl get gateway internal-cross-region-gateway -n store -o yaml --context gke-west1

    Cerca una condizione con stato type:Programmatoand: "True". You should see IP addresses assigned in thestatus.addressesfield, corresponding to the regions you specified (e.g., one forus-west1and one forus-east1`).

  2. Controlla lo stato di HTTPRoute:

    kubectl get httproute store-route -n store -o yaml --context gke-west1

    Cerca una condizione in status.parents[].conditions con type: Accepted (o ResolvedRefs) e status: "True".

Conferma il traffico

Dopo aver assegnato gli indirizzi IP al gateway, puoi testare il traffico da una VM client che si trova all'interno della rete VPC e in una delle regioni, o in una regione che può connettersi all'indirizzo IP del gateway.

  1. Recupera gli indirizzi IP del gateway.

    Il seguente comando tenta di analizzare l'output JSON. Potrebbe essere necessario modificare jsonpath in base alla struttura esatta.

    kubectl get gateway cross-region-gateway -n store --context gke-west1 -o=jsonpath="{.status.addresses[*].value}".

    L'output di questo comando deve includere i VIP, ad esempio VIP1_WEST o VIP2_EAST.

  2. Invia richieste di test: Da una VM client nel tuo VPC:

    # Assuming VIP_WEST is an IP in us-west1 and VIP_EAST is an IP in us-east1
# Traffic to /west should ideally be served by gke-west-1
curl -H "host: store.example.internal" http://VIP_WEST/west
curl -H "host: store.example.internal" http://VIP_EAST/west # Still targets store-west-1 due to path

# Traffic to /east should ideally be served by gke-east-1
curl -H "host: store.example.internal" http://VIP_WEST/east # Still targets store-east-1 due to path
curl -H "host: store.example.internal" http://VIP_EAST/east

# Traffic to / (default) could be served by either cluster
curl -H "host: store.example.internal" http://VIP_WEST/
curl -H "host: store.example.internal" http://VIP_EAST/

    La risposta deve includere dettagli dell'applicazione store che indicano quale pod di backend ha gestito la richiesta, ad esempio cluster_name o zone.

Utilizza indirizzi IP statici

Anziché indirizzi IP temporanei, puoi utilizzare indirizzi IP interni statici preassegnati.

  1. Crea indirizzi IP statici nelle regioni che vuoi utilizzare:

    gcloud compute addresses create cross-region-gw-ip-west --region us-west1 --subnet default --project=${PROJECT_ID}
gcloud compute addresses create cross-region-gw-ip-east --region us-east1 --subnet default --project=${PROJECT_ID}

    Se non utilizzi la subnet predefinita, sostituisci default con il nome della subnet che ha l'indirizzo IP che vuoi allocare. Queste subnet sono subnet normali, non le subnet solo proxy.

  2. Aggiorna il manifest del gateway modificando la sezione spec.addresses nel file cross-regional-gateway.yaml:

    # cross-regional-gateway-static-ip.yaml
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: internal-cross-region-gateway # Or a new name if deploying alongside
  namespace: store
spec:
  gatewayClassName: gke-l7-cross-regional-internal-managed-mc
  addresses:
  - type: networking.gke.io/named-address-with-region # Use for named static IP
    value: "regions/us-west1/addresses/cross-region-gw-ip-west"
  - type: networking.gke.io/named-address-with-region
    value: "regions/us-east1/addresses/cross-region-gw-ip-east"
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

  3. Applica il manifest del gateway aggiornato.

    kubectl apply --context gke-west1 -f cross-regional-gateway.yaml

Considerazioni speciali per le subnet non predefinite

Tieni presenti le seguenti considerazioni quando utilizzi subnet non predefinite:

  • Stessa rete VPC:tutte le risorse create dall'utente, come indirizzi IP statici, subnet solo proxy e cluster GKE, devono risiedere nella stessa rete VPC.

  • Subnet di indirizzi:quando crei indirizzi IP statici per il gateway, questi vengono allocati da subnet regolari nelle regioni specificate.

  • Denominazione delle subnet del cluster:ogni regione deve avere una subnet con lo stesso nome della subnet in cui si trova il cluster di configurazione MCG.

    • Ad esempio, se il cluster di configurazione gke-west-1 si trova in projects/YOUR_PROJECT/regions/us-west1/subnetworks/my-custom-subnet, anche le regioni per cui richiedi gli indirizzi devono avere la subnet my-custom-subnet. Se richiedi indirizzi nelle regioni us-east1 e us-centra1, deve esistere anche una subnet denominata my-custom-subnet in queste regioni.

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

La subnet solo proxy per il gateway interno non esiste

Se sul gateway interno viene visualizzato il seguente evento, non esiste una subnet solo proxy per quella regione. Per risolvere il problema, esegui il deployment di una subnet solo proxy.

generic::invalid_argument: error ensuring load balancer: Insert: Invalid value for field 'resource.target': 'regions/us-west1/targetHttpProxies/gkegw-x5vt-default-internal-http-2jzr7e3xclhj'. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

Nessun upstream integro

Sintomo:

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

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