Integrazione di Cloud Service Mesh con Service Directory
Questo documento fornisce una panoramica su come utilizzare il registry dei servizi di Service Directory con Cloud Service Mesh, che consente a Cloud Service Mesh di instradare il traffico e applicare i relativi criteri ai servizi registrati con Service Directory. Questo documento è rivolto agli sviluppatori di Cloud Service Mesh che vogliono integrare le proprie applicazioni con altri servizi in Google Cloud.
Service Directory è un registro di servizi che memorizza informazioni sui servizi di rete registrati al suo interno, inclusi i relativi nomi, le località e gli attributi. Puoi registrare i tuoi servizi automaticamente, acquisendo tutti i dettagli. Tutti i servizi possono essere registrati, indipendentemente dalla loro infrastruttura.
Il registry può contenere non solo servizi Google Cloud, ma anche servizi ibridi eseguiti on-premise o in altri cloud pubblici. Per comprendere meglio le informazioni riportate in questo documento, ti consigliamo di acquisire familiarità con le nozioni di base sulle operazioni di Service Directory.
Quando utilizzi il registry dei servizi di Service Directory con Cloud Service Mesh, l'integrazione rende disponibili i servizi nel registry dei servizi per le applicazioni nel tuo mesh e per i gateway configurati da Cloud Service Mesh. L'integrazione di Cloud Service Mesh con Service Directory è supportata con Envoy e gRPC senza proxy per le integrazioni di Service Directory con bilanciatori del carico di rete passthrough interni, bilanciatori del carico di applicazioni interni e L4 Private Service Connect.
Per integrare i servizi, registra un servizio con Service Directory, quindi associalo a un servizio di backend Cloud Service Mesh. Dopo aver stabilito una definizione, Cloud Service Mesh esegue query Service Directory per ottenere informazioni sul servizio registrato e su come raggiungerlo. Cloud Service Mesh monitora anche eventuali modifiche al servizio. L'utilizzo dell'integrazione consente alla rete mesh di servizi e al gateway autogestito di inviare traffico a questi servizi. Ti consente inoltre di applicare criteri, ad esempio criteri di gestione avanzata del traffico, che configuri in Cloud Service Mesh.
Quando utilizzi questa integrazione, il binding del servizio funge da backend, indipendentemente dal tipo di backend utilizzato dal servizio stesso. L'integrazione semplifica il deployment di Cloud Service Mesh, perché Cloud Service Mesh può inviare traffico al servizio indipendentemente dal tipo di backend.
Quando un servizio è registrato in Service Directory, non è necessario configurare gruppi di istanze o diversi tipi di gruppi di endpoint di rete (NEG) per accedere ai servizi di cui hai bisogno. Puoi registrare automaticamente Google Kubernetes Engine, i bilanciatori del carico interni e Private Service Connect in Service Directory, semplificando ulteriormente l'accesso di Cloud Service Mesh a questi servizi.
Risorse utilizzate dall'integrazione
L'integrazione tra Cloud Service Mesh e Service Directory utilizza le seguenti risorse.
Servizi Service Directory
Service Directory è un registry di servizi. Service Directory ti consente di registrare vari tipi di servizi, inclusi quelli basati su Google Cloud o su altri ambienti (ad esempio un data center on-premise). Ogni servizio è costituito da un nome univoco e da zero o più endpoint di servizio. Un endpoint di servizio è composto da un indirizzo, da una porta, da proprietà e da metadati. Se non sono presenti endpoint,non puoi instradare il traffico al servizio.
Associazioni dei servizi
Un'associazione di servizi è una risorsa che include il nome di dominio completo (FQDN) del servizio Service Directory. Ad esempio, projects/test-proj/locations/us-east1/namespaces/test-namespace/services/test-service
è un FQDN per un servizio Service Directory.
Servizi di backend
I servizi di backend sono risorse di configurazione che forniscono informazioni a Cloud Service Mesh, inclusi i backend, come i gruppi di istanze gestite, a cui il servizio di backend instrada il traffico. I servizi di backend che fanno riferimento alle associazioni di servizi non possono avere backend. Per utilizzare l'integrazione di Cloud Service Mesh con Service Directory, crea un nuovo servizio di backend per fare riferimento alle associazioni di servizi.
Un servizio di backend può avere più associazioni di servizi. Questa configurazione è utile in una situazione in cui sono presenti implementazioni regionali della stessa applicazione. Potresti registrare ogni deployment regionale a un'istanza regionale di Service Directory, come servizio regionale 1 e servizio regionale 2. Ciascuno di questi servizi Service Directory regionali può essere associato allo stesso servizio di backend utilizzando due associazioni di servizi. L'associazione al servizio globale 1 viene associata al servizio regionale 1 nella regione A e l'associazione al servizio globale 2 viene associata al servizio regionale 2 nella regione B.
Casi d'uso
L'integrazione del deployment di Cloud Service Mesh con Service Directory consente nuovi casi d'uso utili quando si dipendono da servizi di proprietà o pubblicati da altri team o organizzazioni.
Rendere disponibili i servizi esistenti per Cloud Service Mesh
Service Directory si integra con i prodotti Google Cloud come GKE, bilanciatori del carico di rete passthrough interni e bilanciatori del carico delle applicazioni interni. Quando i produttori di servizi creano un servizio GKE o un bilanciatore del carico, possono registrarlo in Service Directory.
Dopo aver registrato un servizio in Service Directory, puoi configurare Cloud Service Mesh in modo che comunichi con quel servizio. I client Cloud Service Mesh possono quindi comunicare con i servizi in esecuzione dietro bilanciatori del carico di rete passthrough interni e bilanciatori del carico delle applicazioni interni.
Migliorare il coordinamento tra produttori e consumatori di servizi
Le grandi aziende hanno molti team di sviluppatori indipendenti. Questi team rendono disponibili i propri servizi ad altri team in modo che un maggior numero di team possa utilizzare le funzionalità fornite dal servizio condiviso. Ciò crea dipendenze tra team. Sebbene queste dipendenze consentano ai team di condividere le proprie risorse, creano anche un overhead di coordinamento.
Quando utilizzi Service Directory, un team (il produttore) registra un servizio che vuole rendere disponibile ad altri team o organizzazioni (consumatori). Il produttore condivide un riferimento a questo servizio con un consumatore. Il consumatore può utilizzare questo riferimento per cercare il servizio del produttore in Service Directory e scoprire gli endpoint del servizio. Ad esempio, l'endpoint potrebbe essere un indirizzo IP virtuale (VIP) su cui il servizio del producer si aspetta di ricevere traffico.
L'integrazione di Cloud Service Mesh con Service Directory ti consente di automatizzare il processo associando un servizio Service Directory a un servizio di backend Cloud Service Mesh, che presenta i seguenti vantaggi:
- Cloud Service Mesh risolve automaticamente gli endpoint del servizio sincronizzandoli da Service Directory. Se gli endpoint del servizio Service Directory vengono aggiornati, Cloud Service Mesh sincronizza automaticamente queste modifiche.
- In Cloud Service Mesh puoi impostare vari criteri di routing e gestione del traffico, ad esempio i timeout. Queste norme ti consentono di ottimizzare il modo in cui le tue applicazioni inviano richieste al servizio Service Directory. Per informazioni sul routing e sulla gestione del traffico in Cloud Service Mesh, consulta Gestione avanzata del traffico.
- Cloud Service Mesh utilizza funzionalità di gestione del traffico come il bilanciamento del carico in base alla prossimità per indirizzare in modo ottimale il traffico dalle applicazioni agli endpoint, ad esempio riducendo al minimo tempo di round trip.
Quando utilizzi Cloud Service Mesh e colleghi un servizio di backend a un servizio Service Directory, il sovraccarico della coordinazione tra team viene ridotto.
- Collega il servizio
Paymentsper nome. Cloud Service Mesh condivide informazioni sul servizio
Paymentscon i suoi clienti.- Ad esempio, i proxy sidecar in esecuzione nel tuo mesh di servizi ora conoscono l'endpoint (ad esempio
10.0.0.1:80) a cui è possibile raggiungere il servizio.
- Ad esempio, i proxy sidecar in esecuzione nel tuo mesh di servizi ora conoscono l'endpoint (ad esempio
Le tue applicazioni possono chiamare questo servizio per nome senza che tu o la tua applicazione debbano conoscere nulla sull'endpoint del servizio esterno. Nel diagramma, il servizio è il servizio
Payments.Quando il producer di servizi aggiorna il servizio esterno (ad esempio, modificando l'endpoint), Cloud Service Mesh rileva l'aggiornamento e lo condivide senza problemi con i propri clienti.
Accedere ai servizi all'interno di un perimetro utilizzando un punto di ingresso
Un team potrebbe raggruppare una raccolta di servizi all'interno di un perimetro dei Controlli di servizio VPC ed esporre questi servizi tramite un unico punto di ingresso. Questo punto di ingresso può essere registrato in Service Directory e reso disponibile agli utenti che vogliono accedere ai servizi all'interno del perimetro. Per maggiori informazioni sui perimetri dei Controlli di servizio VPC, consulta Dettagli e configurazione dei perimetri di servizio.
Ad esempio, un team crea un gateway di ingresso utilizzando un bilanciatore del carico delle applicazioni interno che distribuisce le richieste a una raccolta di servizi Kubernetes in un cluster. Questo gateway di ingresso viene registrato automaticamente come servizio in Service Directory. Un consumatore che vuole accedere ai servizi Kubernetes può cercare questo gateway di ingresso nella Service Directory. Il consumatore può quindi configurare il mesh Cloud Service Mesh per accedere ai servizi all'interno del perimetro tramite il gateway.
Collegare i servizi tra domini
Potresti avere servizi in domini diversi che devi collegare.
Collegare i servizi tra organizzazioni
Potresti voler accedere a servizi di proprietà di un'altra organizzazione, ad esempio le API Google (ad esempio Cloud SQL) o i servizi gestiti di terze parti.
Service Directory supporta Private Service Connect. Quando crei un endpoint Private Service Connect nella tua rete, l'endpoint può essere registrato come servizio in Service Directory. Puoi quindi collegare questo servizio a Cloud Service Mesh, in modo che i client di mesh, come i client Envoy e gRPC, e i gateway self-managed, come Apigee, possano chiamare questi servizi.
L'esempio precedente, che utilizza Cloud Storage, illustra come puoi utilizzare Private Service Connect per chiamare le API di Google utilizzando un endpoint nella tua rete Virtual Private Cloud.
Connetti i servizi tra reti VPC
Alcune aziende utilizzano più reti VPC nell'ambito del loro deployment di Google Cloud. In questi casi, un servizio in una rete VPC potrebbe dover accedere a un servizio in un'altra rete VPC. Puoi configurare il peering VPC per accedere a un servizio in un'altra rete VPC, ma questa configurazione crea complicazioni quando sono presenti intervalli di indirizzi IP sovrapposti tra le reti con peering.
Private Service Connect può rendere un servizio in una rete VPC accessibile in modo sicuro e privato ai servizi di un'altra rete VPC utilizzando un singolo endpoint IP:port.
Altri esempi in più domini
I due esempi precedenti illustrano casi in cui potrebbe essere necessario passare da un dominio all'altro, ma esistono molti altri esempi. Ad esempio, crei un gateway all'intersezione di due regioni Google Cloud. I servizi di una regione possono raggiungere i servizi di un'altra regione tramite questo gateway. Registra il gateway come servizio in Service Directory, quindi utilizzalo con Cloud Service Mesh come descritto in questo documento.
Applicare i criteri quando si accede ai servizi
Cloud Service Mesh supporta funzionalità come la gestione avanzata del traffico che sono configurabili utilizzando i criteri. Ad esempio, puoi impostare un criterio di mirroring del traffico in modo che ogni volta che un client invia una richiesta a un determinato servizio di backend, il traffico venga inviato anche a un secondo servizio di backend.
Quando colleghi un servizio Service Directory a un servizio di backend Cloud Service Mesh, puoi configurare questi tipi di criteri in Cloud Service Mesh. I proxy sidecar, i proxy intermedi o di smistamento e i client senza proxy vengono a conoscenza di queste norme e le applicano.
Ecco alcuni esempi:
- Suddivisione del traffico in base al peso, ad esempio tra due servizi Service Directory
- Mirroring del traffico, ad esempio a un servizio di controllo
users vengono replicate nel servizio audit (fai clic per ingrandire)Supporto di Cloud Service Mesh e dei client esistenti
Anche quando Cloud Service Mesh è dipiegato nella tua organizzazione, potresti avere clienti che non lo utilizzano. Ad esempio, potresti dover accedere a un servizio da una macchina virtuale che non fa parte di una rete mesh di servizi.
Quando colleghi un servizio Service Directory a un servizio di backend Cloud Service Mesh, i client di Cloud Service Mesh ricevono automaticamente informazioni aggiornate su quel servizio. I clienti che non utilizzano Cloud Service Mesh possono cercare e utilizzare le informazioni sui servizi in Service Directory.
Limitazioni
Cloud Service Mesh non supporta i NEG FQDN (INTERNET_FQDN_PORT NEG) nell'integrazione di Service Directory.
Passaggi successivi
- Scopri come configurare l'integrazione.
- Per informazioni sull'osservabilità con questa integrazione, consulta Osservabilità e debug con Service Directory.