Informazioni sull'API Gateway

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

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

L'API Gateway è uno standard open source per il networking di servizi. L'API Gateway evolve 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 provider di infrastruttura. In questo modo, gli operatori dei cluster possono definire come 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, che consente di mantenere coerenti i concetti e le risorse principali tra le implementazioni e gli ambienti, riducendo la complessità e aumentando la familiarità degli utenti. Il suo design utilizza il concetto di conformità flessibile, utilizzando un'API di base altamente portabile (come Ingress) che ha comunque la flessibilità e l'estensibilità per supportare le funzionalità native dell'ambiente e dell'implementazione.

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

  • Supporto flessibile dello stack IP: puoi eseguire il deployment delle risorse Gateway (gke-l7-rilb, gke-l7-regional-external-managed o gke-l7-global-external-managed) su cluster IPv4 a stack singolo, cluster a doppio stack o cluster IPv6 a stack singolo (anteprima). Poiché i bilanciatori del carico delle applicazioni terminano le connessioni client sul proxy, il frontend e il backend possono utilizzare versioni IP diverse. Ad esempio, una risorsa Gateway con un indirizzo frontend IPv4 può instradare il traffico agli endpoint dei pod solo IPv6 e una risorsa Gateway con un indirizzo frontend IPv6 può instradare il traffico agli endpoint dei pod solo IPv4.

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 di Kubernetes. Come mostrato nel diagramma seguente, questo modello consente a diversi proprietari di servizi non coordinati di condividere in sicurezza la stessa infrastruttura di rete sottostante in modo da centralizzare la 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 associano alle risorse Gateway.
Figura: Panoramica di API Gateway

L'API Gateway contiene i seguenti tipi di risorse:

  • GatewayClass: definisce una risorsa con ambito cluster che funge da 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 dei cluster creano i gateway nei loro cluster in base a una GatewayClass. GKE crea bilanciatori del carico che implementano la configurazione definita nella risorsa Gateway.
  • HTTPRoute: definisce regole specifiche per il 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: abilita 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 dei cluster specificano una GatewayClass quando creano i gateway nei loro cluster.

Le diverse GatewayClass corrispondono ai diversi bilanciatori del caricoGoogle Cloud . 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 classi GatewayClass disponibili nei cluster GKE, il tipo di bilanciatore del carico sottostante e il supporto dello stack IP. Per i dettagli completi sulle GatewayClass, consulta Funzionalità e specifiche di GatewayClass.

Nome GatewayClass Descrizione Tipi di stack di cluster supportati
gke-l7-global-external-managed Bilanciatori del carico delle applicazioni esterni globali basati sul bilanciatore del carico delle applicazioni esterno globale Solo IPv4, dual-stack, solo IPv6
gke-l7-regional-external-managed Bilanciatori del carico delle applicazioni esterni regionali basati sul bilanciatore del carico delle applicazioni esterno regionale Solo IPv4, dual-stack, solo IPv6
gke-l7-rilb Bilanciatori del carico delle applicazioni interni basati sul bilanciatore del carico delle applicazioni interno Solo IPv4, dual-stack, solo IPv6
gke-l7-gxlb Bilanciatori del carico delle applicazioni esterni globali basati sul bilanciatore del carico delle applicazioni classico Solo IPv4, dual-stack
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 Solo IPv4, dual-stack
gke-l7-global-external-managed-mc Bilanciatori del carico delle applicazioni esterni globali multi-cluster basati sul bilanciatore del carico delle applicazioni esterno globale Solo IPv4, dual-stack
gke-l7-regional-external-managed-mc Bilanciatori del carico delle applicazioni esterni regionali multi-cluster basati sul bilanciatore del carico delle applicazioni esterno regionale Solo IPv4, dual-stack
gke-l7-rilb-mc Bilanciatori del carico delle applicazioni interni multi-cluster basati sul bilanciatore del carico delle applicazioni interno Solo IPv4, dual-stack
gke-l7-gxlb-mc Bilanciatori del carico delle applicazioni esterni globali multi-cluster basati sul bilanciatore del carico delle applicazioni classico Solo IPv4, dual-stack
gke-td Cloud Service Mesh multi-cluster Solo IPv4
asm-l7-gxlb Bilanciatori del carico delle applicazioni esterni globali basati su Cloud Service Mesh Solo IPv4

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

Gateway

Gli operatori dei cluster creano i gateway per definire dove e come i bilanciatori del carico ascoltano il traffico. I gateway assumono il loro comportamento (ovvero il modo in cui vengono implementati) dalla risorsa GatewayClass associata.

La specifica del gateway include la 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 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.

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 HTTPRoute definisce i gateway da cui può instradare il traffico, i servizi a cui instradarlo e le regole che definiscono il traffico corrispondente all'HTTPRoute. L'associazione di gateway e route è bidirezionale, il che significa che entrambe le risorse devono selezionarsi a vicenda per essere associate. Le risorse HTTPRoute possono trovare corrispondenze con le richieste in base ai dettagli nell'intestazione della richiesta. HTTPRoute supporta anche i filtri per la modifica, il reindirizzamento, la riscrittura e CORS delle intestazioni.

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'infrastrutturaGoogle Cloud sottostante.

Una policy è in genere associata 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 consente di collegare una policy a una risorsa di primo livello (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 GKE Gateway 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 bilanciatore del caricoGoogle Cloud . Questa policy è simile a un FrontendConfig per una risorsa Ingress.
  • GCPBackendPolicy: definisce il modo in cui 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 segnalate tramite i report di carico ORCA.
  • GCPTrafficDistributionPolicy: definisce il modo in cui 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.
  • GCPAuthzPolicy: definisce le policy di controllo dell'accesso basate sull'identità che applicano l'autorizzazione Zero Trust direttamente al livello del gateway GKE per tutto il traffico in entrata (nord-sud). Questa policy consente agli amministratori di impostare regole di accesso granulari in base alle identità dei client, ad esempio limitando l'accesso a percorsi o intestazioni specifici.

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 agisce come un provider di autorizzazioni, specificando quali risorse (from) sono autorizzate a 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, la risorsa 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 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à del gateway e pattern di utilizzo

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 dell'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 in modo esclusivo. Il deployment di gateway e route in questo modo è simile a quello di 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 controllate dal proprietario del servizio.

Un singolo proprietario può avere il controllo completo sia del gateway sia 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 offrono una gamma di opzioni per il controllo e la proprietà distribuiti.

Gateway per namespace gestito dalla piattaforma

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 per l'utilizzo del gateway. In questo modo, il proprietario del servizio ha il pieno controllo sulle regole di instradamento senza alcun rischio di conflitto con altri team. In questo modo, l'amministratore della piattaforma può 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 chiara separazione delle responsabilità tra i diversi ruoli.

Il routing tra spazi dei nomi consente alle route di collegarsi ai gateway oltre i confini degli spazi dei nomi. I gateway possono limitare gli spazi dei nomi da cui possono essere collegate 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 collegamento bidirezionale fornisce a ciascun 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 univoco con bilanciamento del carico e consente a ogni team di eseguire il deployment di un numero qualsiasi di route sul gateway per i domini o le route scelti.

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 spazi dei nomi offre agli amministratori della piattaforma una forma di proprietà ancora più centralizzata. In questo modo, i diversi proprietari dei servizi, in esecuzione in spazi dei nomi diversi, possono 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 eseguire il routing per un dominio specifico. Questo è simile all'esempio precedente, ad eccezione del fatto che i gateway consentono il collegamento 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 collegarsi 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 singolo gateway

Il dominio m.example.com è delegato allo spazio dei nomi mobile, che consente ai proprietari di servizi mobile di configurare le regole di instradamento 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 dover 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 organizzazioni di grandi dimensioni 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. L'aggiunta principale a questo caso d'uso è che le route fanno riferimento a servizi multi-cluster, di cui viene eseguito il deployment nei cluster. Il traffico può essere indirizzato 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 indirizzato 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 risorse fornisce il bilanciamento del carico multi-cluster e multiregionale

Controller GKE Gateway

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

Esistono due versioni del 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 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 control plane di GKE o nel progetto utente, il che li rende più scalabili e robusti. Entrambi i controller Gateway sono in disponibilità generale (GA).

I controller gateway non sono un piano dati di networking e non elaborano il traffico. Si trovano 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 dalla classe 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 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 Il deployment viene eseguito a livello di regione nella stessa regione del cluster GKE. Deployment a livello globale in più regioni Google Cloud .
Come attivare Abilitato per impostazione predefinita in GKE. Abilitato tramite l'API Ingress multi-cluster e la registrazione in un parco risorse. Consulta Abilitazione dei gateway multi-cluster.
GatewayClasses 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, contemporaneamente in un cluster GKE. Ogni GatewayClass è supportata 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 GKE Gateway supporta le estensioni di servizio, che ti consentono di aggiungere logica personalizzata a Cloud Load Balancing.

Il controller GKE Gateway supporta i seguenti tipi di estensioni:

  • GCPTrafficExtension: questa estensione consente di aggiungere una 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 consente di aggiungere una logica personalizzata a Cloud Load Balancing per controllare dove viene indirizzato il traffico per una determinata richiesta.
  • GCPAuthzExtension: questa estensione consente di delegare le decisioni di autorizzazione a motori di autorizzazione personalizzati o di terze parti con callout di servizio. Questa estensione consente l'ispezione e l'autorizzazione in tempo reale del traffico in transito, supportando integrazioni come Identity-Aware Proxy.

Per saperne di più su come configurare i controller GKE Gateway, consulta Personalizza il traffico GKE Gateway utilizzando le estensioni dei servizi.

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, che offrono 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 convertibili direttamente in risorse Gateway e HTTPRoute. Una singola risorsa 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 separatamente, anche da utenti diversi. I gateway possono avere molte route e una route può anche essere collegata a più gateway. Le relazioni tra gateway e route 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/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute

Inoltra

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 Cloud Service Mesh utilizzando l'API Gateway. In questo modo, è possibile abilitare 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.

Passaggi successivi