🥇Casi d'uso del service mesh

Nota. trad.: L'autore di questo articolo (Luc Perkins) è un sostenitore degli sviluppatori presso l'organizzazione CNCF, che ospita progetti Open Source come Linkerd, SMI (Service Mesh Interface) e Kuma (a proposito, ti sei anche chiesto perché Istio è non in questa lista? .). Ancora una volta, nel tentativo di fornire alla comunità DevOps una migliore comprensione della moda alla moda chiamata "service mesh", elenca 16 funzionalità caratteristiche fornite da tali soluzioni.

oggi rete di servizi ― uno degli argomenti più scottanti nel campo dell'ingegneria del software (e giustamente!). Penso che questa tecnologia sia incredibilmente promettente e mi piacerebbe vederla ampiamente adottata (quando avrà senso, ovviamente). Tuttavia, per la maggior parte delle persone è ancora circondato da un’aura di mistero. Allo stesso tempo, anche quelli che ben noto con esso, è spesso difficile articolare i suoi vantaggi e di cosa si tratta esattamente (compreso il sottoscritto). In questo articolo cercherò di correggere la situazione elencandone vari casi d'uso "reti di servizio"*.

* Nota trad.: qui e più avanti nell'articolo verrà utilizzata esattamente questa traduzione (“service mesh”) per il termine ancora nuovo service mesh.

Ma prima voglio fare alcune osservazioni:

Non ho mai lavorato con le reti di servizio né le ho utilizzate al di fuori di progetti avviati per la mia istruzione. D'altra parte, sono stato io a scrivere un sacco di documentazione per il service mesh interno di Twitter nel 2015 (all'epoca non si chiamava nemmeno "service mesh") e a partecipare allo sviluppo del sito web e della documentazione per Linkerd, quindi questo significa qualcosa.
Il mio elenco è approssimativo e incompleto. Potrebbero esserci casi d'uso a me sconosciuti e nuove opzioni probabilmente emergeranno nel tempo man mano che la tecnologia si sviluppa e la sua popolarità cresce.
Allo stesso tempo, non tutte le implementazioni di service mesh esistenti supportano tutti i casi d’uso elencati. Pertanto, le mie affermazioni come "la mesh di servizi possono..." dovrebbero essere lette come "individuali, e forse tutte le implementazioni di mesh di servizi più diffuse possono...".
L'ordine degli esempi non fa alcuna differenza.

Breve elenco:

scoperta del servizio;
crittografia;
autenticazione e autorizzazione;
bilancio del carico;
interruzione del circuito;
scalabilità automatica;
implementazioni canarini;
schieramenti blu-verdi;
Controllo della salute;
riduzione del carico;
mirroring del traffico;
isolamento;
richiedere limitazione della velocità, nuovi tentativi e timeout;
telemetria;
revisione contabile;
visualizzazione.

1. Scoperta del servizio

TL;DR: Connettiti ad altri servizi sulla rete utilizzando nomi semplici.

I servizi dovrebbero essere in grado di “trovarsi” automaticamente utilizzando nomi adeguati, ad esempio service.api.production, pets/staging o cassandra. Gli ambienti cloud sono elastici e un singolo nome può nascondere molte istanze di un servizio. È chiaro che in una situazione del genere è fisicamente impossibile codificare tutti gli indirizzi IP.

Inoltre, quando un servizio ne trova un altro, dovrebbe essere in grado di inviare richieste a quel servizio senza timore che finiscano all'input della sua istanza danneggiata. In altre parole, la rete di servizi deve monitorare lo stato di tutte le istanze del servizio e mantenere l'elenco degli host quanto più aggiornato possibile.

Ogni mesh di servizi implementa il meccanismo di rilevamento dei servizi in modo diverso. Al momento, il modo più comune è delegare a processi esterni come Kubernetes DNS. In passato su Twitter utilizzavamo a questo scopo un sistema di denominazione Finocchio. Inoltre, la tecnologia service mesh rende possibile l'emergere di meccanismi di denominazione personalizzati (anche se non ho ancora visto alcuna implementazione SM con tale funzionalità).

2. Crittografia

TL;DR: elimina il traffico non crittografato tra i servizi e rendi questo processo automatizzato e scalabile.

È bello sapere che gli aggressori non possono penetrare nella tua rete interna. I firewall fanno un ottimo lavoro in questo senso. Ma cosa succede se un hacker riesce ad entrare? Riuscirà a fare quello che vuole con il traffico intra-servizio? Speriamo che questo non accada, dopo tutto. Per evitare questo scenario, dovresti implementare una rete Zero Trust in cui tutto il traffico tra i servizi sia crittografato. La maggior parte delle mesh di servizi moderne raggiungono questo obiettivo attraverso la mutua TLS (TLS reciproco, mTLS). In alcuni casi, mTLS funziona in intere nuvole e ammassi (penso che un giorno le comunicazioni interplanetarie saranno organizzate in modo simile).

Naturalmente, per la rete di servizi mTLS opzionale. Ogni servizio può occuparsi del proprio TLS, ma ciò significa che dovrai trovare un modo per generare certificati, distribuirli tra gli host del servizio e includere il codice nell'applicazione che caricherà questi certificati dai file. Sì, non dimenticare di rinnovare questi certificati a intervalli regolari. Le mesh di servizi automatizzano mTLS con sistemi simili SPIFFE, che, a loro volta, automatizzano il processo di emissione e rotazione dei certificati.

3. Autenticazione e Autorizzazione

TL;DR: stabilire chi è il richiedente e definire cosa gli è consentito fare prima ancora che la richiesta raggiunga il servizio.

I servizi spesso vogliono sapere che esegue la richiesta (autenticazione) e, utilizzando queste informazioni, decide che una determinata entità è autorizzata a fare (autorizzazione). In questo caso il pronome “chi” può nascondere:

Altri servizi. Questa si chiama "autenticazione" pari" Ad esempio, il servizio web vuole accedere al servizio db. Le mesh di servizi di solito risolvono questi problemi utilizzando mTLS: i certificati in questo caso fungono da identificatore necessario.
Alcuni utenti umani. Questa si chiama "autenticazione" domanda" Ad esempio, utente haxor69 vuole comprare una nuova lampada. Le service mesh forniscono vari meccanismi, ad es. Token Web JSON.
Molti di noi lo hanno fatto nel codice dell'applicazione. Arriva una richiesta, guardiamo la tabella users, trova l'utente e confronta la password, quindi controlla la colonna permissions eccetera. Nel caso di un service mesh, ciò avviene prima ancora che la richiesta raggiunga il servizio.

Una volta stabilito da chi proviene la richiesta, dobbiamo determinare cosa è autorizzata a fare questa entità. Alcune mesh di servizi ti consentono di impostare policy di base (su chi può fare cosa) come file YAML o sulla riga di comando, mentre altre offrono l'integrazione con framework come Agente di politica aperto. L'obiettivo finale è che i tuoi servizi accettino qualsiasi richiesta, presupponendo con sicurezza che provenga da una fonte attendibile и questa azione è consentita.

4. Bilanciamento del carico

TL;DR: distribuisci il carico tra le istanze del servizio secondo uno schema specifico.

Un “Servizio” all'interno di una sezione di servizio è molto spesso costituito da molte istanze identiche. Ad esempio, oggi il servizio cache è composto da 5 copie e domani il loro numero potrebbe aumentare fino a 11. Richieste inviate a cache, devono essere distribuiti secondo uno scopo specifico. Ad esempio, per ridurre al minimo la latenza o massimizzare la probabilità di raggiungere un'istanza funzionante. L'algoritmo più comunemente utilizzato è il Round-robin, ma ne esistono molti altri, ad esempio il metodo ponderato (ponderato) query (è possibile selezionare i target preferiti), squillo (squillo) hashing (utilizzando un hashing coerente tra gli host upstream) o il metodo di richiesta minima (la preferenza viene data all'istanza con il minor numero di richieste).

I bilanciatori classici hanno altre funzioni, come il caching HTTP e la protezione DDoS, ma non sono molto rilevanti per il traffico est-ovest (cioè per il traffico che scorre all'interno di un data center - trad. ca.) (ambito tipico del service mesh). Naturalmente, non è necessario utilizzare una rete di servizi per il bilanciamento del carico, ma consente di impostare e controllare le policy di bilanciamento per ciascun servizio da un livello di controllo centralizzato, eliminando così la necessità di eseguire e configurare bilanciatori di carico separati nello stack di rete .

5. Interruzione del circuito

TL; DR: ferma il traffico verso il servizio problematico e controlla il danno negli scenari peggiori.

Se per qualche motivo il servizio non riesce a far fronte al traffico, il service mesh fornisce diverse opzioni per risolvere questo problema (altre verranno discusse nelle sezioni appropriate). L'interruzione del circuito è l'opzione più grave per disconnettere un servizio dal traffico. Tuttavia, di per sé non ha senso: è necessario un piano di riserva. Può essere fornita contropressione (contropressione) ai servizi che effettuano richieste (non dimenticare di configurare la rete di servizi per questo!), o, ad esempio, colorando di rosso la pagina di stato e reindirizzando gli utenti a un'altra versione della pagina con una "balena che cade" ("Twitter è giù").

Le mesh di servizi non solo consentono di definire quando il seguirà lo spegnimento e che questo seguirà. In questo caso, "quando" può includere qualsiasi combinazione di parametri specificati: il numero totale di richieste per un determinato periodo, il numero di connessioni parallele, richieste pendenti, tentativi attivi, ecc.

Probabilmente non vorrai abusare dell'interruzione del circuito, ma è bello sapere di avere un piano di riserva in caso di emergenza.

6. Scalabilità automatica

TL;DR: aumenta o diminuisci il numero di istanze del servizio in base ai criteri specificati.

Le mesh di servizi non sono pianificatori, quindi non lo fanno effettuare, eseguire ridimensionare te stesso. Tuttavia, possono fornire informazioni su quali pianificatori baseranno le loro decisioni. Dato che le service mesh hanno accesso a tutto il traffico tra i servizi, dispongono di ampie informazioni su ciò che sta accadendo: quali servizi stanno riscontrando problemi, quali servizi sono poco caricati (la capacità loro assegnata è sprecata), ecc.

Ad esempio, Kubernetes scala i servizi in base all'utilizzo della CPU e della memoria dei pod (vedi il nostro resoconto "Scalabilità automatica e gestione delle risorse in Kubernetes" - ca. trad.), ma se decidi di ridimensionare in base a qualsiasi altra metrica (nel nostro caso, relativa al traffico), avrai bisogno di una metrica speciale. Gestione come questo mostra come farlo con Inviato, Istio и Prometeo, ma il processo in sé è piuttosto complicato. Vorremmo che il service mesh semplificasse tutto ciò permettendoci di impostare semplicemente condizioni come "aumentare il numero di istanze del servizio". auth, se il numero di richieste pendenti supera la soglia entro un minuto."

7. Distribuzioni delle Canarie

TL;DR: testare nuove funzionalità o versioni del servizio su un sottoinsieme di utenti.

Supponiamo che tu stia sviluppando un prodotto SaaS e intendi lanciarne una nuova interessante versione. L'hai testato in fase di staging e ha funzionato benissimo. Ma ci sono ancora alcune preoccupazioni sul suo comportamento in condizioni reali. In altre parole, è necessario testare la nuova versione su problemi reali senza mettere a rischio la fiducia degli utenti. Le implementazioni Canary sono ottime per questo. Ti consentono di dimostrare una nuova funzionalità a un sottoinsieme di utenti. Questo sottoinsieme può essere costituito dagli utenti più fedeli o da coloro che lavorano con la versione gratuita del prodotto, oppure dagli utenti che hanno espresso il desiderio di essere “cavie”.

Le mesh di servizi implementano ciò consentendo di specificare criteri che determinano chi vedrà quale versione dell'applicazione e instradando il traffico di conseguenza. Tuttavia, per i servizi stessi non cambia nulla. La versione 1.0 del servizio ritiene che tutte le richieste provengano da utenti che dovrebbero vederlo, e la versione 1.1 crede lo stesso per i suoi utenti. Nel frattempo puoi modificare la percentuale di traffico tra la vecchia e la nuova versione, reindirizzando un numero crescente di utenti alla nuova se funziona stabilmente e le tue “cavie” danno il via libera.

8. Distribuzioni blu-verdi

TL;DR: lancia una nuova interessante funzionalità, ma preparati a riprendere immediatamente tutto.

senso schieramenti blu-verdi è lanciare un nuovo servizio “blu”, lanciandolo parallelamente a quello vecchio, “verde”. Se tutto va liscio e il nuovo servizio funziona bene, quello vecchio può essere gradualmente disabilitato. (Ahimè, un giorno questo nuovo servizio “blu” ripeterà il destino di quello “verde” e scomparirà...) Le implementazioni blu-verde differiscono da quelle canary in quanto la nuova funzione copre tutto in una volta utenti (non parte); Il punto qui è avere un “porto sicuro” pronto nel caso qualcosa vada storto.

Le service mesh offrono un modo molto conveniente per testare un servizio “blu” e passare immediatamente a uno “verde” funzionante in caso di problemi. Senza contare che lungo il percorso forniscono moltissime informazioni (vedi sotto “Telemetria”) sull'operato del “blu”, che aiutano a capire se è pronto per la piena operatività.

Nota. trad.: puoi leggere ulteriori informazioni sulle diverse strategie di distribuzione in Kubernetes (inclusi i menzionati canary, blue/green e altri) in questo articolo.

9. Controllo dello stato di salute

TL;DR: tieni traccia di quali istanze del servizio sono funzionanti e rispondi a quelle che non lo sono più.

Controllo della salute (Controllo della salute) aiuta a decidere se le istanze del servizio sono pronte per accettare ed elaborare il traffico. Ad esempio, nel caso dei servizi HTTP, un controllo dello stato potrebbe apparire come una richiesta GET all'endpoint /health... Risposta 200 OK significherà che l'istanza è integra, qualsiasi altra che non è pronta a ricevere traffico. Le service mesh consentono di specificare sia il modo in cui verrà verificata la funzionalità sia la frequenza con cui verrà effettuato tale controllo. Queste informazioni possono poi essere utilizzate per altri scopi, ad esempio per il bilanciamento del carico e l'interruzione del circuito.

Pertanto, il controllo dello stato non è un caso d’uso autonomo, ma viene solitamente utilizzato per raggiungere altri obiettivi. Inoltre, a seconda dei risultati dei controlli di integrità, potrebbero essere necessarie azioni esterne ad altri target della rete di servizi: ad esempio, l'aggiornamento della pagina di stato, la creazione di un problema su GitHub o la compilazione di un ticket JIRA. E la mesh di servizi offre un meccanismo conveniente per automatizzare tutto questo.

10. Riduzione del carico

TL;DR: reindirizzare il traffico in risposta a un picco temporaneo di utilizzo.

Se un determinato servizio è sovraccarico di traffico, è possibile reindirizzare temporaneamente parte di questo traffico verso un'altra posizione (ovvero "dump", "transfer" (capannone) lui lì). Ad esempio, a un servizio di backup o data center o a un permanente Pulsar argomento. Di conseguenza, il servizio continuerà a elaborare alcune richieste invece di bloccarsi e interrompere del tutto l'elaborazione. La riduzione del carico è preferibile all'interruzione del circuito, ma non è comunque consigliabile abusarne. Aiuta a prevenire errori a catena che causano il fallimento dei servizi downstream.

11. Parallelizzazione/mirroring del traffico

TL;DR: invia una richiesta a più posti contemporaneamente.

A volte è necessario inviare una richiesta (o una determinata selezione di richieste) a più servizi contemporaneamente. Un tipico esempio è l'invio di parte del traffico di produzione ad un servizio di staging. Il server Web di produzione principale invia una richiesta al servizio downstream products.production e solo a lui. E la rete di servizi copia in modo intelligente questa richiesta e la invia a products.staging, di cui il server web non è nemmeno a conoscenza.

Un altro caso d'uso correlato alla rete di servizi che può essere implementato oltre alla parallelizzazione del traffico è test di regressione. Si tratta di inviare le stesse richieste a diverse versioni del servizio e verificare se tutte le versioni si comportano allo stesso modo. Non mi sono ancora imbattuto in un'implementazione di service mesh con un sistema di test di regressione integrato simile Difficile, ma l'idea in sé sembra promettente.

12. Isolamento

TL; DR: suddividi la rete di servizi in mini-reti.

Conosciuto anche come segmentazioneL'isolamento è l'arte di dividere una rete di servizi in segmenti logicamente distinti che non sanno nulla l'uno dell'altro. L’isolamento è un po’ come creare reti private virtuali. La differenza fondamentale è che puoi comunque usufruire di tutti i vantaggi di un service mesh (come il service discovery), ma con maggiore sicurezza. Ad esempio, se un utente malintenzionato riesce a penetrare in un servizio su una sottorete, non sarà in grado di vedere quali servizi sono in esecuzione su altre sottoreti o di intercettarne il traffico.

Inoltre i benefici possono essere anche organizzativi. Potresti voler creare una sottorete dei tuoi servizi in base alla struttura della tua azienda e sollevare gli sviluppatori dal carico cognitivo di dover tenere a mente l'intera rete di servizi.

13. Richiedere limitazione della velocità, nuovi tentativi e timeout

TL; DR: non è più necessario includere le attività essenziali di gestione delle richieste nella base di codice.

Tutte queste cose potrebbero essere considerate casi d'uso separati, ma ho deciso di combinarli per una caratteristica comune: assumono il controllo delle attività di gestione del ciclo di vita delle richieste tipicamente gestite dalle librerie dell'applicazione. Se stai sviluppando un server web in Ruby on Rails (non integrato con un service mesh) che effettua richieste ai servizi backend tramite gRPC, l'applicazione dovrà decidere cosa fare se N richieste falliscono. Dovrai anche scoprire quanto traffico questi servizi saranno in grado di elaborare e codificare questi parametri utilizzando una libreria speciale. Inoltre, l’applicazione dovrà decidere quando è il momento di arrendersi e lasciare che la richiesta svanisca (in base al timeout). E per modificare uno qualsiasi dei parametri di cui sopra, il server web dovrà essere arrestato, riconfigurato e riavviato.

Scaricare queste attività su una rete di servizi non significa solo che gli sviluppatori di servizi non dovranno pensarci, ma anche che potranno essere viste in un modo più globale. Se viene utilizzata una catena di servizi complessa, ad esempio A -> B -> C -> D -> E, è necessario tenere conto dell'intero ciclo di vita della richiesta. Se l'attività è estendere i timeout nel servizio C, è logico farlo tutto in una volta, e non in parti: aggiornando il codice del servizio e aspettando che la richiesta pull venga accettata e il sistema CI distribuisca il servizio aggiornato.

14. Telemetria

TL; DR: raccogli tutte le informazioni necessarie (e non del tutto) dai servizi.

La telemetria è un termine generale che include metriche, traccia distribuita e log. Le mesh di servizi offrono meccanismi per la raccolta e l'elaborazione di tutti e tre i tipi di dati. È qui che le cose diventano un po’ confuse perché il numero di opzioni possibili è troppo grande. Per raccogliere parametri c'è Prometeo e altri strumenti che possono essere utilizzati per raccogliere registri fluente, Loki, Vettoriale (Vector) др и. (ad esempio ClickHouse con il ns casa in legno per K8 - ca. trad.), per la traccia distribuita esiste Jaeger e così via. Ciascuna rete di servizi può supportare alcuni strumenti e non altri. Sarà interessante vedere se il progetto potrà farlo Apri Telemetria fornire una certa convergenza.

In questo caso il vantaggio della tecnologia Service Mesh è che i contenitori sidecar possono, in linea di principio, raccogliere tutti i dati di cui sopra dai loro servizi. In altre parole, hai a disposizione un unico sistema di raccolta telemetria e il service mesh può elaborare tutte queste informazioni in vari modi. Per esempio:

log di coda da un determinato servizio nella CLI;
monitorare il volume delle richieste dalla dashboard del service mesh;
raccogliere tracce distribuite e inoltrarle a un sistema come Jaeger.

Attenzione, giudizio soggettivo: In generale, la telemetria è un'area in cui non sono desiderabili forti interferenze da parte della rete di servizi. Raccogliere informazioni di base e monitorare al volo alcuni parametri d'oro come il tasso di successo delle richieste e la latenza va bene, ma speriamo di non vedere emergere stack di Frankenstein che tentano di sostituire sistemi specializzati, alcuni dei quali si sono già dimostrati validi e ben studiati .

15. Audit

TL;DR: Coloro che dimenticano le lezioni della storia sono condannati a ripeterle.

L'auditing è l'arte di osservare eventi importanti in un sistema. Nel caso di una rete di servizi, ciò potrebbe significare tenere traccia di chi ha effettuato richieste a endpoint specifici per servizi specifici o quante volte si è verificato un evento relativo alla sicurezza nell'ultimo mese.

È chiaro che l'auditing è strettamente correlato alla telemetria. La differenza è che la telemetria è solitamente associata a aspetti come la produttività e l'integrità tecnica, mentre l'auditing può riguardare questioni legali e di altro tipo che vanno oltre la sfera strettamente tecnica (ad esempio, la conformità al GDPR, il regolamento generale dell'UE sulla protezione dei dati).

16. Visualizzazione

TL;DR: Lunga vita a React.js: una fonte inesauribile di interfacce fantasiose.

Potrebbe esserci un termine migliore, ma non lo conosco. Intendo semplicemente una rappresentazione grafica di una mesh di servizi o di alcuni dei suoi componenti. Queste visualizzazioni possono includere indicatori come latenze medie, informazioni sulla configurazione del sidecar, risultati del controllo dello stato e avvisi.

Lavorare in un ambiente orientato ai servizi comporta un carico cognitivo molto più elevato rispetto a Sua Maestà il Monolite. Pertanto, la pressione cognitiva dovrebbe essere ridotta a tutti i costi. Una semplice interfaccia grafica per un service mesh con la possibilità di cliccare su un pulsante e ottenere il risultato desiderato potrebbe essere decisiva per la crescita della popolarità di questa tecnologia.

Non sono stati inclusi nell'elenco

Inizialmente intendevo includere alcuni altri casi d'uso nell'elenco, ma poi ho deciso di non farlo. Eccoli insieme alle ragioni della mia decisione:

Multi-data center. A mio avviso, questo non è tanto un caso d'uso quanto un'area ristretta e specifica di applicazione delle mesh di servizi o un insieme di funzioni come il rilevamento dei servizi.
Ingresso e uscita. Questa è un'area correlata, ma mi sono limitato (forse artificialmente) al caso d'uso del "traffico est-ovest". Ingresso e uscita meritano un articolo a parte.

conclusione

È tutto per ora! Ancora una volta, questo elenco è molto arbitrario e molto probabilmente incompleto. Se pensi che mi sia sfuggito qualcosa o che abbia sbagliato qualcosa, contattami su Twitter (@luckerkins). Si prega di rispettare le regole della decenza.

PS da traduttore

L'illustrazione del titolo dell'articolo si basa su un'immagine dell'articolo "Che cos'è un Service Mesh (e quando utilizzarlo)?"(di Gregory MacKinnon). Mostra come alcune funzionalità delle applicazioni (in verde) sono state spostate in una rete di servizi che fornisce interconnessioni tra loro (in blu).