Informazioni sull'API Gateway

Autopilot Standard

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

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

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. In questo modo, gli operatori del cluster possono definire in che modo l'infrastruttura condivisa può essere utilizzata da molti team di sviluppatori diversi e non coordinati.

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

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

Risorse 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 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 i criteri e il controllo per l'amministratore della piattaforma.

Figura: panoramica di Gateway API

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 GatewayClasses che possono essere utilizzate 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 una 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 proprie 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

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

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

Alcune GatewayClass supportano il bilanciamento del carico multi-cluster.

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

Nome di GatewayClass	Descrizione
gke-l7-global-external-managed	Bilanciatore del carico delle applicazioni esterno globale creato sul bilanciatore del carico delle applicazioni esterno globale
gke-l7-regional-external-managed	Bilanciatore del carico delle applicazioni esterno regionale creato sul bilanciatore del carico delle applicazioni esterno regionale
gke-l7-rilb	Bilanciatore del carico delle applicazioni interno o bilanciatori del carico delle applicazioni interni creati sul bilanciatore del carico delle applicazioni interno
gke-l7-gxlb	Bilanciatore del carico delle applicazioni esterno globale creato sul bilanciatore del carico delle applicazioni classico
gke-l7-cross-regional-internal-managed-mc	Bilanciatore del carico delle applicazioni interno tra regioni multicluster creato sul bilanciatore del carico delle applicazioni interno tra regioni
gke-l7-global-external-managed-mc	Bilanciatore del carico delle applicazioni esterno globale multicluster creato sul bilanciatore del carico delle applicazioni esterno globale
gke-l7-regional-external-managed-mc	Bilanciatore del carico delle applicazioni esterno regionale multicluster creato sul bilanciatore del carico delle applicazioni esterno regionale
gke-l7-rilb-mc	Bilanciatore del carico delle applicazioni interno multicluster creato sul bilanciatore del carico delle applicazioni interno
gke-l7-gxlb-mc	Bilanciatore del carico delle applicazioni esterno globale multicluster creato sul bilanciatore del carico delle applicazioni classico
gke-td	Service Mesh di Cloud Service Mesh multicluster
asm-l7-gxlb	Bilanciatore del carico delle applicazioni esterno globale creato su Cloud Service Mesh

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

Nota: quando valuti il deployment di un bilanciatore del carico delle applicazioni esterno globale, ti consigliamo di utilizzare le GatewayClass gke-l7-global-external-managed(-mc) anziché le GatewayClass gke-l7-gxlb(-mc) per usufruire delle funzionalità avanzate di sicurezza e gestione del traffico. Per scoprire di più sulle diverse funzionalità supportate da ogni GatewayClass, consulta Funzionalità di GatewayClass.

Gateway

Gli operatori del cluster creano gateway per definire dove e come i bilanciatori del carico ascoltano il traffico. I gateway derivano il proprio comportamento (ovvero la modalità di implementazione) dalla GatewayClass associata.

La specifica Gateway include 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 Route.

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

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

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 da quali gateway può instradare il traffico, a quali servizi instradare il traffico e le regole che definiscono il traffico corrispondente a HTTPRoute. Il binding di gateway e route è bidirezionale, il che significa che entrambe le risorse devono selezionarsi a vicenda per essere associate. HTTPRoute può abbinare le richieste in base ai dettagli nell'intestazione della richiesta.

Nota :quando più risorse HTTPRoute fanno riferimento allo stesso gateway, vengono tutte compilate in una singola mappa URL nell'infrastruttura Google Cloud sottostante. Di conseguenza, tutte le HTTPRoute collegate a un singolo gateway sono soggette alle stesse quote e limiti della mappa URL.

Norme

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. Un criterio definisce il funzionamento dell'infrastruttura Google Cloud sottostante.

Un criterio è in genere associato 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 ti consente di collegare una policy a una risorsa di primo livello (Gateway) in uno spazio dei nomi e fare in modo che tutte le risorse sottostanti in spazi dei nomi diversi ricevano le caratteristiche di questa policy.

Il controller GKE Gateway supporta i seguenti criteri:

• 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 bilanciatore del caricoGoogle Cloud . Questo criterio è simile a un FrontendConfig per una risorsa Ingress.
• GCPBackendPolicy: definisce in che modo i servizi di backend del bilanciatore del carico devono distribuire il traffico agli endpoint. Questo criterio è simile a un BackendConfig per una risorsa Ingress.
• GCPBackendPolicy: definisce in che modo i servizi di backend del bilanciatore del carico distribuiscono il traffico ai backend. La policy GCPBackendPolicy supporta la modalità di bilanciamento CUSTOM_METRICS, che consente di prendere decisioni di routing in base a metriche dell'applicazione definite dall'utente e riportate nei report di carico ORCA.
• GCPTrafficDistributionPolicy: definisce come viene distribuito il traffico tra gli endpoint all'interno di un backend. Queste norme sono simili a quelle che configureresti per algoritmi di bilanciamento del carico specifici per il servizio di backend a cui fa riferimento una risorsa Ingress.

Nota: Google Cloud ha sostituito la policy LbPolicy con la policy GCPBackendPolicy. LbPolicy è ancora supportato, ma senza attributi aggiuntivi.

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, è necessario 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 dove:

• Il campo from elenca lo spazio dei nomi di origine e il tipo di risorsa autorizzati a creare 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 nel tuo stato del gateway ricevi il messaggio di errore "Nessuna concessione di riferimento valida trovata", 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 implementato e gestito da un team di infrastruttura, 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 GKE Gateway supporta l'utilizzo multi-tenant di un bilanciatore del carico, condiviso tra spazi dei nomi, cluster e regioni. Inoltre, 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 esclusivamente. 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 implementano e gestiscono i propri gateway. Analogamente a Ingress, ogni gateway corrisponde al proprio bilanciatore del carico e indirizzo IP univoco. TLS, routing e altre norme sono completamente controllati dal proprietario del servizio.

Questo pattern di utilizzo è comune per Ingress, ma è difficile da scalare in 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 implementare un gateway per spazio dei nomi o team, concedendo a quest'ultimo l'accesso esclusivo all'utilizzo del gateway. In questo modo, il proprietario del servizio ha il pieno controllo delle regole di routing senza alcun rischio di conflitto con altri team. In questo modo, l'amministratore della piattaforma può controllare aspetti quali l'allocazione 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 modello di utilizzo crea una chiara 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 a cui possono essere associate le route. 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 attacco bidirezionale fornisce a ogni lato controlli flessibili che consentono questa diversità di modelli di utilizzo.

Nel seguente diagramma, l'amministratore della piattaforma ha eseguito il deployment di un gateway per l'accesso esclusivo per 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 con bilanciamento del carico univoco e consente a ogni team di eseguire il deployment di un numero qualsiasi di route rispetto al gateway per qualsiasi dominio o route scelti.

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. In questo modo, diversi proprietari di servizi, in esecuzione in spazi dei nomi diversi, possono condividere lo stesso indirizzo IP, dominio DNS, certificati o percorsi per un routing granulare tra i servizi. I gateway consentono agli amministratori della piattaforma di controllare quali spazi dei nomi possono instradare per un dominio specifico. Questo esempio è simile al 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 ai percorsi degli spazi dei nomi web e mobile di essere collegati 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.

Il dominio m.example.com viene delegato allo spazio dei nomi mobile, che consente ai proprietari di servizi mobili 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.

Shared Gateway per Fleet

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 multicluster 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 in più cluster. Il traffico può essere instradato in modo esplicito, il traffico verso store.example.com/us va ai pod gke-us oppure in modo implicito, il traffico verso example.com/* viene instradato al cluster più vicino al client. Questa flessibilità consente ai proprietari del servizio di definire la strategia di routing ottimale per la loro applicazione.

GKE Gateway Controller

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

Esistono due versioni del controller GKE Gateway:

• 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 di GKE, i controller Gateway non sono ospitati sui piani di controllo GKE o nel progetto utente, il che li rende più scalabili e robusti. Entrambi i controller gateway sono disponibili pubblicamente (GA).

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

Controller	Controller del gateway a cluster singolo	Controller del 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.	Eseguiti il deployment a livello globale in più Google Cloud regioni.
Come attivare	Abilitato per impostazione predefinita in GKE.	Abilitato tramite l'API Multi Cluster Ingress e la registrazione in un parco risorse. Consulta Attivazione di gateway multi-cluster.
GatewayClass supportate	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 quelli non forniti da Google, in un cluster GKE contemporaneamente. Ogni GatewayClass è supportata da un solo controller Gateway, che consente di utilizzare contemporaneamente il bilanciamento del carico singolo e multi-cluster.

Service Extensions

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

Nota: il supporto per le estensioni di servizio è in fase di anteprima.

Il controller GKE Gateway supporta due tipi di estensioni:

• GCPTrafficExtension: questa estensione consente di 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 GKE Gateway, consulta Personalizzare il traffico del gateway GKE utilizzando le estensioni di servizio.

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, attingendo alle 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 direttamente convertibili in risorse Gateway e HTTPRoute. Un singolo Ingress corrisponde sia a un gateway (per la configurazione del frontend) sia a una risorsa HTTPRoute (per la configurazione del routing). L'esempio seguente mostra l'aspetto della configurazione corrispondente di Gateway e HTTPRoute. 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ò essere collegata anche a più di un gateway. Le relazioni tra gateway e route sono descritte in Modelli 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 le service mesh

Puoi configurare un Cloud Service Mesh utilizzando l'API Gateway. Ciò consente le comunicazioni da servizio a servizio, la gestione del traffico, il bilanciamento del carico globale e l'applicazione delle policy di sicurezza per i casi d'uso di 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 è 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 Gateway multi-cluster e Ingress multi-cluster.

Passaggi successivi

• Scopri come configurare le risorse Gateway utilizzando i criteri
• Scopri di più sul deployment dei gateway.
• Scopri di più sul deployment di gateway multi-cluster.
• Per informazioni complete sull'utilizzo di Cloud Service Mesh con l'API Gateway, consulta la panoramica di Cloud Service Mesh.