Informazioni sull'API 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 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 di Google Cloud , consulta Ruoli utente e attività comuni di GKE Enterprise.

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.

• Portabile: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 offre comunque la flessibilità e l'estensibilità per supportare le funzionalità native dell'ambiente e dell'implementazione.

• Espressivo:le risorse API Gateway forniscono funzionalità integrate per la corrispondenza basata sull'intestazione, 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 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.

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 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 instradare le 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 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 bilanciamento del carico sottostante. Per informazioni dettagliate sulle GatewayClass, consulta le funzionalità e le specifiche di GatewayClass.

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 assumono il proprio comportamento (ovvero la modalità di implementazione) dalla GatewayClass associata.

La specifica del 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, vedi Deployment dei gateway.

Per un esempio di deployment di un gateway multi-cluster, consulta 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 proprie 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.

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 un criterio 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 questo 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 caricoGoogle Cloud . Questo criterio è simile a un FrontendConfig per una risorsa Ingress.
• GCPBackendPolicy: definisce la modalità di distribuzione del traffico agli endpoint da parte dei servizi di backend del bilanciatore del carico. Questo criterio è simile a un BackendConfig per una risorsa Ingress.
• GCPBackendPolicy: definisce la modalità di distribuzione del traffico ai backend da parte dei servizi di backend del bilanciatore del carico. Il criterio GCPBackendPolicy supporta la modalità di bilanciamento del carico CUSTOM_METRICS, che consente di prendere decisioni di routing in base alle metriche dell'applicazione definite dall'utente e riportate nei report sul 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.

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: networking.gke.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 indirizzo IP univoco e al proprio bilanciamento del carico. 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 uno spettro 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 pattern 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 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 collegate. Ogni gateway rappresenta un indirizzo IP univoco e bilanciato per il carico, quindi 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, condividono 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 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.

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 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 o 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 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 GKE, i controller Gateway non sono ospitati sui control plane GKE o nel progetto utente, il che li rende più scalabili e robusti. Entrambi i controller Gateway sono disponibili pubblicamente.

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 multi-cluster. Il controller sottostante utilizzato dipende da GatewayClass del gateway di cui è stato eseguito il deployment.

Puoi utilizzare più controller Gateway, inclusi quelli non forniti da Google, in un cluster GKE contemporaneamente. Ogni GatewayClass è supportata da un solo controller Gateway, il che consente di utilizzare contemporaneamente il bilanciamento del carico su un singolo cluster e su più cluster.

Service Extensions

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

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 norme 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 instradato il traffico per una determinata richiesta.

Per ulteriori informazioni su come configurare i controller GKE Gateway, consulta Personalizzare il traffico di GKE Gateway 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 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 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ò anche essere collegata a più di un gateway. Le relazioni tra gateway e route sono descritte in Modelli di utilizzo del gateway.

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

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

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 i service mesh

Puoi configurare un mesh di servizi 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 norme di sicurezza per i casi d'uso demesh di servizish. Per informazioni complete sull'utilizzo di Cloud Service Mesh con l'API Gateway, incluse le guide alla configurazione del deployment, consulta Panoramica di Cloud Service Mesh Gmesh di serviziice 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 Ingress multi-cluster e del gateway.

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 GKE mesh di servizi mesh.