Integrazione di Cloud Service Mesh con Service Directory
Questo documento fornisce una panoramica su come utilizzare il registro dei servizi di Service Directory con Cloud Service Mesh, che consente a Cloud Service Mesh di instradare il traffico a servizi registrati in Service Directory e applicarli. Questo documento è rivolto agli sviluppatori di Cloud Service Mesh che vogliono integrare le loro applicazioni con altri servizi di Google Cloud.
Service Directory è un registro di servizi che archivia informazioni sui servizi di rete registrati, inclusi nomi, posizioni e attributi. Puoi registrare i tuoi servizi automaticamente, acquisendo tutti i dettagli, e tutti i servizi possono essere registrati, indipendentemente dalla loro infrastruttura.
Il registry può contenere non solo servizi Google Cloud, ma anche servizi ibridi in esecuzione on-premise o in altri cloud pubblici. Per comprendere al meglio le informazioni contenute in questo documento, ti consigliamo di acquisire familiarità con le nozioni di base delle operazioni di Service Directory.
Quando utilizzi il registro dei servizi di Service Directory con Cloud Service Mesh, l'integrazione rende i servizi nel registro dei servizi disponibili 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 con gRPC senza proxy, per le integrazioni di Service Directory con bilanciatori del carico di rete passthrough interni, bilanciatori del carico delle applicazioni interni e L4 Private Service Connect.
Per integrare i tuoi servizi, devi registrare un servizio con Service Directory, quindi associarlo a un servizio di backend Cloud Service Mesh. Dopo aver stabilito un'associazione, Cloud Service Mesh esegue una query su Service Directory per ottenere informazioni sul servizio registrato e su come è possibile raggiungere questo servizio. Cloud Service Mesh tiene traccia anche di eventuali modifiche al servizio. L'integrazione consente al mesh di servizi e al gateway autogestito di inviare traffico a questi servizi. Consente inoltre di applicare in modo forzato i criteri, ad esempio quelli avanzati per la gestione del traffico, che configuri in Cloud Service Mesh.
Quando utilizzi questa integrazione, l'associazione del servizio agisce come un backend, indipendentemente dal tipo di backend utilizzato dal servizio stesso. L'integrazione semplifica il deployment di Cloud Service Mesh, poiché Cloud Service Mesh può inviare traffico al servizio indipendentemente dal tipo di backend.
Quando un servizio è registrato in Service Directory, non devi 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, bilanciatori del carico interni e Private Service Connect a 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 risorse riportate di seguito.
Servizi Service Directory
Service Directory è un registro di servizi. Service Directory consente di registrare vari tipi di servizi, compresi quelli basati su Google Cloud o altri ambienti (ad esempio, un data center on-premise). Ogni servizio è composto da un nome univoco e da zero o più endpoint di servizio. Un endpoint di servizio è costituito da un indirizzo, una porta, le proprietà e i 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 nome di dominio completo 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, devi creare 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 se esistono deployment della stessa applicazione a livello di regione. Puoi registrare ogni deployment a livello di regione in un'istanza di Service Directory a livello di regione, come servizio 1 e servizio regionale 2 a livello di regione. È quindi possibile associare ciascuno di questi servizi Service Directory regionali allo stesso servizio di backend, utilizzando due associazioni di servizi. L'associazione del servizio globale 1 verrà associata al servizio regionale 1 nella regione A, mentre l'associazione del servizio globale 2 verrebbe associata al servizio regionale 2 nella regione B.
Casi d'uso
L'integrazione del deployment di Cloud Service Mesh con Service Directory dà vita a nuovi casi d'uso utili quando dipendi da servizi che altri team o organizzazioni possiedono o pubblicano.
Rendi 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 producer di servizi creano un servizio GKE o un bilanciatore del carico, possono registrarlo con Service Directory.
Dopo che un servizio è stato registrato in Service Directory, puoi configurare Cloud Service Mesh per comunicare 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.
Migliora il coordinamento tra producer di servizi e consumer
Le grandi imprese hanno molti team di sviluppatori indipendenti. Questi team rendono i propri servizi disponibili ad altri team, in modo che più team possano utilizzare le funzionalità fornite dal servizio condiviso. Questo crea dipendenze tra team. Sebbene queste dipendenze consentano ai team di condividere i propri sforzi, le dipendenze creano anche un overhead di coordinazione.
Quando utilizzi Service Directory, un team (il producer) registra un servizio che vuole rendere disponibile ad altri team o organizzazioni (consumer). Il producer condivide un riferimento a questo servizio con un consumer. Il consumer può utilizzare questo riferimento per cercare il servizio del producer 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 prevede 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 offre 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.
- Puoi impostare diversi criteri di gestione del routing e del traffico, ad esempio i timeout, in Cloud Service Mesh. Questi criteri consentono di ottimizzare il modo in cui le applicazioni inviano le richieste al servizio Service Directory. Per informazioni sulla gestione del routing e 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 basato sulla prossimità per indirizzare in modo ottimale il traffico dalle applicazioni agli endpoint, ad esempio riducendo al minimo il tempo di round trip.
Quando tu, come consumer, utilizzi Cloud Service Mesh e colleghi un servizio di backend a un servizio Service Directory, l'overhead del coordinamento tra team viene ridotto.
- Puoi collegare il servizio
Paymentsper nome. Cloud Service Mesh condivide informazioni sul servizio
Paymentscon i suoi client.- Ad esempio, i proxy sidecar in esecuzione nel 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 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 debba conoscere l'endpoint del servizio esterno. Nel diagramma, il servizio è il servizio
Payments.Quando il producer di servizi aggiorna il servizio esterno (ad esempio modificando il relativo endpoint), Cloud Service Mesh recupera l'aggiornamento e lo condivide senza soluzione di continuità con i client.
Accedi 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 singolo punto di ingresso. Questo punto in entrata può essere registrato in Service Directory e reso disponibile agli utenti che vogliono accedere ai servizi all'interno del perimetro. Per saperne di più sui perimetri Controlli di servizio VPC, consulta Dettagli e configurazione del perimetro di servizio.
Ad esempio, un team crea un gateway in entrata utilizzando un bilanciatore del carico delle applicazioni interno che distribuisce le richieste a una raccolta di servizi Kubernetes in un cluster. Questo gateway in entrata viene registrato automaticamente come servizio in Service Directory. Un consumer che vuole accedere ai servizi Kubernetes può cercare questo gateway in entrata in Service Directory. Il consumatore può quindi configurare il mesh di Cloud Service Mesh per accedere ai servizi all'interno del perimetro tramite il gateway.
Connetti i servizi tra i domini
Potresti dover connettere servizi in domini diversi.
Connetti i servizi tra le organizzazioni
Potresti voler accedere a servizi di proprietà di un'altra organizzazione, ad esempio API Google (ad esempio Cloud SQL) o 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 con Service Directory. Puoi quindi collegare questo servizio a Cloud Service Mesh, in modo che i client mesh come i client Envoy e gRPC e i gateway autogestiti come Apigee possano chiamare questi servizi.
L'esempio precedente, utilizzando Cloud Storage, illustra come utilizzare Private Service Connect per chiamare le API di Google utilizzando un endpoint nella tua rete Virtual Private Cloud.
Connetti servizi su reti VPC
Alcune aziende utilizzano più reti VPC come parte del 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 una rete VPC diversa, ma questa configurazione crea complicazioni quando sono presenti intervalli di indirizzi IP sovrapposti tra reti in peering.
Private Service Connect può rendere in modo sicuro e privato un servizio in una rete VPC accessibile ai servizi in un'altra rete VPC, utilizzando un singolo endpoint IP:port.
Altri esempi in più domini
I due esempi precedenti illustrano alcuni casi in cui potrebbe essere necessario eseguire più domini, ma ci sono molti altri esempi. Ad esempio, puoi creare un gateway che si trova all'intersezione di due regioni Google Cloud. I servizi in una regione possono raggiungere quelli di un'altra tramite questo gateway. Puoi registrare il gateway come servizio in Service Directory e utilizzarlo con Cloud Service Mesh come descritto in questo documento.
Applica i criteri quando si accede ai servizi
Cloud Service Mesh supporta funzionalità come la gestione avanzata del traffico configurabili tramite criteri. Ad esempio, puoi impostare un criterio di mirroring del traffico in modo che ogni volta che un client invia una richiesta a un particolare servizio di backend, il traffico venga inviato anche a un secondo servizio di backend.
Quando associ un servizio Service Directory a un servizio di backend Cloud Service Mesh, puoi configurare questi tipi di criteri in Cloud Service Mesh. I proxy collaterali, i proxy medi o perimetrali e i client senza proxy apprendono questi criteri e li applicano.
Alcuni esempi:
- Suddivisione del traffico in base alla ponderazione, ad esempio tra due servizi Service Directory
- Mirroring del traffico, ad esempio verso un servizio di controllo
users vengono sottoposte a mirroring al servizio audit (fai clic per ingrandire)Supporto per Cloud Service Mesh e client esistenti
Anche se nella tua organizzazione viene eseguito il deployment di Cloud Service Mesh, potresti avere client che non utilizzano Cloud Service Mesh. Ad esempio, potresti aver bisogno di accedere a un servizio da una macchina virtuale che non fa parte di un mesh di servizi.
Quando associ 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 client 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, vedi Osservabilità e debug con Service Directory.