Deployment dei gateway


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

  • Attiva l'API Google Kubernetes Engine.
  • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con 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 1.24 o versioni successive.
  • Per Autopilot, GKE versione 1.26 o successive.
  • Google Cloud CLI versione 407.0.0 o successive.
  • L'API Gateway è supportata solo su cluster VPC-native.
  • Se utilizzi GatewayClasses interno, devi attivare una subnet solo proxy.
  • Nel cluster deve essere attivato il componente aggiuntivo HttpLoadBalancing.
  • Se utilizzi Istio, devi eseguire l'upgrade di Istio a una delle seguenti opzioni 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

Quando utilizzi GKE Gateway, tieni presente le seguenti limitazioni:

Scopri le best practice:

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

  • Le GatewayClass di GKE supportano diverse funzionalità a seconda al bilanciatore del carico che utilizzano. Per ulteriori informazioni sulle varie funzionalità supportata con ogni GatewayClass, Funzionalità GatewayClass.

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

  • GKE Gateway si comporta in modo diverso rispetto a Ingress, in quanto non deducono i parametri di controllo dell'integrità. Se il servizio non restituisce 200 per le richieste a GET / o se hai altri controlli di idoneità dei pod ottimizzati, devi configurare un criterio di controllo dell'integrità per il 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 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 dei campi supportati dal controller gateway GKE, consulta Funzionalità di GatewayClass.

  • Le intestazioni di richiesta e risposta personalizzate con reindirizzamenti di Gateway o percorso e riscritture di URL con Gateway sono disponibili solo nella versione 1.27 o successiva di GKE.

  • 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 GKE Gateway)
    • cdn_cache_status (Cloud CDN non è supportato con il gateway GKE)
    • origin_request_header (i criteri CORS non sono supportati con GKE Gateway)
  • 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 verso il gateway.

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

  • Quando un Gateway è configurato per eseguire il provisioning di un indirizzo IP, la modifica di Gateway.spec.gatewayClass non è supportata. Per assicurarti che Il controller 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.

  • Se utilizzi GKE Gateway con external-dns e lo stato di salute del gateway non è buono, per impostazione predefinita tutti i record DNS associati al gateway vengono eliminati dalle zone DNS. Per evitare l'eliminazione degli attuali record DNS, ti consigliamo di impostare il flag --policy=upsert-only quando esegui external-dns.

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 nei cluster Autopilot a partire dalla versione 1.26 di GKE. Se crei nuovi cluster Autopilot su GKE 1.26 o versioni successive, l'API Gateway è abilitata per impostazione predefinita. Per i cluster esistenti su GKE versione 1.25 o precedenti, l'API Gateway è disabilitata per impostazione predefinita.

Se crei il cluster prima senza specificare una rete (utilizzando il metodo --network), GKE crea il cluster nel percorso predefinito in ogni rete. In questo caso, devi anche creare il cluster solo una subnet nella rete predefinita. Se specifichi una rete durante la creazione del cluster, assicurati di creare anche una subnet solo proxy nella stessa rete.

Autopilot

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

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

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • CLUSTER_LOCATION: la regione o la zona Compute Engine per il nuovo cluster.
  • RELEASE_CHANNEL: il nome del canale di rilascio.
  • VERSION: la versione di GKE, che deve essere 1.26 o successiva. Puoi anche utilizzare il flag --release-channel per selezionare 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 dal flag --gateway-api. Puoi utilizzare il valore standard per l'attivazione e disattivato per 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 Regione o zona di Compute Engine per il nuovo cluster.

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

Attivare l'API Gateway in 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:

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 di gateway GKE installa automaticamente GatewayClasses. Potrebbe richiede qualche minuto affinché il controller riconosca i CRD e installi GatewayClass.

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

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

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

    "networkConfig": {
      ...
      "gatewayApiConfig": {
        "channel": "CHANNEL_STANDARD"
      },
      ...
    },
    
  2. Verifica che le classi Gateway siano installate nel cluster:

    kubectl get gatewayclass
    

    L'output è simile al seguente:

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

Per comprendere le funzionalità di ogni GatewayClass, 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 regionale

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

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

  1. Crea una subnet solo proxy:

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

    Sostituisci quanto segue:

    • SUBNET_NAME: il nome della subnet solo proxy.
    • COMPUTE_REGION: la regione della subnet solo proxy.
    • VPC_NETWORK_NAME: il nome del VPC in cui crei la subnet solo proxy. Assicurati che si tratti della stessa rete VPC in cui si trova il cluster GKE e in cui 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 principale della subnet. Devi utilizzare una subnet mask non più lunga di /26 in modo che siano disponibili almeno 64 indirizzi IP per i proxy nella regione. La subnet mask consigliata è /23.
  2. Verifica la subnet solo proxy:

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

    L'output è simile al seguente:

    ...
    gatewayAddress: 10.1.1.1
    ipCidrRange: 10.1.1.0/24
    kind: compute#subnetwork
    name: proxy-subnet
    network: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/default
    privateIpGoogleAccess: false
    privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS
    purpose: REGIONAL_MANAGED_PROXY
    region: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION
    role: ACTIVE
    selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION/subnetworks/proxy-subnet
    state: READY
    

Crea un gateway

Una risorsa Gateway rappresenta un piano dati che instrada il traffico in Kubernetes. 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 le applicazioni interne. L'amministratore esegue il deployment del gateway, mentre i team di applicazioni eseguono il deployment dei propri percorsi in modo indipendente e li collegano a questo gateway.

  1. Salva il seguente manifest di 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 al bilanciatore del carico delle applicazioni interno.
    • port: 80: specifica che il gateway espone solo la porta 80 per l'ascolto del traffico HTTP.
  2. Esegui il deployment del gateway nel cluster:

    kubectl apply -f gateway.yaml
    
  3. Verifica che il gateway sia stato implementato correttamente. Potrebbero essere necessari alcuni minuti per 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. Tuttavia, il gateway non ha route e quindi non sa come inviare il traffico ai backend. Senza le route, tutto il traffico viene indirizzato a un backend predefinito, che restituisce un codice HTTP 404. Successivamente, esegui il deployment di un'applicazione e delle route, che indicano al gateway come accedere ai backend dell'applicazione.

Esegui il deployment delle applicazioni demo

I team delle applicazioni possono eseguire il deployment delle applicazioni e dei percorsi indipendentemente dall'implementazione dei gateway. In alcuni casi, il team addetto alla candidatura potrebbe voler il gateway e ne esegue 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 della propria applicazione e di un HTTPRoute associato per esporre la propria app tramite il gateway internal-http creato nella sezione precedente.

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

  1. Esegui il deployment dell'applicazione 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.

  2. 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
    
  3. 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. La risorsa HTTPRoute esegue la corrispondenza e il filtraggio del traffico HTTP e HTTPS ed è supportata da tutte le classi gke-l7Gateway.

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.

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

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

    kubectl apply -f store-route.yaml
    

    Il parametro HTTPRoute store è associato al gateway internal-http utilizzando la proprietà parentRefs. Queste regole di routing sono configurate sulla piattaforma come in questo diagramma:

    Le regole di routing configurate da HTTPRoute del negozio

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

    • Il traffico verso store.example.com/de viene indirizzato al servizio store-german.
    • Il traffico verso store.example.com con l'intestazione HTTP "env: canary" viene indirizzato al servizio store-v2.
    • Il traffico rimanente verso store.example.com viene indirizzato al servizio store-v1.
  3. Verifica che sia stato eseguito il deployment di HTTPRoute:

    kubectl describe httproute store
    

    L'output è simile al seguente:

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

    kubectl describe gateway
    

    L'output è simile al seguente:

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

Invia traffico all'applicazione

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

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

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

    L'output è un indirizzo IP.

  2. Invia traffico a questo indirizzo IP dalla shell su un'istanza di una macchina virtuale (VM) con connettività al cluster. Puoi creare 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.

    Fai una richiesta a store.example.com:

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

    Sostituisci GATEWAY_IP_ADDRESS con l'indirizzo IP del 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"
    }
    
  3. Testa la corrispondenza del percorso visitando la versione tedesca del servizio dello Store all'indirizzo store.example.com/de:

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

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

    {
      "cluster_name": "gke1",
      "host_header": "store.example.com",
      "metadata": "Gutentag!", 
      "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
      "pod_name": "store-german-5cb6474c55-lq5pl", 
      "pod_name_emoji": "🧞‍♀",
      "project_id": "gateway-demo-243723",
      "timestamp": "2022-10-25T13:35:37",
      "zone": "ZONE_NAME"
    }
    
  4. Infine, utilizza l'intestazione HTTP env: canary per inviare il traffico alla versione canary del servizio di archiviazione:

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

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

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

Esegui il deployment di un gateway esterno

Un gateway esterno espone le applicazioni raggiungibili da internet o da reti esterne alla tua 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.

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

Un gateway esterno globale utilizza un indirizzo IP globale (o un indirizzo IP anycast) come frontend del gateway pubblicizzato in tutte le regioni Google Cloud Compute. I client che inviano traffico a questo indirizzo IP anycast vengono indirizzati alla sede di Google più vicina in cui l'IP è pubblicizzato. Il gateway esterno globale è disponibile nel livello di servizio di rete Premium.

Un gateway esterno regionale utilizza un IP regionale come frontend del gateway annuncito solo nella regione Google Cloud Compute locale in cui è dipiegato il gateway esterno regionale. I client che inviano traffico a questo indirizzo IP regionale vengono indirizzati dal proprio ISP locale e su internet prima di raggiungere la regione di Google 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 del negozio con più certificati collegati al gateway esterno globale e raggruppati in una mappa dei certificati utilizzando Certificate Manager e un percorso HTTP.

Crea una mappa di certificati

Google consiglia di utilizzare Certificate Manager per gestire i certificati quando hai bisogno di almeno 15 certificati per gateway o se devi utilizzare certificati generici.

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

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

  1. Abilita l'API Certificate Manager:

    gcloud services enable certificatemanager.googleapis.com
    
  2. Crea una mappa dei certificati:

    gcloud beta certificate-manager maps create store-example-com-map
    
  3. Carica il certificato e le chiavi gestiti da Google in un certificato:

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

    Sostituisci quanto segue:

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

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

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

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

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

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

In questa sezione, crei 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.

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

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

  2. Applica il manifest al cluster:

    kubectl apply -f gateway.yaml
    

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

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

    kubectl describe gateway
    

    L'output è simile al seguente:

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

    Questo output mostra che il gateway di cui è stato eseguito il deployment nel tuo cluster ha un carico e un indirizzo IP pubblico. Il gateway non ha route, il che significa che non può inviare traffico ai backend. Senza Route, tutto il traffico viene indirizzato a 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 applicazioni e dei percorsi indipendentemente dall'implementazione dei gateway. In alcuni casi, il team di applicazioni potrebbe voler possedere anche il gateway e implementarlo autonomamente come risorsa dedicata alle proprie applicazioni. Consulta Associazione 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 la propria app tramite il gateway external-http creato nella sezione precedente.

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

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

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

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

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

    kubectl get pod
    

    L'output è simile al seguente:

    NAME                            READY   STATUS    RESTARTS   AGE
    store-german-66dcb75977-5gr2n   1/1     Running   0          38s
    store-v1-65b47557df-jkjbm       1/1     Running   0          14m
    store-v2-6856f59f7f-sq889       1/1     Running   0          14m
    
  3. Verifica che il deployment dei servizi sia stato eseguito correttamente:

    kubectl get service
    

    L'output è simile al seguente:

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

Crea un HTTPRoute

Le risorse route definiscono regole specifiche di protocollo per mappare il traffico da un Gateway per i backend Kubernetes. La risorsa HTTPRoute esegue la corrispondenza e il filtraggio del traffico HTTP e HTTPS ed è supportata da tutte le gke-l7-* classi Gateway.

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

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

    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/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.

  2. 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 configurate dalla rete HTTPRoute dell&#39;archivio

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

    • Il traffico verso store.example.com/de viene instradato al servizio store-german.
    • Il traffico verso store.example.com con l'intestazione HTTP "env: canary" viene indirizzato al servizio store-v2.
    • Il traffico rimanente verso store.example.com viene instradato al servizio store-v1.
  3. Verifica che HTTPRoute sia stato disegnato:

    kubectl describe httproute store-external
    

    L'output è simile al seguente:

    Name:         store-external
    Namespace:    default
    Labels:       <none>
    Annotations:  <none>
    API Version:  gateway.networking.k8s.io/v1beta1
    Kind:         HTTPRoute
    <...>
    Spec:
      Hostnames:
        store.example.com
      Parent Refs:
        Group:  gateway.networking.k8s.io
        Kind:   Gateway
        Name:   external-http
      Rules:
        Backend Refs:
          Group:
          Kind:    Service
          Name:    store-v1
          Port:    8080
          Weight:  1
        Matches:
          Path:
            Type:   PathPrefix
            Value:  /
        Backend Refs:
          Group:
          Kind:    Service
          Name:    store-v2
          Port:    8080
          Weight:  1
        Matches:
          Headers:
            Name:   env
            Type:   Exact
            Value:  canary
          Path:
            Type:   PathPrefix
            Value:  /
        Backend Refs:
          Group:
          Kind:    Service
          Name:    store-german
          Port:    8080
          Weight:  1
        Matches:
          Path:
            Type:   PathPrefix
            Value:  /de
    Status:
      Parents:
        Conditions:
          Last Transition Time:  2022-11-01T05:42:31Z
          Message:
          Reason:                Accepted
          Status:                True
          Type:                  Accepted
          Last Transition Time:  2022-11-01T05:43:18Z
          Message:
          Reason:                ReconciliationSucceeded
          Status:                True
          Type:                  Reconciled
        Controller Name:         networking.gke.io/gateway
        Parent Ref:
          Group:  gateway.networking.k8s.io
          Kind:   Gateway
          Name:   external-http
    Events:
      Type     Reason  Age    From                   Message
      ----     ------  ----   ----                   -------
      Normal   ADD     2m48s  sc-gateway-controller  default/store-external
      Normal  SYNC  61s (x3 over 2m27s)  sc-gateway-controller  Bind of HTTPRoute "default/store-external" to ParentRef Group:       "gateway.networking.k8s.io",
      ...
    
  4. Verifica che HTTPRoute sia associato al gateway:

    kubectl describe gateway external-http
    

    L'output è simile al seguente:

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

Invia traffico all'applicazione

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

  1. Ottieni l'indirizzo IP del gateway:

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

    L'output è un indirizzo IP.

  2. Crea una VM:

    gcloud cloud-shell ssh
    
  3. Invia 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 https://store.example.com --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 di 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"
    }
    
  4. Testa la corrispondenza del percorso visitando la versione tedesca del servizio store su store.example.com/de:

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

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

    {
      "cluster_name": "gke1",
      "host_header": "store.example.com",
      "metadata": "Gutentag!",
      "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
      "pod_name": "store-german-5cb6474c55-lq5pl",
      "pod_name_emoji": "🧞‍♀",
      "project_id": "gateway-demo-243723",
      "timestamp": "2022-09-25T13:35:37",
      "zone": "us-central1-a"
    }
    
  5. Invia il traffico alla versione canary del servizio store utilizzando l'intestazione HTTP env: canary:

    curl -H "env: canary" https://store.example.com"/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 regionale

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 del 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 certificato, consulta Archiviare un certificato in un secret di Kubernetes.

Crea un gateway HTTP(S) esterno regionale

  1. Crea un indirizzo IP statico a livello di regione per il bilanciatore del carico esterno.

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

    Sostituisci quanto segue:

    • IP_ADDRESS_NAME: il nome del nuovo IP statico .
    • COMPUTE_REGION: la regione Compute Engine in cui è in esecuzione il cluster.
  2. Crea un gateway del bilanciatore del carico delle applicazioni esterno regionale utilizzando un certificato autogestito come segue e salva il manifest come regional-gateway.yaml:

      kind: Gateway
      apiVersion: gateway.networking.k8s.io/v1beta1
      metadata:
        name: external-regional-http
      spec:
        gatewayClassName: gke-l7-regional-external-managed
        listeners:
        - name: https
          protocol: HTTPS
          port: 443
          tls:
            mode: Terminate
            certificateRefs:
            - name: store-example-com
        addresses:
        - type: NamedAddress
          value: IP_ADDRESS_NAME
    
  3. Applica il manifest regional-gateway:

      kubectl apply -f regional-gateway.yaml
    
  4. Verifica la configurazione.

      kubectl get gateway
    

    L'output è simile al seguente:

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

    Per ulteriori dettagli, utilizza un comando describe:

    kubectl describe gateway
    

    L'output è simile al seguente:

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

Esegui il deployment dell'applicazione demo

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

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

Crea un HTTPRoute

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

Invia traffico alla tua applicazione

Dopo aver disegnato l'applicazione e creato HTTPRoutes, puoi indirizzare il traffico alla tua applicazione.

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

Utilizzare i gateway condivisi

Le API Gateway utilizzano risorse separate, Gateway e Route, per eseguire il deployment di bilanciatori del carico e regole di routing. È diverso da Ingress, che combina tutto in un'unica risorsa. Suddividendo la responsabilità tra le risorse, Gateway consente di eseguire il deployment del bilanciatore del carico e delle relative regole di routing separatamente e da utenti o team diversi. In questo modo, i gateway possono diventare gateway condivisi che si connettono a molti percorsi diversi che possono essere di proprietà e gestiti da team indipendenti, anche in spazi dei nomi diversi.

Esegui il deployment delle route su un gateway condiviso

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

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

  1. Esegui il deployment dell'applicazione di esempio:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/site.yaml
    
  2. Salva il seguente manifest in un file denominato site-route-internal.yaml:

    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/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.

  3. Applica il manifest al cluster:

    kubectl apply -f site-route-internal.yaml
    
  4. Verifica che HTTPRoute sia collegato al gateway:

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

    L'output è simile al seguente:

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

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

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

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

    Sostituisci GATEWAY_IP_ADDRESS con l'indirizzo IP del gateway.

    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. Puoi configurare il backend predefinito utilizzando una route predefinita esplicita che invia il traffico non corrispondente a un servizio fornito dall'utente.

La seguente HTTPRoute è un esempio di come personalizzare il backend predefinito. Se applichi un percorso HTTP simile al seguente, avrà 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 parametro HTTPRoute corrisponde a tutto il traffico proveniente 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 un utente di creare un backend route predefinito che inoltra tutto il traffico del gateway. Un'HTTPRoute esplicita ha sempre la precedenza sulle nuove HTTPRoute con regole di routing in conflitto.

Configura un indirizzo IP statico per un gateway

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

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

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

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

GatewayClasses Pool di indirizzi IP predefinito
  • gke-l7-rilb
  • gke-l7-rilb-mc
  • Indirizzi IP privati regionali dall'intervallo di indirizzi IPv4/IPv6 del nodo principale
  • 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 provenienti dagli intervalli IPv4/IPv6 esterni globali di Google

    Il campo addresses.NamedAddress ti consente di specificare un indirizzo IP indipendentemente dal gateway. Puoi creare una risorsa 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 IPv4 o IPv6 specificando un NamedAddress. Tu deve eseguire il provisioning di un indirizzo IP statico prima di creare un gateway.

    1. Crea una risorsa indirizzo IP statico:

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

      Sostituisci quanto segue:

      • IP_ADDRESS_NAME: il nome del nuovo indirizzo IP statico
      • COMPUTE_REGION: per i gateway 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 è in esecuzione il tuo cluster GKE.
    2. 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.

    3. Applica il manifest al cluster:

      kubectl apply -f named-ip-gateway.yaml
      
    4. Verifica l'indirizzo IP del gateway:

      kubectl describe gateway internal-http
      

      L'output è simile al seguente:

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

    Configurare i reindirizzamenti da HTTP a HTTPS

    Cloud Load Balancing offre la 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 reindirizzate 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 sia il traffico HTTP sia quello HTTPS. Se disattivi HTTP o HTTPS, il gateway non reindirizzano il traffico.

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

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

    In alcuni casi, non esiste una distinzione chiara tra il team di amministrazione della piattaforma o dell'infrastruttura e i team di applicazioni e la prevenzione dell'uso improprio del gateway può diventare un problema.

    L'esempio seguente limita ulteriormente l'utilizzo dell'ascoltatore HTTP per impedire l'uso involontario di un protocollo non sicuro da parte dei team di 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.

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

      apiVersion: v1
      kind: Namespace
      metadata:
        name: gateway-infra
      
    2. Applica il manifest:

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

      apiVersion: v1
      kind: Namespace
      metadata:
        name: http-redirect
        labels:
          otherInfra: httpToHttps
      
      • Per questo spazio dei nomi sono impostate etichette specifiche.
    4. Applica il manifest:

      kubectl apply -f redirect-namespace.yaml
      
    5. Per limitare l'utilizzo dell'ascoltatore HTTP, crea un gateway utilizzando il seguente manifest. Salva il manifest come external-gateway.yaml:

      kind: Gateway
      apiVersion: gateway.networking.k8s.io/v1beta1
      metadata:
        name: external-http
        namespace: gateway-infra
      spec:
        gatewayClassName: gke-l7-global-external-managed
        listeners:
        - name: http
          protocol: HTTP
          port: 80
          allowedRoutes:
            kinds:
            - kind: HTTPRoute
            namespaces:
              from: selector
              selector:
                matchLabels:
                  otherInfra: httpToHttps
        - name: https
          protocol: HTTPS
          port: 443
          allowedRoutes:
            kinds:
            - kind: HTTPRoute
            namespaces:
              from: All
          tls:
            mode: Terminate
            options:
              networking.gke.io/pre-shared-certs: store-example-com
        ```
      
      • Il campo namespace specifica che il gateway viene creato nello spazio dei nomi gateway-infra.

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

    6. Applica il manifest:

      kubectl apply -f external-gateway.yaml
      
    7. Per forzare il reindirizzamento HTTPS, crea un percorso HTTP predefinito utilizzando il seguente manifest. Salva il manifest come http-redirect.yaml:

      kind: HTTPRoute
      apiVersion: gateway.networking.k8s.io/v1beta1
      metadata:
        name: redirect
        namespace: http-redirect
      spec:
        parentRefs:
        - namespace: gateway-infra
          name: external-http
          sectionName: http
        rules:
        - filters:
          - type: RequestRedirect
            requestRedirect:
              scheme: https
      
      • Il campo sectionName indica al gateway di trovare corrispondenze solo nella pagina http e ascolto. Il filtro RequestRedirect forza il reindirizzamento all'evento listener https.
    8. Applica il manifest:

      kubectl apply -f http-redirect.yaml
      
    9. Crea un servizio per un'applicazione utilizzando il seguente manifest. 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"
      
    10. Applica il manifest:

      kubectl apply -f service-deployment.yaml
      
    11. 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
      
    12. Applica il manifest:

      kubectl apply -f http-route.yaml
      

    Configurare i reindirizzamenti dei percorsi e le riscritture degli URL

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

    Le riscritture degli URL aiutano a modificare l'URL in entrata prima di elaborarlo sul server. Ti consente di modificare la struttura o il formato dell'URL senza modificare effettivamente i contenuti o la struttura del file sottostanti. 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 dei percorsi e le riscritture degli URL non sono configurati. Devi configurare esplicitamente questi reindirizzamenti o riscritture utilizzando un filtro in HTTPRoute.

    GKE Gateway supporta i reindirizzamenti dei percorsi e le riscritture degli URL. Per maggiori 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

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

    2. Crea un manifest HTTPRoute come segue e chiamalo store.yaml:

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

      Ad esempio, questo manifest imposta una regola di routing per un'entità 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/ (rigoroso).

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

    Sostituire solo un prefisso

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

    2. Crea un manifest HTTPRoute come segue e chiamalo store.yaml:

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

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

    3. Applica il manifest:

        kubectl apply -f store.yaml
      

    Questa regola di 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 modificare il modo in cui un URL viene visualizzato dagli utenti. Puoi utilizzare le riscritture di URL per rendere gli URL più facili da usare, migliorare la SEO o reindirizzare gli utenti a una nuova pagina.

    Riscrivere l'intero nome host

    Per riscritturare l'intero nome host:

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

    2. Crea un manifest HTTPRoute come segue e chiamalo www.yaml:

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

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

    3. 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 eseguire la riscrittura utilizzando i modificatori di percorso:

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

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

        apiVersion: gateway.networking.k8s.io/v1beta1
        kind: HTTPRoute
        metadata:
          name: www
        spec:
          parentRefs:
            - kind: Gateway
              name: external-http
          hostnames:
          - www.example.com
          rules:
          - matches:
            - path:
                type: PathPrefix
                value: /store
            filters:
            - type: URLRewrite
              urlRewrite:
                hostname: store.example.com
                path:
                  type: ReplacePrefixMatch
                  replacePrefixMatch: /de
            backendRefs:
            - name: store-german
              port: 8080
      

      Ad esempio, con la configurazione precedente, qualsiasi richiesta 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.

    3. Applica il manifest:

      kubectl apply -f www.yaml
      

    Verifica la configurazione

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

    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 delle richieste e delle risposte personalizzate ti consentono di specificare intestazioni aggiuntive per le richieste e le 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 le intestazioni delle richieste personalizzate

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

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

    Applica il manifest:

      kubectl apply -f http-route-request.yaml
    

    Configurare le 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 le variabili supportate di Google Cloud.

    Esempio 1:

    Per configurare un percorso HTTP che aggiunge le informazioni sulla posizione del client alla richiesta HTTP prima di inviarla al servizio di backend, crea un manifest HTTPRoute e assegnagli 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 con sede a Strasburgo, in Francia, il gateway aggiunge un header come X-Client-Geo-Location:FR,Strasbourg.

    Esempio 2:

    Per configurare un percorso HTTP che aggiunge un'intestazione di risposta personalizzata per supportare HTTP Strict Transport Security, crea un file 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

    1. 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
      
    2. Per ulteriori dettagli, utilizza il comando describe:

        kubectl describe httproute
      

      L'output è simile al seguente:

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

    Stato route

    Le risorse HTTPRoute emettono condizioni ed eventi per aiutare gli utenti a capire se un percorso 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 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 l'associazione di HTTPRoute a questo gateway è stata rifiutata.

    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. Questo può accadere se il percorso non viene selezionato da nessun gateway.

    Eventi HTTPRoute

    Gli eventi HTTPRoute forniscono dettagli sullo stato della route HTTP. 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.

    Unioni, precedenza e convalida dei percorsi

    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:

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

    Unione delle route

    Per gke-l7 GatewayClass, tutti gli HTTPRoute per un determinato gateway vengono uniti in la stessa risorsa mappa URL. Il modo in cui le route HTTP vengono unite dipende dal tipo di sovrapposizione tra le route HTTP. Il percorso HTTP dell'esempio precedente può essere suddiviso in tre percorsi HTTP distinti per illustrare l'unione e la precedenza dei percorsi:

    1. Unione di route: tutti e tre le HTTPRoute si collegano con lo stesso internal-http gateway in modo che vengano uniti.
    2. Unità di nome host unite: tutti e tre i route corrispondono a store.example.com, pertanto le relative regole per i nomi host vengono unite.
    3. Combinazione di percorsi: il percorso store-german-route ha un percorso più specifico /de, pertanto non viene combinato ulteriormente. Anche i percorsi store-v1-route e store-v2-route corrispondono allo stesso percorso /*, pertanto vengono combinati sul percorso.
    4. 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.
    5. 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.

    La singola route HTTP utilizzata nell'esempio precedente è equivalente a queste tre route distinte:

    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 sia l'API Kubernetes Gateway sia l'API Istio hanno una risorsa Gateway. Sebbene svolgano funzioni simili, non sono la stessa risorsa. Se utilizzi Istio e l'API Gateway nello stesso cluster Kubernetes, questi nomi si sovrappongono quando utilizzi kubectl sulla riga di comando. kubectl get gateway potrebbe restituire le risorse Kubernetes Gateway e non quelle 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 gateway Istio è gw. I comandi seguenti restituiscono rispettivamente le risorse Kubernetes Gateway e Istio Gateway.

    # Kubernetes Gateway
    $ kubectl get gtw
    NAME                        CLASS
    multi-cluster-gateway       gke-l7-global-external-managed-mc
    
    $ kubectl get gateway.networking.x-k8s.io
    NAME                        CLASS
    multi-cluster-gateway       gke-l7-global-external-managed-mc
    
    # Istio Gateway
    $ kubectl get gw
    NAME               AGE
    bookinfo-gateway   64m
    
    $ kubectl get gateway.networking.istio.io
    NAME               AGE
    bookinfo-gateway   64m
    

    Risoluzione dei problemi

    Subnet solo proxy mancante nella regione

    Sintomo:

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

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

    Motivo:

    Questo messaggio di errore indica che nella regione per il tuo gateway non esiste alcuna subnet solo proxy.

    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 il gateway regionale (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 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:

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

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

        gcloud compute networks subnets list --regions=COMPUTE_REGION
        

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

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

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

        Sostituisci PROXY_ONLY_SUBNET con la subnet solo proxy.

      Il gateway GKE supporta solo REGIONAL_MANAGED_PROXY solo proxy per i gateway a livello di regione (interni o a livello di regione).

    2. 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, ma non riesci ad accedere ai servizi di backend (codice di risposta 503), potrebbe verificarsi il seguente problema:

    no healthy upstream
    

    Motivo:

    Questo messaggio di errore indica che il prober del controllo di integrità non può 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 ai requisiti della tua applicazione (ad esempio /health) utilizzando un HealthCheckPolicy.

    Passaggi successivi