Panoramica delle API di routing del servizio Traffic Director

Questo documento è destinato agli amministratori di mesh o di piattaforme e agli sviluppatori di servizi che hanno un livello di familiarità intermedio e avanzato con Traffic Director e con i concetti di mesh di servizi. Questo documento si applica ai deployment che utilizzano client Envoy e gRPC. Per ulteriori informazioni sui concetti di Traffic Director, consulta la panoramica generale e la panoramica dei servizi gRPC senza proxy.

Traffic Director fornisce funzionalità di networking di servizi alle applicazioni, tra cui gestione avanzata del traffico, osservabilità e sicurezza. Tuttavia, configurare e gestire un mesh di servizi è un'attività complessa per amministratori di mesh e sviluppatori di servizi.

Questo documento descrive le API di routing dei servizi per la configurazione di Traffic Director. Queste API sono progettate per semplificare e migliorare l'esperienza di configurazione mesh.

Questo modello API sostituisce le precedenti risorse di regola di forwarding, proxy di destinazione e mappa URL con risorse API chiamate Mesh, Gateway e Route. Queste risorse forniscono un'esperienza di configurazione più pertinente in base al contesto quando definisci il piano di controllo del networking di servizi.

Questo documento introduce i seguenti modelli e risorse dell'API Service routing.

Mesh
- Gestione e configurazione della sicurezza del traffico service-to-service (est-ovest) per proxy collaterali Envoy e client gRPC senza proxy.
- Identifica il mesh di servizi, rappresenta il componente responsabile dell'intercettazione e del routing del traffico e dell'applicazione dei criteri. Inoltre, identifica la porta di intercettazione del traffico.
Gateway
- Configurazione della sicurezza e della gestione del traffico per i proxy Envoy che agiscono come gateway in entrata, consentendo ai client esterni di connettersi al mesh di servizi (nord-sud).
- Identifica i proxy centrali e rappresenta il componente che rimane in ascolto su un elenco di coppie di indirizzi IP:porte, instrada il traffico e applica i criteri.
Route
- Identifica i nomi host e la porta che i client utilizzano per instradare il traffico ai servizi di backend e contiene informazioni complesse di routing del traffico. Esistono diversi tipi di risorse Route.
- HTTPRoute
- GRPCRoute
- TCPRoute
- TLSRoute

La console Google Cloud non fornisce supporto per le API di routing dei servizi. Devi implementare queste risorse API utilizzando Google Cloud CLI o le API REST. Inoltre, non esiste un percorso di migrazione automatico dalle API precedenti alle API di routing dei servizi. Per sostituire un deployment esistente, devi creare un nuovo deployment di Traffic Director con le API di routing dei servizi e quindi arrestare il deployment precedente.

Casi d'uso e vantaggi

Le API di routing dei servizi consentono di configurare Traffic Director per i deployment proxy sia di gRPC senza proxy che di Envoy. Il modello API di routing dei servizi offre diversi vantaggi chiave.

Nel diagramma seguente, due servizi nel mesh di servizi sono connessi da una risorsa Mesh. Le due risorse HTTPRoute configurano il routing. L'amministratore del mesh o della piattaforma gestisce la risorsa Mesh e i due proprietari dei servizi creano la configurazione di routing per i propri servizi.

Traffico da servizio a servizio da est-ovest in un mesh di servizi (fai clic per ingrandire)

La progettazione delle API orientata ai ruoli consente una chiara separazione delle responsabilità

Le API di routing dei servizi consentono di separare le responsabilità di configurazione mesh in base ai ruoli dell'organizzazione:

Gli amministratori di mesh possono definire il mesh logico e l'infrastruttura con gateway in entrata.
I proprietari dei servizi (sviluppatori di applicazioni) possono definire in modo indipendente i pattern di accesso per i loro servizi. Possono inoltre definire e applicare criteri di gestione del traffico per i propri servizi.

Nel diagramma seguente, Cloud Load Balancing e una risorsa Gateway forniscono un gateway in entrata per il traffico che entra nel mesh da un client che non si trova nel mesh. L'amministratore di mesh configura e gestisce la risorsa Gateway, mentre i proprietari dei servizi configurano e gestiscono i propri servizi e il routing del traffico.

Traffico da nord-sud nel mesh attraverso un gateway — Traffico da nord-sud nel mesh tramite un gateway (fai clic per ingrandire)

Affidabilità migliorata con il modello self-service

Nella precedente API Traffic Director, la mappa URL definisce il routing per la comunicazione service-to-service nel mesh, nonché per il traffico esterno che entra nel mesh attraverso un bilanciatore del carico gestito. Più team potrebbero modificare una singola risorsa della mappa URL, il che presenta potenziali problemi di affidabilità e complica il processo di delega per la configurazione del servizio ai proprietari dei servizi.

Le API di routing dei servizi introducono risorse per protocollo e per route che possono essere configurate e possedute da proprietari di servizi indipendenti. Questo approccio presenta diversi vantaggi.

I proprietari dei servizi ora hanno autonomia nel modo in cui vogliono configurare i criteri e la gestione del traffico per i servizi di loro proprietà.
L'aggiornamento di una risorsa Route non influisce sulle altre risorse Route nella rete mesh. Inoltre, il processo di aggiornamento è meno soggetto a errori perché i proprietari dei servizi gestiscono configurazioni molto più piccole.
Il proprietario del servizio responsabile del servizio o dell'host di destinazione è proprietario di ogni risorsa Route.
I proprietari dei servizi non devono dipendere dagli amministratori del mesh per aggiornare il routing utilizzando la risorsa centralizzata della mappa URL.

Configura solo ciò che è pertinente

Le API di routing dei servizi sostituiscono le regole di forwarding, i proxy di destinazione e le mappe di URL. Non è più necessario allocare indirizzi IP virtuali dalla rete Virtual Private Cloud (VPC) per la comunicazione tra servizi con proxy sidecar e gRPC senza proxy.

Abilita un mesh di servizi che comprende più progetti in ambienti VPC condiviso

Il modello API di routing dei servizi consente ai proprietari dei servizi di partecipare a un'infrastruttura mesh condivisa utilizzando il VPC condiviso e altri mezzi di connettività, mantenendo al contempo il controllo indipendente sui propri servizi. Ad esempio, i proprietari del servizio possono definire le risorse Route nei propri progetti. Gli amministratori della piattaforma possono definire un Mesh in un progetto host amministrato centralmente, quindi concedere ai proprietari del servizio le autorizzazioni IAM per collegare le proprie risorse Route a un elemento Mesh o Gateway condiviso. Il seguente diagramma mostra un esempio con un VPC condiviso.

Riferimento tra progetti con il VPC condiviso — Riferimento tra progetti con VPC condiviso (fai clic per ingrandire)

Le API di routing dei servizi consentono inoltre di disporre di client mesh di servizi connessi a reti diverse utilizzando il peering di rete VPC.

Instrada il traffico in base all'indicatore del nome del server

La risorsa TLSRoute consente di instradare il traffico criptato TLS in base all'indicazione dei nomi server (SNI) nell'handshake TLS. Puoi configurare il traffico TLS in modo che venga instradato ai servizi di backend appropriati configurando la corrispondenza SNI nella risorsa TLSRoute. In questi deployment, i proxy instradano solo il traffico e la sessione TLS viene terminata nellistanza di backend di destinazione.

La risorsa TLSRoute è supportata solo con i proxy Envoy il cui deployment viene eseguito come proxy o gateway collaterale.

Risorsa `TLSRoute` collegata a una risorsa `Mesh`

Il deployment mostrato nel seguente diagramma instrada qualsiasi traffico del mesh di servizi in cui l'estensione SNI ha il valore service1 al servizio di backend service1. Inoltre, qualsiasi traffico del mesh di servizi in cui l'estensione SNI ha il valore service2 viene instradato al servizio di backend service2. Il valore dell'estensione SNI e il nome del servizio di backend sono indipendenti l'uno dall'altro.

Risorsa TLSRoute e risorsa mesh — Risorsa `TLSRoute` e risorsa `Mesh` (fai clic per ingrandire)

Risorsa `TLSRoute` collegata a una risorsa `Gateway`

Il deployment mostrato nel diagramma seguente instrada tutto il traffico in entrata alla risorsa Gateway in cui l'estensione SNI ha il valore serviceA al servizio di servizio di backend serviceA. Inoltre, tutto il traffico in entrata verso Gateway in cui l'estensione SNI ha il valore serviceB viene instradato al servizio di backend serviceB. Il valore dell'estensione SNI e il nome servizio di backend sono indipendenti l'uno dall'altro. Anche il valore dell'estensione SNI e l'intestazione nelle richieste HTTP sono indipendenti.

La risorsa Gateway non termina la connessione TLS sul proxy Envoy di Gateway. ma la connessione TLS viene terminata in corrispondenza del servizio di backend corrispondente. Gateway non può esaminare alcuna informazione criptata nel livello TLS, ad eccezione di ClientHello, che contiene un'estensione SNI in testo normale. L'Gateway esegue il passthrough TLS in questa modalità. Tieni presente che il valore ClientHello criptato non è supportato.

Risorsa TLSRoute e risorsa gateway — Risorsa `TLSRoute` e risorsa `Gateway` (fai clic per ingrandire)

Supporto gRPC integrato

Puoi configurare i client gRPC senza proxy utilizzando gli attributi gRPC integrati, come la corrispondenza per metodo, invece di tradurre in percorsi equivalenti e utilizzare i matcher percorso.

Suddivisione del traffico per il traffico TCP

Ora puoi implementare la suddivisione del traffico in base al peso per il traffico TCP su più servizi di backend. Puoi configurare pattern come le implementazioni canary (blu-verde) quando aggiorni il servizio. La suddivisione del traffico consente inoltre di eseguire la migrazione del traffico in modo controllato senza tempi di inattività.

Intercettazione del traffico

Quando utilizzi l'API di routing dei servizi Mesh e le risorse Gateway, tutto il traffico viene intercettato automaticamente. Per maggiori informazioni, consulta Opzioni per la configurazione delle VM di Compute Engine con deployment Envoy automatico.

Architettura e risorse

Questa sezione descrive il modello dell'API Service routing e le relative risorse e aiuta a capire come funzionano insieme le risorse dell'API Service routing.

`Mesh` risorsa

La risorsa Mesh rappresenta un'istanza di un mesh di servizi. Puoi utilizzarlo per creare un mesh di servizi logico nel tuo progetto. Ogni risorsa Mesh deve avere un nome univoco nel progetto. Una volta creata una risorsa Mesh, il nome non può essere modificato.

Risorsa API Mesh con sidecar Envoy e deployment gRPC senza proxy — `Mesh`Risorsa API con deployment collaterali Envoy e gRPC senza proxy (fai clic per ingrandire)

Nella risorsa Route viene fatto riferimento alla risorsa Mesh per aggiungere route per i servizi che fanno parte del mesh.

I client gRPC proxy e senza proxy ricevono la configurazione da Traffic Director unendo il mesh di servizi identificato dal nome della risorsa Mesh. Il nome Mesh, come parametro di bootstrap, è supportato dal deployment automatizzato di Envoy su Compute Engine e dall'iniettore envoy automatico su GKE.

La risorsa Mesh supporta i seguenti deployment del piano dati:

Envoy in esecuzione insieme all'applicazione come proxy collaterale
Client gRPC senza proxy
Mix di client gRPC proxy e collaterali Envoy

`Route` risorsa

La risorsa Route viene utilizzata per configurare il routing ai servizi. Esistono quattro diversi tipi di risorsa dell'API Route. Definiscono il protocollo usato per instradare il traffico a un servizio di backend.

L'API non contiene parola per l'API Route. Le uniche risorse API configurabili sono HTTPRoute, GRPCRoute, TCPRoute e TLSRoute.

La risorsa Route fa riferimento a una o più risorse Mesh e Gateway per aggiungere le route che fanno parte della configurazione Mesh o Gateway corrispondente. Una risorsa Route può fare riferimento sia alle risorse Gateway sia Mesh.

La risorsa Route fa anche riferimento a una o più risorse di servizio di backend. I servizi vengono configurati utilizzando l'API del servizio di backend con il flusso di configurazione esistente. Le API di routing dei servizi non modificano il modo in cui i servizi di backend e i controlli di integrità vengono definiti nella configurazione di Traffic Director. Per farlo, devi creare una risorsa del servizio di backend che punta a uno o più backend MIG o NEG.

Il seguente diagramma mostra le relazioni tra le risorse Mesh, Gateway e Route e la risorsa del servizio di backend e i relativi backend.

Risorse dell'API Route — `Route` Risorse API (fai clic per ingrandire)

Puoi definire altre funzionalità di gestione del traffico, come routing, modifiche delle intestazioni, timeout e suddivisione del traffico in base al peso nelle risorse Route. Ad esempio, nel diagramma seguente, una risorsa HTTPRoute definisce una suddivisione del traffico tra il 70% e il 30% tra due servizi di backend.

Suddivisione del traffico in base alla ponderazione (fai clic per ingrandire)

`TLSRoute` risorsa

Utilizza la risorsa TLSRoute per instradare il traffico TLS ai servizi di backend in base ai nomi host SNI e al nome della negoziazione del protocollo a livello di applicazione (ALPN). La configurazione di TLSRoute implica il passthrough TLS, in cui il proxy Envoy non termina il traffico TLS.

La risorsa TLSRoute fa riferimento a una o più risorse Mesh e Gateway per aggiungere le route che fanno parte della configurazione mesh o gateway corrispondente.

La risorsa TLSRoute fa anche riferimento a una o più risorse di servizio di backend. I servizi vengono configurati utilizzando la risorsa API del servizio di backend usando le API e il flusso di configurazione esistenti.

`Gateway` risorsa

La risorsa Gateway viene utilizzata per rappresentare i proxy Envoy che agiscono come gateway di ingresso, consentendo ai client esterni di connettersi al mesh di servizi (traffico nord-sud). Questa risorsa ha porte di ascolto insieme a un parametro scope. Il proxy Envoy che agisce come gateway in entrata si associa alle porte specificate e a 0.0.0.0, che rappresenta tutti gli indirizzi IP sulla VM locale. Il seguente schema mostra i proxy Envoy di cui è stato eseguito il deployment come servizio in entrata e configurati dalla risorsa Gateway. In questo particolare esempio, i proxy Envoy sono configurati per ascoltare sulla porta 80 le connessioni in entrata dai client.

La risorsa API Gateway supporta solo il piano dati del proxy Envoy. Non supporta gRPC senza proxy. gRPCRoutes è supportato nella risorsa Gateway, ma il traffico gRPC viene instradato dal proxy Envoy, fungendo da proxy intermedio.

Mesh di servizi in entrata attraverso una risorsa "Gateway" — Ingresso del mesh di servizi tramite una risorsa `Gateway` (fai clic per ingrandire)

Che cosa sono un ambito `Gateway` e una configurazione `Gateway` unita?

Un'istanza di risorsa Gateway rappresenta le porte e la configurazione specifiche per il traffico ricevuto su queste porte. La risorsa API Gateway ha un parametro, scope, che viene utilizzato per raggruppare e unire logicamente la configurazione di due o più risorse Gateway.

Ad esempio, se vuoi che i proxy Gateway ascoltino sulle porte 80 e 443 per ricevere rispettivamente traffico HTTP e HTTPS, crei due risorse Gateway. Configurare una risorsa Gateway con la porta 80 per il traffico HTTP e l'altra con 443 per il traffico HTTPS. Assegna al campo scope lo stesso valore per ogni campo. Traffic Director unisce dinamicamente le singole configurazioni di tutti i gateway che hanno lo stesso ambito. Sul lato del piano dati, i proxy Envoy in esecuzione in modalità gateway in entrata devono anche presentare lo stesso parametro di ambito a Traffic Director per ricevere la configurazione Gateway. Tieni presente che devi specificare l'ambito al momento della creazione della risorsa Gateway e lo stesso ambito del parametro di bootstrap per i proxy.

Comportamento unione risorse gateway — `Gateway` comportamento di unione delle risorse (fai clic per ingrandire)

Di seguito sono riportate le considerazioni chiave per la risorsa Gateway:

Il parametro di ambito Gateway è obbligatorio. Specifica l'ambito nella risorsa Gateway e nella configurazione di bootstrap dei proxy Envoy anche quando ne esiste un solo Gateway.
La creazione di una risorsa Gateway non esegue il deployment di un servizio con un proxy Envoy. Il deployment del proxy Envoy è un passaggio separato.
La risorsa Gateway ha un type che rappresenta il tipo di deployment in entrata. Questo campo è riservato per un uso futuro. L'unico valore attualmente supportato è OPEN_MESH, che è il valore predefinito e non può essere modificato.

Deployment di mesh con protocolli misti e piani dati

Puoi avere un deployment di un piano dati misto, con proxy Envoy e gRPC senza proxy nello stesso mesh. Quando crei deployment di questo tipo, considera quanto segue.

I deployment collaterali Envoy supportano tutte le route (HTTPRoute, GRPCRoute, TCPRoute e TLSRoute).
I deployment gRPC senza proxy supportano solo GRPCRoute.
GRPCRoute è limitato alle funzionalità supportate solo dai deployment senza proxy gRPC.

Topologie supportate in ambienti VPC condiviso multiprogetto

Traffic Director supporta l'aggiunta di risorse Route definite in altri progetti a una risorsa Mesh o Gateway definita in un progetto di amministrazione centralizzato. I proprietari dei servizi autorizzati possono aggiungere direttamente le proprie configurazioni di routing a Mesh o Gateway.

Riferimento tra progetti tra risorse mesh e route — Riferimento tra progetti tra risorse `Mesh` e `Route` (fai clic per ingrandire)

In un tipico scenario tra progetti, scegli un progetto (progetto host o progetto di amministrazione controllato centralmente) come progetto di amministrazione del mesh in cui crei una risorsa Mesh. Il proprietario del progetto di amministrazione del mesh autorizza Route risorse di altri progetti a fare riferimento alla risorsa Mesh, consentendo alla configurazione di routing di altri progetti di far parte del mesh. Un piano dati mesh, sia Envoy o gRPC, richiede la configurazione dal progetto di amministrazione e riceve un'unione di tutte le route collegate a Mesh. Per un oggetto Gateway, vengono unite anche le route in tutte le Gateways che utilizzano lo stesso ambito.

Il progetto di amministrazione Mesh può essere qualsiasi progetto che preferisci e la configurazione funziona purché i progetti sottostanti abbiano la connettività di rete VPC, tramite VPC condiviso o peering di rete VPC.

Autorizzazioni e ruoli IAM

Di seguito sono riportate le autorizzazioni IAM necessarie per recuperare, creare, aggiornare, eliminare, elencare e utilizzare in modo sicuro le risorse Mesh e Route.

Gli amministratori di mesh devono avere le autorizzazioni networkservices.mesh.*.
Gli amministratori del gateway devono avere le autorizzazioni networkservices.gateways.*.
I proprietari del servizio devono disporre delle autorizzazioni networkservices.grpcRoutes.*, networkservices.httpRoutes.* o networkservices.tcpRoutes.*.

Gli amministratori di mesh devono concedere l'autorizzazione networkservices.mesh.use ai proprietari del servizio in modo che i proprietari del servizio possano collegare le proprie risorse Route alla risorsa Mesh. Lo stesso modello si applica a Gateway risorse.

Per visualizzare tutte le autorizzazioni IAM per le risorse Mesh, vai alla pagina di riferimento per le autorizzazioni IAM e cerca meshes.

Non sono necessari ruoli predefiniti aggiuntivi. Il ruolo predefinito esistente Amministratore rete Compute (roles/compute.networkAdmin) ha le autorizzazioni networkservices.* per impostazione predefinita. Potrebbe essere necessario aggiungere ai ruoli personalizzati le autorizzazioni descritte in precedenza.

Confronto tra il routing dei servizi e i modelli API precedenti

Questa sezione esegue un confronto argomento per argomento tra i modelli dell'API Traffic Director precedenti e di routing di servizi.

	API precedenti	API di routing dei servizi
Risorse API	Regola di forwarding, proxy di destinazione, mappa URL e servizio di backend.	Gateway, mesh, route e servizio di backend.
Indirizzi IP e numeri di porta dei servizi	Devi eseguire il provisioning degli indirizzi IP e dei numeri di porta per i servizi e configurare le regole di forwarding, che devono corrispondere alle coppie IP:Porta per tutti i casi d'uso. Devi mappare manualmente gli indirizzi IP ai nomi host oppure utilizzare l'indirizzo IP catch-all `0.0.0.0`.	Non è necessario configurare gli indirizzi IP per i casi d'uso `Mesh` o `Gateway`. `Gateway` richiede la configurazione dei numeri di porta.
Ambito del mesh di servizi	Traffic Director programma tutti i proxy collegati alla rete VPC, quindi l'ambito mesh è rete VPC.	Traffic Director non programma i proxy in base alla rete VPC. Per la comunicazione service-to-service est-ovest, i client gRPC Envoy e senza proxy utilizzano il nome della risorsa `Mesh`. Per i casi d'uso del gateway in entrata nord-sud, il parametro `scope` nell'API `Gateway` consente di raggruppare più `Gateways` con la configurazione unita.
Riferimenti tra progetti negli VPC condiviso condivisi	I riferimenti tra progetti non sono supportati. Tutte le risorse API devono essere configurate nello stesso progetto.	È possibile creare risorse `Mesh` o `Gateway` in un progetto gestito centralmente (progetto host) e i proprietari del servizio possono creare risorse `Route` nei progetti di servizio nell'ambiente VPC condiviso. Le risorse `Route` possono fare riferimento a `Mesh` o `Gateway` che si trovano tra i progetti.
Porta di intercettazione	Il parametro di bootstrap `TRAFFICDIRECTOR_INTERCEPTION_PORT` deve essere specificato in ogni Envoy che si connette a Traffic Director. Con il deployment automatico di Envoy sull'API Compute Engine e con l'inserimento di sidecar automatico su GKE, questo valore viene impostato in modo predefinito su `15001`.	La porta di intercettazione è configurata nella risorsa `Mesh` e si applica automaticamente a tutti gli Envoy che richiedono la configurazione per quello `Mesh`. Se non specificato, il valore predefinito continua a essere `15001`.

Avvio del bootstrap di client Envoy e gRPC su Compute Engine e GKE

	API precedenti	API di routing dei servizi
Utilizzo del deployment Envoy automatico su Compute Engine	Quando crei il modello di VM, specifichi un parametro della riga di comando, `--service-proxy=enabled`, che avvia in modo dinamico il proxy Envoy con gli attributi richiesti.	Quando crei il modello di VM, specifichi parametri aggiuntivi. Ad esempio, `--service-proxy=enabled`, `mesh=[MESH_NAME]` (per i mesh) o `--service-proxy=enabled, scope=[SCOPE_NAME]` (per i gateway). Altri attributi obbligatori sono il bootstrapping dinamico. Per gli Envoy che fungono da gateway, assicurati che `serving_ports` non sia specificato nell'argomento della riga di comando `--service-proxy`. Per maggiori informazioni, consulta Opzioni per la configurazione delle VM di Compute Engine con deployment Envoy automatico
Utilizzo dell'inserimento collaterale automatico su GKE	Devi specificare gli attributi di bootstrap richiesti nel campo `configMap` dell'iniettore sidecar.	Stesso flusso di lavoro con i nuovi attributi specificati in configMap.
Utilizzo dell'inserimento manuale di file collaterali su GKE	Come spiegato qui, il pod di applicazioni deve avere un bootstrapping di container collaterale Envoy con gli attributi richiesti.	Stesso flusso di lavoro per i nuovi attributi.
Utilizzo di Compute Engine o GKE per il deployment di client gRPC	L'applicazione client deve essere sottoposta a bootstrapping con gli attributi richiesti.	Stesso flusso di lavoro per i nuovi attributi.

Configurazione dei casi d'uso della sicurezza di mesh e gateway

	API precedenti	API di routing dei servizi
mTLS service-to-service in GKE	Segui le istruzioni riportate qui per i deployment basati su sidecar Envoy. Segui le istruzioni riportate qui per i deployment basati su gRPC senza proxy.	Vale le stesse istruzioni. Il criterio TLS client e il criterio TLS del server devono essere applicati rispettivamente alle risorse del servizio di backend e del criterio dell'endpoint. Poiché entrambe queste API sono ortogonali alle API di routing dei servizi, il flusso di configurazione rimane lo stesso di prima.
Protezione dei deployment del proxy intermedio (gateway in entrata o in uscita)	Segui le istruzioni riportate qui. Le risorse del criterio TLS del server e del criterio di autorizzazione sono collegate alla risorsa proxy HTTPS di destinazione.	Collega le risorse del criterio TLS del server e delle risorse del criterio di autorizzazione al gateway.

Considerazioni e limitazioni

La console Google Cloud non supporta le API di routing dei servizi.
Utilizza l'API xDS versione 3 o successive.
- Versione minima di Envoy: 1.24.9.
- Versione minima del generatore di bootstrap gRPC della v0.14.0
La risorsa TLSRoute è supportata solo con i proxy Envoy di cui viene eseguito il deployment come proxy o gateway collaterali.
Sono supportate solo le VM Compute Engine con deployment Envoy automatico e i pod GKE con inserimento Envoy automatico. Non puoi utilizzare il deployment manuale con le API di routing dei servizi.
Terraform non è supportato in questa release.
Le API di routing dei servizi non sono compatibili con le versioni precedenti delle API.
Quando una risorsa TCPRoute è collegata a una risorsa Mesh, la porta utilizzata per corrispondere al traffico TCP può essere utilizzata per gestire altri elementi ad eccezione del traffico descritto da questo TCPRoute.
- Ad esempio, i tuoi deployment potrebbero includere una risorsa TCPRoute corrispondente alla porta "8000" e una risorsa HttpRoute. Quando entrambi sono collegati alla stessa risorsa Mesh, il traffico instradato dalla risorsa HTTPRoute non può utilizzare la porta 8000 anche se gli indirizzi IP sottostanti sono diversi. Questo limite deriva dall'implementazione del proxy Envoy, che assegna prima la route corrispondente alla porta.
La risorsa Gateway non esegue il provisioning di un bilanciatore del carico gestito e non crea dinamicamente un servizio Envoy.
Gli Envoy di cui è stato eseguito il deployment automaticamente che fungono da gateway in entrata non devono avere l'argomento serving_ports per il flag --service-proxy.
Il deployment automatico di Envoy non supporta la fornitura di un numero di progetto diverso da quello della VM.

Passaggi successivi

Per informazioni sulle configurazioni disponibili con le API di routing dei servizi, leggi le guide alla configurazione del routing del servizio Traffic Director .
Per informazioni sulle API di routing dei servizi, leggi la documentazione relativa alle API dei servizi di rete.