Questa pagina descrive come eseguire il deployment delle risorse gateway Kubernetes per il bilanciamento del carico del traffico in entrata in un singolo cluster Google Kubernetes Engine (GKE).
Per eseguire il deployment dei gateway per bilanciare il carico del traffico in entrata in più cluster (o nel parco risorse), consulta Deployment di gateway multi-cluster.Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Abilita l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività, installa e quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo
gcloud components update
.
Requisiti del controller gateway GKE
- Per Standard, GKE versione 1.24 o successive.
- Per Autopilot, GKE versione 1.26 o successive.
- Google Cloud CLI versione 407.0.0 o successive.
- L'API Gateway è supportata solo sui cluster nativi VPC.
- Se utilizzi GatewayClass interni, devi abilitare una subnet solo proxy.
- Nel cluster deve essere abilitato il componente aggiuntivo
HttpLoadBalancing
. - Se utilizzi Istio, devi eseguire l'upgrade di Istio a una delle seguenti
versioni:
- 1.15.2 o versioni successive
- 1.14.5 o versioni successive
- 1.13.9 o versioni successive.
- Se utilizzi un VPC condiviso, nel progetto host devi assegnare il ruolo
Compute Network User
all'account di servizio GKE per il progetto di servizio.
Restrizioni e limitazioni
Le GatewayClass di GKE supportano diverse a seconda del bilanciatore del carico utilizzato. Per saperne di più sulle diverse funzionalità supportate con ogni GatewayClass, consulta Funzionalità di GatewayClass.
Non puoi utilizzare FrontendConfig o BackendConfig per configurare un gateway. Devi utilizzare una norma.
Il gateway GKE si comporta in modo diverso rispetto a Ingress, in quanto non deduce i parametri del controllo di integrità. Se il tuo servizio non restituisce 200 per le richieste a
GET /
o se hai altri controlli di idoneità dei pod ottimizzati, devi configurare un HealthCheckPolicy per il tuo servizio.Non puoi specificare un numero di porta direttamente nel nome host (ad esempio, web.example.com:80) per il routing del traffico.
Puoi visualizzare le risorse del bilanciatore del carico create da GKE per i gateway nella console Google Cloud, ma queste risorse non fanno riferimento al gateway o al cluster GKE a cui sono collegate.
Non puoi generare automaticamente un certificato SSL gestito da Google con i gateway, ma puoi creare manualmente e fare riferimento a un certificato SSL gestito da Google. Per ulteriori informazioni, consulta Proteggere un gateway.
HTTPRoute è l'unico tipo di route supportato. Le route TCP, UDPRoute e TLS non sono supportate. Per visualizzare un elenco dei campi supportati dal controller gateway GKE, vedi Funzionalità GatewayClass.
Le intestazioni delle richieste e delle risposte personalizzate con i reindirizzamenti del gateway o del percorso e le riscritture degli URL con il gateway sono disponibili solo su GKE versione 1.27 o successive.
- Per le intestazioni di richiesta e risposta personalizzate con reindirizzamenti del gateway e del percorso e delle riscritture degli URL con Gateway, l'elemento GatewayClass
gke-l7-gxlb
non è supportato.
Quando configuri le intestazioni di richiesta e risposta personalizzate HTTPRoute, le seguenti variabili Google Cloud non sono supportate:
cdn_cache_id
(Cloud CDN non è supportato con il gateway GKE)cdn_cache_status
(Cloud CDN non è supportato con il gateway GKE)origin_request_header
(i criteri CORS non sono supportati con il gateway GKE)
Il gateway GKE non supporta la funzionalità di bilanciamento del carico di Cloud CDN.
Le intestazioni personalizzate TLS reciproche non sono supportate (mTLS con il gateway GKE non è supportato)
Al gateway GKE si applicano le limitazioni del bilanciatore del carico delle applicazioni classico di Google Cloud 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 i filtri contemporaneamente nelle stesse regole.
Il reindirizzamento del traffico a una porta diversa non è supportato con Cloud Load Balancing. Per visualizzare l'elenco dei campi supportati dal controller gateway GKE, 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 a livello di regione, il controller esegue il provisioning di un indirizzo IP interno anziché di un indirizzo esterno. Per scoprire come utilizzare un indirizzo denominato con il bilanciatore del carico delle applicazioni esterno regionale, consulta Eseguire 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.Il gateway GKE non supporta i riferimenti a un servizio a cui fa riferimento anche un GKE Ingress.
Quando un
Gateway
è configurato per eseguire il provisioning di un indirizzo IP, la modifica delGateway.spec.gatewayClass
non è supportata. Per assicurarti che il controller gateway riconcilia correttamente il bilanciatore del carico, elimina il gateway esistente ed esegui nuovamente il deployment del manifest con il valoregatewayClass
aggiornato.L'annotazione
networking.gke.io/app-protocols
non è supportata. Utilizza il campoappProtocol
invece per ottenere lo stesso risultato.
Abilita l'API Gateway nel tuo cluster
Prima di utilizzare le risorse Gateway in GKE, nel cluster deve essere abilitata l'API Gateway.
Crea un nuovo cluster con l'API Gateway abilitata
GKE supporta l'API Gateway sui cluster Autopilot a partire dalla versione 1.26 di GKE. Se crei nuovi cluster Autopilot su 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
: regione o zona di Compute Engine per il nuovo cluster.RELEASE_CHANNEL
: il nome del canale di rilascio.VERSION
: la versione GKE, che deve essere 1.26 o successiva. Puoi anche utilizzare il flag--release-channel
per selezionare un 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 dal flag --gateway-api
. Puoi utilizzare il valore standard quando viene attivato e disattivato durante la disattivazione.
Crea un nuovo cluster GKE VPC nativo con l'API Gateway abilitata:
gcloud container clusters create CLUSTER_NAME \
--gateway-api=standard \
--cluster-version=VERSION \
--location=CLUSTER_LOCATION
Sostituisci quanto segue:
RELEASE_CHANNEL
: il nome del canale di rilascio.CLUSTER_NAME
: il nome del cluster.VERSION
: la versione GKE, che deve essere 1.24 o successiva. Puoi anche utilizzare il flag--release-channel
per selezionare un canale di rilascio. Il canale di rilascio deve avere una versione predefinita 1.24 o successiva.CLUSTER_LOCATION
: la regione o la zona di Compute Engine per il nuovo cluster.
Il flag --gateway-api=standard
indica a GKE di installare
i CRD v1beta1
con il cluster.
Abilita l'API Gateway su un cluster esistente
Assicurati che la versione del cluster Autopilot sia 1.26 o successiva e che la versione del cluster Standard sia 1.24 o successiva.
Per abilitare l'API Gateway su un cluster GKE esistente (Autopilot o Standard), utilizza quanto segue:
gcloud container clusters update CLUSTER_NAME \
--location=CLUSTER_LOCATION\
--gateway-api=standard
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster esistente.CLUSTER_LOCATION
: la regione o la zona di Compute Engine del cluster.
Il flag --gateway-api=standard
indica a GKE di installare
i CRD v1beta1
con il cluster.
Verifica il cluster
Dopo aver creato o eseguito l'upgrade del cluster, il controller gateway GKE installa automaticamente GatewayClass. Potrebbero essere necessari alcuni minuti prima che il controller riconosca i CRD e installi le 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à di GatewayClass.
Esegui il deployment di un gateway interno
Un gateway interno espone le applicazioni raggiungibili solo dall'interno del VPC o dalle reti connesse al VPC.
Esegui il deployment di un gateway interno a livello di regione
L'esempio seguente mostra come eseguire il deployment di un gateway interno regionale che consenta comunicazioni efficienti e sicure tra i servizi all'interno di una specifica regione geografica.
Configura una subnet solo proxy
Devi configurare una subnet solo proxy prima di creare un gateway che utilizza un bilanciatore del carico delle applicazioni interno. Ogni regione di un VPC in cui utilizzi i bilanciatori del carico delle applicazioni interni deve avere una subnet solo proxy. Questa subnet fornisce indirizzi IP interni ai proxy del bilanciatore del carico.
Crea una subnet solo proxy:
gcloud compute networks subnets create SUBNET_NAME \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=COMPUTE_REGION \ --network=VPC_NETWORK_NAME \ --range=CIDR_RANGE
Sostituisci quanto segue:
SUBNET_NAME
: il nome della subnet solo proxy.COMPUTE_REGION
: la regione della subnet solo proxy.VPC_NETWORK_NAME
: il nome della rete VPC che contiene la subnet.CIDR_RANGE
: l'intervallo di indirizzi IP principali della subnet. Devi utilizzare una subnet mask non più lunga di/26
, in modo che siano disponibili almeno 64 indirizzi IP per i proxy nella regione. La subnet mask consigliata è/23
.
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 classe 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 diversi team per esporre internamente le proprie applicazioni. L'amministratore esegue il deployment del gateway e i team delle applicazioni eseguono il deployment delle route in modo indipendente e le collegano a questo gateway.
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 il 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.
Esegui il deployment del gateway nel tuo cluster:
kubectl apply -f gateway.yaml
Verifica che il deployment del gateway sia stato eseguito correttamente. Il deployment di tutte le risorse potrebbe richiedere qualche minuto.
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 eseguito il provisioning di un bilanciatore del carico e di un indirizzo IP. Il gateway non ha route, quindi non sa come deve inviare il traffico ai backend. Senza route, tutto il traffico va a un backend predefinito, che restituisce un errore HTTP 404. Poi, esegui il deployment di un'applicazione e delle route, che indicano al gateway come raggiungere i backend dell'applicazione.
Esegui il deployment delle applicazioni demo
I team delle applicazioni possono eseguire il deployment delle applicazioni e delle route in modo indipendente rispetto al deployment dei gateway. In alcuni casi, anche il team dell'applicazione potrebbe voler acquisire la proprietà del gateway ed eseguirne il deployment come risorsa dedicata alle applicazioni. Consulta Associazione di route per i diversi modelli di proprietà di gateway e route. In questo esempio,
il team dello store esegue il deployment dell'applicazione e di un HTTPRoute associato per esporre
l'app tramite il gateway internal-http
creato nella sezione precedente.
La risorsa HTTPRoute ha molti campi configurabili per la corrispondenza del traffico. Per una spiegazione dei campi di HTTPRoute, consulta la specifica 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
In questo modo 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 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 ai backend di Kubernetes. La risorsa HTTPRoute esegue la corrispondenza e i filtri del traffico HTTP e HTTPS ed è supportata da tutte le gke-l7
GatewayClass.
In questa sezione eseguirai il deployment di una HTTPRoute, che programma il gateway con le regole di routing necessarie per raggiungere l'applicazione del datastore.
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 gatewayinternal-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
va al serviziostore-german
. - Il traffico verso
store.example.com
con l'intestazione HTTP"env: canary"
va al serviziostore-v2
. - Il traffico rimanente verso
store.example.com
va al serviziostore-v1
.
- Il traffico verso
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 è stato eseguito il deployment del gateway, della route e dell'applicazione nel cluster, puoi 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 il traffico a questo indirizzo IP dalla shell di un'istanza di una macchina virtuale (VM) con connettività al cluster. A questo scopo, puoi creare una VM. Questa operazione è necessaria perché il gateway ha un indirizzo IP interno ed è accessibile solo dall'interno della rete VPC. Poiché
internal-http
è un bilanciatore del carico a livello di regione, la shell del client deve trovarsi all'interno della stessa regione del cluster GKE.Poiché non sei il proprietario del nome host example.com, imposta manualmente l'intestazione dell'host in modo da poter osservare il routing del traffico. Innanzitutto, prova a richiedere store.example.com:
curl -H "host: store.example.com" VIP
Sostituisci
VIP
con l'indirizzo IP del passaggio precedente.L'output dell'app demo mostra informazioni sulla posizione in cui è in esecuzione l'app:
{ "cluster_name": "gke1", "host_header": "store.example.com", "metadata": "store-v1", "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal", "pod_name": "store-v1-84b47c7f58-pmgmk", "pod_name_emoji": "💇🏼♀️", "project_id": "gateway-demo-243723", "timestamp": "2022-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 da reti esterne al VPC. Il deployment è simile al deployment interno di un gateway, con la differenza che devi proteggere le tue applicazioni poiché il gateway è accessibile alla rete internet pubblica.
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 di computing di Google Cloud. I client che inviano traffico a questo indirizzo IP Anycast vengono instradati alla località Google più vicina in cui è pubblicizzato l'IP. Il gateway esterno globale è disponibile solo 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 di computing di Google Cloud locale in cui viene eseguito il deployment del gateway esterno a livello di regione. I client che inviano traffico a questo indirizzo IP regionale vengono instradati dal loro ISP locale e su internet prima di raggiungere la regione di Google in cui l'IP è pubblicizzato. Il gateway esterno a livello di regione è disponibile solo nel livello di servizio di rete Standard.
Esegui il deployment di un gateway esterno globale
L'esempio seguente mostra come esporre un'applicazione del datastore con più certificati collegati al gateway esterno globale e raggruppati in una mappa di certificati utilizzando Gestore certificati e una route HTTP.
Crea una mappa di certificati
Google consiglia di utilizzare Gestore certificati per gestire i certificati se hai bisogno di almeno 15 certificati per gateway o se devi utilizzare certificati con caratteri jolly.
Puoi anche proteggere il tuo gateway esterno utilizzando secret di Kubernetes o certificati SSL gestiti da Google. Per maggiori informazioni, consulta Sicurezza del gateway.
In questa sezione, creerai certificati utilizzando Gestore certificati per proteggere le applicazioni in esecuzione sul cluster.
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 scegli. Il file deve avere l'estensione.pem
. Ad esempio,cert.pem
.PRIVATE_KEY_FILE
: il nome del file della chiave privata.
Per maggiori informazioni, consulta Creare una chiave privata e un certificato.
Crea un
CertificateMapEntry
che assegna il certificato alla mappa di certificati:gcloud beta certificate-manager maps entries create store-example-com-map-entry \ --map=store-example-com-map \ --hostname=store.example.com \ --certificates=store-example-com-cert
Per scoprire come proteggere un gateway utilizzando altre origini per i certificati, come i secret di Kubernetes o i certificati SSL, vedi Proteggere un gateway.
Crea un gateway
Una risorsa Gateway rappresenta un piano dati che instrada il traffico in Kubernetes. Un gateway può rappresentare molti tipi diversi di bilanciamento del carico e routing a seconda del GatewayClass che utilizza.
Per saperne di più sulla risorsa Gateway, consulta la descrizione della risorsa Gateway o la specifica API.
In questa sezione devi creare un gateway. I team delle applicazioni possono utilizzare il gateway per esporre le proprie applicazioni a internet eseguendo il deployment delle route in modo indipendente e collegandole in modo sicuro al gateway.
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 classe GatewayClass per questo gateway. Questa classe gateway utilizza un bilanciatore del carico delle applicazioni esterno globale.protocol: HTTPS
eport: 443
: specifica che il gateway espone la porta 443 per il traffico HTTPS. Questi campi attivano TLS.networking.gke.io/certmap: store-example-com-map
: specifica il nome della mappa di certificati in Gestore certificati.
Non esiste una sezione TLS perché TLS è configurato 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 bilanciatore del carico e un indirizzo IP pubblico. Il gateway non ha route, il che significa che non può inviare traffico ai backend. Senza route, tutto il traffico va a un backend predefinito, che restituisce una risposta HTTP 404. Nella sezione successiva eseguirai il deployment delle route, che indicano al gateway di inviare il traffico ai backend.
Esegui il deployment delle applicazioni demo
I team delle applicazioni possono eseguire il deployment delle applicazioni e delle route in modo indipendente rispetto al deployment dei gateway. In alcuni casi, anche il team dell'applicazione potrebbe voler essere proprietario
del gateway ed eseguirne il deployment come risorsa dedicata alle
applicazioni. Consulta Associazione di route per i diversi modelli di proprietà di gateway e route. In questo esempio, il team del negozio esegue il deployment dell'applicazione e di un HTTPRoute associato per esporre l'app tramite il gateway external-http
creato nella sezione precedente.
Per ulteriori informazioni sui campi HTTPRoute, consulta la specifica API.
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
estore-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 ai backend di Kubernetes. La risorsa HTTPRoute esegue la corrispondenza e i filtri del traffico HTTP e HTTPS ed è supportata da tutte le GatewayClass di gke-l7-*
.
In questa sezione eseguirai 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
La connessione HTTPRoute
store
è associata al gatewayexternal-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 instradato al serviziostore-german
. - Traffico verso
store.example.com
con l'intestazione HTTP"env: canary"
instrada al serviziostore-v2
. - Il traffico rimanente verso
store.example.com
viene instradato al serviziostore-v1
.
- Il traffico verso
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 è stato eseguito il deployment del gateway, della route e dell'applicazione nel cluster, puoi 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 manualmente l'intestazione host perché non sei il proprietario del nome host
example.com
.curl -H "host: store.example.com" https://GATEWAY_IP_ADDRESS --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
Sostituisci
GATEWAY_IP_ADDRESS
con l'indirizzo IP del gateway del passaggio precedente.L'output mostra informazioni dell'app demo sulla posizione in cui è in esecuzione l'app:
{ "cluster_name": "gke1", "host_header": "store.example.com", "metadata": "store-v1", "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal", "pod_name": "store-v1-84b47c7f58-pmgmk", "pod_name_emoji": "💇🏼♀️", "project_id": "gateway-demo-243723", "timestamp": "2022-09-25T13:31:17", "zone": "us-central1-a" }
Verifica la corrispondenza del percorso andando alla versione tedesca del servizio
store
all'indirizzostore.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 l'intestazione HTTPenv: 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 del datastore con più certificati collegati al gateway esterno a livello di regione 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 dall'autorità di certificazione (CA) o creare un certificato autofirmato. Per ulteriori informazioni su come creare un certificato, 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 indirizzo IP statico.COMPUTE_REGION
: la regione di Compute Engine 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 rispetto al deployment dei gateway.
Per ulteriori informazioni su come eseguire il deployment delle applicazioni demo, consulta Eseguire il deployment delle applicazioni demo.Crea una HTTPRoute
Devi creare una HTTPRoute per eseguire la corrispondenza e i filtri del traffico HTTP e HTTPS.
Invia traffico alla tua applicazione
Dopo aver eseguito il deployment dell'applicazione e creato HTTPRoute, puoi passare il traffico all'applicazione.
Per ulteriori informazioni su come inviare traffico alla tua applicazione, consulta Inviare traffico alla tua applicazione.Utilizza gateway condivisi
Le API Gateway utilizzano risorse separate, gateway e risorse route, per eseguire il deployment dei bilanciatori del carico e delle regole di routing. A differenza di Ingress, che combina tutto in un'unica risorsa. Suddividendo la responsabilità tra le risorse, il gateway consente di eseguire separatamente il deployment del bilanciatore del carico e delle relative regole di routing, oltre che per utenti o team diversi. In questo modo i gateway possono diventare gateway condivisi che si collegano a molte route diverse che possono essere possedute e gestite completamente da team indipendenti, anche tra spazi dei nomi diversi.
Esegui il deployment delle route su un gateway condiviso
Questo esempio si basa sul gateway internal-http
di cui è stato eseguito il deployment in Deployment di un gateway interno.
In questo esempio, il team del sito esegue il deployment dell'applicazione, dei servizi e di una route HTTP 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 HTTPRoute che corrisponde a tutto il traffico per
site.example.com
e lo instrada al serviziosite-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 si è associato correttamente al gateway. Per saperne di più sul campo Stato, vedi 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 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 senza corrispondenza. Puoi configurare il backend predefinito utilizzando una route predefinita esplicita che invia traffico senza corrispondenza a un servizio fornito dall'utente.
Il seguente HTTPRoute è un esempio di come personalizzare il backend predefinito. Se applichi una richiesta HTTPRoute simile alla seguente, questa 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 da un determinato gateway. Puoi avere una sola regola di questo tipo per ciascun gateway, altrimenti le regole entrano in conflitto e si applica l'ordinamento di precedenza.
Puoi utilizzare un backend predefinito per impedire a qualcuno di creare un backend di route predefinito che instrada tutto il traffico del gateway. Un HTTPRoute esplicito 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 nel 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 |
---|---|
|
Indirizzi IP privati a livello di regione dall'intervallo di indirizzi IPv4/IPv6 del nodo primario |
|
Indirizzi IP pubblici a livello di regione degli intervalli IPv4/IPv6 esterni a livello di regione di Google |
|
Indirizzi IP pubblici globali degli intervalli IPv4/IPv6 esterni globali di Google |
Il campo addresses.NamedAddress
consente di specificare un indirizzo IP
indipendentemente dal gateway. Puoi creare una risorsa di indirizzo IP statico prima del deployment del gateway e 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 indirizzo IP staticoCOMPUTE_REGION
: per i gateway regionali, la regione di Compute Engine in cui è in esecuzione il cluster. Questo flag non è necessario per i gateway esterni globali.SUBNET
: la subnet per l'indirizzo IP. Questo flag non è necessario per i gateway esterni globali.PROJECT_ID
: il progetto in cui è in esecuzione il cluster GKE.
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 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 reindirizzamenti da HTTP a HTTPS abilitati, entrambi questi bilanciatori del carico vengono creati automaticamente. Le richieste all'indirizzo IP esterno del gateway sulla porta 80 vengono reindirizzate automaticamente allo stesso indirizzo IP esterno sulla porta 443.
Per impostazione predefinita, i reindirizzamenti da HTTP a HTTPS non sono definiti nel gateway.
Per reindirizzare il traffico HTTP a HTTPS, configura un gateway per gestire il traffico sia HTTP che HTTPS. Se disabiliti HTTP o HTTPS, il gateway non reindirizza il traffico.
I seguenti esempi mostrano come utilizzare il reindirizzamento da HTTP a HTTPS come mezzo per garantire che il traffico dai client alle tue applicazioni web venga sempre reindirizzato a una pagina sicura.
Reindirizza il traffico HTTP dallo spazio dei nomi Gateway
Nell'esempio seguente, il gateway è configurato per consentire Same
(allegato dallo stesso spazio dei nomi) sul listener HTTP, mentre il listener HTTPS è aperto per 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 HTTPRoute possa associarsi al listener HTTP del gateway. Ciò richiede che le HTTPRoute del team dell'applicazione non siano consentite nello spazio dei nomi gateway-infra
.
Crea lo spazio dei nomi del gateway
gateway-infra
. Salva il manifest comegateway-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 sezioneallowedRoutes
limita il listener HTTP solo allo spazio dei nomigateway-infra
del gateway.Il listener https non include una limitazione per gli spazi dei nomi consentiti, 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 una HTTPRoute predefinita utilizzando il file manifest seguente e salva il manifest come
redirect-httproute.yaml
:kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: redirect namespace: gateway-infra spec: parentRefs: - namespace: gateway-infra name: external-http sectionName: http rules: - filters: - type: RequestRedirect requestRedirect: scheme: https
- Il campo
sectionName
indica al gateway di trovare corrispondenze solo nell'elenco http. Il filtroRequestRedirect
forza il reindirizzamento al listener https.
Questa configurazione reindirizza il traffico ricevuto sulla porta 80 del gateway al listener sulla porta 443, applicando una comunicazione sicura tra il client e il bilanciatore del carico.
- Il campo
Applica il manifest:
kubectl apply -f redirect-httproute.yaml
Crea un servizio per un'applicazione utilizzando il manifest seguente. Salva il file 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 il file 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
Applica il manifest:
kubectl apply -f httproute.yaml
Reindirizza il traffico HTTP da uno spazio dei nomi dell'infrastruttura
In alcuni casi, non esiste una chiara distinzione tra il team di amministrazione dell'infrastruttura o della piattaforma e i team delle applicazioni e impedire l'uso improprio del gateway può diventare una sfida.
L'esempio seguente limita ulteriormente l'uso del listener HTTP per impedire l'utilizzo involontario di un protocollo non sicuro da parte dei team delle applicazioni. In questo esempio, il gateway viene configurato in modo da consentire a una 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 in 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 manifest seguente. 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 nomigateway-infra
.Il campo
namespaces
nella sezioneallowedRoutes
limita il listener HTTP allo spazio dei nomi corrispondente all'etichettaotherInfra: httpToHttps
.
Applica il manifest:
kubectl apply -f external-gateway.yaml
Per forzare il reindirizzamento HTTPS, crea una HTTPRoute predefinita utilizzando il manifest riportato di seguito. 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 nell'elenco http. Il filtroRequestRedirect
forza il reindirizzamento al listener https.
- Il campo
Applica il manifest:
kubectl apply -f http-redirect.yaml
Crea un servizio per un'applicazione utilizzando il manifest seguente. Salva il file 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 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
Configura i reindirizzamenti del percorso e le riscritture di URL
I reindirizzamenti del percorso prevedono il reindirizzamento di una richiesta in entrata da un percorso URL a un altro. I reindirizzamenti dei percorsi ti consentono di modificare la struttura dell'URL quando devi gestire URL obsoleti o deprecati.
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 la struttura dei file o i contenuti sottostanti. La riscrittura degli URL è utile per creare URL semplici da usare e ottimizzati per la SEO e facili da ricordare e capire. Per impostazione predefinita, i reindirizzamenti del percorso e le riscritture degli URL non sono configurati. Devi configurare esplicitamente questi reindirizzamenti o le riscritture utilizzando un filtro in HTTPRoute.
Il gateway GKE supporta i reindirizzamenti dei percorsi e le riscritture degli URL. Per maggiori informazioni, consulta l'articolo Reindirizzamenti e riscritture dei percorsi HTTP.
Configura i reindirizzamenti del percorso
Puoi configurare i reindirizzamenti per sostituire l'intero percorso o solo un prefisso 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 con il valore restrittivo/new-path
.Crea un manifest
HTTPRoute
come segue e assegnagli il nomestore.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 all'URL https://store.example.com/any-path/... deve essere reindirizzato a una nuova posizione, https://store.example.com/new-path/ (livello obbligatorio).
Applica il manifest:
kubectl apply -f store.yaml
Questa regola di routing segue una regola di reindirizzamento rigida, secondo cui il browser non tenta di memorizzare nella cache il reindirizzamento, ma reindirizza alla versione più recente.
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 con il valore restrittivo/new-prefix
.Crea un manifest
HTTPRoute
come segue e assegnagli il nomestore.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 route 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 il browser ti reindirizzi 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 utilizzare le riformulazioni degli URL per rendere gli URL più facili da usare, per migliorare la SEO o per reindirizzare gli utenti a una nuova pagina.
Riscrivi l'intero nome host
Per riscrivere l'intero nome host:
Configurare un filtro in una HTTPRoute che indichi al gateway di sostituire le informazioni
Host
nell'intestazione della richiesta da www.example.com a store.example.com prima di inoltrare la richiesta al servizio di backend.Crea un manifest
HTTPRoute
come segue e assegnagli il nomewww.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
Riscrivi utilizzando i modificatori di percorso
Puoi combinare le riscritture con i modificatori del 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:
Configurare un filtro in una HTTPRoute per indicare al gateway di sostituire le informazioni "Host" nell'intestazione della richiesta da www.example.com a 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 assegnagli il nomewww.yaml
:apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: www spec: parentRefs: - kind: Gateway name: external-http hostnames: - www.example.com rules: - matches: - path: type: PathPrefix value: /store filters: - type: URLRewrite urlRewrite: hostname: store.example.com path: type: ReplacePrefixMatch replacePrefixMatch: /de backendRefs: - name: store-german port: 8080
Ad esempio, con la configurazione precedente, qualsiasi richiesta a https://www.example.com/store/... viene inoltrata al servizio di backend con
Host: store.example.com
nell'intestazione della richiesta (anzichéHost: www.example.com
) e/store
viene riscritta in/de
.Applica il manifest:
kubectl apply -f www.yaml
Verifica la configurazione
Per verificare che il filtro sia stato applicato dopo aver creato i filtri HTTPRoute con riscrittura URL 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 richieste e risposte personalizzate consentono di specificare ulteriori intestazioni 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, alle richieste inviate/ricevute ai/dai servizi di backend non vengono aggiunte intestazioni personalizzate. Devi configurare esplicitamente intestazioni personalizzate utilizzando un filtro in HTTPRoute.
Puoi configurare intestazioni personalizzate aggiungendo una sezione filtro nelle regole di HTTPRoute come segue:
Configura intestazioni delle richieste personalizzate
Crea un manifest HTTPRoute con un filtro RequestHeaderModifier e salvalo come
http-route-request.yaml:
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: store
spec:
<...>
rules:
filters:
- type: RequestHeaderModifier
requestHeaderModifier:
<...>
Applica il manifest:
kubectl apply -f http-route-request.yaml
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 da Google Cloud.
Esempio 1:
Per configurare un HTTPRoute che aggiunge informazioni sulla posizione del client alla richiesta HTTP prima di inviarlo al servizio di backend, crea un manifest HTTPRoute e denominalo external-http-request.yaml
:
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: store
spec:
parentRefs:
- kind: Gateway
name: external-http
hostnames:
- store.example.com
rules:
- matches:
- path:
type: PathPrefix
value: /fr
filters:
- type: RequestHeaderModifier
requestHeaderModifier:
add:
- name: X-Client-Geo-Location
value: "{client_region},{client_city}"
backendRefs:
- name: store-french
port: 8080
Ad esempio, per i clienti con sede a Strasburgo, in Francia, il gateway aggiunge un'intestazione X-Client-Geo-Location:FR,Strasbourg
.
Esempio 2:
Per configurare un HTTPRoute che aggiunge un'intestazione della risposta personalizzata per supportare HTTP Strict Transport Security, crea un manifest HTTPRoute e denominalo come
external-http-response.yaml
:
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: store
spec:
parentRefs:
- kind: Gateway
name: external-http
hostnames:
- store.example.com
rules:
- matches:
- path:
type: PathPrefix
value: /de
filters:
- type: ResponseHeaderModifier
responseHeaderModifier:
add:
- name: Strict-Transport-Security
value: max-age=63072000
backendRefs:
- name: store-german
port: 8080
Verifica la configurazione
Per verificare la configurazione dopo aver configurato le intestazioni di richiesta e risposta personalizzate, segui questi passaggi:
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 se è 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 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 la route HTTP è stata rifiutata dall'associazione con questo gateway.
Se nell'intestazione Gateway bindings
non sono elencati gateway, le etichette HTTPRoute e i selettori delle etichette del gateway potrebbero non corrispondere. Ciò può verificarsi se la route non viene selezionata da alcun gateway.
Eventi HTTPRoute
Gli eventi HTTPRoute forniscono dettagli sullo stato di HTTPRoute. Gli eventi sono raggruppati per i seguenti motivi:
- Gli eventi
ADD
vengono attivati dall'aggiunta di una risorsa. - Gli eventi
UPDATE
vengono attivati da una risorsa in fase di aggiornamento. SYNC
eventi vengono attivati da riconciliazione periodica.
Unione di route, precedenza e convalida
Precedenza route
L'API Gateway definisce regole di precedenza rigide per stabilire la corrispondenza tra il traffico e le route con regole di routing sovrapposte. 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 nella stessa risorsa mappa URL. Il modo in cui le HTTPRoute vengono unite dipende dal tipo di sovrapposizione tra le richieste HTTPRoute. La HTTPRoute dell'esempio precedente può essere suddivisa in tre HTTPRoute separate per illustrare l'unione e la precedenza delle route:
- Unione di route: tutti e tre gli HTTPRoute si collegano con lo stesso gateway
internal-http
, quindi vengono uniti. - Unione di nomi host: tutte e tre le route corrispondono a
store.example.com
, quindi le relative regole host vengono unite. - Unione di percorsi: il percorso store-german-route ha un percorso più specifico
/de
, quindi non viene unito ulteriormente. store-v1-route e store-v2-route corrispondono anche sullo stesso percorso/*
, quindi vengono uniti nel percorso. - Unione di intestazioni: store-v2-route ha un insieme più specifico di corrispondenze di intestazione HTTP rispetto a store-v1-route, quindi non vengono ulteriormente unite.
- Conflitto: poiché le route possono essere unite su nome host, percorso e intestazioni, non ci sono conflitti e tutte le regole di routing vengono applicate al 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 denominata Gateway
. Pur svolgendo 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 nella riga di comando.
kubectl get gateway
potrebbe restituire le risorse del gateway Kubernetes e non
le risorse del gateway di Istio o viceversa.
$ kubectl api-resources
NAME SHORTNAMES APIGROUP NAMESPACED KIND
gateways gw networking.istio.io/v1beta1 true Gateway
gateways gtw networking.k8s.io/v1beta1 true Gateway
Se utilizzi Istio ed esegui l'upgrade a GKE 1.20 e versioni successive, ti consigliamo di iniziare a utilizzare il nome breve della risorsa Gateway o di specificare il gruppo di API. Il nome breve di un gateway Kubernetes è gtw
e il nome breve di un
gateway di Istio è gw
. I comandi seguenti restituiscono rispettivamente
le risorse del gateway Kubernetes e 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 (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 una 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:
Quando crei una subnet solo proxy per il gateway a livello di regione (interno o esterno), potrebbe verificarsi il seguente problema:
ERROR: (gcloud.compute.networks.subnets.create) Could not fetch resource:
- The resource 'projects/[PROJECT_NAME]/regions/[REGION_NAME]/subnetworks/[PROXY_ONLY_SUBNET_NAME]' already exists
Motivo:
Questo messaggio di errore indica che hai tentato di creare una subnet solo proxy a livello di regione in una regione che 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 che abbia lo scopo corretto:
Elenca le subnet per individuare quella solo proxy nella regione:
gcloud compute networks subnets list --regions=COMPUTE_REGION
Sostituisci
COMPUTE_REGION
con la regione Compute Engine in cui vuoi creare il gateway a livello di regione.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
subnet solo proxy per i gateway regionali (interni o a livello di regione).Se la subnet solo proxy esistente nella regione è stata creata con uno scopo
INTERNAL_HTTPS_LOAD_BALANCER
, esegui la migrazione del suo scopo aREGIONAL_MANAGED_PROXY
.
Passaggi successivi
- Scopri di più sul controller gateway.
- Scopri come configurare le risorse del gateway utilizzando i criteri.