Gateway

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

Questa pagina è rivolta agli architetti cloud e agli esperti di networking che progettano e progettano la rete per la propria organizzazione. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

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

  • Orientato ai ruoli:Gateway è composto 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.

  • Portabile:l'API Gateway è uno standard open source con molte implementazioni. È progettato utilizzando il concetto di conformità flessibile, che promuove un'API di base altamente portatile (come Ingress) che offre comunque la flessibilità e l'estensibilità per supportare le funzionalità native dell'ambiente e dell'implementazione. In questo modo, i concetti e le risorse di base sono coerenti tra implementazioni e ambienti, riducendo la complessità e aumentando la familiarità degli utenti.

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

Risorse API Gateway

L'API Gateway è un modello di risorse orientato ai ruoli, progettato per gli utenti che interagiscono con il networking di Kubernetes. Come mostrato dal seguente diagramma, questo modello consente a diversi proprietari di servizi non coordinatori di condividere la stessa infrastruttura di rete di base in modo sicuro, in modo da centralizzare i criteri 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 associano alle risorse Gateway.
Figura: panoramica dell'API Gateway

L'API Gateway contiene i seguenti tipi di risorse:

  • GatewayClass: definisce una risorsa basata sul 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 di cluster creano gateway nei loro cluster in base a una classe Gateway. GKE crea bilanciatori del carico che implementano la configurazione definita nella risorsa Gateway.
  • HTTPRoute: definisce regole specifiche per il protocollo per instradare le richieste da un gateway ai servizi Kubernetes. GKE supporta HTTPRoutes per il routing del traffico basato su HTTP(S). Gli sviluppatori di applicazioni creano RouteHTTP per esporre le proprie applicazioni HTTP utilizzando i gateway.
  • Criterio: definisce un insieme di caratteristiche specifiche dell'implementazione di una risorsa Gateway. Puoi associare un criterio a un gateway, a un percorso o a un servizio Kubernetes.
  • ReferenceGrant: consente i riferimenti tra ambiti all'interno dell'API Gateway. Per fare riferimento a un oggetto esterno al suo spazio dei nomi, devi creare una risorsa ReferenceGrant.

GatewayClass

Una classe Gateway è 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 una classe Gateway quando creano gateway nei loro cluster.

I diversi GatewayClass corrispondono a diversi bilanciatori del carico Google Cloud. 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 le classi Gateway disponibili nei cluster GKE e il relativo tipo di bilanciatore del carico sottostante. Per informazioni dettagliate su 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-global-external-managed-mc Bilanciatori del carico delle applicazioni esterni globali multicluster basati sul bilanciatore del carico delle applicazioni esterno globale
gke-l7-regional-external-managed-mc Bilanciatori del carico delle applicazioni esterni regionali multicluster basati sul bilanciatore del carico delle applicazioni esterno globale
gke-l7-rilb-mc Bilanciatori del carico delle applicazioni interni multicluster basati sul bilanciatore del carico delle applicazioni interno
gke-l7-gxlb-mc Bilanciatori del carico delle applicazioni esterni globali multicluster basati sul bilanciatore del carico delle applicazioni classico
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 di cluster creano gateway per definire dove e come i bilanciatori del carico devono monitorare il traffico. Il comportamento dei gateway (ovvero il modo in cui vengono implementati) dipende dal GatewayClass associato.

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

Per un esempio di deployment di un gateway, consulta Eseguire il deployment dei gateway.

Per un esempio di deployment di un gateway multi-cluster, consulta Eseguire il 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 HTTPRoutes per esporre le proprie applicazioni tramite i gateway.

Un parametro HTTPRoute definisce i gateway da cui può instradare il traffico, i servizi a cui indirizzarlo e le regole che definiscono il traffico a cui corrisponde. La mappatura di gateway e route è bidirezionale, il che significa che entrambe le risorse devono selezionare l'una l'altra per poter essere associate. HTTPRoutes può abbinare le richieste in base ai dettagli nell'intestazione della richiesta.

Norme

Un criterio definisce le caratteristiche di una risorsa gateway, in genere specifica dell'implementazione, che gli operatori del cluster possono collegare a un gateway, a un percorso o a un servizio Kubernetes. Un criterio definisce il funzionamento dell'infrastruttura Google Cloud di base.

Un criterio è in genere associato a uno spazio dei nomi e può fare riferimento a una risorsa nello stesso spazio dei nomi. L'accesso viene concesso utilizzando RBAC. La natura gerarchica dell'API Gateway ti consente di associare un criterio 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 del criterio.

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 carico Google Cloud. È 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. È simile a un BackendConfig per una risorsa Ingress.

ReferenceGrant

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

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

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

Proprietà e pattern di utilizzo del gateway

Le risorse Gateway e Route offrono flessibilità in termini di proprietà ed esecuzione all'interno di un'organizzazione. Ciò significa che un singolo bilanciatore del carico può essere eseguito 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ò implementare un gateway e un route solo per le sue applicazioni e utilizzarli esclusivamente. I gateway e i percorsi 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. Come per Ingress, ogni gateway corrisponde al proprio indirizzo IP e bilanciatore del carico univoci. TLS, routing e altri parametri sono completamente controllati dal proprietario del servizio.

Un unico proprietario può avere il controllo completo sia della porta di accesso che del percorso

Questo modello di utilizzo è comune per Ingress, ma è difficile scalarlo su molti team a causa della mancanza di risorse condivise. Il modello di risorsa dell'API Gateway consente i seguenti pattern di utilizzo che offrono una serie 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 di servizi. Gli amministratori della piattaforma possono implementare un gateway per spazio dei nomi o team, concedendo allo 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 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 schema di utilizzo consente di separare chiaramente le responsabilità tra i diversi ruoli.

Il routing tra spazi dei nomi consente alle route di collegarsi ai gateway oltre i confini dello spazio dei nomi. I gateway possono limitare gli spazi dei nomi a cui possono essere collegati i percorsi. Analogamente, 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 offre a ciascuna parte controlli flessibili che consentono questa diversità di modelli di utilizzo.

Nel seguente diagramma, l'amministratore della piattaforma ha implementato 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 associate. Ogni gateway rappresenta un indirizzo IP univoco con bilanciamento del carico e consente a ogni team di eseguire il deployment di un numero qualsiasi di route sul gateway per qualsiasi dominio o route che sceglie.

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 agli amministratori della piattaforma una forma di proprietà ancora più centralizzata. In questo modo, i proprietari di servizi diversi, che vengono eseguiti in Namespaces diversi, possono condividere lo stesso indirizzo IP, dominio DNS, certificati o percorsi per il routing granulare tra i servizi. I gateway consentono agli amministratori della piattaforma di controllare quali spazi dei nomi possono essere indirizzati per un dominio specifico. È simile all'esempio precedente, tranne per il fatto che i gateway consentono di collegare i percorsi da più spazi dei nomi.

Nel seguente diagramma, l'amministratore della piattaforma ha disegnato due gateway nello spazio dei nomi infra. Il gateway external consente di collegare i percorsi dagli spazi dei nomi web e mobile al gateway. I percorsi dallo spazio dei nomi accounts non possono utilizzare il gateway external perché lo spazio dei nomi accounts è solo per servizi interni. Il gateway internal consente ai client interni di comunicare privatamente all'interno della 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 di servizi mobili di configurare le regole di routing di cui hanno bisogno nel dominio m.example.com. In questo modo, i proprietari di servizi hanno un maggiore grado di controllo per l'introduzione di nuovi endpoint API e il controllo del traffico senza richiedere una modifica da parte degli 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, delegando al contempo la proprietà del routing. Come negli esempi precedenti, un amministratore della piattaforma gestisce il gateway e delega il routing. La maggiore aggiunta a questo caso d'uso è che le route fanno riferimento a servizi multi-cluster, che vengono dispiegando in più cluster. Il traffico può essere indirizzato in modo esplicito, ad esempio il traffico verso store.example.com/us viene indirizzato ai pod gke-us, oppure in modo implicito, ad esempio il traffico verso example.com/* viene indirizzato al cluster più vicino al cliente. Questa flessibilità consente ai proprietari di servizi di definire la strategia di routing ottimale per la loro applicazione.

Un gateway per flotta fornisce il bilanciamento del carico multi-cluster e multi-regionale

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 API Gateway e riconcilia le risorse Cloud Load Balancing per implementare il comportamento di rete specificato dalle risorse Gateway.

Esistono due versioni di GKE Gateway Controller:

  • 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 in hosting su Google che monitorano l'API Kubernetes per i cluster GKE. A differenza del controller di ingressi GKE, i controller di gateway non sono ospitati sui piani di controllo GKE o nel progetto dell'utente, il che li rende più scalabili e robusti. Entrambi i controller Gateway sono disponibili a livello generale.

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

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

Controller Controller di 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 di regione nella stessa regione del cluster GKE. Implementato a livello globale in più regioni Google Cloud.
Come attivare Abilitato per impostazione predefinita in GKE. Abilitato tramite l'API Multi Cluster Ingress e la registrazione in un parco risorse. Consulta Attivare i 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
  • Anteprima asm-l7-gxlb
  • gke-l7-global-external-managed-mc GA
  • gke-l7-regional-external-managed-mc GA
  • gke-l7-rilb-mc GA
  • gke-l7-gxlb-mc GA
  • Anteprima di gke-td

In un cluster GKE puoi utilizzare contemporaneamente più controller di gateway, inclusi quelli non forniti da Google. Ogni GatewayClass è supportato da un solo controller di gateway, che consente di utilizzare contemporaneamente il bilanciamento del carico a livello di singolo e multi-cluster.

Ingress e gateway

Confronto tra Ingress e Gateway

Gateway e Ingress sono entrambi standard open source per il routing del traffico. Gateway è stato progettato dalla community Kubernetes, sulla base delle lezioni apprese dagli ecosistemi Ingress e mesh di servizi. Gateway è un'evoluzione di Ingress che fornisce la stessa funzione, offerta come superset delle funzionalità di Ingress. Entrambi possono essere utilizzati contemporaneamente senza conflitti, anche se nel tempo le risorse Gateway e Route offriranno più funzionalità non disponibili in Ingress, costringendo gli utenti a iniziare a utilizzare Gateway se in precedenza utilizzavano 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 un HTTPRoute (per la configurazione del routing). L'esempio seguente mostra la configurazione corrispondente di Gateway e HTTPRoute. Tieni presente che le risorse Gateway e HTTPRoute possono essere create distintamente, anche da utenti diversi. I gateway possono avere molti percorsi e un percorso può anche essere collegato a più di un gateway. Le relazioni tra gateway e percorsi sono descritte in Modelli di utilizzo dei 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/v1beta1
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/v1beta1
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 reti mesh di servizi

Puoi configurare un mesh di servizi Cloud Service Mesh utilizzando l'API Gateway. In questo modo, vengono abilitate le comunicazioni tra servizi, la gestione del traffico, il bilanciamento del carico globale e l'applicazione dei criteri 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 del mesh di servizi GKE Cloud Service Mesh.

Prezzi

Tutte le risorse Compute Engine di cui è stato eseguito il deployment tramite i controller di gateway vengono addebitate sul progetto in cui si trovano 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 Ingress e Gateway multi-cluster.

Passaggi successivi