Deployment dei gateway

Autopilot Standard

---

Questa pagina descrive come eseguire il deployment delle risorse gateway Kubernetes per il bilanciamento del carico del traffico in entrata in un singolo cluster Google Kubernetes Engine (GKE).

Per eseguire il deployment dei gateway per bilanciare il carico del traffico in entrata in più cluster (o parco risorse), consulta Deployment di gateway multi-cluster.

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
• Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: One of [--zone, --region] must be supplied: Please specify location.

Requisiti del controller gateway GKE

• Per Standard, GKE versione 1.24 o successive.

• Per Autopilot, GKE versione 1.26 o successive.
• Google Cloud CLI versione 407.0.0 o successive.
• L'API Gateway è supportata solo su cluster native VPC.
• Se utilizzi le classi di gateway interne, devi abilitare una subnet solo proxy.
• Nel cluster deve essere abilitato il componente aggiuntivo HttpLoadBalancing.
• Se utilizzi Istio, devi eseguire l'upgrade di Istio 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 all'account di servizio GKE per il progetto di servizio.

Limitazioni e limitazioni

• Le classi gateway GKE supportano funzionalità diverse a seconda del bilanciatore del carico utilizzato. Per saperne di più sulle diverse funzionalità supportate con ogni GatewayClass, consulta Funzionalità di GatewayClass.

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

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

• Puoi visualizzare nella console Google Cloud le risorse del bilanciatore del carico che GKE crea per i gateway, 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 crearlo manualmente e fare riferimento a un certificato SSL gestito da Google. Per maggiori informazioni, consulta Proteggere un gateway.

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

• Le intestazioni di richieste e risposte personalizzate con reindirizzamenti gateway o percorsi e riscritture di URL con gateway sono disponibili solo in GKE versione 1.27 o successive.

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

• Le seguenti variabili di intestazione Google Cloud non sono supportate:

  • cdn_cache_id (Cloud CDN non è supportato con il gateway GKE)
  • cdn_cache_status (Cloud CDN non è supportato con il gateway GKE)
  • origin_request_header (CORS non è supportato con il gateway GKE)

• Il gateway GKE non supporta la funzionalità di bilanciamento del carico di Cloud CDN.

• Le intestazioni personalizzate TLS reciproche non sono supportate (mTLS con gateway GKE non è supportato)

• Al gateway GKE si applicano le limitazioni del bilanciatore del carico delle applicazioni classico di Google Cloud, con un'ulteriore limitazione:

  • Non puoi configurare un'intestazione personalizzata della risposta dell'host nel servizio di backend.

• I reindirizzamenti dei percorsi e le riscritture di 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 gateway GKE, consulta Funzionalità di gatewayClass.

• Il gateway GKE non supporta caratteri jolly, espressioni regolari e URL dinamici.

• Se specifichi un gateway con una classe di gateway esterno a livello di regione, il controller esegue il provisioning di un indirizzo IP interno anziché di un indirizzo esterno. Per scoprire come utilizzare un indirizzo denominato con l'Application Load Balancer esterno regionale, vedi Eseguire il deployment di un gateway esterno regionale.

• Il gateway utilizza i NEG autonomi per il provisioning dei gruppi di endpoint di rete. Per garantire che il controller del gateway riconcilia 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 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 gateway riconcilia 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. Utilizza invece il campo appProtocol per ottenere lo stesso risultato.

Abilita l'API Gateway nel cluster

Prima di utilizzare le risorse gateway in GKE, è necessario che nel cluster sia abilitata l'API Gateway.

Crea un nuovo cluster con l'API Gateway abilitata

GKE supporta l'API Gateway sui cluster Autopilot a partire da GKE versione 1.26. Se crei nuovi cluster Autopilot su GKE 1.26 e versioni successive, l'API Gateway viene abilitata per impostazione predefinita. Per i cluster esistenti su GKE versione 1.25 e precedenti, l'API Gateway è disabilitata per impostazione predefinita.

Pilota automatico

Crea un nuovo cluster GKE Autopilot con l'API Gateway abilitata:

  gcloud container clusters create-auto CLUSTER_NAME \
      --location=CLUSTER_LOCATION \
      --release-channel=RELEASE_CHANNEL \
      --cluster-version=VERSION

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster.
• CLUSTER_LOCATION: la regione o zona di Compute Engine per il nuovo cluster.
• RELEASE_CHANNEL: il nome del canale di rilascio.
• VERSION: la versione di GKE, che deve essere 1.26 o successiva. Puoi anche utilizzare il flag --release-channel per selezionare un canale di rilascio. La versione predefinita del canale di rilascio deve essere 1.26 o successive.

Nota: non è necessario utilizzare gcloud flag --gateway-api=standard durante la creazione del cluster.

Standard

Con GKE Standard, l'API Gateway è controllata dal flag --gateway-api. Puoi utilizzare il valore standard durante l'attivazione e la disattivazione durante la disabilitazione.

Crea un nuovo cluster GKE nativo di VPC con l'API Gateway abilitata:

  gcloud container clusters create CLUSTER_NAME \
    --gateway-api=standard \
    --cluster-version=VERSION \
    --location=CLUSTER_LOCATION

Sostituisci quanto segue:

• RELEASE_CHANNEL: il nome del canale di rilascio.
• CLUSTER_NAME: il nome del cluster.
• VERSION: la versione di GKE, che deve essere 1.24 o successiva. Puoi anche utilizzare il flag --release-channel per selezionare un canale di rilascio. La versione predefinita del canale di rilascio deve essere 1.24 o successive.
• CLUSTER_LOCATION: la regione o zona di Compute Engine per il nuovo cluster.

Il flag --gateway-api=standard indica a GKE di installare i CRD v1beta1 con il cluster.

Abilita l'API Gateway su un cluster esistente

Nota: quando abiliti il gateway su un cluster esistente, potrebbero essere necessari fino a 45 minuti prima che il cluster esegua la riconciliazione e l'installazione delle CRD.

Assicurati che la versione del cluster Autopilot sia 1.26 o successiva e che la versione del cluster Standard sia 1.24 o successiva.

Per abilitare l'API Gateway su un cluster GKE esistente (Autopilot o Standard), utilizza quanto segue:

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 i CRD v1beta1 con il cluster.

Nota: se aggiorni un cluster GKE Standard esistente per abilitare l'API Gateway, assicurati che i requisiti minimi siano soddisfatti prima di procedere con l'aggiornamento. Per scoprire di più sull'upgrade della versione Standard del cluster, consulta Upgrade standard dei cluster. Per scoprire di più sull'upgrade della versione del cluster Autopilot, consulta Upgrade dei cluster Autopilot.

Verifica il cluster

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

1. Verifica che l'API Gateway sia abilitata nel piano di controllo 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 classi Gateway 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.

Nota: vengono installati automaticamente solo GatewayClass a cluster singolo. Per installare e utilizzare le classi di gateway multi-cluster per il bilanciamento del carico multi-cluster interno ed esterno, vedi Abilitare i gateway multi-cluster.

Esegui il deployment di un gateway interno

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

Esegui il deployment di un gateway interno a livello di regione

L'esempio seguente mostra come eseguire il deployment di un gateway interno a livello di regione che consente comunicazioni efficienti e sicure tra i servizi all'interno di una specifica regione geografica.

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 Application Load Balancer 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
   

   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 che contiene la subnet.
   • CIDR_RANGE: l'intervallo di indirizzi IP principali della subnet. Devi utilizzare una subnet mask non più lunga di /26 in modo che siano disponibili almeno 64 indirizzi IP 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:

   ...
   gatewayAddress: 10.1.1.1
   ipCidrRange: 10.1.1.0/24
   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
   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 del GatewayClass da cui è derivato. Per saperne di più sulla risorsa gateway, consulta la descrizione della risorsa gateway o la specifica API.

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

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

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: internal-http
   spec:
     gatewayClassName: gke-l7-rilb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
   

   Il file manifest include i seguenti campi:

   • gatewayClassName: gke-l7-rilb: specifica il GatewayClass da cui deriva il gateway. gke-l7-rilb corrisponde all'Application Load Balancer interno.
   • port: 80: specifica che il gateway espone solo la porta 80 per l'ascolto del traffico HTTP.

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:  1970-01-01T00:00:00Z
       Message:               Waiting for controller
       Reason:                NotReconciled
       Status:                False
       Type:                  Scheduled
   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
   

   A questo punto, c'è un gateway di cui è stato eseguito il deployment nel cluster che ha eseguito il provisioning di un bilanciatore del carico e di un indirizzo IP. Tuttavia, il gateway non ha route e non sa come inviare il traffico ai backend. Senza route, tutto il traffico passa a un backend predefinito, che restituisce un errore HTTP 404. Successivamente, eseguirai il deployment di un'applicazione e di Routes, che indicano al gateway come accedere ai backend delle applicazioni.

Esegui il deployment delle applicazioni demo

I team delle applicazioni possono eseguire il deployment delle applicazioni e delle route in modo indipendente dal deployment dei gateway. In alcuni casi, anche il team addetto all'applicazione potrebbe voler essere proprietario del gateway e implementarlo come risorsa dedicata alle applicazioni. Consulta Associazione di route per i diversi modelli di proprietà di gateway e route. In questo esempio, tuttavia, il team del negozio esegue il deployment dell'applicazione e di un HTTPRoute associato 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 HTTPRoute, consulta la specifica API.

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

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

   Questo crea tre deployment e tre servizi denominati store-v1, store-v2 e store-german.

2. Verifica che il deployment dell'applicazione sia stato eseguito correttamente:

   kubectl get pod
   

   Una volta eseguita l'applicazione, l'output sarà 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 stato implementato:

   kubectl get service
   

   L'output mostra un Service per ogni deployment del negozio:

   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 di route definiscono regole specifiche per il protocollo per la mappatura del traffico da un gateway ai backend Kubernetes. La risorsa HTTPRoute esegue la corrispondenza e l'applicazione di filtri al traffico HTTP e HTTPS ed è supportata da tutte le classi di gateway gke-l7.

In questa sezione eseguirai il deployment di una libreria HTTPRoute, che programma il gateway con le regole di routing necessarie per raggiungere l'applicazione del negozio.

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

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

2. Esegui il deployment della route HTTP nel cluster:

   kubectl apply -f store-route.yaml
   

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

   

   Queste regole di routing 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 viene indirizzato al servizio store-v1.

3. Verifica che sia stato eseguito il deployment di HTTPRoute:

   kubectl describe httproute store
   

   L'output è simile al seguente:

   Name:         store
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  gateway.networking.k8s.io/v1beta1
   Kind:         HTTPRoute
   <...>
   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",
     <...>
   

4. Verifica che HTTPRoute sia associato 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 il traffico alla tua applicazione

Ora che hai eseguito il deployment del gateway, della route e dell'applicazione nel cluster, puoi passare il traffico all'applicazione.

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 dalla shell su un'istanza di macchina virtuale (VM) con connettività al cluster. A questo scopo, puoi creare una VM. Questa operazione è necessaria perché il gateway ha un indirizzo IP interno ed è accessibile solo dall'interno della rete VPC. Poiché internal-http è un bilanciatore del carico a livello di regione, la shell del client deve trovarsi all'interno della stessa regione del cluster GKE.

   Poiché non possiedi il nome host example.com, imposta manualmente l'intestazione host in modo da poter osservare il routing del traffico. Innanzitutto, prova a richiedere store.example.com:

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

   Sostituisci VIP con l'indirizzo IP del passaggio precedente.

   L'output dell'app demo mostra le informazioni sulla posizione in cui viene eseguita 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-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 -H "host: store.example.com" VIP/de
   

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

   curl -H "host: store.example.com" -H "env: canary " VIP
   

   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 al VPC. Il deployment è simile a un deployment del 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 a livello di regione.

Un gateway esterno globale utilizza un indirizzo IP globale (o indirizzo IP Anycast) come frontend del gateway pubblicizzato in tutte le regioni di Google Cloud Compute. I client che inviano traffico a questo indirizzo IP Anycast vengono instradati alla località Google più vicina in cui viene pubblicizzato l'IP. Il gateway esterno globale è disponibile solo nel livello Premium di Network Service Tiers.

Un gateway esterno a livello di regione utilizza un IP a livello di regione come frontend del gateway pubblicizzato solo nella regione locale di Google Cloud Compute in cui viene eseguito il deployment del gateway esterno a livello di regione. I client che inviano traffico a questo indirizzo IP a livello di regione vengono instradati dal proprio ISP locale e su internet prima di raggiungere l'area geografica di Google in cui l'IP viene pubblicizzato. Il gateway esterno a livello di regione è disponibile solo nel livello di servizio di rete Standard.

Esegui il deployment di un gateway esterno globale

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

Crea una mappa di certificati

Google consiglia di utilizzare Gestione certificati per gestire i certificati se sono necessari almeno 15 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 maggiori informazioni, consulta Sicurezza del gateway.

In questa sezione creerai certificati utilizzando Gestore certificati per proteggere le applicazioni in esecuzione sul cluster.

1. Abilita l'API Certificate Manager:

   gcloud services enable certificatemanager.googleapis.com
   

2. Crea una mappa di certificati:

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

3. Carica le chiavi e il certificato 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 nuovo file che scegli. Il file deve avere l'estensione .pem. Ad esempio, cert.pem.
   • PRIVATE_KEY_FILE: il nome del file della chiave privata.

   Per maggiori informazioni, consulta Creare una chiave privata e un certificato.

4. Crea un oggetto CertificateMapEntry che assegna il certificato alla mappa di 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, come i secret di Kubernetes o i certificati SSL, vedi Proteggere 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 del GatewayClass che utilizza.

Per saperne di più sulla risorsa Gateway, consulta la descrizione della risorsa gateway o la specifica API.

In questa sezione creerai un gateway. I team addetti alle 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 manifest seguente in un file denominato gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     annotations:
       networking.gke.io/certmap: store-example-com-map
   spec:
     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 il GatewayClass per questo gateway. Questa classe del gateway utilizza un bilanciatore del carico delle applicazioni esterno globale.
   • protocol: HTTPS e port: 443: specifica che il gateway espone la porta 443 per il traffico HTTPS. Questi campi attivano TLS.
   • networking.gke.io/certmap: store-example-com-map: specifica il nome della mappa di certificati in Gestore certificati.

   Non è presente una sezione TLS perché TLS è configurato con Gestore certificati utilizzando l'annotazione networking.gke.io/certmap.

2. Applica il manifest al tuo cluster:

   kubectl apply -f gateway.yaml
   

   GKE potrebbe impiegare qualche minuto per eseguire il deployment delle risorse.

3. Verifica che il deployment del gateway sia stato eseguito correttamente:

   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 dispone di un bilanciatore del carico e di un indirizzo IP pubblico. Il gateway non ha route, ossia non può inviare traffico ai backend. Senza route, tutto il traffico passa a un backend predefinito, che restituisce una risposta HTTP 404. Nella sezione successiva, eseguirai il deployment delle route, che indicano al gateway di inviare traffico ai backend.

Esegui il deployment delle applicazioni demo

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

Per ulteriori informazioni sui campi HTTPRoute, consulta la specifica API.

1. Esegui il deployment dell'applicazione di esempio nel 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 stato eseguito correttamente:

   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 stato eseguito correttamente:

   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
   

Creazione di una HTTPRoute

Le risorse di route definiscono regole specifiche per il protocollo per la mappatura del traffico da un gateway ai backend Kubernetes. La risorsa HTTPRoute esegue l'applicazione di filtri e corrispondenze al traffico HTTP e HTTPS ed è supportata da tutte le classi di gateway gke-l7-*.

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

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

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

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

2. Applica il manifest al tuo cluster:

   kubectl apply -f store-route-external.yaml
   

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

   

   Le regole di routing elaborano il traffico HTTP nel seguente modo:

   • Il traffico verso store.example.com/de instrada al servizio store-german.
   • Il traffico verso store.example.com con l'intestazione HTTP "env: canary" viene indirizzato 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 di 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/v1beta1
   Kind:         HTTPRoute
   <...>
   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:
       Conditions:
         Last Transition Time:  2022-11-01T05:42:31Z
         Message:
         Reason:                Accepted
         Status:                True
         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 HTTPRoute sia associato al gateway:

   kubectl describe gateway external-http
   

   L'output è simile al seguente:

   Name:         external-http
   Namespace:    default
   Labels:       <none>
   <...>
   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
         <...>
   

Invia il traffico alla tua applicazione

Ora che hai eseguito il deployment del gateway, della route e dell'applicazione nel cluster, puoi passare il traffico all'applicazione.

1. Recupera 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 manualmente l'intestazione host perché non possiedi il nome host example.com.

   curl -H "host: store.example.com" https://GATEWAY_IP_ADDRESS --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.

   L'output mostra informazioni dall'app demo sul luogo in cui viene eseguita 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 -H "host: store.example.com" https://GATEWAY_IP_ADDRESS/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 "host: store.example.com" -H "env: canary " https://GATEWAY_IP_ADDRESS/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-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 a livello di regione

L'esempio seguente mostra come esporre un'applicazione di archiviazione con più certificati collegati al gateway esterno a livello di regione utilizzando certificati autogestiti e una HTTPRoute.

Crea una subnet proxy per il gateway a livello di regione

Devi configurare una subnet solo proxy prima di creare un gateway che utilizza un Application Load Balancer esterno regionale. Ogni regione di un VPC in cui utilizzi un Application Load Balancer 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 client

Puoi utilizzare un certificato emesso e convalidato dalla tua autorità di certificazione (CA) o crea un certificato autofirmato. Per ulteriori informazioni su come creare un certificato, consulta Archiviare un certificato in un secret di Kubernetes.

Nota: i certificati SSL CertificateMap o gestiti da Google non sono supportati con i gateway a livello di regione. Utilizza certificati o secret SSL a livello di regione autogestiti per proteggere il traffico tra i client e il gateway a livello di regione. Per saperne di più sui bilanciatori del carico di Certificate e Google Cloud, consulta Certificati e bilanciatori del carico Google Cloud

Crea un gateway HTTP(S) esterno a livello di regione

1. Crea un indirizzo IP statico a livello di regione 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 descritto di seguito e salva il manifest come regional-gateway.yaml:

     kind: Gateway
     apiVersion: gateway.networking.k8s.io/v1beta1
     metadata:
       name: external-regional-http
     spec:
       gatewayClassName: gke-l7-regional-external-managed
       listeners:
       - name: https
         protocol: HTTPS
         port: 443
         tls:
           mode: Terminate
           certificateRefs:
           - name: store-example-com
       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 ulteriori 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 in modo indipendente dal deployment dei gateway.

Per ulteriori informazioni su come eseguire il deployment delle applicazioni demo, vedi Eseguire il deployment delle applicazioni demo.

Creazione di una HTTPRoute

Devi creare una libreria HTTPRoute per applicare i filtri e la corrispondenza del traffico HTTP e HTTPS.

Invia il traffico alla tua applicazione

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

Per ulteriori informazioni su come inviare traffico alla tua applicazione, consulta Inviare traffico all'applicazione.

Utilizza gateway condivisi

Le API gateway utilizzano risorse separate, gateway e risorse route, per eseguire il deployment dei bilanciatori del carico e delle regole di routing. È 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 regole di routing separatamente e da parte di diversi utenti o team. In questo modo i gateway possono diventare gateway condivisi che si connettono a molte route diverse che possono essere interamente possedute 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 libreria HTTPRoute per abbinare il traffico dal gateway ai 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 manifest seguente in un file denominato site-route-internal.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: site-internal
   spec:
     parentRefs:
     - kind: Gateway
       name: internal-http
     hostnames:
     - "site.example.com"
     rules:
     - backendRefs:
       - name: site-v1
         port: 8080
   

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

3. Applica il manifest al tuo cluster:

   kubectl apply -f site-route-internal.yaml
   

4. Verifica che HTTPRoute sia collegato 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 la sezione Stato del percorso.

5. Verifica che il traffico al gateway sia 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.

   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"
   }
   

Configura il backend predefinito del gateway

Tutte le classi di gateway gke-l7-* restituiscono HTTP 404 al traffico senza corrispondenza. Puoi configurare il backend predefinito utilizzando una route predefinita esplicita che invia traffico senza corrispondenza a un servizio fornito dall'utente.

Nota: i gateway sono configurati per gestire codici di errore come 404 (Non trovato) e 500 (Errore del server) anche in assenza di definizioni di backend esplicite. Il comportamento predefinito può variare tra le implementazioni del gateway. Per un maggiore controllo sulla gestione degli errori, valuta la possibilità di configurare backend personalizzati.

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

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: custom-default-backend
spec:
  parentRefs:
  - kind: Gateway
    name: my-internal-gateway
  rules:
  - backendRefs:
    - name: my-custom-default-backend-service
      port: 8080

Questa connessione HTTPRoute corrisponde a tutto il traffico da un determinato gateway. Puoi avere una sola regola di questo tipo per ogni gateway, in caso contrario verrà applicato il conflitto tra le regole e l'ordinamento di precedenza.

Puoi usare un backend predefinito per impedire a qualcuno di creare una route predefinita di backend che instrada tutto il traffico del gateway. Una HTTPRoute esplicita ha sempre la precedenza sulle nuove HTTPRoutes con regole di routing 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 gateway fornisce automaticamente un indirizzo IP. Puoi anche creare un indirizzo IP statico in modo che esista indipendente dal ciclo di vita del gateway.

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

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

A seconda del GatewayClass, l'indirizzo IP viene allocato dalle seguenti subnet:

GatewayClasses	Pool di indirizzi IP predefinito
gke-l7-rilb gke-l7-rilb-mc	Indirizzi IP privati a livello di regione dall'intervallo di indirizzi IPv4/IPv6 del nodo principale
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Indirizzi IP pubblici a livello di regione dagli intervalli IPv4/IPv6 esterni di Google
gke-l7-global-external-managed gke-l7-global-external-managed-mc gke-l7-gxlb gke-l7-gxlb-mc	Indirizzi IP pubblici globali dagli intervalli IPv4/IPv6 esterni globali di Google

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

Utilizza un indirizzo IP denominato

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

1. Crea una risorsa indirizzo IP statico:

   gcloud compute addresses create IP_ADDRESS_NAME \
       --purpose=SHARED_LOADBALANCER_VIP \
       --region=COMPUTE_REGION \
       --subnet=SUBNET \
       --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: la subnet per l'indirizzo IP. Questo flag non è necessario per i gateway esterni globali.
   • PROJECT_ID: il progetto in cui è in esecuzione il cluster GKE.

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

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   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 il tuo 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
   

Configurare 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 nel gateway.

Per reindirizzare il traffico HTTP a HTTPS, configura un gateway in modo che gestisca il traffico sia HTTP che HTTPS. Se disabiliti HTTP o HTTPS, il gateway non reindirizza il traffico.

I seguenti esempi mostrano come utilizzare il reindirizzamento da HTTP a HTTPS per garantire che il traffico dai client alle applicazioni web sia sempre reindirizzato a una pagina sicura.

Nota: i reindirizzamenti da HTTP a HTTPS non sono supportati con le classi di gateway gke-l7-gxlb e gke-l7-gxlb-mc. Per ulteriori informazioni sulle diverse funzionalità supportate con ogni GatewayClass, consulta Funzionalità GatewayClass

Reindirizza il traffico HTTP dallo spazio dei nomi del gateway

Nell'esempio seguente, il gateway è configurato per consentire l'utilizzo di Same (Allegato dallo stesso spazio dei nomi) nel listener HTTP, mentre il listener HTTPS è aperto a tutti gli spazi dei nomi. Quando si utilizza questa configurazione, solo il reindirizzamento HTTPRoute deve esistere nello stesso spazio dei nomi del gateway.

Questa configurazione garantisce che nessuna ulteriore HTTPRoute possa essere associata al listener HTTP del gateway. Ciò richiede che le HTTPRoutes del team dell'applicazione non siano consentite nello spazio dei nomi gateway-infra.

1. Crea lo spazio dei nomi del gateway gateway-infra. Salva il manifest con il nome gateway-namespace.yaml:

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

2. Applica il manifest:

   kubectl apply -f gateway-namespace.yaml
   

3. Crea un gateway utilizzando il manifest seguente e salvalo come external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     namespace: gateway-infra
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: Same
     - name: https
       protocol: HTTPS
       port: 443
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: All
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: store-example-com
   

   • Il campo namespaces nella sezione allowedRoutes limita il listener HTTP solo allo spazio dei nomi gateway-infra del gateway.

   • Il listener https non include una restrizione sugli spazi dei nomi consentiti, pertanto tutti gli spazi dei nomi utilizzano il listener https con un HTTPRoute.

4. Applica il manifest:

   kubectl apply -f external-gateway.yaml
   

5. Per forzare il reindirizzamento HTTPS, crea una HTTPRoute predefinita utilizzando il seguente manifest e salva il manifest come redirect-httproute.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: redirect
     namespace: gateway-infra
   spec:
     parentRefs:
     - namespace: gateway-infra
       name: external-http
       sectionName: http
     rules:
     - filters:
       - type: RequestRedirect
         requestRedirect:
           scheme: https
   

   • Il campo sectionName indica al gateway di corrispondere solo all'elenco di attesa http. Il filtro RequestRedirect forza il reindirizzamento al listener https.

   Questa configurazione reindirizza il traffico ricevuto sulla porta 80 del gateway al listener sulla porta 443 per garantire una comunicazione sicura tra il client e il bilanciatore del carico.

6. Applica il manifest:

   kubectl apply -f redirect-httproute.yaml
   

7. Crea un servizio per un'applicazione utilizzando il manifest seguente. 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.2.20
           ports:
           - containerPort: 8080
           env:
           - name: METADATA
             value: "store-v1"
   

8. Applica il manifest:

   kubectl apply -f service-deployment.yaml
   

9. Creare un'HTTPRoute per un'applicazione che consente solo HTTPS. Salva il manifest come httproute.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http
       namespace: gateway-infra
       sectionName: https
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
   

10. Applica il manifest:

    kubectl apply -f httproute.yaml
    

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

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

L'esempio seguente limita ulteriormente l'utilizzo del listener HTTP per impedire l'uso involontario di protocollo non sicuro da parte dei team delle applicazioni. Questo esempio configura il gateway in modo da consentire a una HTTPRoute di utilizzare il listener HTTP solo se la route si trova in uno spazio dei nomi specifico (reindirizzamento HTTP), mentre il listener HTTPS viene aperto a tutti gli spazi dei nomi. Puoi limitare lo spazio dei nomi di reindirizzamento http utilizzando Kubernetes RBAC 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 con il nome 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
   

   • Per questo spazio dei nomi sono impostate etichette specifiche.

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 file manifest come external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     namespace: gateway-infra
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: selector
           selector:
             matchLabels:
               otherInfra: httpToHttps
     - name: https
       protocol: HTTPS
       port: 443
       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 HTTPRoute predefinita utilizzando il seguente manifest. Salva il file manifest come http-redirect.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: redirect
     namespace: http-redirect
   spec:
     parentRefs:
     - namespace: gateway-infra
       name: external-http
       sectionName: http
     rules:
     - filters:
       - type: RequestRedirect
         requestRedirect:
           scheme: https
   

   • Il campo sectionName indica al gateway di corrispondere solo all'elenco di attesa 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 manifest seguente. 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.2.20
           ports:
           - containerPort: 8080
           env:
           - name: METADATA
             value: "store-v1"
   

10. Applica il manifest:

    kubectl apply -f service-deployment.yaml
    

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

    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: store-external
      labels:
        gateway: external-http
    spec:
      parentRefs:
      - name: external-http
        namespace: gateway-infra
        sectionName: https
      hostnames:
      - "store.example.com"
      rules:
      - backendRefs:
        - name: store-v1
          port: 8080
    

12. Applica il manifest:

    kubectl apply -f http-route.yaml
    

Configurazione dei reindirizzamenti dei percorsi e delle riscritture degli URL

I reindirizzamenti del percorso prevedono 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 gli URL obsoleti o deprecati.

Le riscrittura degli URL aiutano a modificare l'URL in arrivo prima di elaborarlo sul server. Consente di 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 da capire. Per impostazione predefinita, i reindirizzamenti del percorso e le riscritture degli URL non sono configurati, devi configurare esplicitamente questi reindirizzamenti o le riformulazioni utilizzando un filtro nella tua HTTPRoute.

GKE Gateway supporta i reindirizzamenti dei percorsi e le riscritture degli URL. Per ulteriori informazioni, consulta la sezione Reindirizzamenti e riscritture del percorso HTTP.

Configura reindirizzamenti percorso

Puoi configurare i reindirizzamenti del percorso 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 HTTPRoute che sostituisca qualsiasi URL contenente il prefisso /any-path nel percorso dell'URL con il valore restrittivo /new-path.

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

     apiVersion: gateway.networking.k8s.io/v1beta1
     kind: HTTPRoute
     metadata:
       name: store
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - store.example.com
       rules:
       - matches:
         - path:
             type: PathPrefix
             value: /any-path
         filters:
         - type: RequestRedirect
           requestRedirect:
             path:
               type: ReplaceFullPath
               replaceFullPath: /new-path
             statusCode: 302
   

   Ad esempio, questo file manifest imposta una regola di routing per una HTTPRoute come segue: Qualsiasi route verso l'URL https://store.example.com/any-path/... deve essere reindirizzata a una nuova posizione, https://store.example.com/new-path/ (limite).

3. Applica il manifest:

   kubectl apply -f store.yaml
   

Questa regola di routing segue una regola di reindirizzamento rigida, ovvero il browser non tenta di memorizzare nella cache il reindirizzamento, ma reindirizza l'utente alla versione più recente.

Sostituisci solo un prefisso

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

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

   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: HTTPRoute
   metadata:
     name: store
   spec:
     parentRefs:
       - kind: Gateway
         name: external-http
     hostnames:
     - store.example.com
     rules:
     - matches:
         - path:
             type: PathPrefix
             value: /any-prefix
       filters:
       - type: RequestRedirect
         requestRedirect:
           path:
             type: ReplacePrefixMatch
             replacePrefixMatch: /new-prefix
           statusCode: 302
   

   Ad esempio, questo file manifest imposta una regola di routing per una HTTPRoute come segue: Qualsiasi route verso l'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 routing segue l'unica regola di reindirizzamento, che garantisce che il browser reindirizzi sempre alla stessa pagina prevista.

Configura riscrittura degli URL

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

Riscrivi l'intero nome host

Per riscrivere l'intero nome host:

1. Configura un filtro in una 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/v1beta1
     kind: HTTPRoute
     metadata:
       name: www
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - www.example.com
       rules:
       - filters:
         - type: URLRewrite
           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
   

Riscrivi usando i modificatori del percorso

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

Per riscrivere utilizzando i modificatori di percorso:

1. Configura un filtro in una HTTPRoute che indichi al gateway di sostituire le informazioni su "Host" nell'intestazione della richiesta da www.example.com a 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/v1beta1
     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
           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 riscritta a /de.

3. Applica il manifest:

   kubectl apply -f www.yaml
   

Verifica la configurazione

Per verificare che il filtro sia stato applicato dopo aver creato la tua HTTPRoute con i filtri di riscrittura degli URL o di reindirizzamento del percorso, procedi nel seguente modo:

kubectl get httproute www -o yaml

L'output è simile al seguente:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"gateway.networking.k8s.io/v1beta1","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 ulteriori dettagli, utilizza il comando describe:

kubectl describe httproute

Configurare intestazioni di richieste e risposte personalizzate

Le intestazioni di richieste e risposte 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 cliente
• Parametri della connessione TLS

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

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

Configura intestazioni delle richieste personalizzate

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

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

Applica il manifest:

  kubectl apply -f http-route-request.yaml

Configurare intestazioni delle risposte personalizzate

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

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

Applica il manifest:

  kubectl apply -f http-route-response.yaml

Nota: il controller gateway GKE implementa 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 HTTPRoute con un'intestazione personalizzata utilizzando le variabili supportate da Google Cloud.

Esempio 1:

Per configurare una HTTPRoute che aggiunga informazioni 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/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /fr
        filters:
          - type: RequestHeaderModifier
            requestHeaderModifier:
              add:
                - name: X-Client-Geo-Location
                  value: "{client_region},{client_city}"
        backendRefs:
          - name: store-french
            port: 8080

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

Esempio 2:

Per configurare una HTTPRoute che aggiunge un'intestazione della risposta personalizzata al fine di supportare HTTP Strict Transport Security, crea un manifest HTTPRoute e denominalo come external-http-response.yaml:

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /de
        filters:
          - 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 intestazioni di richiesta e risposta personalizzate:

     kubectl get httproute
   

   L'output è simile al seguente:

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

2. Per ulteriori 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/v1beta1
     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:
       <...>
   

Stato route

Le risorse HTTPRoute emettono condizioni ed eventi per aiutare gli utenti a capire se HTTPRoute è stato associato correttamente a uno o più gateway o se è stato rifiutato.

Condizioni HTTPRoute

Le condizioni HTTPRoute indicano lo stato della route e i gateway a cui è associata. Poiché una route può essere associata a più gateway, questo è un elenco di gateway e le singole condizioni tra la route e ogni gateway.

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

Se sotto l'intestazione Gateway bindings non è elencato alcun gateway, le etichette HTTPRoute e i selettori di etichette del gateway potrebbero non corrispondere. Questo può verificarsi se la tua route non è selezionata da alcun gateway.

Eventi HTTPRoute

Gli eventi HTTPRoute forniscono dettagli sullo stato di HTTPRoute. Gli eventi vengono raggruppati per i seguenti motivi:

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

Unione, precedenza e convalida delle route

Precedenza route

L'API Gateway definisce regole di precedenza rigide su come il traffico viene abbinato alle route che hanno regole di routing sovrapposte. La precedenza tra due HTTPRoute sovrapposte è la seguente:

1. Unione host: la corrispondenza più lunga/più specifica del nome host.
2. Unione di percorsi: la corrispondenza del percorso più lunga/più specifica.
3. Unione intestazioni: il numero più alto di intestazioni HTTP corrispondenti.
4. Conflitto: se le tre regole precedenti non stabiliscono la precedenza, la precedenza va alla risorsa HTTPRoute con il timestamp meno recente.

Unione del percorso

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

1. Unione delle route: tutte e tre le 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, pertanto le regole del nome host vengono unite.
3. Unione di percorso: store-german-route ha un percorso /de più specifico, che non viene quindi unito. store-v1-route e store-v2-route corrispondono entrambi allo stesso percorso /*, pertanto vengono uniti nel percorso.
4. Unione di intestazioni: store-v2-route ha un insieme più specifico di corrispondenze di intestazione HTTP rispetto a store-v1-route, quindi non vengono unite ulteriormente.
5. Conflitto: poiché è possibile unire le route per nome host, percorso e intestazioni, non esistono conflitti e tutte le regole di routing vengono applicate al traffico.

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

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
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/v1beta1
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/v1beta1
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 l'API Kubernetes Gateway e l'API Istio hanno entrambe una risorsa denominata Gateway. Sebbene svolgono 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 del gateway Kubernetes e non le risorse del gateway Istio e 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 di API. Il nome breve per un gateway Kubernetes è gtw, mentre il nome breve per 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 a livello di regione (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 nell'area geografica non esiste una subnet solo proxy per il tuo gateway.

Soluzione alternativa:

Per risolvere questo problema, configura una subnet solo proxy.

Una subnet solo proxy esiste già nella regione con lo scopo sbagliato

Sintomo:

Quando crei una subnet solo proxy per il gateway della tua regione (interno o esterno), potrebbe verificarsi il seguente problema:

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 dispone già di una subnet solo proxy.

Soluzione alternativa:

Per risolvere il problema:

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

   1. Elenca le tue 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 a livello di regione.

   2. Descrivi la tua 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 le subnet solo proxy REGIONAL_MANAGED_PROXY per i gateway a livello di regione (interni o regionali).

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

Passaggi successivi

• Scopri di più sul controller gateway.
• Scopri come configurare le risorse gateway utilizzando i criteri.