Panoramica di Cloud Service Mesh
Questo documento è rivolto agli amministratori di rete e ai proprietari di servizi che vogliono familiarizzare con Cloud Service Mesh e le sue funzionalità. Questo è un documento legacy che si applica alle configurazioni che utilizzano le API di bilanciamento del carico.
Cloud Service Mesh è un piano di controllo gestito per il networking delle applicazioni. Cloud Service Mesh ti consente di fornire servizi globali ad alta disponibilità con funzionalità avanzate di networking delle applicazioni come gestione e osservabilità del traffico.
Man mano che il numero di servizi e microservizi nel deployment aumenta, in genere inizi ad affrontare problemi di networking delle applicazioni comuni, ad esempio:
- Come posso rendere resilienti i miei servizi?
- Come faccio a ricevere il traffico verso i miei servizi, come fanno a sapere e come comunicare tra loro?
- Come faccio a capire cosa succede quando i miei servizi comunicano tra loro?
- Come faccio ad aggiornare i miei servizi senza rischiare un'interruzione?
- Come gestisco l'infrastruttura che rende possibile il mio deployment?
Cloud Service Mesh ti aiuta a risolvere questi tipi di sfide in un deployment moderno basato sui servizi. Cloud Service Mesh si basa sull'infrastruttura gestita da Google Cloud, così non devi gestire la tua infrastruttura. Puoi concentrarti sulla distribuzione del codice dell'applicazione in grado di risolvere i problemi aziendali e consentire a Cloud Service Mesh di gestire le complessità del networking delle applicazioni.
Cloud Service Mesh
Un pattern comune per risolvere le sfide di networking delle applicazioni è l'utilizzo di un mesh di servizi. Cloud Service Mesh supporta mesh di servizi e altri pattern di deployment adatti alle tue esigenze.
In un tipico mesh di servizi, si verifica quanto segue:
- Esegui il deployment dei tuoi servizi in un cluster Kubernetes.
- Ciascun pod dei servizi ha un proxy dedicato (di solito Envoy) in esecuzione come proxy sidecar.
- Ogni proxy sidecar comunica con l'infrastruttura di rete (un piano di controllo) installata nel cluster. Il piano di controllo comunica ai proxy collaterali di servizi, endpoint e criteri nel mesh di servizi.
- Quando un pod invia o riceve una richiesta, questa va al proxy sidecar del pod. Ad esempio, il proxy sidecar gestisce la richiesta inviandola alla destinazione prevista.
Nei diagrammi in questo documento e in altri documenti di Cloud Service Mesh, le icone rosa a sei lati rappresentano i proxy. Il piano di controllo è collegato a ciascun proxy e fornisce le informazioni necessarie ai proxy per gestire le richieste. Le frecce tra le caselle mostrano i flussi di traffico. Ad esempio, il codice dell'applicazione in Service A
invia una richiesta. Il proxy gestisce la richiesta e la inoltra a Service B.
Questo modello consente di spostare la logica di networking dal codice dell'applicazione. Puoi concentrarti sulla fornitura di valore aziendale lasciando che sia la tua infrastruttura a occuparsi del networking delle applicazioni.
In che modo Cloud Service Mesh è diverso
Cloud Service Mesh funziona in modo simile a questo modello, ma è diverso sotto aspetto importante. Tutto inizia dal fatto che Cloud Service Mesh è un servizio gestito da Google Cloud. Non puoi installarlo, non viene eseguito nel tuo cluster e non hai bisogno di gestirlo.
Nel diagramma seguente, Cloud Service Mesh è il piano di controllo. In questo cluster Kubernetes sono presenti quattro servizi, ciascuno con proxy sidecar collegati a Cloud Service Mesh. Cloud Service Mesh fornisce le informazioni
necessarie ai proxy per instradare le richieste. Ad esempio, il codice dell'applicazione in un pod
appartiene a Service A invia una richiesta. Il proxy sidecar in esecuzione insieme a questo pod gestisce la richiesta e la instrada a un pod appartenente a Service B.
Oltre il mesh di servizi
Cloud Service Mesh supporta più tipi di deployment rispetto a un tipico mesh di servizi.
Kubernetes multi-cluster
Con Cloud Service Mesh, il networking delle applicazioni funziona su
tutti i cluster Kubernetes. Nel diagramma seguente, Cloud Service Mesh fornisce il piano di controllo per i cluster Kubernetes in us-central1 e europe-west1.
Le richieste possono essere instradate tra i tre servizi in us-central1, tra
i due servizi in europe-west1 e tra servizi nei due cluster.
Il tuo mesh di servizi può estendersi su più cluster Kubernetes in più regioni Google Cloud. I servizi in un cluster possono comunicare con quelli di un altro cluster. Puoi anche avere servizi costituiti da pod in più cluster.
Con il bilanciamento del carico globale basato sulla prossimità di Cloud Service Mesh, le richieste
destinate per Service B vengono inviate al pod più vicino in grado di gestire la richiesta. Ottieni anche un failover senza interruzioni. Se un pod non è attivo, la richiesta esegue automaticamente il failover su un altro pod in grado di gestire la richiesta, anche se questo pod si trova in un cluster Kubernetes diverso.
Macchine virtuali
Kubernetes sta diventando sempre più popolare, ma il deployment di molti carichi di lavoro in istanze di macchine virtuali (VM). Cloud Service Mesh risolve anche il networking delle applicazioni per questi carichi di lavoro; i carichi di lavoro basati su VM interagiscono con i carichi di lavoro basati su Kubernetes.
Nel diagramma seguente, il traffico entra nel deployment tramite il bilanciatore del carico delle applicazioni esterno. Viene instradato a Service A nel cluster Kubernetes
in asia-southeast1 e a Service D su una VM in europe-west1.
Google fornisce un meccanismo semplice per configurare i carichi di lavoro basati su VM con Cloud Service Mesh. Basta aggiungere un flag al modello di istanza VM di Compute Engine e Google gestisce la configurazione dell'infrastruttura. Questa configurazione include l'installazione e la configurazione dei proxy che forniscono funzionalità di networking delle applicazioni.
gRPC senza proxy
gRPC è un framework RPC open source ricco di funzionalità che puoi utilizzare per scrivere microservizi ad alte prestazioni. Con Cloud Service Mesh, puoi portare le funzionalità di networking delle applicazioni (come Service Discovery, bilanciamento del carico e gestione del traffico) nelle tue applicazioni gRPC. Per ulteriori informazioni, consulta Cloud Service Mesh e gRPC, servizi senza proxy per il mesh di servizi.
Nel diagramma seguente, le applicazioni gRPC instradano il traffico a servizi basati su cluster Kubernetes in una regione e a servizi in esecuzione su VM in regioni diverse. Due di questi servizi includono proxy sidecar, mentre gli altri sono senza proxy.
Cloud Service Mesh supporta i servizi gRPC senza proxy. Questi servizi utilizzano una versione recente della libreria gRPC open source che supporta le API xDS. Le tue applicazioni gRPC possono connettersi a Cloud Service Mesh utilizzando le stesse API xDS utilizzate da Envoy.
Dopo che le applicazioni sono connesse, la libreria gRPC si occupa delle funzioni di networking delle applicazioni come Service Discovery, il bilanciamento del carico e la gestione del traffico. Queste funzioni vengono eseguite in modo nativo in gRPC, quindi i proxy di servizio non sono necessari. Ecco perché sono chiamate applicazioni gRPC proxyless.
Ingress e gateway
Per molti casi d'uso, è necessario [gestire il traffico che proviene da client che non sono configurati da Cloud Service Mesh. Ad esempio, potrebbe essere necessario in entrata il traffico internet pubblico verso i tuoi microservizi. Puoi anche configurare un bilanciatore del carico come proxy inverso che gestisce il traffico proveniente da un client prima di inviarlo a una destinazione.
Nel diagramma seguente, un bilanciatore del carico delle applicazioni esterno consente il traffico in entrata per i client esterni, con il traffico instradato ai servizi in un cluster Kubernetes. Un bilanciatore del carico delle applicazioni interno instrada il traffico interno al servizio in esecuzione sulla VM.
Cloud Service Mesh funziona con Cloud Load Balancing per fornire un'esperienza di traffico in entrata gestita. Configuri un bilanciatore del carico esterno o interno e quindi lo configuri per inviare il traffico ai microservizi. Nel diagramma precedente, i client internet pubblici raggiungono i tuoi servizi tramite il bilanciatore del carico delle applicazioni esterno. I client, ad esempio i microservizi che risiedono sulla rete Virtual Private Cloud (VPC), utilizzano un bilanciatore del carico delle applicazioni interno per raggiungere i tuoi servizi.
Per alcuni casi d'uso, potresti voler configurare Cloud Service Mesh per configurare un gateway. Un gateway è essenzialmente un proxy inverso, solitamente Envoy in esecuzione su una o più VM, che ascolta le richieste in entrata, le gestisce e le invia a una destinazione. La destinazione può trovarsi in qualsiasi regione Google Cloud o in un cluster Google Kubernetes Engine (GKE). Può anche essere una destinazione esterna a Google Cloud raggiungibile da Google Cloud tramite la connettività ibrida. Per ulteriori informazioni su quando utilizzare un gateway, consulta Traffico in entrata per il mesh.
Nel diagramma seguente, una VM nell'area geografica europe-west1 esegue un proxy che
agisce da gateway a tre servizi che non eseguono proxy. Il traffico proveniente sia da un bilanciatore del carico delle applicazioni esterno sia da un bilanciatore del carico delle applicazioni interno viene instradato al gateway e quindi ai tre servizi.
Più ambienti
Che tu abbia servizi in Google Cloud, on-premise, in altri cloud o in tutti questi, le sfide fondamentali di networking delle applicazioni rimangono le stesse. Come ricevi il traffico verso questi servizi? Come comunicano tra loro questi servizi?
Nel diagramma seguente, Cloud Service Mesh instrada il traffico dai servizi in esecuzione in Google Cloud a Service G, in esecuzione su un altro cloud pubblico, e a Service E e Service F, entrambi in esecuzione in un data center on-premise.
Service A, Service B e Service C utilizzano Envoy come proxy sidecar, mentre
Service D è un servizio gRPC senza proxy.
Quando utilizzi Cloud Service Mesh, puoi inviare richieste a destinazioni esterne a Google Cloud. Ciò ti consente di utilizzare Cloud Interconnect o Cloud VPN per instradare privatamente il traffico dai servizi interni a Google Cloud a servizi o gateway in altri ambienti.
Configurazione di Cloud Service Mesh
La configurazione di Cloud Service Mesh prevede due passaggi. Dopo aver completato il processo di configurazione, la tua infrastruttura gestisce il networking delle applicazioni e Cloud Service Mesh mantiene tutto aggiornato in base alle modifiche al deployment.
Esegui il deployment delle applicazioni
Il primo è il deployment del codice dell'applicazione in container o VM. Google fornisce meccanismi che ti consentono di aggiungere un'infrastruttura di rete delle applicazioni (in genere proxy Envoy) alle tue istanze VM e ai tuoi pod. Questa infrastruttura è configurata per comunicare con Cloud Service Mesh e conoscere i tuoi servizi.
Configura Cloud Service Mesh
In seguito, devi configurare i servizi globali e definire la modalità di gestione del traffico. Per configurare Cloud Service Mesh, puoi utilizzare la console Google Cloud (per alcune funzionalità e configurazioni), Google Cloud CLI, l'API Traffic Director o altri strumenti come Terraform.
Una volta completati questi passaggi, Cloud Service Mesh è pronto per configurare l'infrastruttura di rete delle applicazioni.
L'infrastruttura gestisce il networking delle applicazioni
Quando un'applicazione invia una richiesta a my-service, la tua infrastruttura di networking
dell'applicazione (ad esempio un proxy sidecar Envoy) gestisce la richiesta
in base alle informazioni ricevute da Cloud Service Mesh. In questo modo, una richiesta per my-service può essere instradata senza problemi a un'istanza dell'applicazione in grado di ricevere la richiesta.
Monitoraggio e aggiornamenti continui
Cloud Service Mesh monitora le istanze dell'applicazione che costituiscono i servizi. Il monitoraggio consente a Cloud Service Mesh di scoprire se un servizio è integro o la sua capacità è stata modificata, ad esempio quando viene creato un nuovo pod Kubernetes. Sulla base di queste informazioni, Cloud Service Mesh aggiorna continuamente l'infrastruttura di networking delle applicazioni.
Funzionalità
Le funzionalità di Cloud Service Mesh forniscono funzionalità di networking delle applicazioni ai microservizi. In questa sezione sono presentate alcune caratteristiche principali.
Piano di controllo, controllo di integrità e bilanciamento del carico completamente gestiti
Vuoi dedicare tempo a fornire valore aziendale, non a gestire l'infrastruttura. Cloud Service Mesh è una soluzione completamente gestita, quindi non devi installare, configurare o aggiornare l'infrastruttura. Puoi sfruttare la stessa infrastruttura utilizzata da Google per il controllo di integrità e il bilanciamento del carico globale.
Basato su prodotti open source
Cloud Service Mesh utilizza lo stesso piano di controllo (API xDS) utilizzato da progetti open source popolari come Envoy e Istio. Per visualizzare le versioni dell'API supportate, consulta le API del piano di controllo xDS.
Anche l'infrastruttura che offre funzionalità di networking delle applicazioni, Envoy o gRPC, a seconda del caso d'uso, è open source, per cui non devi preoccuparti di essere vincolata a un'infrastruttura di proprietà.
Scalabilità
Da soluzioni una tantum di networking delle applicazioni a deployment di mesh di servizi di grandi dimensioni con migliaia di servizi, Cloud Service Mesh è progettato per soddisfare le tue esigenze di scalabilità.
Service Discovery e monitoraggio di endpoint e backend
Quando l'applicazione invia una richiesta a my-service, la tua infrastruttura
gestisce senza problemi la richiesta e la invia alla destinazione corretta. La tua
applicazione non deve conoscere nulla su
indirizzi IP, protocolli o altre complessità di rete.
Bilanciamento del carico e failover globali
Cloud Service Mesh utilizza il bilanciamento del carico globale e il controllo di integrità di Google per bilanciare in modo ottimale il traffico in base alla località del client e del backend, alla vicinanza del backend, all'integrità e alla capacità. Puoi migliorare la disponibilità dei servizi grazie al fail over automatico del traffico verso backend integri con capacità. Puoi personalizzare il bilanciamento del carico per distribuire il traffico in modo da supportare correttamente le tue esigenze aziendali.
Gestione del traffico
La gestione avanzata del traffico, inclusa la manipolazione delle richieste e di routing (in base a nome host, percorso, intestazioni, cookie e altro), consente di determinare il flusso del traffico tra i servizi. Puoi anche applicare azioni come nuovi tentativi, reindirizzamenti e suddivisione del traffico basata sui pesi per i deployment canary. Pattern avanzati come fault injection, mirroring del traffico e rilevamento outlier consentono di utilizzare i casi d'uso DevOps che migliorano la resilienza.
Osservabilità
La tua infrastruttura di networking delle applicazioni raccoglie informazioni di telemetria, come metriche, log e tracce, che possono essere aggregate a livello centrale in Google Cloud Observability. Dopo aver raccolto queste informazioni, puoi ottenere insight e creare avvisi in modo da ricevere una notifica in caso di problemi.
Controlli di servizio VPC
Puoi utilizzare Controlli di servizio VPC per fornire ulteriore sicurezza per le risorse e i servizi della tua applicazione. Puoi aggiungere progetti ai perimetri di servizio che proteggono risorse e servizi (come Cloud Service Mesh) dalle richieste provenienti dall'esterno del perimetro. Per saperne di più su Controlli di servizio VPC, consulta la panoramica di Controlli di servizio VPC.
Per scoprire di più sull'utilizzo di Cloud Service Mesh con i Controlli di servizio VPC, consulta la pagina Prodotti supportati.
Passaggi successivi
Questo è un documento legacy che si applica principalmente alle API di bilanciamento del carico. Ti consigliamo vivamente di non configurare Cloud Service Mesh utilizzando le API di bilanciamento del carico.
Per eseguire il deployment di Cloud Service Mesh:
- Per Compute Engine con VM, utilizza le API di routing del servizio.
- Per Google Kubernetes Engine con i pod, utilizza le API Gateway.
Per trovare casi d'uso e pattern di architettura per i servizi gRPC senza proxy, consulta la panoramica sui servizi gRPC senza proxy.
Per informazioni su come la gestione del traffico ti permette di controllare le modalità di gestione del traffico, consulta la panoramica sulla gestione avanzata del traffico.
Per scoprire in che modo Cloud Service Mesh supporta ambienti che si estendono oltre Google Cloud, consulta i seguenti documenti: