Questa pagina è stata tradotta dall'API Cloud Translation.

Deployment dei gateway

Autopilot . . Standard

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

Per il deployment dei gateway in modo da 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à:

Attiva l'API Google Kubernetes Engine.

Abilita l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi initialize con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
Nota: per gcloud CLI esistente di installazione, assicurati di impostare compute/region e compute/zone proprietà. Se imposti località predefinite, puoi evitare errori in gcloud CLI come i seguenti: 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 su Nativo VPC di cluster GKE.
Se si utilizzano le classi gateway interne, è necessario abilitare un 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 opzioni versions:
- 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.

Restrizioni e limitazioni

Le GatewayClass di GKE supportano diverse funzionalità a seconda al bilanciatore del carico che utilizzano. Per ulteriori informazioni sulle varie funzionalità supportato con ogni GatewayClass, Funzionalità GatewayClass.
Non puoi utilizzare un FrontendConfig o un BackendConfig per configurare un gateway. Devi utilizzare una norma.
Il gateway GKE si comporta in modo diverso da Ingress in quel 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 idoneità dei pod ottimizzati, devi configurare un criterio HealthCheckPolicy per il tuo servizio.
Non puoi specificare un numero di porta direttamente nel nome host (ad esempio, web.example.com:80) per l'instradamento del traffico.
Puoi visualizzare le risorse del bilanciatore del carico create da GKE gateway nella console Google Cloud, ma queste risorse non fanno riferimento Gateway o cluster GKE a cui sono collegati.

Non puoi generare automaticamente un certificato SSL gestito da Google Gateway ma puoi creare manualmente e fare riferimento a un protocollo SSL gestito da Google certificato. Per ulteriori informazioni, vedi Proteggi un gateway.

HTTPRoute è l'unico tipo di route supportato. TCPRoute, UDPRoutes e Le TLSRoute non sono supportate. Per visualizzare un elenco di campi in GKE, Il controller gateway, vedi Funzionalità GatewayClass.
Intestazioni di richiesta e risposta personalizzate con reindirizzamenti del gateway o del percorso e URL le riscritture con il gateway è disponibile solo su GKE versione 1.27 o in un secondo momento.

Per intestazioni di richiesta e risposta personalizzate con reindirizzamenti del gateway e del percorso e Riscrittura di URL con Gateway; il valore GatewayClass gke-l7-gxlb non è supportato.

Quando configuri le intestazioni personalizzate di richieste e risposte HTTPRoute, le seguenti variabili Google Cloud non sono supportati:
- 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 (criteri CORS non sono supportati con il gateway GKE)
Il gateway GKE non supporta il bilanciamento del carico di Cloud CDN funzionalità.

Le intestazioni TLS personalizzate reciproche non sono supportate (mTLS con GKE il gateway non è supportato).
Le limitazioni del bilanciatore del carico delle applicazioni classico di Google Cloud si applicano Gateway GKE con una limitazione aggiuntiva:
- Non puoi configurare un'intestazione della risposta dell'host personalizzata nel servizio di backend.
I reindirizzamenti dei percorsi e le riscritture degli URL si escludono a vicenda, non puoi utilizzare entrambi 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, vedi Funzionalità GatewayClass.
Il gateway GKE 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 . Per scoprire come utilizzare un indirizzo denominato con il bilanciatore del carico delle applicazioni esterno regionale, consulta Eseguire il deployment di un gateway esterno a livello di regione.
Il gateway utilizza NEG autonomi per il provisioning di gruppi di endpoint di rete. Per assicurarti che il gateway riconcilia correttamente la configurazione del bilanciatore del carico, modificare l'annotazione cloud.google.com/neg per un servizio che fa parte di nel gateway.
Il gateway GKE non supporta il riferimento a un servizio che è anche a cui fa riferimento un traffico 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 l'elemento gatewayClass aggiornato valore.
L'annotazione networking.gke.io/app-protocols non è supportata. Utilizza la Campo appProtocol per ottenere lo stesso risultato.

Abilita l'API Gateway nel tuo cluster

Prima di utilizzare le risorse gateway in GKE, il cluster deve disporre API Gateway abilitata.

Crea un nuovo cluster con l'API Gateway abilitata

GKE supporta l'API Gateway sui cluster Autopilot a partire da con GKE versione 1.26. Se crei nuovi cluster Autopilot GKE 1.26 e versioni successive, l'API Gateway è 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: il valore Regione o zona di Compute Engine per nel nuovo cluster.
RELEASE_CHANNEL: il nome del canale di rilascio.
VERSION: la versione GKE, che deve essere 1.26 o versioni successive. Puoi anche utilizzare il flag --release-channel per selezionare una canale di rilascio. Il canale di rilascio deve avere una versione predefinita di 1.26 o successiva.

Standard

Con GKE Standard, l'API Gateway è controllata --gateway-api flag. Puoi utilizzare il valore standard quando viene attivato e disattivato durante la disattivazione.

Crea un nuovo cluster GKE VPC nativo con 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 GKE, che deve essere 1.24 o versioni successive. Puoi anche utilizzare il flag --release-channel per selezionare una canale di rilascio. Il canale di rilascio deve avere una versione predefinita 1.24 o successiva.
CLUSTER_LOCATION: il valore Regione o zona di Compute Engine per il nuovo cluster.

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

Abilita l'API Gateway su un cluster esistente

Assicurati che la versione del cluster Autopilot sia 1.26 o successiva e che La versione standard del cluster 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: il valore Regione o zona di Compute Engine nel cluster.

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

Verifica il cluster

Dopo aver creato o eseguito l'upgrade del cluster, Il controller gateway GKE installa automaticamente GatewayClass. Potrebbe occorre qualche minuto affinché il controller riconosca i CRD e installi GatewayClass.

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

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, vedi Funzionalità GatewayClass.

Esegui il deployment di un gateway interno

Un gateway interno espone le applicazioni raggiungibili solo dall’interno VPC o di 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 regionale che consente una comunicazione efficiente e sicura tra i servizi all'interno di uno specifico 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 Il VPC in cui utilizzi i bilanciatori del carico delle applicazioni interni deve avere un server una subnet. 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 del VPC in cui crei la subnet solo proxy. Assicurati che sia uguale Rete VPC in cui si trova il cluster GKE e dove esegui il deployment del gateway. È importante per una comunicazione senza interruzioni tra il bilanciatore del carico e i servizi di backend.
- CIDR_RANGE: l'intervallo di indirizzi IP principali della subnet. Devi utilizzare una subnet mask non più lunga di /26, in modo che abbia almeno 64 sono disponibili 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. R Il gateway può rappresentare molti tipi diversi di bilanciamento del carico e routing a seconda del GatewayClass da cui deriva. Per saperne di più sulle Risorsa gateway; consulta la risorsa gateway o la specifica API.

In questo caso, l'amministratore del cluster GKE vuole creano un gateway che possa essere utilizzato da diversi team per esporre applicazioni aziendali. L'amministratore esegue il deployment del gateway e dell'applicazione i team eseguono il deployment delle 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 classe GatewayClass che questo Il gateway deriva da. gke-l7-rilb corrisponde alla il bilanciatore del carico delle applicazioni interno.
- port: 80: specifica che il gateway espone solo la porta 80 per l'ascolto per il traffico HTTP.
Esegui il deployment del gateway nel tuo cluster:
```
kubectl apply -f gateway.yaml
```

Verifica che il deployment del gateway sia stato eseguito correttamente. L'operazione potrebbe richiedere alcuni minuti per eseguire il deployment di 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:  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, nel tuo cluster è stato eseguito il deployment di un gateway che ha di cui è stato eseguito il provisioning di un bilanciatore del carico e di un indirizzo IP. Il gateway non ha route e quindi non sa come inviare il traffico ai backend. Senza route, tutto il traffico va a un backend predefinito, che restituisce un errore HTTP 404. Quindi, esegui il deployment di un'applicazione e delle route, che indicano al gateway per raggiungere i backend dell'applicazione.

Esegui il deployment delle applicazioni demo

I team delle applicazioni possono eseguire il deployment delle proprie applicazioni e delle proprie route il deployment dei gateway. In alcuni casi, il team addetto alla candidatura potrebbe voler possiedono anche il gateway e ne eseguono il deployment come risorsa dedicata le loro applicazioni. Vedi Percorso associazione per 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 la sua app tramite il gateway internal-http creato nella sezione precedente.

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

Esegui il deployment dell'applicazione store (deployment store-v1, store-v2 e store-german) nel 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-tedesco.

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 sia stato eseguito il deployment dei servizi:

kubectl get service

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

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

esegui il deployment di HTTPRoute

Le risorse route definiscono regole specifiche di protocollo per mappare il traffico da un Gateway per i backend Kubernetes. L'intestazione HTTPRoute di Google Cloud esegue HTTP Corrispondenza e filtri del traffico HTTPS ed è supportato da tutte le gke-l7 GatewayClass.

In questa sezione eseguirai il deployment di una HTTPRoute, che programma il gateway con e 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
```
La connessione HTTPRoute store è associata al gateway internal-http utilizzando il metodo proprietà parentRefs. Queste regole di routing sono configurate sulla piattaforma come in questo diagramma:

Queste regole di routing elaborano il traffico HTTP nel seguente modo:
- Il traffico verso store.example.com/de va al servizio store-german.
- Il traffico verso store.example.com con l'intestazione HTTP "env: canary" va a il servizio store-v2.
- Il traffico rimanente verso store.example.com va al servizio store-v1.

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

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 traffico alla tua applicazione

Ora che il deployment del gateway, della route e dell'applicazione è stato eseguito nel tuo cluster, può passare il traffico alla tua applicazione.

Recupera l'indirizzo IP dal gateway in modo da poter inviare il 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 di un'istanza di una macchina virtuale (VM) con connettività al cluster. Puoi crea una VM a questo scopo. Questo è necessario perché il gateway ha un indirizzo IP interno ed è accessibile dall'interno della rete VPC. Poiché internal-http è un bilanciatore del carico a livello di regione, la shell del client deve trovarsi nella stessa regione del cluster GKE.

Poiché non sei il proprietario del nome host example.com, imposta l'intestazione dell'host manualmente in modo da poter osservare il routing del traffico. Primo tentativo di richiesta 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 dell'app sia in esecuzione:
```
{
  "cluster_name": "gke1",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
  "pod_name": "store-v1-84b47c7f58-pmgmk",
  "pod_name_emoji": "💇🏼‍♀️",
  "project_id": "gateway-demo-243723",
  "timestamp": "2022-10-25T13:31:17",
  "zone": "ZONE_NAME"
}
```

Verifica la corrispondenza del percorso andando alla versione tedesca del servizio di archiviazione 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"
}

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

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 reti esterne al VPC. Il deployment è simile deployment interno di un gateway con la differenza che devi proteggere il tuo perché il gateway è accessibile alla rete internet pubblica.

Puoi creare un gateway esterno in due modi: un gateway esterno globale o a un gateway esterno regionale.

Un gateway esterno globale utilizza un indirizzo IP globale (o un indirizzo IP Anycast) il frontend del gateway pubblicizzato in tutte le regioni di computing di Google Cloud. I client che inviano traffico a questo indirizzo IP Anycast vengono instradati al più vicino Località Google in cui è pubblicizzato l'IP. Il gateway esterno globale è disponibile nel livello di servizio di rete Premium.

Un gateway esterno a livello di regione utilizza un IP a livello di regione come frontend del gateway è pubblicizzato solo nella regione locale di computing di Google Cloud in cui è stato eseguito il deployment del gateway esterno. Client che inviano traffico a questo indirizzo IP regionale vengono indirizzati dal loro ISP locale e su Internet prima di raggiungere il regione in cui è 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 dello store con più certificati collegati al gateway esterno globale e raggruppati in un certificato mappa utilizzando Gestore certificati e una HTTPRoute.

Crea una mappa di certificati

Google ti consiglia di utilizzare Gestore certificati per gestire i certificati quando hai bisogno di almeno 15 certificati per gateway utilizzare certificati con caratteri jolly.

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

In questa sezione, creerai certificati utilizzando Gestore certificati per proteggere le applicazioni in un cluster Kubernetes.

Abilita l'API Certificate Manager:

gcloud services enable certificatemanager.googleapis.com

Crea una mappa di 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 nuovo file che scegliere. Il file deve avere l'estensione .pem. Ad esempio: cert.pem.
- PRIVATE_KEY_FILE: nome della chiave privata .
Per ulteriori informazioni, vedi Crea una chiave privata e un certificato.

Crea un CertificateMapEntry che assegna il certificato a 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

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

Crea un gateway

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

In questa sezione devi creare un gateway. I team delle applicazioni possono utilizzare il gateway di esporre le proprie applicazioni a internet eseguendo il deployment di route in modo indipendente allegandoli 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 GatewayClass per questo gateway. Questa classe gateway utilizza un bilanciatore del carico delle applicazioni esterno globale.
- protocol: HTTPS e port: 443: specificano che il gateway espone la porta 443 per il traffico HTTPS. Questi campi attivano TLS.
- networking.gke.io/certmap: store-example-com-map: specifica il nome di la mappa di certificati in Gestore certificati.
Nessuna sezione TLS perché TLS è configurati con Gestore certificati utilizzando l'annotazione networking.gke.io/certmap.
Applica il manifest al cluster:
```
kubectl apply -f gateway.yaml
```
Il deployment delle risorse da parte di GKE potrebbe richiedere alcuni minuti.
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 tuo cluster ha un carico e un indirizzo IP pubblico. Il gateway non ha route, il che significa non possono inviare traffico ai backend. Senza Route, tutto il traffico viene indirizzato a una di 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 proprie applicazioni e delle proprie route il deployment dei gateway. In alcuni casi, il team addetto all'applicazione potrebbe decidere di ed eseguirne il deployment come risorsa dedicata diverse applicazioni. Consulta Associazione di route per diversi modelli di proprietà di gateway e route. In questo esempio, team del negozio esegue il deployment dell'applicazione e di una HTTPRoute associata la sua app tramite il gateway external-http creato nella sezione precedente.

Per ulteriori informazioni sui campi HTTPRoute, consulta specifica 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 hanno i nomi 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 una HTTPRoute

Le risorse route definiscono regole specifiche di protocollo per mappare il traffico da un Gateway per i backend Kubernetes. La Risorsa HTTPRoute effettua la corrispondenza e i filtri del traffico HTTP e HTTPS ed è supportato da tutti i le GatewayClass di gke-l7-*.

In questa sezione eseguirai il deployment di una HTTPRoute, che configura il gateway con e 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 file manifest descrive una HTTPRoute che fa riferimento a external-http Gateway.

Applica il manifest al cluster:
```
kubectl apply -f store-route-external.yaml
```
La connessione HTTPRoute store è associata al gateway external-http utilizzando il metodo proprietà parentRefs. Il 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 viene instradato al servizio store-german.
- Traffico verso store.example.com con route HTTP "env: canary" al servizio store-v2.
- Il traffico rimanente verso store.example.com viene instradato al servizio store-v1.

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

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 traffico alla tua applicazione

Ora che il deployment del gateway, della route e dell'applicazione è stato eseguito nel tuo cluster, può passare il traffico alla tua 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 il traffico all'indirizzo IP del gateway dalla VM. Devi impostare il parametro 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 di il gateway dal passaggio precedente.

L'output mostra le informazioni dell'app demo sulla posizione in cui dell'app sia in esecuzione:

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

Verifica la corrispondenza del percorso andando alla versione tedesca del servizio store alle ore 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"
}

Invia il traffico alla versione canary del servizio store utilizzando il metodo 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 dello store con più certificati collegati al gateway esterno a livello di regione tramite autogestiti e una 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 Un VPC in cui utilizzi un bilanciatore del carico delle applicazioni esterno regionale deve avere external_managed_proxy subnet. 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 ulteriori informazioni su come creare un vedi Archiviare un certificato in un secret di Kubernetes.

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

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 IP statico .
- COMPUTE_REGION: Compute Engine regione in cui è in esecuzione il cluster.

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

  kind: Gateway
  apiVersion: gateway.networking.k8s.io/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 in modo indipendente Gateway

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

Crea una HTTPRoute

Devi creare una HTTPRoute per eseguire HTTP e HTTPS corrispondenza e filtri del traffico.

Invia traffico alla tua applicazione

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

Per ulteriori informazioni su come inviare traffico al tuo vedi l'applicazione Invia il traffico alla tua applicazione.

Utilizza gateway condivisi

Le API Gateway utilizzano risorse separate, ovvero gateway e route, il deployment di bilanciatori del carico e regole di routing. È diverso da Ingress, combina tutto in un'unica risorsa. Suddividendo la responsabilità tra di risorse, il gateway abilita il bilanciatore del carico e le relative regole di routing separatamente e che devono essere distribuiti da utenti o team diversi. Questo consente ai gateway di diventare gateway condivisi che si collegano a molte route diverse che possono essere posseduti e gestiti da team indipendenti, anche 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 HTTPRoute per abbinare 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 una rete 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 ha associate correttamente al gateway. Per scoprire di più sullo stato vedi lo stato del percorso.

Verifica che il traffico verso il 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 come 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 senza corrispondenza. Tu puoi configurare il backend predefinito utilizzando una route predefinita esplicita che invia a un servizio fornito dall'utente.

Il seguente HTTPRoute è un esempio di come personalizzare il backend predefinito. Se applichi una connessione HTTPRoute simile alla seguente, questa ha la precedenza il 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 da un determinato gateway. Puoi avere solo una di queste regole per ogni gateway, altrimenti le regole saranno in conflitto viene applicato l'ordinamento precedente.

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 accetta sempre 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. In caso contrario un indirizzo IP sul gateway, quindi il controller gateway automaticamente fornisce un indirizzo IP. Puoi anche creare un indirizzo IP statico in modo che 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 di GatewayClass, l'indirizzo IP viene allocato dalle seguenti subnet:

GatewayClasses	Pool di indirizzi IP predefinito
gke-l7-rilb gke-l7-rilb-mc	Gli indirizzi IP privati a livello di regione intervallo di indirizzi IPv4/IPv6 del nodo primario
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Indirizzi IP pubblici a livello di regione da Intervalli IPv4/IPv6 esterni a livello di regione di Google
gke-l7-global-external-managed gke-l7-global-external-managed-mc gke-l7-gxlb gke-l7-gxlb-mc	Indirizzi IP pubblici globali da Intervalli IPv4/IPv6 esterni globali di Google

Il campo addresses.NamedAddress consente di specificare un indirizzo IP in modo indipendente del gateway. Puoi creare una risorsa di indirizzo IP statico prima del gateway deployment e NamedAddress fa riferimento alla risorsa. 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.

Crea una risorsa di 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 IP statico indirizzo
- COMPUTE_REGION: per i gateway regionali, Compute Engine regione 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 Il cluster GKE è in esecuzione.

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 file 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 funzionalità di reindirizzamento da HTTP a HTTPS. Un il 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 HTTP-to-HTTPS reindirizzamenti abilitati, entrambi i bilanciatori del carico vengono creati automaticamente. Le richieste all'indirizzo IP esterno del gateway sulla porta 80 vengono automaticamente reindirizzato 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 per gestire entrambi Traffico HTTP e HTTPS. Se disattivi HTTP o HTTPS, il gateway non reindirizzano il traffico.

I seguenti esempi mostrano come utilizzare il reindirizzamento da HTTP a HTTPS come mezzo per assicurarti che il traffico proveniente dai client verso le tue applicazioni web sia sempre viene reindirizzato a una pagina sicura.

Reindirizza il traffico HTTP dallo spazio dei nomi Gateway

Nell'esempio seguente, il gateway è configurato per consentire Same (collegamento dallo stesso spazio dei nomi) sul listener HTTP, mentre il listener HTTPS è aperto a tutti gli spazi dei nomi. Quando utilizzi questa configurazione, solo il reindirizzamento HTTPRoute deve esistere nello stesso spazio dei nomi del gateway.

Questa configurazione garantisce che nessun altro HTTPRoutes possa essere associato Listener HTTP del gateway. Ciò richiede che le chiavi HTTPRoute dell'applicazione team non consentiti nello spazio dei nomi gateway-infra.

Crea lo spazio dei nomi del gateway gateway-infra. 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 un gateway utilizzando il manifest seguente e 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: 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 la Listener http per lo spazio dei nomi gateway-infra solo del gateway.
Il listener https non include una limitazione sul valore consentito , quindi tutti gli spazi dei nomi utilizzano il listener https con un HTTPRoute.

Applica il manifest:
```
kubectl apply -f external-gateway.yaml
```
Per forzare il reindirizzamento HTTPS, crea un HTTPRoute predefinito utilizzando quanto segue manifest e salva il file 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 trovare corrispondenze solo nella pagina http e ascolto. Il filtro RequestRedirect forza il reindirizzamento all'evento listener https.
Questa configurazione reindirizza il traffico ricevuto sulla porta 80 del gateway a il listener sulla porta 443, applicando una comunicazione sicura tra il client tramite il bilanciatore del carico.

Applica il manifest:

kubectl apply -f redirect-httproute.yaml

Crea un servizio per un'applicazione utilizzando il manifest seguente. Salva 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"

Applica il manifest:

kubectl apply -f service-deployment.yaml

Crea un HTTPRoute per un'applicazione che consente solo HTTPS. Salva 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
```
Nota: quando configuri i reindirizzamenti da HTTP a HTTPS sul gateway, devi specificare il campo sectionName:https nella configurazione della route. Se il gateway ha configurati più listener (ad esempio, sia HTTP che HTTPS), devi specificare esplicitamente sectionName:https nella configurazione HTTPRoute. Questo assicura che il reindirizzamento venga applicato solo al listener HTTPS. Se il tuo gateway ha un solo listener HTTPS, puoi omettere il campo sectionName, poiché il un reindirizzamento viene applicato per impostazione predefinita.
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 l'infrastruttura dell'amministratore della piattaforma e dei team delle applicazioni, nonché di impedire l'uso improprio Il gateway può diventare una sfida.

L'esempio seguente limita ulteriormente l'utilizzo del listener HTTP per evitare l'uso involontario di un protocollo non sicuro da parte dei team delle applicazioni. Questo esempio configura il gateway in modo che consenta a HTTPRoute di utilizzare il listener HTTP solo se la route si trova in un determinato spazio dei nomi (reindirizzamento HTTP) 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 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 quanto segue del file 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 nella gateway-infra.
Il campo namespaces nella sezione allowedRoutes limita la listener http per lo spazio dei nomi corrispondente all'etichetta otherInfra: httpToHttps.

Applica il manifest:
```
kubectl apply -f external-gateway.yaml
```
Per forzare il reindirizzamento HTTPS, crea un HTTPRoute predefinito utilizzando quanto segue del file 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 trovare corrispondenze solo nella pagina http e ascolto. Il filtro RequestRedirect forza il reindirizzamento all'evento listener https.
Applica il manifest:
```
kubectl apply -f http-redirect.yaml
```

Crea un servizio per un'applicazione utilizzando il manifest seguente. Salva 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"

Applica il manifest:

kubectl apply -f service-deployment.yaml

Crea un HTTPRoute per un'applicazione che consente solo HTTPS utilizzando manifest successivo. 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
```

Configura i reindirizzamenti del percorso e le riscritture di URL

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

Riscritture degli URL aiutare a modificare l'URL in entrata prima di elaborarlo sul server. Ti permette di modificare la struttura o il formato dell'URL senza modificare effettivamente la parte sottostante o la struttura dei file. La riscrittura degli URL è utile per creare modelli e URL ottimizzati per la SEO che siano 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 riscritture utilizzando un filtro in HTTPRoute.

Il gateway GKE supporta i reindirizzamenti dei percorsi e le riscritture degli URL. Per ulteriori informazioni informazioni, consulta Reindirizzamenti e riscritture dei percorsi HTTP.

Configura i reindirizzamenti del percorso

Puoi configurare i reindirizzamenti del percorso in modo da sostituire l'intero percorso o solo nell'URL.

Sostituisci l'intero percorso

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

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 manifest imposta una regola di routing per una HTTPRoute come segue: Qualsiasi percorso verso l'URL https://store.example.com/any-path/... deve essere reindirizzato a una nuova posizione https://store.example.com/new-path/ (livello massimo).

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

Questa regola di routing segue una rigorosa regola di reindirizzamento, vale a dire che il browser non tenta di memorizzare nella cache il reindirizzamento, ma reindirizza alla versione più recente completamente gestita.

Sostituisci solo un prefisso

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

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 manifest imposta una regola di routing per una HTTPRoute come segue: Qualsiasi percorso verso l'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 browser reindirizza sempre alla stessa pagina prevista.

Configura la riscrittura degli URL

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

Riscrivi l'intero nome host

Per riscrivere l'intero nome host:

Configurare un filtro in una HTTPRoute che indichi al gateway di sostituire il valore Informazioni su Host nell'intestazione della richiesta da Da www.example.com a store.example.com prima di inoltrare la richiesta al servizio di backend.

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 https://www.example.com viene inoltrato a al servizio di backend con l'intestazione Host: store.example.com, anziché Host: www.example.com.

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

Riscrivi utilizzando i modificatori di percorso

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

Per riscrivere utilizzando i modificatori di percorso:

Configurare un filtro in una HTTPRoute che indichi al gateway di sostituire nella sezione "Host" informazioni nell'intestazione della richiesta Da www.example.com a store.example.com e sostituisci il valore /store con / prima di inoltrare la richiesta al di servizio di backend.

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 https://www.example.com/store/... è inoltrato al servizio di backend con Host: store.example.com nel dell'intestazione della richiesta (anziché Host: www.example.com) e /store è 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 la richiesta HTTPRoute con URL di riscrittura o reindirizzamenti 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

Configura intestazioni di richiesta e risposta personalizzate

Le intestazioni di richiesta e risposta personalizzate ti consentono di specificare Richieste e risposte HTTP(S). In base alle 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 a/da devi configurare esplicitamente le intestazioni personalizzate utilizzando nel tuo HTTPRoute.

Puoi configurare intestazioni personalizzate aggiungendo una sezione di filtro nel parametro 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

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 in Implementazione dell'API Gateway. Puoi configurare HTTPRoute con un'intestazione personalizzata utilizzando Variabili supportate da Google Cloud.

Esempio 1:

Per configurare un HTTPRoute che aggiunge informazioni sulla posizione del client all'interfaccia HTTP prima di inviarlo al servizio di backend, crea un manifest HTTPRoute e assegnale il nome 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 una come X-Client-Geo-Location:FR,Strasbourg.

Esempio 2:

Per configurare un HTTPRoute che aggiunge un'intestazione della risposta personalizzata per supportare il protocollo HTTP Strict Transport Security, crea un manifest HTTPRoute e assegnagli il nome 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 la richiesta e la risposta personalizzate intestazioni, procedi nel seguente modo:
```
  kubectl get httproute
```
L'output è simile al seguente:
```
  NAME    HOSTNAMES               AGE
  store   ["store.example.com"]   4d23h
```

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 un HTTPRoute è stato associato correttamente a uno o più gateway o è stato rifiutato.

Condizioni HTTPRoute

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

Accepted=True indica che HTTPRoute è associato correttamente a una Gateway.
Accepted=False indica che HTTPRoute è stato rifiutato dall'associazione con questo gateway.

Se non sono elencati gateway sotto l'intestazione Gateway bindings, la tua Le etichette HTTPRoute e i selettori delle etichette del gateway potrebbero non corrispondere. Ciò può verificarsi se la route non è selezionata da alcun gateway.

Eventi HTTPRoute

Gli eventi HTTPRoute forniscono dettagli sullo stato di HTTPRoute. Gli eventi sono raggruppate in base ai 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 da riconciliazione periodica.

Unione di route, precedenza e convalida

Precedenza route

L'API Gateway definisce il livello regole di precedenza per stabilire la corrispondenza del traffico con route con regole di routing sovrapposte. La la precedenza tra due HTTPRoute sovrapposte è la seguente:

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

Unione delle route

Per gke-l7 GatewayClass, tutti gli HTTPRoute per un determinato gateway vengono uniti in la stessa risorsa mappa URL. Come vengono utilizzati gli HTTPRoute unite dipende dal tipo di sovrapposizione tra HTTPRoute. La HTTPRoute dell'esempio precedente può essere suddiviso in tre HTTPRoute per illustrare l'unione e la precedenza delle route:

Unione di route: tutti e tre le HTTPRoute si collegano con lo stesso internal-http gateway in modo che vengano uniti.
Unione di nomi host: tutte e tre le route corrispondono a store.example.com, quindi le regole per i nomi host vengono unite.
Unione di percorsi: percorso negozio-germanico ha un percorso più specifico /de, quindi non viene ulteriormente unito. store-v1-route e store-v2-route corrispondono entrambe nella stessa route /* percorso, in modo che siano uniti nel percorso.
Unione di 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é è possibile unire le route in base a nome host, percorso non ci siano conflitti e tutte le regole di routing siano applicate per via del traffico.

Le singole HTTPRoute utilizzate nell'esempio precedente sono equivalenti 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 Istio Gateway

Tieni presente che l'API Kubernetes Gateway e l'API Istio hanno entrambe una risorsa denominato Gateway. Pur svolgendo funzioni simili, non sono le stesse risorsa. Se utilizzi Istio e l'API Gateway nello stesso ambiente in un cluster, questi nomi si sovrappongono quando si utilizza kubectl sulla riga di comando. kubectl get gateway potrebbe restituire le risorse del gateway Kubernetes e non alle risorse di 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 l'API gruppo. Il nome breve di un gateway Kubernetes è gtw e il nome breve di un Il gateway Istio è gw. I comandi seguenti restituiscono il gateway Kubernetes e le risorse del 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, potrebbe verificarsi il seguente problema (interno o esterno):

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 per il tuo gateway.

Soluzione:

Per risolvere il problema, configura un una subnet solo proxy.

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

Sintomo:

Quando crei una subnet solo proxy per la tua rete, può verificarsi il seguente problema 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 un server proxy a livello di regione una subnet in una regione che ha già una subnet solo proxy.

Soluzione:

Per risolvere il problema, attieniti alla procedura seguente:

Verifica che nella regione esista già una subnet solo proxy e verifica che ha lo scopo corretto:
1. Elenca le subnet per individuare quella solo proxy nella regione:
```
gcloud compute networks subnets list --regions=COMPUTE_REGION
```
  Sostituisci COMPUTE_REGION con Compute Engine regione in cui vuoi creare il gateway regionale.
2. Descrivi la subnet solo proxy nella regione per trovarne lo scopo:
```
gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
    --region COMPUTE_REGION | grep -E 'name|purpose'
```
  Sostituisci PROXY_ONLY_SUBNET con la subnet solo proxy.
Il gateway GKE supporta solo REGIONAL_MANAGED_PROXY solo proxy per i gateway a livello di regione (interni o a livello di regione).
Se la subnet solo proxy esistente nella regione è stata creata con un INTERNAL_HTTPS_LOAD_BALANCER scopo, esegui la migrazione del suo scopo a REGIONAL_MANAGED_PROXY.

Nessun upstream integro

Sintomo:

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

no healthy upstream

Motivo:

Questo messaggio di errore indica che il prober del controllo di integrità non riesce a trovare stato integro di backend. È 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 alle caratteristiche della tua applicazione (ad esempio, /health) utilizzando HealthCheckPolicy.

Passaggi successivi

Scopri di più sulle Controller gateway.
Scopri come Configura le risorse del gateway utilizzando i criteri.