Deployment dei gateway

Autopilot Standard

Esegui il deployment delle risorse di Kubernetes Gateway per gestire il modo in cui il traffico esterno raggiunge le applicazioni all'interno di un singolo cluster Google Kubernetes Engine (GKE). La configurazione del gateway GKE fornisce un controllo flessibile e potente sul traffico in entrata, migliorando la scalabilità e l'affidabilità delle tue applicazioni. Ad esempio, il gateway GKE offre funzionalità di routing e scalabilità automatica ottimizzate. Queste funzionalità sono essenziali per l'erogazione online a bassa latenza, garantendo un'esperienza utente reattiva e contribuendo al contempo a controllare i costi.

Per eseguire il deployment dei gateway su più cluster o su un parco risorse, consulta Deployment di gateway multi-cluster. Per configurazioni specifiche del gateway, come il routing tra spazi dei nomi e la suddivisione del traffico HTTP, consulta le guide dell'utente dell'API Gateway.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

• Assicurati di avere un cluster Autopilot o Standard esistente. Per creare un nuovo cluster, vedi Crea un cluster Autopilot.

• Assicurati che il tuo account utente disponga del ruolo Certificate Manager Editor (roles/certificatemanager.editor) in modo da poter creare le mappe dei certificati necessarie.

Requisiti del GKE Gateway Controller

• L'API Gateway è supportata solo sui cluster nativi di VPC.
• Se utilizzi le GatewayClass a livello di regione o tra regioni, devi attivare una subnet solo proxy.
• Il componente aggiuntivo HttpLoadBalancing deve essere abilitato nel cluster.
• Se utilizzi Istio, devi eseguire l'upgrade a una delle seguenti versioni:
  • 1.15.2 o versioni successive
  • 1.14.5 o versioni successive
  • 1.13.9 o versioni successive.
• Se utilizzi un VPC condiviso, nel progetto host devi assegnare il ruolo Compute Network User al service account GKE per il progetto di servizio.

Restrizioni e limitazioni

Quando utilizzi il gateway GKE, tieni presente le seguenti limitazioni e restrizioni:

• Le classi GatewayClass di GKE supportano funzionalità diverse a seconda del bilanciatore del carico che utilizzano. Per scoprire di più sulle diverse funzionalità supportate da ogni GatewayClass, consulta Funzionalità di GatewayClass.

  Best practice:

  Per prestazioni ottimali, limita il numero di gateway a un massimo di 100. Il superamento di questo limite può influire sulle prestazioni o comportare un aumento della latenza.

• Il gateway GKE supporta solo il canale di rilascio standard dell'API Gateway.

• Il gateway GKE è sempre abilitato sui cluster Autopilot. Non puoi installare le CRD del canale di rilascio sperimentale dell'API Gateway sui cluster Autopilot.

• Non puoi utilizzare un FrontendConfig o un BackendConfig per configurare un gateway. Devi utilizzare una policy.

• Il gateway GKE si comporta in modo diverso da Ingress, in quanto il gateway non deduce i parametri del controllo di integrità. Se il tuo servizio non restituisce 200 per le richieste a GET / o se hai altri controlli di idoneità dei pod ottimizzati, devi configurare un HealthCheckPolicy per il tuo servizio.

• Non puoi specificare un numero di porta direttamente nel nome host (ad esempio, web.example.com:80) per il routing del traffico.

• Puoi visualizzare le risorse del bilanciatore del carico create da GKE per i gateway nella console Google Cloud , ma queste risorse non fanno riferimento al gateway o al cluster GKE a cui sono collegate.

• Non puoi generare automaticamente un certificato SSL gestito da Google con i gateway, ma puoi creare e fare riferimento manualmente a un certificato SSL gestito da Google. Per saperne di più, consulta Proteggi un gateway.

• HTTPRoute è l'unico tipo di route supportato. TCPRoute, UDPRoute e TLSRoute non sono supportate. Per visualizzare un elenco dei campi supportati dal controller GKE Gateway, consulta Funzionalità di GatewayClass.

• Le intestazioni di richiesta e risposta personalizzate con Gateway o i reindirizzamenti dei percorsi e le riscritture degli URL con Gateway sono disponibili solo su GKE versione 1.27 o successive.

• Per le intestazioni di richiesta e risposta personalizzate con reindirizzamenti di gateway e percorsi e riscritture di URL con gateway, GatewayClass gke-l7-gxlb non è supportato.

• Quando configuri le intestazioni delle richieste personalizzate HTTPRoute, la variabileGoogle Cloud origin_request_header non è supportata. Per configurare CORS, puoi utilizzare il tipo di filtro CORS.

• Si applicano le limitazioni del bilanciatore del carico delle applicazioni classicoGoogle Cloud al gateway GKE. Inoltre, non puoi configurare un'intestazione della risposta Host personalizzata nel servizio di backend.

• I reindirizzamenti dei percorsi e le riscritture degli URL si escludono a vicenda, non puoi utilizzare entrambi i filtri contemporaneamente nelle stesse regole.

• Il reindirizzamento del traffico a una porta diversa non è supportato con Cloud Load Balancing. Per visualizzare l'elenco dei campi supportati dal controller GKE Gateway, consulta Funzionalità di GatewayClass.

• Il gateway GKE non supporta caratteri jolly e URL dinamici. Le espressioni regolari non sono supportate con le GatewayClass gke-l7-gxlb e gke-l7-gxlb-mc. Per saperne di più, consulta Configura la corrispondenza delle espressioni regolari.

• Se specifichi un gateway con una classe di gateway esterno regionale, il controller esegue il provisioning di un indirizzo IP interno anziché dell'indirizzo esterno. Per scoprire come utilizzare un indirizzo denominato con il bilanciatore del carico delle applicazioni esterno regionale, consulta Esegui il deployment di un gateway esterno regionale.

• Gateway utilizza NEG autonomi per il provisioning dei gruppi di endpoint di rete. Per garantire che il controller del gateway riconcili correttamente la configurazione del bilanciatore del carico, non puoi modificare l'annotazione cloud.google.com/neg per un servizio che fa parte del gateway.

• Il gateway GKE non supporta il riferimento a un servizio a cui fa riferimento anche un GKE Ingress.

• Quando un gateway è configurato per eseguire il provisioning di un indirizzo IP, la modifica di Gateway.spec.gatewayClass non è supportata. Per assicurarti che il controller del gateway riconcili correttamente il bilanciatore del carico, elimina il gateway esistente ed esegui nuovamente il deployment del manifest con il valore gatewayClass aggiornato.

• L'annotazione networking.gke.io/app-protocols non è supportata. Per ottenere lo stesso risultato, utilizza invece il campo appProtocol.

• Se utilizzi il gateway GKE con external-dns e lo stato di integrità del gateway non è integro, per impostazione predefinita tutti i record DNS associati al gateway vengono eliminati dalle zone DNS.

  Best practice:

  Quando esegui external-dns, imposta il flag policy=upsert-only. Questa configurazione consente di evitare l'eliminazione dei record DNS esistenti.

• Se una porta viene rimossa da un servizio a cui il gateway GKE fa riferimento tramite una route, l'annotazione NEG autonomo sul servizio deve essere aggiornata anche sul controller NEG autonomo sul servizio per rimuovere la porta. In caso contrario, il controller NEG interromperà la sincronizzazione degli endpoint dei pod per questo servizio. Per maggiori dettagli, consulta Il controller NEG interrompe la gestione degli endpoint quando la porta viene rimossa dal servizio.

• I deployment che utilizzano gateway multi-cluster (MCG) che utilizzano cluster a livello di zona sono soggetti a interruzioni del servizio durante gli upgrade dei cluster. Questo problema si verifica perché un meccanismo di rilevamento dei gruppi di endpoint di rete (NEG) legacy potrebbe segnalare erroneamente zero backend quando il control plane del cluster di zona è temporaneamente non disponibile. È in corso una correzione a lungo termine. Per evitare questo single point of failure, utilizza i cluster GKE regionali con MCG.

Abilita l'API Gateway nel cluster

Prima di utilizzare le risorse Gateway in GKE, devi abilitare l'API Gateway nel cluster.

Prima di aggiornare un cluster GKE esistente per abilitare l'API Gateway, assicurati che i requisiti minimi siano soddisfatti prima di procedere con l'aggiornamento.

Per abilitare l'API Gateway su un cluster GKE esistente (Autopilot o Standard), utilizza il comando seguente. Questa operazione potrebbe richiedere fino a 45 minuti per la riconciliazione del cluster e l'installazione della CustomResourceDefinition.

gcloud container clusters update CLUSTER_NAME \
    --location=CLUSTER_LOCATION\
    --gateway-api=standard

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster esistente.

• CLUSTER_LOCATION: la regione o zona di Compute Engine del cluster.

Il flag --gateway-api=standard indica a GKE di installare le CRD del canale standard dell'API Gateway con il cluster.

Verifica il cluster

Dopo aver creato o eseguito l'upgrade del cluster, il controller GKE Gateway installa automaticamente le GatewayClass. Potrebbero essere necessari alcuni minuti prima che il controller riconosca i CRD e installi le GatewayClass.

1. Verifica che l'API Gateway sia abilitata nel control plane GKE:

   gcloud container clusters describe CLUSTER_NAME \
     --location=CLUSTER_LOCATION \
     --format json
   

   L'output è simile al seguente. Se questo output è vuoto, esegui nuovamente il comando di aggiornamento del cluster.

   "networkConfig": {
     ...
     "gatewayApiConfig": {
       "channel": "CHANNEL_STANDARD"
     },
     ...
   },
   

2. Verifica che le GatewayClass siano installate nel cluster:

   kubectl get gatewayclass
   

   L'output è simile al seguente:

   NAME                             CONTROLLER                  ACCEPTED   AGE
   gke-l7-global-external-managed   networking.gke.io/gateway   True       16h
   gke-l7-regional-external-managed networking.gke.io/gateway   True       16h
   gke-l7-gxlb                      networking.gke.io/gateway   True       16h
   gke-l7-rilb                      networking.gke.io/gateway   True       16h
   

Per comprendere le funzionalità di ogni GatewayClass, consulta Funzionalità di GatewayClass.

Solo le GatewayClass a cluster singolo vengono installate automaticamente. Per installare e utilizzare le GatewayClass multi-cluster per il bilanciamento del carico multi-cluster interno ed esterno, consulta Abilitazione dei gateway multi-cluster.

Esegui il deployment di un gateway interno

Un gateway interno espone le applicazioni raggiungibili solo dall'interno del VPC o dalle reti connesse al VPC.

Esegui il deployment di un gateway interno regionale

L'esempio seguente mostra come eseguire il deployment di un gateway interno regionale che consente una comunicazione efficiente e sicura tra i servizi all'interno di una regione geografica specifica.

Configura una subnet solo proxy

Devi configurare una subnet solo proxy prima di creare un gateway che utilizza un bilanciatore del carico delle applicazioni interno. Ogni regione di un VPC in cui utilizzi i bilanciatori del carico delle applicazioni interni deve avere una subnet solo proxy. Questa subnet fornisce indirizzi IP interni ai proxy del bilanciatore del carico.

1. Crea una subnet solo proxy:

   gcloud compute networks subnets create SUBNET_NAME \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=COMPUTE_REGION \
       --network=VPC_NETWORK_NAME \
       --range=CIDR_RANGE
   

   Se esegui il deployment di una risorsa Gateway regionale (gke-l7-rilb o gke-l7-regional-external-managed) su un cluster IPv6 a stack singolo, devi configurare una subnet solo proxy a doppio stack con il flag --stack-type=IPV4_IPV6. Questo requisito si applica alle risorse Gateway IPv4 e IPv6, in modo che i proxy del bilanciatore del carico possano comunicare con i pod di backend IPv6. Le subnet solo proxy IPv6 a stack singolo (create con il flag --stack-type=IPV6_ONLY) non sono supportate e la rete VPC deve avere un intervallo IPv6 ULA interno abilitato (con il flag --enable-ula-internal-ipv6):

   gcloud compute networks subnets create SUBNET_NAME \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=COMPUTE_REGION \
       --network=VPC_NETWORK_NAME \
       --range=CIDR_RANGE \
       --stack-type=IPV4_IPV6
   

   Nota: non specificare il flag --ipv6-access-type durante la creazione o l'aggiornamento di una subnet REGIONAL_MANAGED_PROXY. Compute Engine assegna automaticamente un prefisso IPv6 ULA (Unique Local Address) /64 interno e rifiuta il flag --ipv6-access-type sulle subnet solo proxy.

   Sostituisci quanto segue:

   • SUBNET_NAME: il nome della subnet solo proxy.
   • COMPUTE_REGION: la regione della subnet solo proxy.
   • VPC_NETWORK_NAME: il nome della rete VPC in cui crei questa subnet solo proxy. Assicurati che sia la stessa rete VPC in cui si trova il cluster GKE e in cui esegui il deployment del gateway. Questo è importante per una comunicazione senza interruzioni tra il bilanciatore del carico e i servizi di backend.
   • CIDR_RANGE: l'intervallo di indirizzi IPv4 principale della subnet. Questo valore deve essere un intervallo CIDR IPv4 anche per una subnet solo proxy a doppio stack (IPV4_IPV6), perché Compute Engine alloca automaticamente l'intervallo di indirizzi IPv6. Devi utilizzare una subnet mask non più lunga di /26 in modo che siano disponibili almeno 64 indirizzi IPv4 per i proxy nella regione. La subnet mask consigliata è /23.

2. Verifica la subnet solo proxy:

   gcloud compute networks subnets describe SUBNET_NAME \
       --region=COMPUTE_REGION
   

   L'output è simile al seguente (per una subnet dual-stack solo proxy, l'output include i campi internalIpv6Prefix, ipv6AccessType e ipv6GceEndpoint):

   ...
   gatewayAddress: 10.1.1.1
   internalIpv6Prefix: fd20:1d14:f522:2:0:0:0:0/64
   ipCidrRange: 10.1.1.0/24
   ipv6AccessType: INTERNAL
   ipv6GceEndpoint: VM_AND_FR
   kind: compute#subnetwork
   name: proxy-subnet
   network: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/default
   privateIpGoogleAccess: false
   privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS
   purpose: REGIONAL_MANAGED_PROXY
   region: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION
   role: ACTIVE
   selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION/subnetworks/proxy-subnet
   stackType: IPV4_IPV6
   state: READY
   

Crea un gateway

Una risorsa Gateway rappresenta un piano dati che instrada il traffico in Kubernetes. Un Gateway può rappresentare molti tipi diversi di bilanciamento del carico e routing a seconda della GatewayClass da cui deriva. Per scoprire di più sulla risorsa Gateway, consulta la descrizione della risorsa Gateway o la specifica dell'API.

In questo caso, l'amministratore del cluster GKE vuole creare un gateway che possa essere utilizzato da team diversi per esporre le proprie applicazioni internamente. L'amministratore esegue il deployment del gateway, mentre i team delle applicazioni eseguono il deployment delle route in modo indipendente e le collegano al gateway.

1. Salva il seguente manifest del gateway in un file denominato gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
      name: internal-http
   spec:
     # Specify an existing GatewayClass.
     gatewayClassName: gke-l7-rilb
     listeners:
     # Listen for HTTP traffic on port 80.
     - name: http
       protocol: HTTP
       port: 80
   

   Questo manifest include i seguenti campi:

   • gatewayClassName: gke-l7-rilb: specifica la classe GatewayClass da cui deriva questo gateway. gke-l7-rilb corrisponde al bilanciatore del carico delle applicazioni interno.
   • port: 80: specifica che il gateway espone solo la porta 80 per l'ascolto del traffico HTTP.

   Questo gateway è configurato per gestire il traffico HTTP solo sulla porta 80. Per impostazione predefinita, non supporta HTTPS (porta 443) e, se tenti di connetterti tramite HTTPS, la richiesta potrebbe non riuscire.

2. Esegui il deployment del gateway nel tuo cluster:

   kubectl apply -f gateway.yaml
   

3. Verifica che il deployment del gateway sia stato eseguito correttamente. Il deployment di tutte le risorse potrebbe richiedere alcuni minuti.

   kubectl describe gateways.gateway.networking.k8s.io internal-http
   

   L'output è simile al seguente:

   Name:         internal-http
   Namespace:    default
   Spec:
     Gateway Class Name:  gke-l7-rilb
     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:  192.168.1.14
      Conditions:
        Last Transition Time:  2025-03-19T19:53:46Z
        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:  2025-03-19T19:53:46Z
        Message:
        Observed Generation:   1
        Reason:                Accepted
        Status:                True
        Type:                  Accepted
        Last Transition Time:  2025-03-19T19:53:46Z
        Message:
        Observed Generation:   1
        Reason:                Programmed
        Status:                True # Indicates that the Gateway is ready.
        Type:                  Programmed
        Last Transition Time:  2025-03-19T19:53:46Z
        Message:               The OSS Gateway API has altered the "Ready" condition semantics and reserved it 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
        Last Transition Time:  2025-03-19T19:53:46Z
        Message:
        Observed Generation:   1
        Reason:                Healthy
        Status:                True
        Type:                  networking.gke.io/GatewayHealthy
   Events:
     Type    Reason  Age                From                       Message
     ----    ------  ----               ----                       -------
     Normal  ADD     92s                networking.gke.io/gateway  test/internal-http
     Normal  UPDATE  45s (x3 over 91s)  networking.gke.io/gateway  test/internal-http
     Normal  SYNC    45s                networking.gke.io/gateway  SYNC on test/internal-http was a success
   

   In questo output, lo stato di True per la condizione Programmed indica che il gateway è pronto.

   A questo punto, nel cluster è stato eseguito il deployment di un gateway che ha eseguito il provisioning di un bilanciatore del carico e di un indirizzo IP. Tuttavia, il gateway non ha route, quindi non sa come inviare il traffico ai backend. Senza route, tutto il traffico va a un backend predefinito, che restituisce un errore HTTP 404. Successivamente, esegui il deployment di un'applicazione e delle route, che indicano al gateway come raggiungere i backend dell'applicazione.

Esegui il deployment delle applicazioni demo

I team delle applicazioni possono eseguire il deployment delle applicazioni e delle route indipendentemente dal deployment dei gateway. In alcuni casi, il team dell'applicazione potrebbe voler possedere anche il gateway ed eseguirne il deployment autonomamente come risorsa dedicata alle proprie applicazioni. Consulta Associazione delle route per i diversi modelli di proprietà di gateway e route. In questo esempio, tuttavia, il team del negozio esegue il deployment della propria applicazione e di una risorsa HTTPRoute associata per esporre l'app tramite il gateway internal-http creato nella sezione precedente.

La risorsa HTTPRoute ha molti campi configurabili per la corrispondenza del traffico. Per una spiegazione dei campi di HTTPRoute, consulta la specifica dell'API.

1. Esegui il deployment dell'applicazione dello store (deployment store-v1, store-v2 e store-german) nel tuo cluster:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
   

   Vengono creati tre deployment e tre servizi denominati store-v1, store-v2 e store-german.

2. Verifica che il deployment dell'applicazione sia andato a buon fine:

   kubectl get pod
   

   L'output è simile al seguente dopo l'esecuzione dell'applicazione:

   NAME                        READY   STATUS    RESTARTS   AGE
   store-german-66dcb75977-5gr2n   1/1     Running   0          38s
   store-v1-65b47557df-jkjbm       1/1     Running   0          14m
   store-v2-6856f59f7f-sq889       1/1     Running   0          14m
   

3. Verifica che sia stato eseguito il deployment dei servizi:

   kubectl get service
   

   L'output mostra un servizio per ogni deployment dello store:

   NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
   store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
   store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
   store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s
   

Esegui il deployment di HTTPRoute

Le risorse Route definiscono regole specifiche per il protocollo per mappare il traffico da un gateway ai backend Kubernetes. La risorsa HTTPRoute esegue la corrispondenza e il filtro del traffico HTTP e HTTPS ed è supportata da tutte le GatewayClass gke-l7.

In questa sezione esegui il deployment di una risorsa HTTPRoute, che programma il gateway con le regole di instradamento necessarie per raggiungere l'applicazione dello store.

1. Salva il seguente manifest HTTPRoute in un file denominato store-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: store
   spec:
     # Attach the HTTPRoute to a Gateway.
     parentRefs:
     - kind: Gateway
       name: internal-http
     # Route requests that have `store.example.com` in the Host header.
     hostnames:
     - "store.example.com"
     rules:
     # Send requests with the `env: canary` header to the `store-v2` Service.
     - matches:
       - headers:
         - name: env
           value: canary
       backendRefs:
       - name: store-v2
         port: 8080
     # Send requests with `/de` in the path to the `store-german` Service.
     - matches:
       - path:
           value: /de
       backendRefs:
       - name: store-german
         port: 8080
     # Send unmatched requests to the store-v1 Service.
     - backendRefs:
       - name: store-v1
         port: 8080
   

2. Esegui il deployment di HTTPRoute nel tuo cluster:

   kubectl apply -f store-route.yaml
   

   La risorsa HTTPRoute store è associata al gateway internal-http utilizzando la proprietà parentRefs. Queste regole di instradamento sono configurate sul bilanciatore del carico sottostante, come mostrato in questo diagramma:

   

   Queste regole di instradamento elaborano il traffico HTTP nel seguente modo:

   • Il traffico verso store.example.com/de viene indirizzato al servizio store-german.
   • Il traffico verso store.example.com con l'intestazione HTTP "env: canary" va al servizio store-v2.
   • Il traffico rimanente verso store.example.com va al servizio store-v1.

3. Verifica che sia stato eseguito il deployment della risorsa HTTPRoute:

   kubectl describe httproute store
   

   L'output è simile al seguente:

   Name:         store
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  gateway.networking.k8s.io/v1
   Kind:         HTTPRoute
   # Multiple lines are omitted here.
   Spec:
     Hostnames:
       store.example.com
     Parent Refs:
       Group:  gateway.networking.k8s.io
       Kind:   Gateway
       Name:   internal-http
     Rules:
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v1
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v2
         Port:    8080
         Weight:  1
       Matches:
         Headers:
           Name:   env
           Type:   Exact
           Value:  canary
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-german
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /de
   Status:
     Parents:
       Conditions:
         Last Transition Time:  2022-11-01T04:18:52Z
         Message:
         Reason:                Accepted
         Status:                True
         Type:                  Accepted
         Last Transition Time:  2022-11-01T04:18:52Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   internal-http
   Events:
     Type    Reason  Age                From                   Message
     ----    ------  ----               ----                   -------
     Normal  ADD     24m                sc-gateway-controller  default/store
     Normal  SYNC    16m (x4 over 23m)  sc-gateway-controller  Bind of HTTPRoute "default/store" to ParentRef {Group:       gateway.networking.k8s.io",
     # Multiple lines are omitted here.
   

4. Verifica che la risorsa HTTPRoute sia associata al gateway:

   kubectl describe gateway
   

   L'output è simile al seguente:

   Name:         internal-http
   Namespace:    default
   Labels:       <none>
   <...>
   Status:
     Addresses:
       Type:   IPAddress
       Value:  10.128.15.203
     Conditions:
       Last Transition Time:  2022-11-01T03:47:01Z
       Message:
       Reason:                Scheduled
       Status:                True
       Type:                  Scheduled
       Last Transition Time:  2022-11-01T03:47:01Z
       Message:
       Reason:                Ready
       Status:                True
       Type:                  Ready
     Listeners:
       Attached Routes:  1
       Conditions:
         Last Transition Time:  2022-11-01T03:47:01Z
         Message:
         Reason:                Ready
         Status:                True
         Type:                  Ready
       Name:                    http
       Supported Kinds:
         Group:  gateway.networking.k8s.io
         Kind:   HTTPRoute
         <...>
   

Invia traffico alla tua applicazione

Ora che il gateway, la route e l'applicazione sono stati sottoposti a deployment nel cluster, puoi passare il traffico all'applicazione. Il gateway è configurato per gestire il traffico HTTP solo sulla porta 80. Le richieste effettuate con HTTPS potrebbero non riuscire, a meno che TLS non sia stato configurato separatamente.

1. Recupera l'indirizzo IP dal gateway in modo da poter inviare traffico alla tua applicazione:

   kubectl get gateways.gateway.networking.k8s.io internal-http -o=jsonpath="{.status.addresses[0].value}"
   

   L'output è un indirizzo IP.

2. Invia il traffico a questo indirizzo IP da un'istanza di macchina virtuale (VM) con connettività al cluster. Questo è necessario perché il gateway ha un indirizzo IP interno ed è accessibile solo dall'interno della tua rete VPC. Poiché internal-http è un bilanciatore del carico regionale, la VM client deve trovarsi nella stessa regione del cluster GKE.

   Crea una VM di test nella stessa rete VPC e nella stessa regione:

   gcloud compute instances create test-vm \
       --zone=COMPUTE_ZONE \
       --network=VPC_NETWORK_NAME
   

   Connettiti alla VM utilizzando SSH:

   gcloud compute ssh test-vm --zone=COMPUTE_ZONE
   

   Dalla shell della VM, invia una richiesta a store.example.com:

   curl http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v
   

   Sostituisci GATEWAY_IP_ADDRESS con l'indirizzo IP del passaggio precedente.

   L'output dell'app demo mostra informazioni sulla località in cui l'app è in esecuzione:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v1-84b47c7f58-pmgmk",
     "pod_name_emoji": "💇🏼‍♀️",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:31:17",
     "zone": "ZONE_NAME"
   }
   

3. Testa la corrispondenza del percorso andando alla versione tedesca del servizio del negozio all'indirizzo store.example.com/de:

   curl http://store.example.com/de --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v
   

   L'output conferma che la richiesta è stata gestita da un pod store-german:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "Gutentag!", 
     "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
     "pod_name": "store-german-5cb6474c55-lq5pl", 
     "pod_name_emoji": "🧞‍♀",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:35:37",
     "zone": "ZONE_NAME"
   }
   

4. Infine, utilizza l'intestazione HTTP env: canary per inviare il traffico alla versione canary del servizio store:

   curl -H "env: canary" http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v
   

   L'output conferma che la richiesta è stata gestita da un pod store-v2:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v2", 
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v2-5788476cbd-s9thb", 
     "pod_name_emoji": "🦰",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:38:26",
     "zone": "ZONE_NAME"
   }
   

Esegui il deployment di un gateway esterno

Un gateway esterno espone le applicazioni raggiungibili da internet o da reti esterne alla tua rete VPC. Il deployment è simile a un deployment di un gateway interno, ad eccezione del fatto che devi proteggere le tue applicazioni perché il gateway è accessibile alla rete internet pubblica.

Hai due opzioni per creare un gateway esterno: un gateway esterno globale o un gateway esterno regionale.

• Gateway esterno regionale: questo gateway utilizza un indirizzo IP regionale come frontend del gateway. Il comportamento di questo gateway dipende dal livello di Network Service Tiers selezionato:
  • Se scegli il livello di servizio di rete Standard (predefinito), l'indirizzo IP regionale viene annunciato solo nella regione Compute Google Cloud locale in cui è stato eseguito il deployment del gateway esterno regionale. I client che inviano traffico a questo indirizzo IP vengono instradati dal proprio ISP locale e tramite la rete internet pubblica prima di raggiungere la regione Google in cui viene annunciato l'indirizzo IP.
  • Se scegli il livello Premium di Network Service Tiers, l'indirizzo IP regionale viene annunciato nell'intera rete globale di Google. Ciò significa che il traffico client entra nella rete backbone globale di alta qualità di Google in un punto di peering perimetrale di Google il più vicino possibile al client, anche se la destinazione è un indirizzo IP regionale. Questa località riduce notevolmente la latenza e migliora le prestazioni riducendo al minimo la distanza percorsa dal traffico sulla rete internet pubblica.
• Gateway esterno globale: questo gateway utilizza un indirizzo IP globale (o un indirizzo IP anycast) come frontend del gateway. Questo indirizzo IP viene annunciato in tutte le regioni Google Cloud Compute. I client che inviano traffico a questo indirizzo IP anycast vengono indirizzati alla località Google più vicina in cui viene annunciato l'indirizzo IP. Il gateway esterno globale è disponibile solo nel livello Premium di Network Service Tiers.

Esegui il deployment di un gateway esterno regionale

L'esempio seguente mostra come esporre un'applicazione di un negozio con più certificati collegati al gateway esterno regionale utilizzando certificati autogestiti e un HTTPRoute.

Crea una subnet proxy per il gateway regionale

Devi configurare una subnet solo proxy prima di creare un gateway che utilizza un bilanciatore del carico delle applicazioni esterno regionale. Ogni regione di un VPC in cui utilizzi il bilanciatore del carico delle applicazioni esterno regionale deve avere una subnet external_managed_proxy. Questa subnet fornisce indirizzi IP interni ai proxy del bilanciatore del carico.

Crea un certificato per proteggere il traffico dei client

Puoi utilizzare un certificato emesso e convalidato dalla tua autorità di certificazione (CA) o creare un certificato autofirmato. Per saperne di più su come creare un certificato, consulta Archivia un certificato in un secret di Kubernetes.

Per proteggere il traffico tra i client e il gateway regionale, puoi utilizzare i seguenti metodi:

• Certificati di Certificate Manager gestiti da Google o autogestiti
• Certificati SSL a livello di regione autogestiti
• Secret Kubernetes

I certificati SSL CertificateMap o gestiti da Google non sono supportati con i gateway a livello di regione.

Per saperne di più, consulta Certificati e bilanciatori del carico Google Cloud .

Crea un gateway HTTP(S) esterno regionale

1. Crea un indirizzo IP statico regionale per il bilanciatore del carico esterno.

   gcloud compute addresses create IP_ADDRESS_NAME \
     --region=COMPUTE_REGION \
     --network-tier=STANDARD
   

   Sostituisci quanto segue:

   • IP_ADDRESS_NAME: il nome del nuovo indirizzo IP statico.
   • COMPUTE_REGION: la regione di Compute Engine in cui è in esecuzione il cluster.

2. Crea un gateway del bilanciatore del carico delle applicazioni esterno regionale utilizzando un certificato autogestito come segue e salva il manifest come regional-gateway.yaml:

     kind: Gateway
     apiVersion: gateway.networking.k8s.io/v1
     metadata:
       name: external-regional-http
     spec:
       # Name of an existing GatewayClass.
       gatewayClassName: gke-l7-regional-external-managed
       # Listen for HTTPS traffic on port 443
       listeners:
       - name: https
         protocol: HTTPS
         port: 443
         tls:
           # Terminate the TLS session with the client at the Gateway.
           mode: Terminate
           # Certificates for the Gateway to use to create a new TLS session.
           certificateRefs:
           - name: store-example-com
       # The name of the static IP address of the external load balancer.
       # You can also use the `IPAddress` type to specify the actual IP address.
       addresses:
       - type: NamedAddress
         value: IP_ADDRESS_NAME
   

3. Applica il manifest regional-gateway:

     kubectl apply -f regional-gateway.yaml
   

4. Verifica la configurazione.

     kubectl get gateway
   

   L'output è simile al seguente:

   NAME            CLASS                              ADDRESS         READY   AGE
   external-http   gke-l7-regional-external-managed   35.118.32.224   True    49s
   

   Per maggiori dettagli, utilizza un comando describe:

   kubectl describe gateway
   

   L'output è simile al seguente:

   Name:         external-regional-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Gateway Class Name:  gke-l7-regional-external-managed
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      https
       Port:      443
       Protocol:  HTTPS
       Tls:
         Certificate Refs:
           Group:
           Kind:   Secret
           Name:   store-example-com
         Mode:     Terminate
     ...
   

Esegui il deployment delle applicazioni demo

I team delle applicazioni possono eseguire il deployment delle applicazioni e delle route indipendentemente dal deployment dei gateway. In alcuni casi, il team dell'applicazione potrebbe voler possedere anche il gateway ed eseguirne il deployment autonomamente come risorsa dedicata alle proprie applicazioni. Consulta Associazione delle route per i diversi modelli di proprietà di gateway e route. In questo esempio, il team del negozio esegue il deployment della propria applicazione e di una risorsa HTTPRoute associata per esporre l'app tramite il gateway external-http creato nella sezione precedente.

Per saperne di più sui campi HTTPRoute, consulta la specifica dell'API.

1. Esegui il deployment dell'applicazione di esempio nel tuo cluster:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
   

   Questa applicazione di esempio crea tre deployment e tre servizi denominati store-v1, store-v2 e store-german.

2. Verifica che il deployment dell'applicazione sia andato a buon fine:

   kubectl get pod
   

   L'output è simile al seguente:

   NAME                            READY   STATUS    RESTARTS   AGE
   store-german-66dcb75977-5gr2n   1/1     Running   0          38s
   store-v1-65b47557df-jkjbm       1/1     Running   0          14m
   store-v2-6856f59f7f-sq889       1/1     Running   0          14m
   

3. Verifica che il deployment dei servizi sia andato a buon fine:

   kubectl get service
   

   L'output è simile al seguente:

   NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
   store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
   store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
   store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s
   

Crea una risorsa HTTPRoute

Le risorse Route definiscono regole specifiche per il protocollo per mappare il traffico da un gateway ai backend Kubernetes. La risorsa HTTPRoute esegue la corrispondenza e il filtro del traffico HTTP e HTTPS ed è supportata da tutte le GatewayClass gke-l7-*.

In questa sezione eseguirai il deployment di una risorsa HTTPRoute, che configura il gateway con le regole di instradamento necessarie per raggiungere l'applicazione di esempio.

1. Salva il seguente manifest in un file denominato store-route-external.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: store-external
   spec:
     parentRefs:
     # Bind the route to the 'external-http' Gateway.
     - kind: Gateway
       name: external-http
     hostnames:
     - "store.example.com"
     rules:
     # Default rule for store.example.com that sends traffic to the store-v1 service.
     - backendRefs:
       - name: store-v1
         port: 8080
     # Match requests with the "env: canary" header and send them to the store-v2 service.
     - matches:
       - headers:
         - name: env
           value: canary
       backendRefs:
       - name: store-v2
         port: 8080
     # Match requests with the path "/de" and sends them to the store-german service.
     - matches:
       - path:
           value: /de
       backendRefs:
       - name: store-german
         port: 8080
   

   Questo manifest descrive una risorsa HTTPRoute che fa riferimento al gateway external-http.

2. Applica il manifest al tuo cluster:

   kubectl apply -f store-route-external.yaml
   

   La risorsa HTTPRoute store è associata al gateway external-http utilizzando la proprietà parentRefs. Il seguente diagramma mostra le regole di instradamento configurate sul bilanciatore del carico sottostante:

   

   Le regole di instradamento elaborano il traffico HTTP come segue:

   • Il traffico verso store.example.com/de viene instradato al servizio store-german.
   • Il traffico verso store.example.com con l'intestazione HTTP "env: canary" viene instradato al servizio store-v2.
   • Il traffico rimanente verso store.example.com viene instradato al servizio store-v1.

3. Verifica che sia stato eseguito il deployment della risorsa HTTPRoute:

   kubectl describe httproute store-external
   

   L'output è simile al seguente:

   Name:         store-external
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  gateway.networking.k8s.io/v1
   Kind:         HTTPRoute
   # Multiple lines are omitted here.
   Spec:
     Hostnames:
       store.example.com
     Parent Refs:
       Group:  gateway.networking.k8s.io
       Kind:   Gateway
       Name:   external-http
     Rules:
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v1
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v2
         Port:    8080
         Weight:  1
       Matches:
         Headers:
           Name:   env
           Type:   Exact
           Value:  canary
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-german
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /de
   Status:
     Parents:
       # This section shows the status of this route in relation to each Gateway attached.
       Conditions:
         Last Transition Time:  2022-11-01T05:42:31Z
         Message:
         Reason:                Accepted
         Status:                True # Means that the Gateway has validated and accepted this route's configuration.
         Type:                  Accepted
         Last Transition Time:  2022-11-01T05:43:18Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   external-http
   Events:
     Type     Reason  Age    From                   Message
     ----     ------  ----   ----                   -------
     Normal   ADD     2m48s  sc-gateway-controller  default/store-external
     Normal  SYNC  61s (x3 over 2m27s)  sc-gateway-controller  Bind of HTTPRoute "default/store-external" to ParentRef Group:       "gateway.networking.k8s.io",
     ...
   

4. Verifica che la risorsa HTTPRoute sia associata al gateway:

   kubectl describe gateway external-http
   

   L'output è simile al seguente:

   Name:         external-http
   Namespace:    default
   Labels:       <none>
   # Multiple lines are omitted here.
   Status:
     Addresses:
       Type:   IPAddress
       Value:  34.149.207.45
     Conditions:
       Last Transition Time:  2022-11-01T05:37:21Z
       Message:
       Reason:                Scheduled
       Status:                True
       Type:                  Scheduled
       Last Transition Time:  2022-11-01T05:43:18Z
       Message:
       Reason:                Ready
       Status:                True
       Type:                  Ready
     Listeners:
       Attached Routes:  1
       Conditions:
         Last Transition Time:  2022-11-01T05:43:18Z
         Message:
         Reason:                Ready
         Status:                True
         Type:                  Ready
       Name:                    https
       Supported Kinds:
         Group:  gateway.networking.k8s.io
         Kind:   HTTPRoute
         # Multiple lines are omitted here.
   

Invia traffico alla tua applicazione

Ora che il gateway, la route e l'applicazione sono stati sottoposti a deployment nel cluster, puoi passare il traffico all'applicazione.

1. Ottieni l'indirizzo IP del gateway:

   kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}"
   

   L'output è un indirizzo IP.

2. Crea una VM:

   gcloud cloud-shell ssh
   

3. Invia il traffico all'indirizzo IP del gateway dalla VM. Devi impostare l'intestazione host manualmente perché non sei il proprietario del nome host example.com.

   curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   Sostituisci GATEWAY_IP_ADDRESS con l'indirizzo IP del gateway del passaggio precedente.

   cacert.pem: il file del certificato che hai generato. Devi salvare questo file sul computer che utilizzi per connetterti al gateway.

   L'output mostra le informazioni dell'app demo sulla località in cui è in esecuzione l'app:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v1-84b47c7f58-pmgmk",
     "pod_name_emoji": "💇🏼‍♀️",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:31:17",
     "zone": "us-central1-a"
   }
   

4. Testa la corrispondenza del percorso andando alla versione tedesca del servizio store all'indirizzo store.example.com/de:

   curl https://store.example.com/de --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   L'output conferma che la richiesta è stata gestita da un pod store-german:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "Gutentag!",
     "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
     "pod_name": "store-german-5cb6474c55-lq5pl",
     "pod_name_emoji": "🧞‍♀",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:35:37",
     "zone": "us-central1-a"
   }
   

5. Invia il traffico alla versione canary del servizio store utilizzando l'intestazione HTTP env: canary:

   curl -H "env: canary" https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   L'output conferma che la richiesta è stata gestita da un pod store-v2:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v2",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v2-5788476cbd-s9thb",
     "pod_name_emoji": "👩🏿",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:38:26",
     "zone": "us-central1-a"
   }
   

Esegui il deployment di un gateway esterno globale

L'esempio seguente mostra come esporre un'applicazione di un negozio con più certificati collegati al gateway esterno globale e raggruppati in una mappa dei certificati utilizzando Certificate Manager e un HTTPRoute.

Crea una mappa dei certificati

Google consiglia di utilizzare Certificate Manager per gestire i certificati quando hai bisogno di 15 o più certificati per gateway o se devi utilizzare certificati con caratteri jolly.

Puoi anche proteggere il gateway esterno utilizzando i secret di Kubernetes o i certificati SSL gestiti da Google. Per saperne di più, consulta Sicurezza del gateway.

In questa sezione, creerai i certificati utilizzando Certificate Manager per proteggere le applicazioni in esecuzione sul cluster.

1. Abilita l'API Certificate Manager:

   gcloud services enable certificatemanager.googleapis.com
   

2. Crea una mappa dei certificati:

   gcloud beta certificate-manager maps create store-example-com-map
   

3. Carica il certificato e le chiavi gestiti da Google in un certificato:

   gcloud beta certificate-manager certificates create store-example-com-cert \
       --certificate-file="CERTIFICATE_FILE" \
       --private-key-file="PRIVATE_KEY_FILE"
   

   Sostituisci quanto segue:

   • CERTIFICATE_FILE: il nome del file del certificato. Il file deve avere l'estensione .pem. Ad esempio cert.pem.
   • PRIVATE_KEY_FILE: il nome del file della chiave privata.

   Per saperne di più, consulta Crea una chiave privata e un certificato.

4. Crea un CertificateMapEntry che assegna il certificato alla mappa dei certificati:

   gcloud beta certificate-manager maps entries create store-example-com-map-entry \
       --map=store-example-com-map \
       --hostname=store.example.com \
       --certificates=store-example-com-cert
   

Per scoprire come proteggere un gateway utilizzando altre origini per i certificati, ad esempio i secret di Kubernetes o i certificati SSL, consulta Proteggi un gateway.

Crea un gateway

Una risorsa Gateway rappresenta un piano dati che instrada il traffico in Kubernetes. Un Gateway può rappresentare molti tipi diversi di bilanciamento del carico e routing a seconda della GatewayClass che utilizza.

Per scoprire di più sulla risorsa Gateway, consulta la descrizione della risorsa Gateway o la specifica dell'API.

In questa sezione creerai un gateway. I team delle applicazioni possono utilizzare il gateway per esporre le proprie applicazioni a internet eseguendo il deployment delle route in modo indipendente e collegandole in modo sicuro al gateway.

1. Salva il seguente manifest in un file denominato gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
     annotations:
       networking.gke.io/certmap: store-example-com-map
   spec:
     # This GatewayClass uses a global external Application Load Balancer.
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
   
   

   Questo manifest descrive un gateway con i seguenti campi:

   • gatewayClassName: gke-l7-global-external-managed: specifica la GatewayClass per questo gateway. Questa classe di gateway utilizza un bilanciatore del carico delle applicazioni esterno globale.
   • protocol: HTTPS e port: 443: specificano che il gateway espone la porta 443 per il traffico HTTPS. Questi campi abilitano TLS.
   • networking.gke.io/certmap: store-example-com-map: specifica il nome della mappa dei certificati in Certificate Manager.

   Non esiste una sezione TLS perché TLS è configurato con Certificate Manager utilizzando l'annotazione networking.gke.io/certmap.

2. Applica il manifest al tuo cluster:

   kubectl apply -f gateway.yaml
   

   Il deployment delle risorse da parte di GKE potrebbe richiedere alcuni minuti.

3. Verifica che il deployment del gateway sia andato a buon fine:

   kubectl describe gateway
   

   L'output è simile al seguente:

   Name:         external-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Gateway Class Name:  gke-l7-global-external-managed
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      https
       Port:      443
       Protocol:  HTTPS
       Tls:
         Certificate Refs:
           Group:
           Kind:   Secret
           Name:   store-example-com
         Mode:     Terminate
    ...
   

   Questo output mostra che il gateway di cui è stato eseguito il deployment nel cluster ha un bilanciatore del carico e un indirizzo IP pubblico. Il gateway non ha route, il che significa che non può inviare traffico ai backend. Senza route, tutto il traffico va a un backend predefinito, che restituisce una risposta HTTP 404. Nella sezione successiva, eseguirai il deployment delle route, che indicano al gateway di inviare il traffico ai backend.

Esegui il deployment dell'applicazione demo

Puoi eseguire il deployment delle applicazioni e delle route indipendentemente dal deployment dei gateway.

Per ulteriori informazioni su come eseguire il deployment delle applicazioni demo, consulta Esegui il deployment delle applicazioni demo.

Crea una risorsa HTTPRoute

Devi creare una risorsa HTTPRoute per eseguire la corrispondenza e il filtro del traffico HTTP e HTTPS.

Invia traffico alla tua applicazione

Dopo aver eseguito il deployment dell'applicazione e creato le risorse HTTPRoute, puoi passare il traffico all'applicazione.

Per saperne di più su come inviare traffico alla tua applicazione, consulta Invia traffico alla tua applicazione.

Esegui il deployment di un gateway esterno regionale

L'esempio seguente mostra come esporre un'applicazione di un negozio con più certificati collegati al gateway esterno regionale utilizzando certificati autogestiti e un HTTPRoute.

Crea una subnet proxy per il gateway regionale

Devi configurare una subnet solo proxy prima di creare un gateway che utilizza un bilanciatore del carico delle applicazioni esterno regionale. Ogni regione di un VPC in cui utilizzi il bilanciatore del carico delle applicazioni esterno regionale deve avere una subnet external_managed_proxy. Questa subnet fornisce indirizzi IP interni ai proxy del bilanciatore del carico.

Crea un certificato per proteggere il traffico dei client

Puoi utilizzare un certificato emesso e convalidato dalla tua autorità di certificazione (CA) o creare un certificato autofirmato. Per saperne di più su come creare un certificato, consulta Archivia un certificato in un secret di Kubernetes.

Per proteggere il traffico tra i client e il gateway regionale, puoi utilizzare i seguenti metodi:

• Certificati di Certificate Manager gestiti da Google o autogestiti
• Certificati SSL a livello di regione autogestiti
• Secret Kubernetes

I certificati SSL CertificateMap o gestiti da Google non sono supportati con i gateway a livello di regione.

Per saperne di più, consulta Certificati e bilanciatori del carico Google Cloud

Crea un gateway HTTP(S) esterno regionale

Nota: in un cluster IPv6 a stack singolo la cui subnet del nodo principale utilizza indirizzi IPv6 interni (--ipv6-access-type=INTERNAL), una risorsa gateway IPv6 gke-l7-regional-external-managed richiede una subnet separata nella stessa rete VPC e nella stessa regione con --ipv6-access-type=EXTERNAL. Specifica la subnet utilizzando il flag --subnet quando crei un indirizzo IPv6 statico o collega una risorsa GCPGatewayPolicy con il campo spec.default.subnetwork impostato quando utilizzi un indirizzo IPv6 temporaneo. Per istruzioni, consulta Requisito della subnet IPv6 esterna regionale sui cluster IPv6 interni.

1. Crea un indirizzo IP statico regionale per il bilanciatore del carico esterno.

   gcloud compute addresses create IP_ADDRESS_NAME \
     --region=COMPUTE_REGION \
     --network-tier=STANDARD
   

   Sostituisci quanto segue:

   • IP_ADDRESS_NAME: il nome del nuovo indirizzo IP statico.
   • COMPUTE_REGION: la regione di Compute Engine in cui è in esecuzione il cluster.

2. Crea un gateway del bilanciatore del carico delle applicazioni esterno regionale utilizzando un certificato autogestito come segue e salva il manifest come regional-gateway.yaml:

     kind: Gateway
     apiVersion: gateway.networking.k8s.io/v1
     metadata:
       name: external-regional-http
     spec:
       # Name of an existing GatewayClass.
       gatewayClassName: gke-l7-regional-external-managed
       # Listen for HTTPS traffic on port 443
       listeners:
       - name: https
         protocol: HTTPS
         port: 443
         tls:
           # Terminate the TLS session with the client at the Gateway.
           mode: Terminate
           # Certificates for the Gateway to use to create a new TLS session.
           certificateRefs:
           - name: store-example-com
       # The name of the static IP address of the external load balancer.
       # You can also use the `IPAddress` type to specify the actual IP address.
       addresses:
       - type: NamedAddress
         value: IP_ADDRESS_NAME
   

3. Applica il manifest regional-gateway:

     kubectl apply -f regional-gateway.yaml
   

4. Verifica la configurazione.

     kubectl get gateway
   

   L'output è simile al seguente:

   NAME            CLASS                              ADDRESS         READY   AGE
   external-http   gke-l7-regional-external-managed   35.118.32.224   True    49s
   

   Per maggiori dettagli, utilizza un comando describe:

   kubectl describe gateway
   

   L'output è simile al seguente:

   Name:         external-regional-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Gateway Class Name:  gke-l7-regional-external-managed
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      https
       Port:      443
       Protocol:  HTTPS
       Tls:
         Certificate Refs:
           Group:
           Kind:   Secret
           Name:   store-example-com
         Mode:     Terminate
     ...
   

Esegui il deployment dell'applicazione demo

Puoi eseguire il deployment delle applicazioni e delle route indipendentemente dal deployment dei gateway.

Per ulteriori informazioni su come eseguire il deployment delle applicazioni demo, consulta Esegui il deployment delle applicazioni demo.

Crea una risorsa HTTPRoute

Devi creare una risorsa HTTPRoute per eseguire la corrispondenza e il filtro del traffico HTTP e HTTPS.

Invia traffico alla tua applicazione

Dopo aver eseguito il deployment dell'applicazione e creato le risorse HTTPRoute, puoi passare il traffico all'applicazione.

Per saperne di più su come inviare traffico alla tua applicazione, consulta Invia traffico alla tua applicazione.

Utilizza i gateway condivisi

L'API Gateway utilizza risorse separate, Gateway e Route, per eseguire il deployment di bilanciatori del carico e regole di instradamento. Questo approccio è diverso da Ingress, che combina tutto in un'unica risorsa. Suddividendo la responsabilità tra le risorse, Gateway consente di eseguire il deployment del bilanciatore del carico e delle relative regole di instradamento separatamente e da parte di utenti o team diversi. In questo modo, i gateway diventano gateway condivisi che si collegano a molte route diverse che possono essere completamente di proprietà e gestite da team indipendenti, anche in spazi dei nomi diversi.

Esegui il deployment delle route su un gateway condiviso

Questo esempio si basa sul gateway internal-http di cui è stato eseguito il deployment in Esegui il deployment di un gateway interno.

In questo esempio, il team del sito esegue il deployment dell'applicazione, dei servizi e di una risorsa HTTPRoute per abbinare il traffico dal gateway a questi servizi.

1. Esegui il deployment dell'applicazione di esempio:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/site.yaml
   

2. Salva il seguente manifest in un file denominato site-route-internal.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: site-internal
   spec:
     # Attach the HTTPRoute to the `internal-http` Gateway.
     parentRefs:
     - kind: Gateway
       name: internal-http
     # Route requests that have `site.example.com` in the Host header.
     hostnames:
     - "site.example.com"
     # Send all requests to the `site-v1` Service.
     rules:
     - backendRefs:
       - name: site-v1
         port: 8080
   

   Questo manifest descrive un HTTPRoute che corrisponde a tutto il traffico per site.example.com e lo instrada al servizio site-v1.

3. Applica il manifest al tuo cluster:

   kubectl apply -f site-route-internal.yaml
   

4. Verifica che la risorsa HTTPRoute sia collegata al gateway:

   kubectl describe httproute.gateway.networking.k8s.io site-internal
   

   L'output è simile al seguente:

   Status:
     Parents:
       Conditions:
         Last Transition Time:  2023-01-09T15:05:43Z
         Message:
         Reason:                Accepted
         Status:                True
         Type:                  Accepted
         Last Transition Time:  2023-01-09T15:05:43Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   internal-http
         ...
   

   Se la condizione Accepted per il gateway è True, HTTPRoute è stato associato correttamente al gateway. Per scoprire di più sul campo Stato, consulta Stato della route.

5. Verifica che il traffico verso il gateway venga instradato correttamente:

   curl -H "host: site.example.com" GATEWAY_IP_ADDRESS
   curl -H "host: store.example.com" GATEWAY_IP_ADDRESS
   

   Sostituisci GATEWAY_IP_ADDRESS con l'indirizzo IP del gateway interno.

   Devi utilizzare una macchina virtuale (VM) nello stesso VPC del gateway.

   L'output è simile al seguente:

   {
     "cluster_name": "CLUSTER_NAME",
     "host_header": "site.example.com",
     "metadata": "site-v1",
     "pod_name": "site-v1-5d64fc4d7d-fz6f6",
     "pod_name_emoji": "👩🏼‍🍳",
     "project_id": "PROJECT_ID",
     "timestamp": "2022-11-02T19:07:01",
     "zone": "ZONE_NAME"
   }
   ...
   {
     "cluster_name": "CLUSTER_NAME",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "pod_name": "store-v1-6d8d58d78-vz8pn",
     "pod_name_emoji": "🧝🏻‍♂️",
     "project_id": "PROJECT_ID",
     "timestamp": "2022-11-02T19:07:01",
     "zone": "ZONE_NAME"
   }
   

   Questo output indica che le richieste con l'intestazione Host site.example.com raggiungono il servizio site-v1, mentre le richieste con l'intestazione Host store.example.com raggiungono il servizio store-v1.

Configura livello di rete

Puoi specificare il livello di rete e la versione IP per l'indirizzo del listener temporaneo di un gateway utilizzando il campo type all'interno dell'array addresses[] nella definizione del gateway. Se ometti il campo spec.addresses, il controller Gateway esegue il provisioning di un indirizzo IP temporaneo predefinito in base al tipo di stack del cluster (un indirizzo IPv4 su cluster IPv4 a stack singolo e a doppio stack o un indirizzo IPv6 su cluster IPv6 a stack singolo quando è disponibile una subnet compatibile). Per le risorse Gateway gke-l7-regional-external-managed, l'omissione del campo spec.addresses imposta come predefinito un indirizzo IPv4 temporaneo di livello Standard su cluster IPv4 a stack singolo e a doppio stack o un indirizzo IPv6 temporaneo di livello Premium su cluster IPv6 a stack singolo (il livello Standard non è supportato per gli indirizzi IPv6).

Nei cluster IPv6 a stack singolo, quando alloca un indirizzo IP temporaneo per una risorsa Gateway a livello di regione (gke-l7-rilb o gke-l7-regional-external-managed), il controller del gateway seleziona la subnet nel seguente ordine:

1. Se una risorsa GCPGatewayPolicy collegata alla risorsa Gateway specifica il campo spec.default.subnetwork, l'indirizzo IP temporaneo viene allocato da quella subnet.
2. Se non viene specificata alcuna subnet in una risorsa GCPGatewayPolicy e la subnet del nodo principale del cluster ha il tipo di accesso IPv6 richiesto (INTERNAL per gke-l7-rilb o EXTERNAL per gke-l7-regional-external-managed), l'indirizzo IP temporaneo viene allocato dalla subnet del nodo principale.
3. Se non è disponibile una subnet compatibile, il controller del gateway segnala un errore. Per istruzioni sulla configurazione di una subnet personalizzata, consulta Requisito della subnet IPv6 esterna regionale sui cluster IPv6 interni.

Utilizza i seguenti valori per il campo type:

• networking.gke.io/premium-ephemeral-ipv4-address: assegna un indirizzo IPv4 temporaneo di livello Premium (gke-l7-regional-external-managed).
• networking.gke.io/standard-ephemeral-ipv4-address: assegna un indirizzo IPv4 temporaneo di livello Standard (gke-l7-regional-external-managed).
• networking.gke.io/premium-ephemeral-ipv6-address: assegna un indirizzo IPv6 temporaneo di livello Premium (gke-l7-regional-external-managed).
• networking.gke.io/ephemeral-ipv4-address/REGION: assegna un indirizzo IPv4 temporaneo regionale in REGION (gke-l7-rilb e gke-l7-cross-regional-internal-managed-mc).
• networking.gke.io/ephemeral-ipv6-address/REGION: assegna un indirizzo IPv6 temporaneo regionale in REGION (gke-l7-rilb).

Per assegnare indirizzi IP da entrambi i livelli di rete o da entrambe le versioni IP (ad esempio, un indirizzo IPv4 e un indirizzo IPv6 su un cluster a doppio stack), specifica più tipi nel campo addresses.

L'esempio seguente mostra come Google Cloud assegnare un indirizzo IP di livello Premium a un gateway. Per eseguire il provisioning di un indirizzo IPv4 di livello Standard, utilizza networking.gke.io/standard-ephemeral-ipv4-address.

1. Salva il seguente manifest di esempio come external-regional-http.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-regional-http
   spec:
     # Name of an existing GatewayClass.
     gatewayClassName: gke-l7-regional-external-managed
     # Listen for HTTPS traffic on port 443.
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         # Terminate the TLS session with the client at the Gateway.
         mode: Terminate
         # Certificates for the Gateway to use to create a new TLS session.
         certificateRefs:
         - name: store-example-com
     addresses:
     # Request a Premium Tier ephemeral IPv4 address for the Gateway.
     # For a Premium Tier ephemeral IPv6 address, use:
     # networking.gke.io/premium-ephemeral-ipv6-address
     - type: networking.gke.io/premium-ephemeral-ipv4-address
   

   Nota: per eseguire il provisioning di un indirizzo IPv4 di livello Standard, utilizza networking.gke.io/standard-ephemeral-ipv4-address.

2. Applica il manifest di esempio:

   kubectl apply -f external-regional-http.yaml
   

Nota: se crei una risorsa Gateway del bilanciatore del carico delle applicazioni esterno regionale che utilizza la GatewayClass gke-l7-regional-external-managed senza specificare un indirizzo nel campo spec.addresses, il gateway utilizza per impostazione predefinita un indirizzo IPv4 temporaneo di livello Standard (su cluster IPv4 a stack singolo e a doppio stack) o un indirizzo IPv6 temporaneo di livello Premium (su cluster IPv6 a stack singolo). Se modifichi il manifest del gateway in un secondo momento per specificare un tipo di indirizzo esplicito, ad esempio networking.gke.io/standard-ephemeral-ipv4-address, networking.gke.io/premium-ephemeral-ipv4-address o networking.gke.io/premium-ephemeral-ipv6-address, l'indirizzo IP cambia, il che potrebbe interrompere i servizi. Per evitare interruzioni del servizio, definisci la configurazione dell'indirizzo quando crei il gateway.

Configura il backend predefinito del gateway

Tutte le GatewayClass gke-l7-* restituiscono HTTP 404 per il traffico non corrispondente. Puoi configurare il backend predefinito utilizzando una route predefinita esplicita che invia il traffico non corrispondente a un servizio fornito dall'utente.

I gateway sono configurati per gestire codici di errore come 404 (Non trovato) e 500 (Errore del server), anche senza definizioni esplicite del backend. Il comportamento predefinito può variare a seconda delle implementazioni del gateway. Per un maggiore controllo sulla gestione degli errori, valuta la possibilità di configurare backend personalizzati.

La seguente risorsa HTTPRoute è un esempio di come personalizzare il backend predefinito. Se applichi una risorsa HTTPRoute simile alla seguente, questa ha la precedenza sul backend predefinito implicito:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: custom-default-backend
spec:
  parentRefs:
  - kind: Gateway
    name: my-internal-gateway
  # Omit the `hostnames` field to route all unmatched traffic from the
  # attached Gateway.
  rules:
  - backendRefs:
    - name: my-custom-default-backend-service
      port: 8080

Questa risorsa HTTPRoute corrisponde a tutto il traffico proveniente da un gateway specifico. Puoi avere una sola regola di questo tipo per ogni gateway, altrimenti le regole entrano in conflitto e viene applicato l'ordine di precedenza.

Puoi utilizzare un backend predefinito per impedire a un utente di creare un backend di route predefinito che instrada tutto il traffico del gateway. Una risorsa HTTPRoute esplicita ha sempre la precedenza sulle nuove risorse HTTPRoute con regole di instradamento in conflitto.

Configura un indirizzo IP statico per un gateway

Ogni gateway ha un indirizzo IP che utilizza per ascoltare il traffico. Se non specifichi un indirizzo IP sul gateway, il controller del gateway ne fornisce automaticamente uno. Puoi anche creare un indirizzo IP statico in modo che esista indipendentemente dal ciclo di vita del gateway.

Dopo il deployment di un gateway, il suo indirizzo IP viene visualizzato nel campo dello stato:

kind: Gateway
...
status:
  addresses:
    - value: 10.15.32.3

A seconda della GatewayClass, l'indirizzo IP viene allocato dai seguenti pool e subnet:

GatewayClasses	Pool di indirizzi IPv4 predefinito	Pool di indirizzi IPv6 predefinito (temporaneo e statico)
gke-l7-rilb gke-l7-rilb-mc	Indirizzi IPv4 privati regionali dall'intervallo di indirizzi IPv4 del nodo principale	Indirizzi IPv6 interni regionali dall'intervallo di indirizzi IPv6 interni della subnet del nodo principale (ULA /64) quando la subnet del nodo principale utilizza ipv6AccessType: INTERNAL o da una subnet nella stessa regione configurata con ipv6AccessType: INTERNAL (solo gke-l7-rilb)
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Indirizzi IPv4 pubblici regionali dal pool di indirizzi IPv4 esterni regionali di Google	Indirizzi IPv6 esterni regionali dall'intervallo di indirizzi IPv6 esterni della subnet del nodo principale (GUA pubblico /64) quando la subnet del nodo principale utilizza ipv6AccessType: EXTERNAL o da una subnet VPC separata nella stessa regione configurata con ipv6AccessType: EXTERNAL (solo gke-l7-regional-external-managed; consulta Requisito della subnet IPv6 esterna regionale sui cluster IPv6 interni)
gke-l7-global-external-managed gke-l7-global-external-managed-mc gke-l7-gxlb gke-l7-gxlb-mc	Indirizzi IPv4 pubblici globali dagli intervalli di indirizzi IPv4 esterni globali di Google	Indirizzi IPv6 pubblici globali dagli intervalli di indirizzi IPv6 esterni globali di Google

Requisito della subnet IPv6 esterna regionale sui cluster IPv6 interni

A differenza degli indirizzi IPv4 esterni regionali (che vengono allocati da un pool gestito da Google indipendente dalle subnet VPC), gli indirizzi IPv6 esterni regionali di Compute Engine (NETLB) devono essere allocati da una subnet VPC configurata con ipv6AccessType: EXTERNAL.

Se la subnet dei nodi principali del cluster è già configurata con --ipv6-access-type=EXTERNAL, il controller Gateway utilizza la subnet dei nodi principali per impostazione predefinita per gli indirizzi IPv6 gke-l7-regional-external-managed.

Se il cluster utilizza una subnet dei nodi IPv6 interna (--ipv6-access-type=INTERNAL), la subnet dei nodi principale del cluster ha solo indirizzi locali univoci (ULA) privati. Prima di eseguire il deployment di una risorsa gateway IPv6 gke-l7-regional-external-managed (utilizzando un indirizzo IPv6 temporaneo o statico), devi creare una subnet nella stessa rete VPC e nella stessa regione con --ipv6-access-type=EXTERNAL:

1. Crea una subnet solo IPv6 (o a doppio stack) con accesso IPv6 esterno nella stessa rete VPC e nella stessa regione del cluster:

   gcloud compute networks subnets create EXTERNAL_IPV6_SUBNET_NAME \
       --network=VPC_NETWORK_NAME \
       --region=COMPUTE_REGION \
       --stack-type=IPV6_ONLY \
       --ipv6-access-type=EXTERNAL
   

   Sostituisci quanto segue:

   • EXTERNAL_IPV6_SUBNET_NAME: il nome della subnet con accesso IPv6 esterno.
   • VPC_NETWORK_NAME: il nome della rete VPC in cui viene eseguito il cluster GKE.
   • COMPUTE_REGION: la regione di Compute Engine in cui viene eseguito il cluster.

   Per creare una subnet a doppio stack anziché una subnet solo IPv6, sostituisci --stack-type=IPV6_ONLY con --stack-type=IPV4_IPV6 --range=IPV4_CIDR_RANGE, dove IPV4_CIDR_RANGE è un intervallo CIDR IPv4 primario non utilizzato nella rete VPC.

2. Configura la risorsa Gateway in modo che utilizzi la subnet IPv6 esterna:

   • Per un indirizzo IPv6 temporaneo: collega una risorsa GCPGatewayPolicy alla risorsa Gateway e specifica il nome della subnet nel campo spec.default.subnetwork. Salva il seguente manifest come gateway-policy.yaml:

     apiVersion: networking.gke.io/v1
     kind: GCPGatewayPolicy
     metadata:
       name: GATEWAY_POLICY_NAME
       namespace: GATEWAY_NAMESPACE
     spec:
       default:
         subnetwork: EXTERNAL_IPV6_SUBNET_NAME
       targetRef:
         group: gateway.networking.k8s.io
         kind: Gateway
         name: GATEWAY_NAME
     

     Sostituisci quanto segue:

     • GATEWAY_POLICY_NAME: il nome della risorsa GCPGatewayPolicy.
     • GATEWAY_NAMESPACE: lo spazio dei nomi della risorsa Gateway di destinazione.
     • EXTERNAL_IPV6_SUBNET_NAME: il nome della subnet creata nel passaggio precedente.
     • GATEWAY_NAME: il nome della risorsa gateway di destinazione.

     Applica il manifest gateway-policy.yaml:

     kubectl apply -f gateway-policy.yaml
     

     Nota: sui cluster IPv6 a stack singolo, puoi anche impostare il campo spec.default.subnetwork in una risorsa GCPGatewayPolicy collegata a una risorsa Gateway gke-l7-rilb per allocare indirizzi IPv4 o IPv6 interni temporanei da una subnet personalizzata (ad esempio, se la subnet del nodo principale del cluster utilizza --ipv6-access-type=EXTERNAL).

   • Per un indirizzo IPv6 statico (NamedAddress): specifica il flag --subnet=EXTERNAL_IPV6_SUBNET_NAME quando crei la risorsa indirizzo IPv6 statico, come mostrato in Utilizza un indirizzo IP denominato.

Nota: Compute Engine non supporta l'hairpinning VPC da origini di indirizzi IPv6 interni (ULA) a destinazioni di bilanciatori del carico con indirizzi IPv6 esterni (GUA) nella stessa rete VPC. Le richieste inviate da pod o VM solo IPv6 interni nella stessa rete VPC non possono raggiungere un VIP IPv6 gke-l7-regional-external-managed esterno. Testa le risorse del gateway IPv6 esterno regionale da client IPv6 esterni alla rete VPC o utilizza gke-l7-rilb per i client interni.

Il campo addresses.NamedAddress consente di specificare un indirizzo IP indipendentemente dal gateway. Puoi creare una risorsa indirizzo IP statico prima del deployment del gateway e la risorsa viene indicata da NamedAddress. Puoi riutilizzare l'indirizzo IP statico anche se il gateway viene eliminato.

Utilizza un indirizzo IP denominato

Puoi configurare un indirizzo IPv4 o IPv6 statico specificando un NamedAddress. Devi eseguire il provisioning di un indirizzo IP statico prima di creare un gateway.

1. Crea una risorsa indirizzo IP statico:

   • Indirizzo IPv4 interno regionale (gke-l7-rilb):

     gcloud compute addresses create IP_ADDRESS_NAME \
         --purpose=SHARED_LOADBALANCER_VIP \
         --region=COMPUTE_REGION \
         --subnet=SUBNET \
         --project=PROJECT_ID
     

   • Indirizzo IPv6 interno regionale (gke-l7-rilb):

     gcloud compute addresses create IP_ADDRESS_NAME \
         --region=COMPUTE_REGION \
         --subnet=CLUSTER_NODE_SUBNET \
         --ip-version=IPV6 \
         --project=PROJECT_ID
     

     Nota: il flag --purpose=SHARED_LOADBALANCER_VIP non è supportato per gli indirizzi IPv6 interni. Non puoi condividere un singolo indirizzo IPv6 interno statico tra più regole di forwarding o listener di gateway su porte diverse.

   • Indirizzo IPv6 esterno regionale (gke-l7-regional-external-managed):

     gcloud compute addresses create IP_ADDRESS_NAME \
         --region=COMPUTE_REGION \
         --subnet=EXTERNAL_IPV6_SUBNET_NAME \
         --ip-version=IPV6 \
         --endpoint-type=NETLB \
         --project=PROJECT_ID
     

   Sostituisci quanto segue:

   • IP_ADDRESS_NAME: il nome del nuovo indirizzo IP statico.
   • COMPUTE_REGION: per i gateway a livello di regione, la regione di Compute Engine in cui è in esecuzione il cluster. Questo flag non è necessario per i gateway esterni globali.
   • SUBNET o CLUSTER_NODE_SUBNET: la subnet per l'indirizzo IP interno. Questo flag non è necessario per i gateway esterni globali.
   • EXTERNAL_IPV6_SUBNET_NAME: la subnet regionale configurata con ipv6AccessType: EXTERNAL da cui allocare l'indirizzo IPv6 esterno regionale.
   • PROJECT_ID: il progetto in cui è in esecuzione il tuo cluster GKE.

   I comandi precedenti allocano automaticamente un indirizzo IP dalla subnet specificata. Puoi anche specificare un indirizzo IPv4 personalizzato o un intervallo di indirizzi IPv6 /96 personalizzato con il flag --addresses. Per saperne di più, consulta Prenota un indirizzo IP interno statico e Prenota un indirizzo IP esterno statico.

2. Salva il seguente manifest in un file denominato named-ip-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: internal-http
   spec:
     gatewayClassName: gke-l7-rilb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
     addresses:
     - type: NamedAddress
       value: IP_ADDRESS_NAME
   

   Questo manifest descrive un gateway che fa riferimento all'indirizzo IP denominato.

3. Applica il manifest al tuo cluster:

   kubectl apply -f named-ip-gateway.yaml
   

4. Verifica l'indirizzo IP del gateway:

   kubectl describe gateway internal-http
   

   L'output è simile al seguente:

   Name:         internal-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Addresses:
       Type:              NamedAddress
       Value:             IP_ADDRESS_NAME
     Gateway Class Name:  gke-l7-rilb
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      http
       Port:      80
       Protocol:  HTTP
   Status:
     Addresses:
       Type:   IPAddress
       Value:  10.15.32.103
   

Configura le regole firewall IPv6 per il VPC condiviso o la gestione manuale del firewall

Quando la creazione automatica delle regole firewall è disabilitata o limitata (ad esempio nei progetti di servizio VPC condiviso), devi creare manualmente una regola firewall IPv6 in entrata per consentire il traffico dai Google Cloud prober dei controlli di integrità IPv6 (2600:2d00:1:b029::/64), dai proxy Google Front End (GFE) per i bilanciatori del carico delle applicazioni esterni globali (2600:2d00:1:1::/64) e dalla subnet internalIpv6Prefix solo proxy regionale per i bilanciatori del carico delle applicazioni regionali:

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --network=VPC_NETWORK_NAME \
    --action=ALLOW \
    --direction=INGRESS \
    --rules=tcp:80,tcp:443 \
    --source-ranges="2600:2d00:1:b029::/64,2600:2d00:1:1::/64,PROXY_SUBNET_INTERNAL_IPV6_PREFIX" \
    --target-tags=GKE_NODE_TAG

Sostituisci quanto segue:

• FIREWALL_RULE_NAME: il nome della regola firewall.
• VPC_NETWORK_NAME: il nome della tua rete VPC.
• PROXY_SUBNET_INTERNAL_IPV6_PREFIX: il prefisso IPv6 /64 interno della subnet solo proxy a livello di regione (internalIpv6Prefix).
• GKE_NODE_TAG: il tag di rete applicato ai nodi del cluster.

Nota: nel flag --rules, specifica le porte TCP su cui i pod di backend sono in ascolto per il traffico con bilanciamento del carico e i controlli di integrità (ad esempio tcp:80,tcp:443 o tcp:8080).

Configura i reindirizzamenti da HTTP a HTTPS

Cloud Load Balancing offre la funzionalità di reindirizzamento da HTTP a HTTPS. Un bilanciatore del carico delle applicazioni esterno reindirizza le richieste HTTP non criptate a un bilanciatore del carico HTTPS che utilizza lo stesso indirizzo IP. Quando crei un gateway con i reindirizzamenti da HTTP a HTTPS abilitati, entrambi i bilanciatori del carico vengono creati automaticamente. Le richieste all'indirizzo IP esterno del gateway sulla porta 80 vengono reindirizzate automaticamente allo stesso indirizzo IP esterno sulla porta 443.

Per impostazione predefinita, i reindirizzamenti da HTTP a HTTPS non sono definiti sul gateway.

Per reindirizzare il traffico HTTP a HTTPS, configura un gateway per gestire sia il traffico HTTP che quello HTTPS. Se disattivi HTTP o HTTPS, il gateway non reindirizza il traffico.

L'esempio seguente mostra come utilizzare il reindirizzamento da HTTP a HTTPS per garantire che il traffico dei client verso le tue applicazioni web venga sempre reindirizzato a una pagina sicura.

I reindirizzamenti da HTTP a HTTPS non sono supportati con le GatewayClass gke-l7-gxlb e gke-l7-gxlb-mc. Per scoprire di più sulle diverse funzionalità supportate da ogni GatewayClass, consulta Funzionalità di GatewayClass.

Tieni presente che la sezione hostnames in una risorsa HTTPRoute è facoltativa. Puoi creare un reindirizzamento catch-all per tutti i nomi host su una porta HTTP specifica omettendo la sezione hostnames. Inoltre, puoi utilizzare un reindirizzamento con caratteri jolly, ad esempio:

...
hostnames:
- "*.example.com" # Matches all subdomains of example.com
...

Reindirizza il traffico HTTP da uno spazio dei nomi dell'infrastruttura

In alcuni casi, non esiste una distinzione chiara tra il team di amministrazione dell'infrastruttura o della piattaforma e i team delle applicazioni e impedire l'uso improprio del gateway può diventare una sfida.

L'esempio seguente limita ulteriormente l'utilizzo del listener HTTP per impedire l'utilizzo involontario di un protocollo non sicuro da parte dei team dell'applicazione. Questo esempio configura il gateway in modo da consentire a una risorsa HTTPRoute di utilizzare il listener HTTP solo se la route si trova in uno spazio dei nomi con l'etichetta otherInfra: httpToHttps. Tuttavia, il gateway consente alle risorse HTTPRoute in qualsiasi spazio dei nomi di utilizzare il listener HTTPS. Puoi limitare lo spazio dei nomi http-redirect utilizzando RBAC di Kubernetes in modo che i team delle applicazioni non possano creare un HTTPRoute in questo spazio dei nomi per errore.

1. Crea lo spazio dei nomi di un gateway. Salva il manifest come gateway-namespace.yaml:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: gateway-infra
   

2. Applica il manifest:

   kubectl apply -f gateway-namespace.yaml
   

3. Crea lo spazio dei nomi di un gateway e salva il manifest come redirect-namespace.yaml:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: http-redirect
     labels:
       otherInfra: httpToHttps
   

   Questo spazio dei nomi http-redirect ha l'etichetta otherInfra: httpToHttps.

4. Applica il manifest:

   kubectl apply -f redirect-namespace.yaml
   

5. Per limitare l'utilizzo del listener HTTP, crea un gateway utilizzando il seguente manifest. Salva il manifest come external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
     namespace: gateway-infra
   spec:
     # Name of an existing GatewayClass.
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       #  Allow only HTTPRoutes from namespaces that have the
       # `otherInfra: httpToHttps` label to use this listener.
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: Selector
           selector:
             matchLabels:
               otherInfra: httpToHttps
     - name: https
       protocol: HTTPS
       port: 443
       # Allow HTTPRoutes from any namespace to use this listener.
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: All
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: store-example-com
   

   • Il campo namespace specifica che il gateway viene creato nello spazio dei nomi gateway-infra.

   • Il campo namespaces nella sezione allowedRoutes limita il listener http allo spazio dei nomi corrispondente all'etichetta otherInfra: httpToHttps.

6. Applica il manifest:

   kubectl apply -f external-gateway.yaml
   

7. Per forzare il reindirizzamento HTTPS, crea una risorsa HTTPRoute predefinita utilizzando il seguente manifest. Salva il manifest come http-redirect.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: redirect
     # Create the HTTPRoute in the `http-redirect` namespace.
     namespace: http-redirect
   spec:
     # Attach the HTTPRoute to the `http` listener in the `external-http`
     # Gateway.
     parentRefs:
     - namespace: gateway-infra
       name: external-http
       sectionName: http
     rules:
     # Respond to the request with an HTTPS redirection.
     - filters:
       - type: RequestRedirect
         requestRedirect:
           scheme: https
   

   • Il campo sectionName indica al gateway di trovare corrispondenze solo sul listener http. Il filtro RequestRedirect forza il reindirizzamento al listener https.

8. Applica il manifest:

   kubectl apply -f http-redirect.yaml
   

9. Crea un servizio per un'applicazione utilizzando il seguente manifest. Salva il manifest come service-deployment.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1
   spec:
     selector:
       app: store
       version: v1
     ports:
     - port: 8080
       targetPort: 8080
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: store-v1
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: store
         version: v1
     template:
       metadata:
         labels:
           app: store
           version: v1
       spec:
         containers:
         - name: whereami
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
           ports:
           - containerPort: 8080
           env:
           - name: METADATA
             value: "store-v1"
   

10. Applica il manifest:

    kubectl apply -f service-deployment.yaml
    

11. Crea una risorsa HTTPRoute per un'applicazione che consente solo HTTPS utilizzando il seguente manifest. Salva il manifest come http-route.yaml:

    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1
    metadata:
      name: store-external
      labels:
        gateway: external-http
    spec:
      # Attach the HTTPRoute to the HTTPS listener in the `external-http`
      # Gateway.
      parentRefs:
      - name: external-http
        namespace: gateway-infra
        sectionName: https
      # Match requests that have the `store.example.com` Host header.
      hostnames:
      - "store.example.com"
      # Route requests to the `store-v1` Service.
      rules:
      - backendRefs:
        - name: store-v1
          port: 8080
    

12. Applica il manifest:

    kubectl apply -f http-route.yaml
    

Configura i reindirizzamenti dei percorsi e le riscritture degli URL

I reindirizzamenti dei percorsi comportano il reindirizzamento di una richiesta in entrata da un percorso dell'URL a un altro. I reindirizzamenti dei percorsi ti consentono di modificare la struttura dell'URL quando devi gestire URL obsoleti o ritirati.

Le riscritture degli URL aiutano a modificare l'URL in entrata prima di elaborarlo sul server. In questo modo, puoi modificare la struttura o il formato dell'URL senza modificare effettivamente i contenuti o la struttura dei file sottostanti. La riscrittura degli URL è utile per creare URL facili da usare e ottimizzati per la SEO, facili da ricordare e comprendere. Per impostazione predefinita, i reindirizzamenti dei percorsi e le riscritture degli URL non sono configurati. Devi configurarli esplicitamente utilizzando un filtro in HTTPRoute.

Il gateway GKE supporta i reindirizzamenti dei percorsi e le riscritture degli URL. Per saperne di più, consulta Reindirizzamenti e riscritture dei percorsi HTTP.

Configura i reindirizzamenti dei percorsi

Puoi configurare i reindirizzamenti dei percorsi in modo da sostituire l'intero percorso o solo un prefisso nell'URL.

Sostituisci l'intero percorso

1. Per sostituire un intero percorso, configura un filtro in una risorsa HTTPRoute che sostituisce qualsiasi URL contenente il prefisso /any-path nel percorso dell'URL con il valore esatto /new-path.

2. Crea un manifest HTTPRoute come segue e assegnagli il nome store.yaml:

     apiVersion: gateway.networking.k8s.io/v1
     kind: HTTPRoute
     metadata:
       name: store
     spec:
       parentRefs:
       - kind: Gateway
         name: external-http
       hostnames:
       - store.example.com
       rules:
       - matches:
         - path:
             # Match requests by a prefix, like `/any-path` and `/any-path/home`.
             type: PathPrefix
             value: /any-path
         filters:
         - type: RequestRedirect
           requestRedirect:
             path:
               # Replace the full path with `/new-path`. For example, both
               # `/any-path/home` and `/any-path` become `/new-path`.
               type: ReplaceFullPath
               replaceFullPath: /new-path
             statusCode: 302
   

   Ad esempio, questo manifest imposta una regola di instradamento per un HTTPRoute come segue: qualsiasi route all'URL https://store.example.com/any-path/... deve essere reindirizzata a una nuova posizione, https://store.example.com/new-path/ (rigorosa).

3. Applica il manifest:

   kubectl apply -f store.yaml
   

Questa regola di instradamento segue una regola di reindirizzamento rigorosa, il che significa che il browser non tenta di memorizzare nella cache il reindirizzamento, ma reindirizza all'ultima versione.

Sostituisci solo un prefisso

1. Per sostituire solo un prefisso, configura un filtro in una risorsa HTTPRoute che sostituisce qualsiasi URL contenente il prefisso /any-prefix nel percorso dell'URL con il valore esatto /new-prefix.

2. Crea un manifest HTTPRoute come segue e assegnagli il nome store.yaml:

   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: store
   spec:
     parentRefs:
       - kind: Gateway
         name: external-http
     hostnames:
     - store.example.com
     rules:
     - matches:
         - path:
             # Match requests by prefix, like `/any-prefix` and
             # `/any-prefix/home`.
             type: PathPrefix
             value: /any-prefix
       filters:
       - type: RequestRedirect
         requestRedirect:
           path:
             # Replace the matched prefix with `/new-prefix`. For example,
             # `/any-prefix` becomes `/new-prefix` and `/any-prefix/home`
             # becomes `/new-prefix/home`.
             type: ReplacePrefixMatch
             replacePrefixMatch: /new-prefix
           statusCode: 302
   

   Ad esempio, questo manifest imposta una regola di instradamento per una risorsa HTTPRoute come segue: qualsiasi route all'URL https://store.example.com/any-path/v1/... deve essere reindirizzata a una nuova posizione, https://store.example.com/new-path/v1/... (solo).

3. Applica il manifest:

     kubectl apply -f store.yaml
   

Questa regola di instradamento segue l'unica regola di reindirizzamento, che contribuisce a garantire che il browser ti reindirizzi sempre alla stessa pagina prevista.

Configura le riscritture URL

Imposta le riscritture degli URL per modificare il modo in cui un URL viene visualizzato dagli utenti. Puoi utilizzare le riscritture degli URL per renderli più facili da usare, migliorare la SEO o reindirizzare gli utenti a una nuova pagina.

Riscrivi l'intero nome host

Per riscrivere l'intero nome host:

1. Configura un filtro in una risorsa HTTPRoute che indichi al gateway di sostituire le informazioni Host nell'intestazione della richiesta da www.example.com a store.example.com prima di inoltrare la richiesta al servizio di backend.

2. Crea un manifest HTTPRoute come segue e assegnagli il nome www.yaml:

     apiVersion: gateway.networking.k8s.io/v1
     kind: HTTPRoute
     metadata:
       name: www
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - www.example.com
       rules:
       - filters:
         - type: URLRewrite
           # Replace the hostname in the URL with `store.example.com`.
           urlRewrite:
             hostname: store.example.com
         backendRefs:
         - name: store-v1
           port: 8080
   

   Ad esempio, con la configurazione precedente, qualsiasi richiesta a https://www.example.com viene inoltrata al servizio di backend con l'intestazione Host: store.example.com anziché Host: www.example.com.

3. Applica il manifest:

     kubectl apply -f www.yaml
   

Riscrittura utilizzando i modificatori di percorso

Puoi combinare le riscritture con i modificatori di percorso per fornire modifiche avanzate di URL e percorsi prima di inoltrare la richiesta al servizio di backend.

Per riscrivere utilizzando i modificatori di percorso:

1. Configura un filtro in un HTTPRoute che indichi al gateway di sostituire le informazioni "Host" nell'intestazione della richiesta da www.example.comto store.example.com e di sostituire il valore /store con / prima di inoltrare la richiesta al servizio di backend.

2. Crea un manifest HTTPRoute come segue e assegnagli il nome www.yaml:

     apiVersion: gateway.networking.k8s.io/v1
     kind: HTTPRoute
     metadata:
       name: www
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - www.example.com
       rules:
       - matches:
         - path:
             type: PathPrefix
             value: /store
         filters:
         - type: URLRewrite
           # For URLs that have `/store` in the path, replace the hostname with
           # store.example.com and replace the `/store` prefix with `/de`.
           urlRewrite:
             hostname: store.example.com
             path:
               type: ReplacePrefixMatch
               replacePrefixMatch: /de
         backendRefs:
         - name: store-german
           port: 8080
   

   Ad esempio, con la configurazione precedente, qualsiasi richiesta a https://www.example.com/store/... viene inoltrata al servizio di backend con Host: store.example.com nell'intestazione della richiesta (anziché Host: www.example.com) e /store viene riscritto in /de.

3. Applica il manifest:

   kubectl apply -f www.yaml
   

Riscrivi utilizzando le espressioni regolari

Puoi utilizzare una risorsa GCPHTTPFilter con spec.urlRewrite.regexModifier per riscrivere i percorsi degli URL utilizzando espressioni regolari prima di inoltrare la richiesta al servizio di backend.

Per riscrivere un percorso dell'URL utilizzando un'espressione regolare:

1. Salva il seguente manifest come store-regex-rewrite-filter.yaml:

   apiVersion: networking.gke.io/v1
   kind: GCPHTTPFilter
   metadata:
     name: store-regex-rewrite-filter
   spec:
     urlRewrite:
       regexModifier:
         pathPattern: /service1/
         pathSubstitution: /service2/
   

   Questo manifest descrive un GCPHTTPFilter con le seguenti proprietà:

   • urlRewrite.regexModifier: configura la riscrittura del percorso dell'URL utilizzando espressioni regolari.
   • pathPattern: specifica l'espressione regolare RE2 che corrisponde al percorso dell'URL della richiesta, ad esempio /service1/([a-zA-Z0-9]+).
   • pathSubstitution: specifica la stringa di sostituzione che sostituisce il percorso dell'URL corrispondente, che può fare riferimento a gruppi Capture numerati di pathPattern, ad esempio /service2/\1.

2. Applica il manifest al cluster:

   kubectl apply -f store-regex-rewrite-filter.yaml
   

3. Salva il seguente manifest come www-regex-rewrite.yaml:

   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: www-regex-rewrite
   spec:
     parentRefs:
     - kind: Gateway
       name: external-http
     hostnames:
     - www.example.com
     rules:
     - matches:
       - path:
           type: PathPrefix
           value: /service1/
       filters:
       - type: ExtensionRef
         extensionRef:
           group: networking.gke.io
           kind: GCPHTTPFilter
           name: store-regex-rewrite-filter
       backendRefs:
       - name: store-v1
         port: 8080
   

   Questo manifest descrive una risorsa HTTPRoute con le seguenti proprietà:

   • extensionRef: fa riferimento alla risorsa GCPHTTPFilter store-regex-rewrite-filter creata nel passaggio precedente.
   • backendRefs: inoltra la richiesta riscritta al servizio store-v1. Ad esempio, una richiesta a https://www.example.com/service1/item123 viene riscritta in /service2/item123 prima di essere inoltrata al servizio di backend store-v1.

4. Applica il manifest al cluster:

   kubectl apply -f www-regex-rewrite.yaml
   

Verifica la configurazione

Per verificare che il filtro sia stato applicato dopo aver creato HTTPRoute con i filtri di riscrittura dell'URL o di reindirizzamento del percorso, segui questi passaggi:

kubectl get httproute www -o yaml

L'output è simile al seguente:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"gateway.networking.k8s.io/v1","kind":"HTTPRoute","metadata":{"annotations":{},"name":"www","namespace":"default"},"spec":{"hostnames":["www.example.com"],"parentRefs":[{"kind":"Gateway","name":"external-http"}],"rules":[{"backendRefs":[{"name":"store-german","port":8080}],"filters":[{"type":"URLRewrite","urlRewrite":{"hostname":"store.example.com","path":{"replacePrefixMatch":"/de","type":"ReplacePrefixMatch"}}}],"matches":[{"path":{"type":"PathPrefix","value":"/store"}}]}]}}
    creationTimestamp: "2023-06-22T01:00:42Z"
    generation: 3
    name: www
    namespace: default
    resourceVersion: "51268631"
    uid: e516493e-806d-44d6-ae0d-1c9ff25682cf
  spec:
    hostnames:
    - www.example.com
    parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: external-http
    rules:
    - backendRefs:
      - group: ""
        kind: Service
        name: store-german
        port: 8080
        weight: 1
      filters:
      - type: URLRewrite
        urlRewrite:
          hostname: store.example.com
          path:
            replacePrefixMatch: /de
            type: ReplacePrefixMatch
      matches:
      - path:
          type: PathPrefix
          value: /store
  status:
    parents:
    - conditions:
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: Accepted
        status: "True"
        type: Accepted
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: ReconciliationSucceeded
        status: "True"
        type: Reconciled
      controllerName: networking.gke.io/gateway
      parentRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: external-http

Per maggiori dettagli, utilizza il comando describe:

kubectl describe httproute

Configura la condivisione di risorse multiorigine (CORS)

Anteprima

Questo prodotto o questa funzionalità sono soggetti ai "Termini dell'offerta pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

La condivisione delle risorse multiorigine (CORS) è un meccanismo di sicurezza che aiuta le applicazioni web in esecuzione in un'origine (dominio) ad accedere in modo sicuro alle risorse ospitate in un'origine diversa.

Puoi configurare le policy CORS direttamente all'interno delle risorse HTTPRoute utilizzando il filtro CORS. Questo approccio consente al bilanciatore del carico di inserire le intestazioni della risposta CORS appropriate e di gestire le richieste di preflight CORS (OPTIONS), scaricando questa responsabilità dai servizi di backend.

Configura una policy CORS

L'esempio seguente mostra un HTTPRoute configurato con un filtro CORS che consente richieste multiorigine da https://www.example.com per metodi e intestazioni specifici:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: route-with-cors
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: my-backend
      port: 8080
    filters:
    - type: CORS
      cors:
        allowOrigins:
        - "https://www.example.com"
        allowMethods:
        - GET
        - POST
        - DELETE
        allowHeaders:
        - "x-request-header-1"
        - "x-request-header-2"
        exposeHeaders:
        - "x-response-header-a"
        - "x-response-header-b"
        allowCredentials: true
        maxAge: 3600

Il blocco di configurazione cors supporta i seguenti campi:

• allowOrigins: un elenco di origini consentite. Sono supportati i protocolli http e https. Puoi specificare queste origini in uno dei seguenti formati:
  • Origini esplicite (ad esempio https://www.example.com).
  • Un singolo carattere jolly catch-all (*) per consentire tutte le origini. Se viene utilizzato questo carattere jolly, non è possibile specificare altre origini. Per motivi di sicurezza, sconsigliamo vivamente di combinare il carattere jolly catch-all con l'impostazione allowCredentials (per ulteriori informazioni, consulta la definizione del campo di seguito).
  • Pattern con caratteri jolly (ad esempio, https://*.domain.com). Il carattere jolly * deve apparire immediatamente dopo lo schema (http:// o https://) e deve essere seguito da un punto (ad esempio, http://*.domain.com), da una porta (ad esempio, https://*:4433) o essere l'ultimo carattere (ad esempio, http://*).
• allowMethods: i metodi HTTP consentiti per le richieste CORS. Supporta il carattere jolly (*) per consentire tutti i metodi. Se viene utilizzato il carattere jolly, non è possibile specificare altri metodi.
• allowHeaders: le intestazioni HTTP che i client possono inviare. Supporta il carattere jolly (*) per consentire tutte le intestazioni. Se viene utilizzato il carattere jolly, non è possibile specificare altre intestazioni.
• exposeHeaders: le intestazioni HTTP che possono essere esposte in sicurezza allo script client. Supporta il carattere jolly (*) per esporre tutte le intestazioni.
• allowCredentials: controlla se il browser può condividere la risposta del server per le richieste inviate in modalità con credenziali, ad esempio le richieste che contengono cookie o l'autenticazione HTTP. Il valore predefinito è false. Quando configuri questa impostazione, tieni presente i seguenti aspetti di sicurezza:
  • Se specifichi il carattere jolly * come valore per uno dei campi allowMethods, allowHeaders o exposeHeaders, il browser blocca una risposta a una richiesta in modalità con credenziali. Questo blocco si verifica anche se il valore del campo allowCredentials è impostato su true per motivi di sicurezza.
  • Quando allowOrigins contiene il carattere jolly *, il controller GKE Gateway non copia letteralmente il carattere jolly * dal campo allowOrigins alle intestazioni della risposta. Di conseguenza, il browser non bloccherà una risposta di questo tipo a una richiesta in modalità con credenziali, consentendo a qualsiasi sito potenzialmente dannoso di accedere ai dati utente. Per questo motivo, sconsigliamo vivamente una configurazione con le seguenti impostazioni: allowCredentials: true e allowOrigins con il carattere jolly *.
• maxAge: specifica per quanto tempo (in secondi) il browser può memorizzare nella cache la risposta preflight. Il valore predefinito è 5 secondi. Il valore deve essere 1 o superiore.

Limitazioni

• Solo gateway a cluster singolo: CORS non è supportato per i gateway multi-cluster.
• Incompatibilità con RequestRedirect: non puoi utilizzare un filtro CORS e un filtro RequestRedirect nella stessa regola di instradamento.
• Limiti delle espressioni regolari: il GKE Gateway Controller rappresenta internamente i pattern con caratteri jolly nel valore del campo allowOrigins come espressioni regolari. Esistono limiti all'utilizzo delle espressioni regolari, che influiscono sulle GatewayClass come segue:
  • Per la GatewayClass gke-l7-global-external-managed, puoi utilizzare una sola espressione regolare per listener del gateway (condivisa con altre funzionalità). Questa limitazione è soggetta alle regole del doppio conteggio, il che significa che la combinazione di un pattern con caratteri jolly con una corrispondenza PathPrefix non è supportata.
  • Per le GatewayClass gke-l7-regional-external-managed e gke-l7-rilb, puoi utilizzare fino a cinque espressioni regolari per nome host (condivise con altre funzionalità).
  • Il carattere jolly catch-all (*) non viene conteggiato ai fini di questi limiti.
  • Un singolo pattern con caratteri jolly in un filtro CORS può essere conteggiato più volte ai fini del limite delle espressioni regolari. Il controller GKE Gateway moltiplica un filtro CORS in una regola HTTPRoute per il numero di corrispondenze in quella regola. Inoltre, una corrispondenza di tipo PathPrefix viene conteggiata due volte, a meno che il percorso non sia /.

Per saperne di più sul comportamento CORS standard nell'API Gateway, consulta la guida dell'utente di CORS upstream.

Configura le intestazioni delle richieste e delle risposte personalizzate

Le intestazioni delle richieste e delle intestazioni della risposta personalizzate consentono di specificare intestazioni aggiuntive per le richieste e le risposte HTTP(S). A seconda delle informazioni rilevate dal bilanciatore del carico, queste intestazioni possono includere le seguenti informazioni:

• Latenza verso il client
• Posizione geografica dell'indirizzo IP del client
• Parametri della connessione TLS

Per impostazione predefinita, non vengono aggiunte intestazioni personalizzate alla richiesta inviata/ricevuta ai/dai tuoi servizi di backend. Devi configurare esplicitamente le intestazioni personalizzate utilizzando un filtro in HTTPRoute.

Puoi configurare intestazioni personalizzate aggiungendo una sezione di filtro nelle regole di HTTPRoute come segue:

Configura intestazioni della richiesta personalizzate

Crea un manifest HTTPRoute con un filtro RequestHeaderModifier e salvalo come http-route-request.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    <...>
    rules:
        filters:
          - type: RequestHeaderModifier
            requestHeaderModifier:
              <...>

Applica il manifest:

  kubectl apply -f http-route-request.yaml

Configura intestazioni delle risposte personalizzate

Crea un manifest HTTPRoute con un filtro ResponseHeaderModifier e salvalo come http-route-response.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store
spec:
  <...>
  rules:
      filters:
        - type: ResponseHeaderModifier
          responseHeaderModifier:
            <...>

Applica il manifest:

  kubectl apply -f http-route-response.yaml

Nota: il controller GKE Gateway implementa le intestazioni personalizzate nella mappa URL e non nel servizio di backend.

Puoi aggiungere, impostare e rimuovere le intestazioni come descritto nell'implementazione dell'API Gateway. Puoi configurare la risorsa HTTPRoute con un'intestazione personalizzata utilizzando le variabili supportate diGoogle Cloud .

Esempio 1:

Per configurare una risorsa HTTPRoute che aggiunga i dati sulla posizione del client alla richiesta HTTP prima di inviarla al servizio di backend, crea un manifest HTTPRoute e denominalo external-http-request.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /fr
        filters:
          # Add custom headers to requests that have `/fr` in the path.
          - type: RequestHeaderModifier
            requestHeaderModifier:
              add:
                - name: X-Client-Geo-Location
                  value: "{client_region},{client_city}"
        backendRefs:
          - name: store-french
            port: 8080

Ad esempio, per i client che si trovano a Strasburgo, in Francia, il gateway aggiunge un'intestazione come X-Client-Geo-Location:FR,Strasbourg.

Esempio 2:

Per configurare una risorsa HTTPRoute che aggiunge un'intestazione della risposta personalizzata per supportare HTTP Strict Transport Security, crea un manifest HTTPRoute e assegnagli il nome external-http-response.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /de
        filters:
          # Add custom headers to responses to requests that have `/de` in the
          # path.
          - type: ResponseHeaderModifier
            responseHeaderModifier:
              add:
                - name: Strict-Transport-Security
                  value: max-age=63072000
        backendRefs:
          - name: store-german
            port: 8080

Verifica la configurazione

1. Per verificare la configurazione dopo aver configurato le intestazioni delle richieste e delle risposte personalizzate:

     kubectl get httproute
   

   L'output è simile al seguente:

     NAME    HOSTNAMES               AGE
     store   ["store.example.com"]   4d23h
   

2. Per maggiori dettagli, utilizza il comando describe:

     kubectl describe httproute
   

   L'output è simile al seguente:

     Name:         store
     Namespace:    default
     Labels:       <none>
     Annotations:  <none>
     API Version:  gateway.networking.k8s.io/v1
     Kind:         HTTPRoute
     Metadata:
       Creation Timestamp:  2023-05-27T00:51:01Z
       Generation:          5
       Resource Version:    25418887
       UID:                 2e07a1b8-420b-41b4-acd1-cecbfcd39f42
     Spec:
       Hostnames:
         store.example.com
       Parent Refs:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   external-http
       Rules:
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-v1
           Port:    8080
           Weight:  1
         Matches:
           Path:
             Type:   PathPrefix
             Value:  /
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-v2
           Port:    8080
           Weight:  1
         Matches:
           Headers:
             Name:   env
             Type:   Exact
             Value:  canary
           Path:
             Type:   PathPrefix
             Value:  /
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-german
           Port:    8080
           Weight:  1
         Filters:
           Request Header Modifier:
             Add:
               Name:   X-Client-Geo-Location
               Value:  {client_region},{client_city}
           Type:       RequestHeaderModifier
         Matches:
           Path:
             Type:   PathPrefix
             Value:  /de
     Status:
       <...>
   

Configura la corrispondenza mediante espressione regolare

Il gateway GKE supporta la corrispondenza delle espressioni regolari per i percorsi, parametri di ricerca e le intestazioni HTTPRoute. Puoi utilizzare le espressioni regolari per definire regole di instradamento flessibili.

La corrispondenza delle espressioni regolari è supportata nelle seguenti GatewayClass:

• gke-l7-global-external-managed
• gke-l7-global-external-managed-mc
• gke-l7-regional-external-managed
• gke-l7-regional-external-managed-mc
• gke-l7-rilb
• gke-l7-rilb-mc
• gke-l7-cross-regional-internal-managed-mc

Limitazioni

• Sintassi RE2: è supportata solo la sintassi RE2. RE2 non supporta lookahead, lookbehind o riferimenti precedenti.
• Quote e limiti:
  • Numero massimo di corrispondenze di espressioni regolari: puoi configurare fino a cinque corrispondenze di espressioni regolari per ogni strumento di corrispondenza dei percorsi (HTTPRoute).
  • Lunghezza massima: la lunghezza massima di un'espressione regolare è di 250 caratteri.
• Impatto sulle prestazioni: la corrispondenza delle espressioni regolari è un'operazione complessa dal punto di vista computazionale. L'utilizzo di matcher di espressioni regolari può aumentare la latenza delle richieste:
  • Un matcher di espressioni regolari: aumento della latenza di circa 100 microsecondi per richiesta.
  • Cinque matcher di espressioni regolari: aumento della latenza di circa 200 microsecondi per richiesta.

Configura la corrispondenza delle espressioni regolari del percorso

Per configurare la corrispondenza dei percorsi utilizzando un'espressione regolare, nella regola di corrispondenza path, imposta il valore del campo type su RegularExpression.

Il seguente esempio indirizza le richieste, in cui il percorso corrisponde all'espressione regolare /videos/hd.* (ad esempio /videos/hd-123 o /videos/hd-promo.mp4), al servizio store-videos-hd:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store-path-regex
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - path:
        type: RegularExpression
        value: /videos/hd.*
    backendRefs:
    - name: store-videos-hd
      port: 8080

Configura la corrispondenza delle espressioni regolari dei parametri di query

Per trovare parametri di ricerca utilizzando un'espressione regolare, nella regola di corrispondenza queryParams, imposta il valore del campo type su RegularExpression.

L'esempio seguente indirizza le richieste, in cui il parametro di query param1 corrisponde all'espressione regolare .*param_value.*-hd, al servizio android-hd:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store-query-regex
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - queryParams:
      - name: param1
        type: RegularExpression
        value: .*param_value.*-hd
    backendRefs:
    - name: android-hd
      port: 8080

Configura la corrispondenza delle espressioni regolari delle intestazioni

Per trovare corrispondenze con le intestazioni HTTP utilizzando un'espressione regolare, nella regola di corrispondenza headers, imposta il valore del campo type su RegularExpression.

L'esempio seguente indirizza le richieste, in cui l'intestazione User-Agent corrisponde all'espressione regolare .*Android.*-hd, al servizio android-hd:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store-header-regex
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - headers:
      - name: User-Agent
        type: RegularExpression
        value: .*Android.*-hd
    backendRefs:
    - name: android-hd
      port: 8080

Configura mTLS di frontend

Per abilitare l'autenticazione dei certificati client, il bilanciatore del carico delle applicazioni Google fornisce mTLS frontend. Per i gateway GKE, mTLS frontend consente di configurare e applicare la convalida dei certificati client a tutte le risorse GatewayClass supportate, sia globali che regionali. Per saperne di più, consulta Configura mTLS di frontend per un gateway.

Configura TLS di backend

TLS autenticato dal backend è una funzionalità di sicurezza che consente al bilanciatore del carico del gateway GKE di verificare l'identità dei backend a cui si connette. Per i gateway GKE, questa funzionalità consente di configurare e applicare la convalida dei certificati di backend alle GatewayClass supportate, come i bilanciatori del carico gestiti esterni globali o regionali e i bilanciatori del carico interni regionali.

Per saperne di più, consulta Proteggi un gateway.

Per richiedere al gateway di autenticare anche la propria identità nei backend (mutual TLS), devi utilizzare un certificato client sulla risorsa gateway. Per le istruzioni, consulta Configura il mutual TLS (mTLS) di backend per un gateway.

Stato route

Le risorse HTTPRoute emettono condizioni ed eventi per aiutare gli utenti a capire se una risorsa HTTPRoute è stata associata correttamente a uno o più gateway o se è stata rifiutata.

Condizioni HTTPRoute

Le condizioni HTTPRoute indicano lo stato della route e dei gateway a cui è associata. Poiché una Route può essere associata a più Gateway, questo è un elenco di Gateway e delle singole condizioni tra la Route e ciascun Gateway.

• Accepted=True indica che HTTPRoute è stato associato correttamente a un gateway.
• Accepted=False indica che l'associazione di HTTPRoute con questo gateway è stata rifiutata.

Se non sono presenti gateway nell'intestazione Gateway bindings, le etichette HTTPRoute e i selettori di etichette del gateway potrebbero non corrispondere. Questo può accadere se la route non viene selezionata da nessun gateway.

Eventi HTTPRoute

Gli eventi HTTPRoute forniscono dettagli sullo stato della risorsa HTTPRoute. Gli eventi sono raggruppati in base ai seguenti motivi:

• Gli eventi ADD vengono attivati dall'aggiunta di una risorsa.
• Gli eventi UPDATE vengono attivati dall'aggiornamento di una risorsa.
• Gli eventi SYNC vengono attivati dalla riconciliazione periodica.

Unione, precedenza e convalida delle route

Precedenza delle route

L'API Gateway definisce rigide regole di precedenza per il modo in cui il traffico viene abbinato dalle route con regole di routing sovrapposte. La precedenza tra due HTTPRoute sovrapposte è la seguente:

1. Unione dei nomi host: la corrispondenza del nome host più lunga/specifica.
2. Unione dei percorsi: la corrispondenza del percorso più lungo/specifico.
3. Unione delle intestazioni: il maggior numero di intestazioni HTTP corrispondenti.
4. Conflitto: se le tre regole precedenti non stabiliscono la precedenza, questa viene assegnata alla risorsa HTTPRoute con il timestamp più vecchio.

Unione di route

Per le GatewayClass gke-l7, tutte le risorse HTTPRoute per un determinato gateway vengono unite nella stessa risorsa mappa URL. Il modo in cui le risorse HTTPRoute vengono unite dipende dal tipo di sovrapposizione tra le risorse HTTPRoute. La risorsa HTTPRoute dell'esempio precedente può essere suddivisa in tre risorse HTTPRoute separate per illustrare l'unione e la precedenza delle route:

1. Unione delle route: tutte e tre le risorse HTTPRoute si collegano allo stesso gateway internal-http, quindi vengono unite.
2. Unione dei nomi host: tutte e tre le route corrispondono a store.example.com, quindi le relative regole dei nomi host vengono unite.
3. Unione dei percorsi: store-german-route ha un percorso più specifico /de, quindi non viene unito ulteriormente. store-v1-route e store-v2-route corrispondono entrambi allo stesso percorso /*, quindi vengono uniti nel percorso.
4. Unione delle intestazioni: store-v2-route ha un insieme più specifico di corrispondenze di intestazioni HTTP rispetto a store-v1-route, quindi non vengono unite ulteriormente.
5. Conflitto: poiché le Routes possono essere unite in base a nome host, percorso e intestazioni, non esistono conflitti e tutte le regole di instradamento vengono applicate al traffico.

La singola risorsa HTTPRoute utilizzata nell'esempio precedente equivale a queste tre route separate:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-v1-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - kind: Service
      name: store-v1
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-v2-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: canary
    backendRefs:
    - kind: Service
      name: store-v2
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-german-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /de
    backendRefs:
    - kind: Service
      name: store-german
      port: 8080

Gateway Kubernetes e gateway Istio

Tieni presente che sia l'API Gateway di Kubernetes sia l'API Istio hanno una risorsa denominata Gateway. Sebbene svolgano funzioni simili, non sono la stessa risorsa. Se utilizzi Istio e l'API Gateway nello stesso cluster Kubernetes, questi nomi si sovrappongono quando utilizzi kubectl sulla riga di comando. kubectl get gateway potrebbe restituire le risorse Gateway Kubernetes e non le risorse Gateway Istio o viceversa.

$ kubectl api-resources
NAME       SHORTNAMES   APIGROUP                       NAMESPACED   KIND
gateways   gw           networking.istio.io/v1beta1    true         Gateway
gateways   gtw          networking.k8s.io/v1beta1      true         Gateway

Se utilizzi Istio ed esegui l'upgrade a GKE 1.20 e versioni successive, ti consigliamo di iniziare a utilizzare il nome breve della risorsa Gateway o di specificare il gruppo API. Il nome breve di un gateway Kubernetes è gtw, mentre quello di un gateway Istio è gw. I seguenti comandi restituiscono rispettivamente le risorse Gateway Kubernetes e Gateway Istio.

# Kubernetes Gateway
$ kubectl get gtw
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

$ kubectl get gateway.networking.x-k8s.io
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

# Istio Gateway
$ kubectl get gw
NAME               AGE
bookinfo-gateway   64m

$ kubectl get gateway.networking.istio.io
NAME               AGE
bookinfo-gateway   64m

Risoluzione dei problemi

Subnet solo proxy mancante nella regione

Sintomo:

Quando crei un gateway regionale (interno o esterno), potrebbe verificarsi il seguente problema:

generic::invalid_argument: error ensuring load balancer: Insert: Invalid value for field 'resource.target': 'regions/[REGION_NAME]/targetHttpProxies/gkegw-x5vt-default-internal-http-[ID]'. A reserved managed proxy subnetwork with purpose REGIONAL_MANAGED_PROXY is required.

Motivo:

Questo messaggio di errore indica che nella regione del gateway non esiste una subnet solo proxy.

Soluzione temporanea:

Per risolvere il problema, configura una subnet solo proxy.

La subnet solo proxy esiste già nella regione con lo scopo errato

Sintomo:

Il seguente problema potrebbe verificarsi quando crei una subnet solo proxy per il gateway regionale (interno o esterno):

ERROR: (gcloud.compute.networks.subnets.create) Could not fetch resource:
 - The resource 'projects/[PROJECT_NAME]/regions/[REGION_NAME]/subnetworks/[PROXY_ONLY_SUBNET_NAME]' already exists

Motivo:

Questo messaggio di errore indica che hai tentato di creare una subnet solo proxy a livello di regione in una regione che ne ha già una.

Soluzione temporanea:

Per risolvere il problema, segui questi passaggi:

1. Verifica che nella regione esista già una subnet solo proxy e che abbia lo scopo corretto:

   1. Elenca le subnet per trovare quella solo proxy nella regione:

      gcloud compute networks subnets list --regions=COMPUTE_REGION
      

      Sostituisci COMPUTE_REGION con la regione di Compute Engine in cui vuoi creare il gateway regionale.

   2. Descrivi la subnet solo proxy nella regione per trovarne lo scopo:

      gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
          --region COMPUTE_REGION | grep -E 'name|purpose'
      

      Sostituisci PROXY_ONLY_SUBNET con la subnet solo proxy.

   Il gateway GKE supporta solo subnet solo proxy REGIONAL_MANAGED_PROXY per i gateway regionali (interni o regionali).

2. Se la subnet solo proxy esistente nella regione è stata creata con uno scopo INTERNAL_HTTPS_LOAD_BALANCER, esegui la migrazione dello scopo a REGIONAL_MANAGED_PROXY.

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 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 criterio HealthCheckPolicy.

Risorse gateway orfane dopo l'eliminazione del cluster

Sintomo:

Quando provi a ricreare il gateway, le risorse del bilanciatore del carico gestite da GKE rimangono visibili nella console Google Cloud , ma non possono essere eliminate utilizzando la UI, che mostra un messaggio simile al seguente:

This load balancing service is read-only. It is managed by GKE and can be modified only by GKE.

Motivo:

Questo problema si verifica quando il controller del gateway non riesce a pulire le risorse Google Cloud sottostanti obsolete durante l'eliminazione e la nuova creazione del cluster o del gateway.

Soluzione temporanea:

Per risolvere il problema, elimina le risorse di bilanciamento del carico orfane utilizzando i comandi di Google Cloud CLI come segue:

gcloud compute forwarding-rules delete FORWARDING_RULE_NAME

# For HTTP proxies
gcloud compute target-http-proxies delete PROXY_NAME

# For HTTPS proxies
gcloud compute target-https-proxies delete PROXY_NAME

gcloud compute url-maps delete URL_MAP_NAME

# For global backend services
gcloud compute backend-services delete BACKEND_SERVICE_NAME --global

# For regional backend services
gcloud compute backend-services delete BACKEND_SERVICE_NAME --region=REGION

gcloud compute health-checks delete HEALTH_CHECK_NAME

gcloud compute network-endpoint-groups delete NEG_NAME --zone=ZONE

Sostituisci quanto segue:

• FORWARDING_RULE_NAME: il nome della regola di forwarding.
• PROXY_NAME: il nome del proxy di destinazione.
• URL_MAP_NAME: il nome della mappa URL.
• BACKEND_SERVICE_NAME: il nome del servizio di backend.
• HEALTH_CHECK_NAME: il nome del controllo di integrità.
• NEG_NAME: il nome del gruppo di endpoint di rete.
• REGION: la regione del servizio di backend regionale.
• ZONE: la zona del gruppo di endpoint di rete.

Passaggi successivi

• Scopri di più sul controller Gateway.
• Scopri come configurare le risorse Gateway utilizzando le policy.
• Scopri altre configurazioni di gateway nella documentazione dell'API Gateway.