Esegui il deployment di un gateway multi-cluster interno

Questo documento ti guida attraverso un esempio pratico per eseguire il deployment di un gateway multi-cluster interno per instradare il traffico all'interno della 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 ingresso per le tue applicazioni, il che semplifica la gestione e migliora 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 in 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.

Esegui il deployment di un gateway multi-cluster interno tra regioni

Puoi eseguire il deployment di gateway multi-cluster che forniscono il bilanciamento del carico interno di livello 7 tra i cluster GKE in più regioni. Questi gateway utilizzano la 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 i client all'interno della rete VPC possono accedere. 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 può essere costituito da 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 l'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 un accesso più semplice:

    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 rete VPC. Assicurati che gli intervalli CIDR siano univoci 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 di servizio Kubernetes e risorse ServiceExport 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 della regione (store-west-1, store-east-1) da ogni cluster, tutti 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 ServiceImport: verifica che le risorse ServiceImport siano create in ogni cluster all'interno dello spazio dei nomi store. La creazione potrebbe richiedere alcuni minuti. bash kubectl get serviceimports --context gke-west1 -n store kubectl get serviceimports --context gke-east1 -n store Dovresti vedere store, store-west-1 e store-east-1 elencati (o le voci pertinenti in base alla propagazione).

Configura un gateway multi-regione interno

Definisci una risorsa Gateway che fa riferimento alla 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 ti consente di richiedere indirizzi IP temporanei in regioni specifiche o di utilizzare indirizzi IP statici preallocati.

  1. Per utilizzare 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 della 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 per l'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 sul percorso:
      • Il traffico /west va a store-west-1 ServiceImport.
      • Il traffico /east va a store-east-1 ServiceImport.
      • Tutto il resto del traffico, ad esempio /, va al ServiceImport generico store.
    • 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 type:Programmedandstatus: "True". Dovresti vedere gli indirizzi IP assegnati nel campo. You should see IP addresses assigned in the corrispondenti alle regioni specificate (ad es. uno perfield, corresponding to the regions you specified (e.g., one for e uno perand one for).

  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 comando seguente tenta di analizzare l'output JSON. Potresti dover 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 dovrebbe includere i VIP, ad esempio VIP1_WEST o VIP2_EAST.

  2. Invia richieste di test: da una VM client nella rete 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 i dettagli dell'applicazione store che indicano il pod di backend che ha gestito la richiesta, ad esempio cluster_name o zone.

Utilizza indirizzi IP statici

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

  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 contiene 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 presente 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 dalle subnet normali nelle regioni specificate.

  • Denominazione delle subnet dei cluster: ogni regione deve avere una subnet con lo stesso nome della subnet in cui risiede 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 stai richiedendo gli indirizzi devono avere la subnet my-custom-subnet. Se richiedi indirizzi nelle regioni us-east1 e us-centra1, in queste regioni deve esistere anche una subnet denominata my-custom-subnet.

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

La subnet solo proxy per il gateway interno non esiste

Se nel gateway interno viene visualizzato il seguente evento, significa che 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:

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 del messaggio:

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 potresti dover 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 un HealthCheckPolicy.

Passaggi successivi