Informazioni sull'API Gateway

Questa pagina descrive l'implementazione di Google Kubernetes Engine (GKE) dell' API Gateway di Kubernetes utilizzando il controller Gateway GKE.

Questa pagina è rivolta agli architetti cloud e agli specialisti di networking che progettano e realizzano l'architettura della rete della loro organizzazione. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti GKE.

L'API Gateway è uno standard open source per il networking di servizi. L'API Gateway fa evolvere la risorsa Ingress e la migliora nei seguenti modi:

  • Orientata ai ruoli: l'API Gateway è composta da risorse API che corrispondono ai ruoli organizzativi di operatore del cluster, sviluppatore e fornitore di infrastrutture. Ciò consente agli operatori del cluster di definire in che modo l'infrastruttura condivisa può essere utilizzata da molti team di sviluppo diversi e non coordinati.

  • Portatile: l'API Gateway è uno standard open source con molte implementazioni, che consente di mantenere la coerenza dei concetti e delle risorse principali tra implementazioni e ambienti, riducendo la complessità e aumentando la familiarità degli utenti. La sua progettazione utilizza il concetto di conformità flessibile, utilizzando un'API di base altamente portatile (come Ingress) che mantiene la flessibilità ed estensibilità per supportare le funzionalità native dell'ambiente e dell'implementazione.

  • Espressiva: le risorse dell'API Gateway forniscono funzionalità integrate per la corrispondenza basata sulle intestazioni, la ponderazione del traffico e altre funzionalità possibili in Ingress solo tramite annotazioni personalizzate.

Risorse dell'API Gateway

L'API Gateway è un modello di risorse orientato ai ruoli, progettato per architetti cloud e specialisti di networking che interagiscono con il networking di Kubernetes. Come mostrato nel seguente diagramma, questo modello consente a diversi proprietari di servizi non coordinati di condividere la stessa infrastruttura di rete sottostante in modo sicuro, centralizzando le policy e il controllo per l'amministratore della piattaforma.

GKE fornisce classi Gateway. Gli operatori del cluster creano risorse Gateway in base a queste classi. Gli sviluppatori di applicazioni creano risorse HTTPRoute che si legano alle risorse Gateway.
Figura: panoramica dell'API Gateway

L'API Gateway contiene i seguenti tipi di risorse:

  • GatewayClass: definisce una risorsa con ambito cluster che è un modello per la creazione di bilanciatori del carico in un cluster. GKE fornisce GatewayClass che possono essere utilizzati nei cluster GKE.
  • Gateway: definisce dove e come i bilanciatori del carico ascoltano il traffico. Gli operatori del cluster creano gateway nei cluster in base a un GatewayClass. GKE crea bilanciatori del carico che implementano la configurazione definita nella risorsa Gateway.
  • HTTPRoute: definisce regole specifiche del protocollo per il routing delle richieste da un gateway ai servizi Kubernetes. GKE supporta HTTPRoute per il routing del traffico basato su HTTP(S). Gli sviluppatori di applicazioni creano HTTPRoute per esporre le loro applicazioni HTTP utilizzando i gateway.
  • Policy: definisce un insieme di caratteristiche specifiche dell'implementazione di una risorsa Gateway. Puoi collegare una policy a un gateway, a una route o a un servizio Kubernetes.
  • ReferenceGrant: consente i riferimenti tra spazi dei nomi all'interno dell'API Gateway. Per fare riferimento a un oggetto al di fuori del suo spazio dei nomi, devi creare una risorsa ReferenceGrant.

GatewayClass

Un GatewayClass è una risorsa che definisce un modello per i bilanciatori del carico HTTP(S) (livello 7) in un cluster Kubernetes. GKE fornisce GatewayClass come risorse con ambito cluster. Gli operatori del cluster specificano un GatewayClass quando creano gateway nei cluster.

I diversi GatewayClass corrispondono a diversi Google Cloud bilanciatori di carico. Quando crei un gateway basato su un GatewayClass, viene creato un bilanciatore del carico corrispondente per implementare la configurazione specificata.

Alcuni GatewayClass supportano il bilanciamento del carico multi-cluster.

La tabella seguente elenca i GatewayClass disponibili nei cluster GKE e il tipo di bilanciatore del carico sottostante. Per informazioni dettagliate sui GatewayClass, consulta le funzionalità e le specifiche di GatewayClass.

Nome GatewayClass Descrizione
gke-l7-global-external-managed Bilanciatori del carico delle applicazioni esterni globali basati sul bilanciatore del carico delle applicazioni esterno globale
gke-l7-regional-external-managed Bilanciatori del carico delle applicazioni esterni regionali basati sul bilanciatore del carico delle applicazioni esterno regionale
gke-l7-rilb Bilanciatori del carico delle applicazioni interni basati sul bilanciatore del carico delle applicazioni interno
gke-l7-gxlb Bilanciatori del carico delle applicazioni esterni globali basati sul bilanciatore del carico delle applicazioni classico
gke-l7-cross-regional-internal-managed-mc Bilanciatori del carico delle applicazioni interni tra regioni multi-cluster basati sul bilanciatore del carico delle applicazioni interno tra regioni
gke-l7-global-external-managed-mc Bilanciatori del carico delle applicazioni esterni globali multi-cluster basati sul bilanciatore del carico delle applicazioni esterno globale
gke-l7-regional-external-managed-mc Bilanciatori del carico delle applicazioni esterni regionali multi-cluster basati sul bilanciatore del carico delle applicazioni esterno regionale
gke-l7-rilb-mc Bilanciatori del carico delle applicazioni interni multi-cluster basati sul bilanciatore del carico delle applicazioni interno
gke-l7-gxlb-mc Bilanciatori del carico delle applicazioni esterni globali multi-cluster basati sul bilanciatore del carico delle applicazioni classico
gke-td Cloud Service Mesh multi-cluster
asm-l7-gxlb Bilanciatori del carico delle applicazioni esterni globali basati su Cloud Service Mesh

Ogni GatewayClass è soggetto alle limitazioni del bilanciatore del carico sottostante.

Gateway

Gli operatori del cluster creano gateway per definire dove e come i bilanciatori del carico ascoltano il traffico. I gateway prendono il loro comportamento (ovvero come vengono implementati) dal GatewayClass associato.

La specifica del gateway include il GatewayClass per il gateway, le porte e i protocolli da ascoltare e le route che possono essere associate al gateway. Un gateway seleziona le route in base ai metadati della route, in particolare al tipo, allo spazio dei nomi e alle etichette delle risorse della route.

Per un esempio di deployment di un gateway, consulta Deployment dei gateway.

Per un esempio di deployment di un gateway multi-cluster, consulta Deployment di gateway multi-cluster Gateways.

HTTPRoute

Un parametro HTTPRoute definisce il modo in cui le richieste HTTP e HTTPS ricevute da un gateway vengono indirizzate ai servizi. Gli sviluppatori di applicazioni creano HTTPRoute per esporre le loro applicazioni tramite i gateway.

Un parametro HTTPRoute definisce i gateway da cui può instradare il traffico, i servizi a cui instradare e le regole che definiscono il traffico corrispondente a HTTPRoute. L'associazione di gateway e route è bidirezionale, il che significa che entrambe le risorse devono selezionarsi a vicenda per essere associate. HTTPRoute può trovare corrispondenze con le richieste in base ai dettagli nell'intestazione della richiesta.

Policy

Una policy definisce le caratteristiche di una risorsa Gateway, in genere specifiche dell'implementazione, che gli operatori del cluster possono collegare a un gateway, a una route o a un servizio Kubernetes. Una policy definisce il funzionamento dell'infrastruttura sottostante Google Cloud .

Una policy viene in genere collegata a uno spazio dei nomi e può fare riferimento a una risorsa nello stesso spazio dei nomi e l'accesso viene concesso utilizzando RBAC. La natura gerarchica dell'API Gateway consente di collegare una policy a una risorsa principale (gateway) in uno spazio dei nomi e di fare in modo che tutte le risorse sottostanti in spazi dei nomi diversi ricevano le caratteristiche di quella policy.

Il controller Gateway GKE supporta le seguenti policy:

  • HealthCheckPolicy: definisce i parametri e il comportamento del controllo di integrità utilizzato per verificare lo stato di integrità dei pod di backend.
  • GCPGatewayPolicy: definisce parametri specifici del frontend del Google Cloud bilanciatore del carico. Questa policy è simile a un FrontendConfig per una risorsa Ingress.
  • GCPBackendPolicy: definisce in che modo i servizi di backend del bilanciatore del carico distribuiscono il traffico agli endpoint (backend). Questa policy è simile a un BackendConfig per una risorsa Ingress e supporta funzionalità come la modalità di bilanciamento CUSTOM_METRICS, che consente di prendere decisioni di routing in base alle metriche dell'applicazione definite dall'utente e riportate tramite i report di carico ORCA.
  • GCPTrafficDistributionPolicy: definisce in che modo il traffico viene distribuito tra gli endpoint all'interno di un backend. Questa policy è simile alla configurazione di algoritmi di bilanciamento del traffico specifici per il servizio di backend a cui fa riferimento una risorsa Ingress.

ReferenceGrant

ReferenceGrant consente a risorse come HTTPRoute o Gateway di fare riferimento a servizi di backend o secret che si trovano in spazi dei nomi diversi tramite riferimenti tra spazi dei nomi. ReferenceGrant funge da fornitore di autorizzazioni, specificando quali risorse (from) possono fare riferimento ad altre risorse (to). Per abilitare i riferimenti tra spazi dei nomi, devi avere un ReferenceGrant nello spazio dei nomi della risorsa a cui viene fatto riferimento.

Nell'esempio seguente, HTTPRoute nello spazio dei nomi frontend deve instradare il traffico a un servizio nello spazio dei nomi backend. Crea un ReferenceGrant nello spazio dei nomi backend in cui:

  • Il campo from elenca il tipo di risorsa e lo spazio dei nomi di origine autorizzati a effettuare riferimenti, ovvero HTTPRoute nello spazio dei nomi frontend.
  • Il campo to specifica il tipo di risorsa di destinazione a cui è possibile fare riferimento, ovvero i servizi nello spazio dei nomi backend.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-frontend-to-access-backend
  namespace: backend
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: frontend
  to:
  - group: ""
    kind: Service

Se ricevi il messaggio di errore "No valid reference grant found" (Nessuna concessione di riferimento valida trovata) nello stato del gateway, verifica che i valori group, kind, namespace e name definiti nelle sezioni from e to siano validi.

Proprietà e pattern di utilizzo del gateway

Le risorse Gateway e Route offrono flessibilità in termini di proprietà e deployment all'interno di un'organizzazione. Ciò significa che un singolo bilanciatore del carico può essere sottoposto a deployment e gestito da un team di infrastrutture, ma il routing in un determinato dominio o percorso può essere delegato a un altro team in un altro spazio dei nomi Kubernetes. Il controller Gateway GKE supporta l'utilizzo multi-tenant di un bilanciatore del carico, condiviso tra spazi dei nomi, cluster e regioni. I gateway non devono essere condivisi se è richiesta una proprietà più distribuita. Di seguito sono riportati alcuni dei pattern di utilizzo più comuni per i gateway in GKE.

Gateway autogestito

Un singolo proprietario può eseguire il deployment di un gateway e di una route solo per le proprie applicazioni e utilizzarli in modo esclusivo. I gateway e le route di cui è stato eseguito il deployment in questo modo sono simili a Ingress. Il seguente diagramma mostra due diversi proprietari di servizi che eseguono il deployment e gestiscono i propri gateway. Analogamente a Ingress, ogni gateway corrisponde al proprio indirizzo IP e bilanciatore del carico univoci. TLS, routing e altre policy sono completamente controllati dal proprietario del servizio.

Un singolo proprietario può avere il controllo completo sia del gateway che della route

Questo pattern di utilizzo è comune per Ingress, ma è difficile da scalare su molti team a causa della mancanza di risorse condivise. Il modello di risorse dell'API Gateway consente i seguenti pattern di utilizzo che forniscono una gamma di opzioni per il controllo e la proprietà distribuiti.

Gateway gestito dalla piattaforma per spazio dei nomi

La separazione tra le risorse Gateway e Route consente agli amministratori della piattaforma di controllare i gateway per conto dei proprietari dei servizi. Gli amministratori della piattaforma possono eseguire il deployment di un gateway per spazio dei nomi o team, concedendo a questo spazio dei nomi l'accesso esclusivo all'utilizzo del gateway. In questo modo, il proprietario del servizio ha il pieno controllo sulle regole di routing senza alcun rischio di conflitto da parte di altri team. Ciò consente all'amministratore della piattaforma di controllare aspetti quali l'allocazione degli IP, l'esposizione delle porte, i protocolli, i domini e TLS. Gli amministratori della piattaforma possono anche decidere quali tipi di gateway sono disponibili per i team, ad esempio gateway interni o esterni. Questo pattern di utilizzo crea una netta separazione delle responsabilità tra i diversi ruoli.

Il routing tra spazi dei nomi consente alle route di collegarsi ai gateway oltre i limiti dello spazio dei nomi. I gateway possono limitare gli spazi dei nomi da cui le route possono essere collegate. Allo stesso modo, le route specificano i gateway a cui si collegano, ma possono collegarsi solo a un gateway che ha consentito lo spazio dei nomi della route. Questo collegamento bidirezionale fornisce a ogni lato controlli flessibili che consentono questa diversità di pattern di utilizzo.

Nel seguente diagramma, l'amministratore della piattaforma ha eseguito il deployment di un gateway per l'accesso esclusivo a ogni spazio dei nomi. Ad esempio, il gateway store è configurato in modo che solo le route dello spazio dei nomi store possano essere collegate. Ogni gateway rappresenta un indirizzo IP univoco con bilanciamento del carico, quindi consente a ogni team di eseguire il deployment di un numero qualsiasi di route rispetto al gateway per qualsiasi dominio o route scelga.

Un gateway per spazio dei nomi fornisce l'accesso esclusivo di un gateway a quello spazio dei nomi.

Gateway condiviso per cluster

La condivisione dei gateway tra gli spazi dei nomi offre una forma di proprietà ancora più centralizzata agli amministratori della piattaforma. Ciò consente a diversi proprietari di servizi, in esecuzione in spazi dei nomi diversi, di condividere lo stesso indirizzo IP, dominio DNS, certificati o percorsi per il routing granulare tra i servizi. I gateway forniscono agli amministratori della piattaforma il controllo sugli spazi dei nomi che possono instradare per un dominio specifico. Questo è simile all'esempio precedente, tranne per il fatto che i gateway consentono l'associazione di route da più spazi dei nomi.

Nel seguente diagramma, l'amministratore della piattaforma ha eseguito il deployment di due gateway nello spazio dei nomi infra. Il gateway external consente alle route degli spazi dei nomi web e mobile di essere collegate al gateway. Le route dello spazio dei nomi accounts non possono utilizzare il gateway external perché lo spazio dei nomi accounts è solo per i servizi interni. Il gateway internal consente ai client interni di comunicare privatamente all'interno del VPC utilizzando indirizzi IP privati.

Un gateway per cluster consente a diversi spazi dei nomi all'interno di un cluster di condividere un unico gateway

Il dominio m.example.com viene delegato allo spazio dei nomi mobile, che consente ai proprietari dei servizi mobile di configurare le regole di routing necessarie nel dominio m.example.com. In questo modo, i proprietari dei servizi hanno un maggiore controllo sull'introduzione di nuovi endpoint API e sul controllo del traffico senza richiedere una modifica agli amministratori.

Gateway condiviso per parco risorse

Utilizzando i gateway multi-cluster, un gateway può essere condiviso tra spazi dei nomi, cluster e regioni. Le grandi organizzazioni con app distribuite geograficamente potrebbero trarre vantaggio dai gateway multi-cluster perché possono controllare in modo granulare il traffico globale e delegare la proprietà del routing. Analogamente agli esempi precedenti, un amministratore della piattaforma gestisce il gateway e delega il routing. La principale aggiunta a questo caso d'uso è che le route fanno riferimento a servizi multi-cluster, di cui è stato eseguito il deployment nei cluster. Il traffico può essere instradato in modo esplicito, il traffico verso store.example.com/us va ai pod gke-us o in modo implicito, il traffico verso example.com/* viene instradato al cluster più vicino al client. Questa flessibilità consente ai proprietari dei servizi di definire la strategia di routing ottimale per la loro applicazione.

Un gateway per parco veicoli fornisce il bilanciamento del carico multiregionale e multi-cluster

Controller Gateway GKE

Il controller Gateway GKE è l'implementazione di Google dell'API Gateway per Cloud Load Balancing. Analogamente al controller Ingress GKE, il controller Gateway monitora un'API Kubernetes per le risorse dell'API Gateway e riconcilia le risorse di Cloud Load Balancing per implementare il comportamento di rete specificato dalle risorse Gateway.

Esistono due versioni del controller Gateway GKE:

  • Cluster singolo: gestisce i gateway a cluster singolo per un singolo cluster GKE.
  • Multi-cluster: gestisce i gateway multi-cluster per uno o più cluster GKE.

Entrambi i controller Gateway sono controller ospitati da Google che monitorano l'API Kubernetes per i cluster GKE. A differenza del controller Ingress GKE, i controller Gateway non sono ospitati sui control plane GKE o nel progetto utente, il che consente loro di essere più scalabili e robusti. Entrambi i controller Gateway sono in disponibilità generale (GA).

I controller Gateway non sono un piano dati di rete e non elaborano alcun traffico. Si trovano fuori banda dal traffico e gestiscono vari piani dati che elaborano il traffico. Il seguente diagramma mostra l'architettura dei controller Gateway GKE a cluster singolo e multi-cluster. Il controller sottostante utilizzato dipende dal GatewayClass del gateway di cui è stato eseguito il deployment.

I controller Gateway multi-cluster e single-cluster eseguono il deployment e gestiscono i bilanciatori del carico per GKE, ma non elaborano direttamente il traffico di rete.

Controller Controller Gateway a cluster singolo Controller Gateway multi-cluster
Gestito da Google Cloud Google Cloud
Ambito cluster Gateway a cluster singolo Gateway multi-cluster
Località di deployment Eseguito il deployment a livello regionale nella stessa regione del cluster GKE. Eseguito il deployment a livello globale in più Google Cloud regioni.
Come abilitare Abilitato per impostazione predefinita in GKE. Abilitato tramite l'API Ingress multi-cluster e la registrazione in un parco risorse. Consulta Abilitazione di gateway multi-cluster.
GatewayClass supportati
  • gke-l7-global-external-managed GA
  • gke-l7-regional-external-managed GA
  • gke-l7-rilb GA
  • gke-l7-gxlb GA
  • asm-l7-gxlb Anteprima
  • gke-l7-global-external-managed-mc GA
  • gke-l7-regional-external-managed-mc GA
  • gke-l7-cross-regional-internal-managed-mc GA
  • gke-l7-rilb-mc GA
  • gke-l7-gxlb-mc GA
  • gke-td Anteprima

Puoi utilizzare più controller Gateway, inclusi i controller non forniti da Google, contemporaneamente in un cluster GKE. Ogni GatewayClass è supportato da un solo controller Gateway, il che consente di utilizzare contemporaneamente il bilanciamento del carico a cluster singolo e multi-cluster.

Service Extensions

Il controller Gateway GKE supporta le Service Extensions, che consentono di aggiungere logica personalizzata a Cloud Load Balancing.

Il controller Gateway GKE supporta due tipi di estensioni:

  • GCPTrafficExtension: questa estensione fornisce un modo per aggiungere logica personalizzata a Cloud Load Balancing. Il servizio di estensione può modificare le intestazioni e i payload di richieste e risposte senza influire sulla scelta dei servizi di backend o su altre policy di sicurezza associate al servizio di backend.
  • GCPRoutingExtension: questa estensione fornisce un modo per aggiungere logica personalizzata a Cloud Load Balancing per controllare dove viene indirizzato il traffico per una determinata richiesta.

Per saperne di più su come configurare i controller Gateway GKE, consulta Personalizzare il traffico del gateway GKE utilizzando le Service Extensions.

Ingress e gateway

Ingress e Gateway sono entrambi standard open source per il routing del traffico, ma presentano differenze fondamentali.

Confronto tra Ingress e Gateway

Gateway e Ingress sono entrambi standard open source per il routing del traffico e possono essere utilizzati contemporaneamente senza conflitti. Nel tempo, ti consigliamo di passare all'utilizzo delle risorse Gateway e Route grazie alle loro maggiori funzionalità. Gateway è stato progettato dalla community di Kubernetes, basandosi sulle lezioni apprese dagli ecosistemi Ingress e mesh di servizi. Gateway è un'evoluzione di Ingress che svolge la stessa funzione, fornita come superset delle funzionalità di Ingress.

In GKE, tutte le risorse Ingress sono convertibili direttamente in risorse Gateway e HTTPRoute. Un singolo Ingress corrisponde sia a un gateway (per la configurazione del frontend) sia a un HTTPRoute (per la configurazione del routing). L'esempio seguente mostra l'aspetto della configurazione di Gateway e HTTPRoute corrispondente. Tieni presente che le risorse Gateway e HTTPRoute possono essere create separatamente, anche da utenti diversi. I gateway possono avere molte route e una route può anche essere collegata a più di un gateway. Le relazioni tra gateway e route sono descritte in Pattern di utilizzo del gateway.

In entrata

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: "gce-internal"
spec:
  rules:
  - host: "example.com"
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: site
            port:
              number: 80
      - pathType: Prefix
        path: /shop
        backend:
          service:
            name: store
            port:
              number: 80

Gateway

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

Route

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        value: /
    backendRefs:
    - name: site
      port: 80
  - matches:
    - path:
        value: /shop
    backendRefs:
    - name: store
      port: 80

Integrazione dell'API Gateway con i mesh di servizi

Puoi configurare un Cloud Service Mesh utilizzando l'API Gateway. Ciò consente le comunicazioni tra servizi, la gestione del traffico, il bilanciamento del carico globale e l'applicazione delle policy di sicurezza per i casi d'uso del mesh di servizi. Per informazioni complete sull'utilizzo di Cloud Service Mesh con l'API Gateway, incluse le guide alla configurazione del deployment, consulta la panoramica di Cloud Service Mesh.

Prezzi

Tutte le risorse Compute Engine di cui è stato eseguito il deployment tramite i controller Gateway vengono addebitate al progetto in cui risiedono i cluster GKE. Il controller Gateway a cluster singolo viene offerto senza costi aggiuntivi nell'ambito dei prezzi di GKE Standard e Autopilot. I prezzi dei gateway multi-cluster sono descritti nella pagina dei prezzi di Multi Cluster Gateway e Ingress multi-cluster.

Passaggi successivi