Questa pagina è stata tradotta dall'API Cloud Translation.

Deployment dei gateway

Autopilot Standard

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

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

Per configurazioni di Gateway più specifiche, come il routing tra spazi dei nomi e la suddivisione del traffico HTTP, consulta le guide per l'utente dell'API Gateway.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

Attiva l'API Google Kubernetes Engine.

Attiva l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le località predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

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

Requisiti del controller GKE Gateway

Per Standard, GKE 1.24 o versioni successive.
Per Autopilot, GKE versione 1.26 o successive.
Google Cloud CLI versione 407.0.0 o successive.
L'API Gateway è supportata solo sui cluster VPC nativi.
Se utilizzi GatewayClasses interni, devi abilitare una subnet solo proxy.
Il cluster deve avere il componente aggiuntivo HttpLoadBalancing abilitato.
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.

Limitazioni e restrizioni

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

Le GatewayClass di GKE supportano funzionalità diverse a seconda del bilanciatore del carico utilizzato. 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.
Non puoi utilizzare un FrontendConfig o un BackendConfig per configurare un gateway. Devi utilizzare un criterio.
GKE Gateway si comporta in modo diverso da Ingress, in quanto Gateway non deduce i parametri del controllo di integrità. Se il tuo servizio non restituisce 200 per le richieste a GET / o hai altri controlli di disponibilità 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 ulteriori informazioni, consulta Proteggere un gateway.
HTTPRoute è l'unico tipo di route supportato. TCPRoutes, UDPRoutes e TLSRoutes non sono supportati. Per visualizzare un elenco dei campi supportati dal controller GKE Gateway, consulta la sezione Funzionalità di GatewayClass.
Le intestazioni delle richieste e delle risposte personalizzate con reindirizzamenti di gateway o percorso e la riscrittura degli URL con il gateway sono disponibili solo nella versione 1.27 o successive di GKE.
Per le intestazioni di richieste e risposte personalizzate con reindirizzamenti di gateway e percorsi e riscrittura degli URL con gateway, GatewayClass gke-l7-gxlb non è supportato.
Quando configuri le intestazioni di richiesta e risposta personalizzate HTTPRoute, le seguenti Google Cloud variabili non sono supportate:
- cdn_cache_id (Cloud CDN non è supportato con GKE Gateway)
- cdn_cache_status (Cloud CDN non è supportato con GKE Gateway)
- origin_request_header (le policy CORS non sono supportate con GKE Gateway)
GKE Gateway non supporta la funzionalità di bilanciamento del carico di Cloud CDN.
Le intestazioni personalizzate mutual TLS non sono supportate (mTLS con GKE Gateway non è supportato)
Google Cloud Si applicano le limitazioni del bilanciatore del carico delle applicazioni classico al gateway GKE. Inoltre, non puoi configurare un'intestazione della risposta Host personalizzata nel servizio di backend.
I reindirizzamenti del percorso 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.
GKE Gateway non supporta caratteri jolly, espressioni regolari e URL dinamici.
Se specifichi un gateway con una classe di gateway esterno regionale, il controller esegue il provisioning di un indirizzo IP interno anziché di quello 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.
Il gateway utilizza NEG autonomi per il provisioning dei gruppi di endpoint di rete. Per assicurarti che il controller 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.
GKE Gateway non supporta il riferimento a un servizio a cui fa riferimento anche un ingresso GKE.
Quando un Gateway è configurato per il provisioning di un indirizzo IP, la modifica del Gateway.spec.gatewayClass non è supportata. Per assicurarti che il controller Gateway riconcili correttamente il bilanciatore del carico, elimina il gateway esistente e 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.
Se utilizzi GKE Gateway 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 contribuisce a impedire l'eliminazione dei record DNS esistenti.
Se una porta viene rimossa da un Service a cui fa riferimento GKE Gateway tramite una route, devi aggiornare anche l'annotazione NEG autonomo sul servizio per rimuovere la porta. In caso contrario, il controller NEG alla fine smette di sincronizzare gli endpoint dei pod per questo servizio. Per maggiori dettagli, vedi NEG Controller stops managing endpoints when port removed from Service.

Abilita l'API Gateway nel cluster

Prima di utilizzare le risorse Gateway in GKE, il cluster deve avere l'API Gateway abilitata.

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 seguente comando. Questa operazione potrebbe richiedere fino a 45 minuti per la riconciliazione e l'installazione delle CRD nel cluster.

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

Verifica il cluster

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

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 di nuovo il comando di aggiornamento del cluster.

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

Verifica che GatewayClasses 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, vedi Funzionalità di GatewayClass.

Vengono installate automaticamente solo le GatewayClass a cluster singolo. Per installare e utilizzare le GatewayClass multi-cluster per il bilanciamento del carico multi-cluster interno ed esterno, consulta Attivazione di gateway multi-cluster.

Esegui il deployment di un gateway interno

Un gateway interno espone applicazioni raggiungibili solo dall'interno della VPC o delle reti connesse alla 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 specifica regione geografica.

Configura una subnet solo proxy

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

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 in cui crei questa subnet solo proxy. Assicurati che sia la stessa rete VPC in cui si trova il cluster GKE e in cui viene eseguito 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 IP principale della subnet. Devi utilizzare una subnet mask non superiore a /26 in modo che siano disponibili almeno 64 indirizzi IP per i proxy nella regione. La subnet mask consigliata è /23.

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 della GatewayClass da cui deriva. 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 loro applicazioni internamente. L'amministratore esegue il deployment del gateway e i team dell'applicazione eseguono il deployment delle proprie route in modo indipendente e le collegano a questo gateway.

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
```
Questo manifest include i seguenti campi:
- gatewayClassName: gke-l7-rilb: specifica la 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. Non supporta HTTPS (porta 443) per impostazione predefinita e, se tenti di connetterti tramite HTTPS, la richiesta potrebbe non riuscire.
Esegui il deployment del gateway nel tuo cluster:
```
kubectl apply -f gateway.yaml
```

Verifica che il gateway sia stato implementato correttamente. Potrebbero essere necessari alcuni minuti prima che vengano implementate tutte le risorse.

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

A questo punto, nel tuo cluster è stato eseguito il deployment di un gateway che ha provisionato un bilanciatore del carico e un indirizzo IP. Il gateway non ha route, e quindi non sa come inviare il traffico ai backend. Senza Routes, tutto il traffico viene indirizzato a un backend predefinito, che restituisce un errore HTTP 404. Successivamente, esegui il deployment di un'applicazione e di 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 e implementarlo autonomamente come risorsa dedicata alle proprie applicazioni. Consulta la sezione 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 una HTTPRoute di accompagnamento per esporre l'app tramite il internal-http Gateway creato nella sezione precedente.

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

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.

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

kubectl get pod

Dopo l'esecuzione dell'applicazione, 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

Verifica che i servizi siano stati implementati:

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

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

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

Esegui il deployment di HTTPRoute nel tuo cluster:
```
kubectl apply -f store-route.yaml
```
L'HTTPRoute store è associato al gateway internal-http utilizzando 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.

Verifica che HTTPRoute sia stato eseguito il deployment:

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",
  <...>

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

Inviare traffico alla tua applicazione

Ora che il gateway, la route e l'applicazione sono stati implementati nel cluster, puoi inoltrare 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.

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.
Invia 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. Questo è necessario perché il gateway ha un indirizzo IP interno ed è accessibile solo dall'interno della rete VPC. Poiché internal-http è un bilanciatore del carico regionale, la shell client deve trovarsi nella stessa regione del cluster GKE.

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

Testa la corrispondenza del percorso accedendo alla versione tedesca del servizio di 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"
}

Infine, utilizza l'intestazione HTTP env: canary per inviare il traffico alla versione canary del servizio di negozio:

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 applicazioni raggiungibili da internet o da reti esterne alla tua VPC. Il deployment è simile a un deployment del gateway interno, tranne per il fatto che devi proteggere le tue applicazioni perché il gateway è accessibile a internet pubblico.

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

Un gateway esterno globale utilizza un indirizzo IP globale (o un indirizzo IP anycast) come frontend del gateway pubblicizzato in tutte le regioni Google Cloud Compute. I client che inviano traffico a questo indirizzo IP Anycast vengono indirizzati alla posizione 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 regionale utilizza un IP regionale come frontend del gateway pubblicizzato solo nella regione Google Cloud Compute locale in cui è distribuito il gateway esterno regionale. I client che inviano traffico a questo indirizzo IP regionale vengono instradati dal proprio ISP locale e su internet prima di raggiungere la regione Google in cui viene pubblicizzato l'IP. Il gateway esterno regionale è 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 negozio con più certificati collegati al gateway esterno globale e raggruppati in una mappa dei certificati utilizzando Certificate Manager e un HTTPRoute.

Creare una mappa di certificati

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

Puoi anche proteggere il gateway esterno utilizzando i secret di Kubernetes o i certificati SSL gestiti da Google. Per ulteriori informazioni, vedi Sicurezza del gateway.

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

Abilita l'API Certificate Manager:

gcloud services enable certificatemanager.googleapis.com

Crea una mappatura dei certificati:

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

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ù, vedi Creare una chiave privata e un certificato.

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 Proteggere un gateway.

Crea un gateway

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 di sviluppo 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.

Salva il seguente manifest 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 la GatewayClass per questo gateway. Questa classe 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 abilitano TLS.
- networking.gke.io/certmap: store-example-com-map: specifica il nome della mappa di certificati in Certificate Manager.
Non è presente una sezione TLS perché TLS è configurato con Certificate Manager utilizzando l'annotazione networking.gke.io/certmap.
Applica il manifest al cluster:
```
kubectl apply -f gateway.yaml
```
Il deployment delle risorse potrebbe richiedere alcuni minuti.
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 viene indirizzato a un backend predefinito, che restituisce una risposta HTTP 404. Nella sezione successiva, esegui il deployment delle route, che indicano al gateway di inviare il traffico ai backend.

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 e implementarlo autonomamente come risorsa dedicata alle proprie applicazioni. Consulta la sezione 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 una HTTPRoute di accompagnamento per esporre l'app tramite il gateway external-http creato nella sezione precedente.

Per ulteriori informazioni sui campi HTTPRoute, consulta le specifiche dell'API.

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.

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

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

Crea un HTTPRoute

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

Salva il seguente manifest 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 un HTTPRoute che fa riferimento al gateway external-http.

Applica il manifest al cluster:
```
kubectl apply -f store-route-external.yaml
```
L'HTTPRoute store è associato al gateway external-http utilizzando la proprietà parentRefs. Il seguente diagramma 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 viene indirizzato 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.

Verifica che HTTPRoute sia stato eseguito il deployment:

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",
  ...

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

Inviare traffico alla tua applicazione

Ora che il gateway, la route e l'applicazione sono stati implementati nel cluster, puoi inoltrare il traffico all'applicazione.

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.

Crea una VM:
```
gcloud cloud-shell ssh
```

Invia traffico all'indirizzo IP del gateway dalla VM. Devi impostare manualmente l'intestazione host 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 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-09-25T13:31:17",
  "zone": "us-central1-a"
}

Testa la corrispondenza del percorso accedendo 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"
}

Invia 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 regionale

L'esempio seguente mostra come esporre un'applicazione di 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 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 Archiviare un certificato in un secret di Kubernetes.

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

Crea un gateway HTTP(S) esterno regionale

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 Compute Engine in cui è in esecuzione il cluster.

Crea un gateway 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/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

Applica il manifest regional-gateway:

  kubectl apply -f regional-gateway.yaml

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 indipendentemente dal deployment dei gateway.

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

Crea un HTTPRoute

Devi creare un HTTPRoute per eseguire la corrispondenza e il filtraggio del traffico HTTP e HTTPS.

Inviare traffico alla tua applicazione

Dopo aver eseguito il deployment dell'applicazione e creato HTTPRoute, puoi passare il traffico alla tua applicazione.

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

Utilizzare gateway condivisi

L'API Gateway utilizza risorse separate, gateway e route, per implementare bilanciatori del carico e regole di routing. A differenza di Ingress, che combina tutto in una sola risorsa. Dividendo la responsabilità tra le risorse, Gateway consente di eseguire il deployment del bilanciatore del carico e delle relative regole di routing separatamente e da parte di utenti o team diversi. Ciò consente ai gateway di diventare gateway condivisi che si collegano a molte route diverse che possono essere di proprietà e gestite completamente da team indipendenti, anche in spazi dei nomi diversi.

Eseguire il deployment delle route su un gateway condiviso

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

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

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

Salva il seguente manifest 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 un HTTPRoute che corrisponde a tutto il traffico per site.example.com e lo instrada al servizio site-v1.

Applica il manifest al cluster:

kubectl apply -f site-route-internal.yaml

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 saperne di più sul campo Stato, consulta Stato dell'itinerario.

Verifica che il traffico verso il gateway venga indirizzato 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"
}

Configura il backend predefinito del gateway

Tutte le gke-l7-* GatewayClass restituiscono HTTP 404 al 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 di backend esplicite. 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 HTTPRoute è un esempio di come personalizzare il backend predefinito. Se applichi una HTTPRoute simile alla seguente, ha la precedenza sul backend predefinito implicito:

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

Questo HTTPRoute corrisponde a tutto il traffico proveniente da un determinato gateway. Puoi avere una sola regola di questo tipo per ogni gateway, altrimenti le regole entrano in conflitto e si applica l'ordine di precedenza.

Puoi utilizzare un backend predefinito per impedire a qualcuno di creare una route predefinita Backend che instrada tutto il traffico del gateway. Una HTTPRoute esplicita ha sempre la precedenza sulle nuove HTTPRoute 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 del gateway fornisce automaticamente un indirizzo IP. 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 relativo indirizzo IP viene visualizzato nel campo dello stato:

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

A seconda di 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 regionali dall'intervallo di indirizzi IPv4/IPv6 del nodo primario
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Indirizzi IP pubblici regionali dagli intervalli IPv4/IPv6 esterni regionali 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 ti 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 referenziata da NamedAddress. Puoi riutilizzare l'indirizzo IP statico anche se il gateway viene eliminato.

Utilizzare un indirizzo IP denominato

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

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 regionali, la regione Compute Engine in cui è in esecuzione il cluster. Questo flag non è necessario per i gateway globali ed esterni.
- SUBNET: la subnet per l'indirizzo IP. Questo flag non è necessario per i gateway globali ed esterni.
- PROJECT_ID: il progetto in cui è in esecuzione il cluster GKE.

Salva il seguente manifest 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.

Applica il manifest al cluster:
```
kubectl apply -f named-ip-gateway.yaml
```

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

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 sul gateway.

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

Il seguente esempio mostra come utilizzare il reindirizzamento da HTTP a HTTPS per assicurarti che il traffico dei tuoi client diretto alle tue applicazioni web venga sempre reindirizzato a una pagina sicura.

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

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

In alcuni casi, non esiste una distinzione chiara tra il team di amministratori 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'uso involontario del protocollo non sicuro da parte dei team di sviluppo delle applicazioni. Questo esempio configura il gateway in modo da consentire a un HTTPRoute di utilizzare il listener HTTP solo se la route si trova in uno spazio dei nomi specifico (http-redirect), mentre apre il listener HTTPS a tutti gli spazi dei nomi. Puoi limitare lo spazio dei nomi http-redirect utilizzando Kubernetes RBAC in modo che i team delle applicazioni non possano creare un HTTPRoute in questo spazio dei nomi per errore.

Crea lo spazio dei nomi di un gateway. Salva il manifest come gateway-namespace.yaml:
```
apiVersion: v1
kind: Namespace
metadata:
  name: gateway-infra
```

Applica il manifest:

kubectl apply -f gateway-namespace.yaml

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.

Applica il manifest:

kubectl apply -f redirect-namespace.yaml

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/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.

Applica il manifest:
```
kubectl apply -f external-gateway.yaml
```

Per forzare il reindirizzamento HTTPS, crea una HTTPRoute predefinita utilizzando il seguente manifest. Salva il 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 eseguire la corrispondenza solo con il listener http. Il filtro RequestRedirect forza il reindirizzamento al listener https.

Applica il manifest:
```
kubectl apply -f http-redirect.yaml
```

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"

Applica il manifest:

kubectl apply -f service-deployment.yaml

Crea un 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/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

Applica il manifest:
```
kubectl apply -f http-route.yaml
```

Configurare i reindirizzamenti dei percorsi e le riscritture degli URL

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

Le riscritture degli URL consentono di modificare l'URL in entrata 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 intuitivi 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.

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

Configurare i 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

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

Crea un manifest HTTPRoute come segue e chiamalo 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 manifest imposta una regola di routing per un HTTPRoute nel seguente modo: Qualsiasi route all'URL https://store.example.com/any-path/... deve essere reindirizzato a una nuova posizione, https://store.example.com/new-path/ (rigoroso).

Applica il manifest:
```
kubectl apply -f store.yaml
```

Questa regola di routing 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.

Sostituire solo un prefisso

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

Crea un manifest HTTPRoute come segue e chiamalo 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 manifest imposta una regola di routing per un HTTPRoute nel seguente modo: Qualsiasi route all'URL https://store.example.com/any-path/v1/... deve essere reindirizzato a una nuova posizione, https://store.example.com/new-path/v1/... (solo).

Applica il manifest:
```
  kubectl apply -f store.yaml
```

Questa regola di routing segue l'unica regola di reindirizzamento, che garantisce che il browser ti reindirizzi sempre alla stessa pagina di destinazione.

Configurare le riscritture degli URL

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

Riscrivere l'intero nome host

Per riscrivere l'intero nome host:

Configura un filtro in un HTTPRoute che indica 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.

Crea un manifest HTTPRoute come segue e chiamalo 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.

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:

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

Crea un manifest HTTPRoute come segue e chiamalo 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 riscritto in /de.

Applica il manifest:
```
kubectl apply -f www.yaml
```

Verifica la configurazione

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

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 ottenere maggiori dettagli, utilizza il comando describe:

kubectl describe httproute

Configura intestazioni di richiesta e risposta personalizzate

Le intestazioni delle richieste e delle risposte personalizzate ti 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 da/a i tuoi servizi di backend. Devi configurare esplicitamente le intestazioni personalizzate utilizzando un filtro in HTTPRoute.

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

Configura le 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

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/v1beta1
kind: HTTPRoute
metadata:
  name: store
spec:
  <...>
  rules:
      filters:
        - type: ResponseHeaderModifier
          responseHeaderModifier:
            <...>

Applica il manifest:

  kubectl apply -f http-route-response.yaml

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.Google Cloud

Esempio 1:

Per configurare una HTTPRoute che aggiunge le informazioni sulla posizione del client alla richiesta HTTP prima di inviarla al servizio di backend, crea un manifest HTTPRoute e chiamalo 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 di risposta personalizzata per supportare HTTP Strict Transport Security, crea un manifest HTTPRoute e chiamalo 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

Per verificare la configurazione dopo aver configurato le intestazioni di richieste e risposte personalizzate:
```
  kubectl get httproute
```
L'output è simile al seguente:
```
  NAME    HOSTNAMES               AGE
  store   ["store.example.com"]   4d23h
```

Per ottenere 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/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 generano condizioni ed eventi per aiutare gli utenti a capire se una 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'HTTPRoute è stato rifiutato dal binding con questo gateway.

Se non sono elencati gateway nell'intestazione Gateway bindings, è possibile che i selettori di etichette HTTPRoute e le etichette Gateway non corrispondano. Ciò può verificarsi se la tua route non viene 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 dall'aggiornamento di una risorsa.
Gli eventi SYNC vengono attivati dalla riconciliazione periodica.

Unione, precedenza e convalida delle route

Priorità route

L'API Gateway definisce regole di precedenza rigorose per la corrispondenza del traffico con le route che hanno regole di routing sovrapposte. La precedenza tra due HTTPRoute sovrapposte è la seguente:

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

Unione di itinerari

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

Unione delle route: tutte e tre le HTTPRoute vengono associate allo stesso gateway internal-http, quindi vengono unite.
Unione dei nomi host: tutte e tre le route corrispondono a store.example.com, quindi le relative regole per i nomi host vengono unite.
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 entrambe allo stesso percorso /*, quindi vengono unite nel percorso.
Unione delle intestazioni: store-v2-route ha un insieme più specifico di corrispondenze delle intestazioni HTTP rispetto a store-v1-route, quindi non vengono unite ulteriormente.
Conflitto: poiché le route possono essere unite in base a nome host, percorso e intestazioni, non ci sono conflitti e tutte le regole di routing vengono applicate al traffico.

La singola HTTPRoute utilizzata nell'esempio precedente è equivalente 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 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 dalla riga di comando. kubectl get gateway potrebbe restituire le risorse Kubernetes Gateway e non le risorse Istio Gateway 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, è consigliabile iniziare a utilizzare il nome breve della risorsa Gateway o specificare il gruppo API. Il nome breve di un gateway Kubernetes è gtw e il nome breve di un gateway Istio è gw. I seguenti comandi restituiscono rispettivamente le risorse Kubernetes Gateway e Istio Gateway.

# 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 non esiste alcuna subnet solo proxy nella regione per il tuo gateway.

Soluzione:

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 tuo 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 regionale in una regione che ne ha già una.

Soluzione:

Per risolvere il problema, procedi nel seguente modo:

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 scoprirne 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.
GKE Gateway supporta solo le subnet proxy-only REGIONAL_MANAGED_PROXY per i gateway regionali (interni o regionali).
Se la subnet solo proxy esistente nella regione è stata creata con uno scopo INTERNAL_HTTPS_LOAD_BALANCER, migra il suo 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 probe di controllo di integrità non riesce a trovare servizi di backend integri. È possibile che i tuoi servizi di backend siano integri, ma potresti dover personalizzare i controlli di integrità.

Soluzione:

Per risolvere il problema, personalizza il controllo di integrità in base ai requisiti della tua applicazione (ad esempio, /health) utilizzando un HealthCheckPolicy.

Passaggi successivi

Scopri di più sul controller del gateway.
Scopri come configurare le risorse Gateway utilizzando i criteri.
Scopri di più su altre configurazioni del gateway nella documentazione dell'API Gateway.

Deployment dei gateway Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Prima di iniziare

Requisiti del controller GKE Gateway

Limitazioni e restrizioni

Abilita l'API Gateway nel cluster

Verifica il cluster

Esegui il deployment di un gateway interno

Esegui il deployment di un gateway interno regionale

Configura una subnet solo proxy

Crea un gateway

Esegui il deployment delle applicazioni demo

Esegui il deployment di HTTPRoute

Inviare traffico alla tua applicazione

Esegui il deployment di un gateway esterno

Esegui il deployment di un gateway esterno globale

Creare una mappa di certificati

Crea un gateway

Esegui il deployment delle applicazioni demo

Crea un HTTPRoute

Inviare traffico alla tua applicazione

Esegui il deployment di un gateway esterno regionale

Crea una subnet proxy per il gateway regionale

Crea un certificato per proteggere il traffico client

Crea un gateway HTTP(S) esterno regionale

Esegui il deployment dell'applicazione demo

Crea un HTTPRoute

Inviare traffico alla tua applicazione

Utilizzare gateway condivisi

Eseguire il deployment delle route su un gateway condiviso

Configura il backend predefinito del gateway

Configura un indirizzo IP statico per un gateway

Utilizzare un indirizzo IP denominato

Configurare i reindirizzamenti da HTTP a HTTPS

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

Configurare i reindirizzamenti dei percorsi e le riscritture degli URL

Configurare i reindirizzamenti percorso

Sostituisci l'intero percorso

Sostituire solo un prefisso

Configurare le riscritture degli URL

Riscrivere l'intero nome host

Riscrittura utilizzando i modificatori di percorso

Verifica la configurazione

Configura intestazioni di richiesta e risposta personalizzate

Configura le intestazioni delle richieste personalizzate

Configura intestazioni delle risposte personalizzate

Verifica la configurazione

Stato route

Condizioni HTTPRoute

Eventi HTTPRoute

Unione, precedenza e convalida delle route

Priorità route

Unione di itinerari

Gateway Kubernetes e gateway Istio

Risoluzione dei problemi

Subnet solo proxy mancante nella regione

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

Nessun upstream integro

Passaggi successivi

Deployment dei gateway