Panoramica di Traffic Director
Questo documento è rivolto agli amministratori di rete e ai proprietari di servizi che vogliono acquisire familiarità con Traffic Director e le sue funzionalità.
Traffic Director è un piano di controllo gestito per il networking di applicazioni. Traffic Director consente di fornire servizi globali ad alta disponibilità con funzionalità avanzate di networking delle applicazioni come la gestione e l'osservabilità del traffico.
Con l'aumento del numero di servizi e microservizi nel tuo deployment, in genere ci sono difficoltà comuni per il networking delle applicazioni, come le seguenti:
- Come posso rendere i miei servizi resilienti?
- Come faccio a ricevere il traffico verso i miei servizi e come fanno a conoscere i servizi e comunicano 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 posso gestire l'infrastruttura che rende possibile il mio deployment?
Traffic Director ti aiuta a risolvere questi tipi di sfide in un deployment moderno basato su servizi. Traffic Director si basa sull'infrastruttura gestita da Google Cloud, così non devi gestire la tua infrastruttura. Concentrati sulla spedizione del codice dell'applicazione che risolve i tuoi problemi aziendali e lascia che Traffic Director gestisca le complessità del networking delle applicazioni.
Traffic Director per mesh di servizi
Un modello comune per risolvere le sfide del networking delle applicazioni è l'utilizzo di un mesh di servizi. Traffic Director supporta il mesh di servizi e molti altri pattern di deployment adatti alle tue esigenze.
In un tipico mesh di servizi, si verifica quanto segue:
- Esegui il deployment dei servizi in un cluster Kubernetes.
- Ciascuno dei pod dei servizi ha un proxy dedicato (di solito Envoy) in esecuzione come proxy collaterale.
- Ogni proxy sidecar comunica con l'infrastruttura di rete (un piano di controllo) installata nel cluster. Il piano di controllo indica ai proxy collaterali servizi, endpoint e criteri nel mesh di servizi.
- Quando un pod invia o riceve una richiesta, questa va al proxy sidecar del pod. Il proxy sidecar gestisce la richiesta, ad esempio, inviandola alla destinazione prevista.
Nei diagrammi in questo documento e in altri documenti di Traffic Director, le icone rosa a sei lati rappresentano i proxy. Il piano di controllo è connesso a ogni proxy e fornisce le informazioni necessarie ai proxy per gestire le richieste. Le frecce tra i riquadri indicano 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 fuori dal codice dell'applicazione. Puoi concentrarti sulla fornitura di valore aziendale e lasciare che l'infrastruttura si occupi del networking di applicazioni.
Differenze tra Traffic Director
Traffic Director funziona in modo simile al modello, ma per alcuni aspetti importante è diverso. Tutto inizia dal fatto che Traffic Director è un servizio gestito da Google Cloud. Non devi installarlo, non viene eseguito nel tuo cluster e non è necessario mantenerlo.
Nel diagramma seguente, Traffic Director è il piano di controllo. In questo cluster Kubernetes sono presenti quattro servizi, ciascuno con proxy collaterali connessi a Traffic Director. Traffic Director fornisce le informazioni necessarie
ai proxy per instradare le richieste. Ad esempio, il codice dell'applicazione su un pod
appartenente a Service A invia una richiesta. Il proxy sidecar in esecuzione insieme a questo pod gestisce la richiesta e la instrada a un pod che appartiene a Service B.
Oltre il mesh di servizi
Traffic Director supporta più tipi di deployment rispetto a un tipico mesh di servizi.
Kubernetes multi-cluster
Con Traffic Director, ottieni il networking delle applicazioni che funziona su
cluster Kubernetes. Nel diagramma seguente, Traffic Director 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 i 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 i servizi in un altro cluster. Puoi anche avere servizi costituiti da pod in più cluster.
Con il bilanciamento del carico globale basato sulla prossimità di Traffic Director, le richieste
destinate a Service B vengono inviate al pod più vicino in grado di gestire la richiesta. Puoi anche ottenere un failover senza interruzioni. Se un pod è inattivo, la richiesta esegue automaticamente il failover su un altro pod in grado di gestirla, 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). Traffic Director risolve il networking delle applicazioni anche per questi carichi di lavoro. I tuoi carichi di lavoro basati su VM interagiscono facilmente con i tuoi carichi di lavoro basati su Kubernetes.
Nel diagramma seguente, il traffico entra nel tuo deployment tramite l'Application Load Balancer 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 senza soluzione di continuità per configurare i carichi di lavoro basati su VM con Traffic Director. Devi aggiungere un flag solo al modello di istanza VM di Compute Engine e Google gestisce la configurazione dell'infrastruttura. che include l'installazione e la configurazione dei proxy che offrono funzionalità di networking delle applicazioni.
gRPC senza proxy
gRPC è un framework RPC open source ricco di funzionalità, utilizzabile per scrivere microservizi ad alte prestazioni. Con Traffic Director, puoi integrare facilmente funzionalità di networking delle applicazioni (come Service Discovery, bilanciamento del carico e gestione del traffico) nelle applicazioni gRPC. Per maggiori informazioni, consulta Traffic Director e gRPC: servizi senza proxy per il mesh di servizi.
Nel diagramma seguente, le applicazioni gRPC instradano il traffico ai servizi basati in cluster Kubernetes in una regione e ai servizi in esecuzione su VM in regioni diverse. Due di questi servizi includono proxy sidecar, mentre gli altri sono proxyless.
Traffic Director supporta i servizi gRPC senza proxy. Questi servizi utilizzano una versione recente della libreria gRPC open source che supporta le API xDS. Le applicazioni gRPC possono connettersi a Traffic Director utilizzando le stesse API xDS utilizzate da Envoy.
Una volta connesse le applicazioni, la libreria gRPC si occupa delle funzionalità di networking delle applicazioni come Service Discovery, bilanciamento del carico e gestione del traffico. Questa funzionalità avviene in modo nativo in gRPC, perciò i proxy di servizio non sono richiesti ed è per questo che sono chiamati applicazioni gRPC proxyless.
Ingress e gateway
Per molti casi d'uso, devi gestire il traffico che ha origine da client non configurati da Traffic Director. Ad esempio, potrebbe essere necessario trasferire il traffico internet pubblico in entrata nei microservizi. Potresti anche voler configurare un bilanciatore del carico come proxy inverso che gestisce il traffico da un client prima di inviarlo a una destinazione.
Nel diagramma seguente, un bilanciatore del carico delle applicazioni esterno abilita il traffico in entrata per i client esterni, con il traffico instradato verso i servizi in un cluster Kubernetes. Un bilanciatore del carico delle applicazioni interno instrada il traffico interno al servizio in esecuzione sulla VM.
Traffic Director funziona con Cloud Load Balancing per fornire un'esperienza di traffico in entrata gestita. Configuri un bilanciatore del carico esterno o interno, quindi configurerai il bilanciatore del carico per inviare traffico ai microservizi. Nel diagramma precedente, i client della rete internet pubblica raggiungono i tuoi servizi tramite l'Application Load Balancer esterno. I client, ad esempio i microservizi che risiedono nella rete Virtual Private Cloud (VPC), utilizzano un bilanciatore del carico delle applicazioni interno per raggiungere i servizi.
Per alcuni casi d'uso, potresti voler impostare Traffic Director per configurare un gateway. Un gateway è essenzialmente un proxy inverso, di solito 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 cluster Google Kubernetes Engine (GKE). Può anche essere una destinazione al di fuori di Google Cloud raggiungibile da Google Cloud utilizzando la connettività ibrida. Per ulteriori informazioni su quando utilizzare un gateway, consulta la pagina relativa al traffico in entrata per il tuo mesh.
Nel diagramma seguente, una VM nella regione europe-west1 esegue un proxy che
agisce da gateway per tre servizi che non eseguono proxy. Il traffico proveniente da un bilanciatore del carico delle applicazioni esterno e 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 tutti questi, le tue sfide fondamentali per il networking delle applicazioni rimangono le stesse. Come fai a indirizzare il traffico verso questi servizi? In che modo questi servizi comunicano tra loro?
Nel diagramma seguente, Traffic Director instrada il traffico dai servizi in esecuzione su 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 Traffic Director, 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 all'interno di Google Cloud a servizi o gateway in altri ambienti.
Configurazione di Traffic Director
La configurazione di Traffic Director prevede due passaggi. Una volta completato il processo di configurazione, la tua infrastruttura gestisce il networking delle applicazioni e Traffic Director mantiene tutto aggiornato in base alle modifiche al deployment.
Esegui il deployment delle tue applicazioni
Il primo è il deployment del codice dell'applicazione in container o VM. Google fornisce meccanismi che ti consentono di aggiungere facilmente l'infrastruttura di networking delle applicazioni (in genere proxy Envoy) alle tue istanze VM e ai tuoi pod. Questa infrastruttura è configurata per parlare con Traffic Director e conoscere i tuoi servizi.
Configura Traffic Director
Successivamente, configurerai i servizi globali e definisci la modalità di gestione del traffico. Per configurare Traffic Director, puoi utilizzare la console Google Cloud (per alcune funzionalità e configurazioni), Google Cloud CLI, l'API Traffic Director o altri strumenti come Terraform.
Dopo aver completato questi passaggi, Traffic Director è pronto a configurare la tua infrastruttura di networking delle applicazioni.
L'infrastruttura gestisce il networking delle applicazioni
Quando un'applicazione invia una richiesta a my-service, l'infrastruttura di networking dell'applicazione (ad esempio un proxy sidecar Envoy) gestisce la richiesta in base alle informazioni ricevute da Traffic Director. Ciò consente di instradare senza interruzioni una richiesta my-service a un'istanza dell'applicazione in grado di riceverla.
Monitoraggio e aggiornamenti continui
Traffic Director monitora le istanze dell'applicazione che costituiscono i tuoi servizi. Questo monitoraggio consente a Traffic Director di scoprire se un servizio è integro o che la capacità di un servizio è cambiata, ad esempio quando viene creato un nuovo pod Kubernetes. Sulla base di queste informazioni, Traffic Director aggiorna continuamente l'infrastruttura di networking delle applicazioni.
Funzionalità
Le caratteristiche di Traffic Director forniscono funzionalità di networking delle applicazioni ai tuoi microservizi. Alcuni punti salienti sono argomentati in questa sezione.
Piano di controllo, controllo di integrità e bilanciamento del carico completamente gestiti
Vuoi dedicare il tuo tempo a fornire valore aziendale, non a gestire l'infrastruttura. Traffic Director è una soluzione completamente gestita con SLA (accordo sul livello del servizio) per il tempo di attività, che ti evita di dover installare, configurare o aggiornare l'infrastruttura. Puoi trarre vantaggio dalla stessa infrastruttura utilizzata da Google per il controllo di integrità e il bilanciamento del carico globale.
Basato su prodotti open source
Traffic Director utilizza le stesse API del piano di controllo (xDS) utilizzate dai progetti open source più diffusi come Envoy e Istio. Per visualizzare le versioni supportate delle API, 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, quindi non devi preoccuparti di rimanere vincolato a un'infrastruttura proprietaria.
Scalabilità
Dalle soluzioni di networking delle applicazioni una tantum ai deployment di enormi mesh di servizi con migliaia di servizi, Traffic Director è progettato per soddisfare i tuoi requisiti di scalabilità.
Service Discovery e monitoraggio di endpoint e backend
Quando l'applicazione invia una richiesta a my-service, l'infrastruttura
gestisce senza interruzioni la richiesta e la invia alla destinazione corretta. La tua applicazione non deve avere informazioni su indirizzi IP, protocolli o altre complessità di rete.
Bilanciamento del carico globale e failover
Traffic Director utilizza il bilanciamento del carico globale e il controllo di integrità di Google per bilanciare in modo ottimale il traffico in base alla posizione di client e backend, prossimità del backend, integrità e capacità. Puoi migliorare la disponibilità del servizio impostando il failover automatico del traffico verso backend integri con capacità. Puoi personalizzare il bilanciamento del carico per distribuire il traffico in modo da supportare adeguatamente le tue esigenze aziendali.
Gestione del traffico
La gestione avanzata del traffico, inclusa la gestione del routing e delle richieste (in base a nome host, percorso, intestazioni, cookie e altro ancora), consente di determinare il flusso del traffico tra i servizi. Puoi anche applicare azioni come nuovi tentativi, reindirizzamenti e suddivisione del traffico in base al peso per i deployment canary. I pattern avanzati come l'inserimento di errori, il mirroring del traffico e il rilevamento di outlier consentono ai casi d'uso di DevOps che migliorano la resilienza.
Osservabilità
L'infrastruttura di networking delle applicazioni raccoglie informazioni di telemetria, come metriche, log e tracce, che possono essere aggregate a livello centrale in Osservabilità di Google Cloud. Dopo aver raccolto queste informazioni, puoi ottenere informazioni e creare avvisi in modo che tu possa 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 Traffic Director, dalle richieste provenienti al di fuori del perimetro. Per saperne di più sui Controlli di servizio VPC, consulta la Panoramica dei Controlli di servizio VPC.
Per scoprire di più sull'utilizzo di Traffic Director con i Controlli di servizio VPC, consulta la pagina Prodotti supportati.
Passaggi successivi
Per eseguire il deployment di Traffic Director:
- Per Compute Engine con VM, utilizza le API di routing dei servizi.
- 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 dei servizi gRPC senza proxy.
Per informazioni su come la gestione del traffico ti consente di controllarne la gestione, consulta la Panoramica sulla gestione avanzata del traffico.
Per scoprire in che modo Traffic Director supporta ambienti che vanno oltre Google Cloud, consulta i seguenti documenti: