🥇Casi d'uso della service mesh

Nota di traduzione.: l'autore di questo articolo (Luc Perkins) è un developer advocate presso l'organizzazione CNCF, che ospita progetti Open Source come Linkerd, SMI (Service Mesh Interface) e Kuma (a proposito, vi siete mai chiesti perché non c'è Istio in questo elenco?..). Cercando ancora una volta di portare nella comunità DevOps una migliore comprensione del trend alla moda chiamato «service mesh», elenca 16 caratteristiche distintive che queste soluzioni offrono.

Oggi service mesh ― uno dei temi più caldi nel campo dell'ingegneria del software (e a ragione!). Trovo questa tecnologia incredibilmente promettente e sogno di assistere alla sua ampia diffusione (ovviamente, quando ha senso). Tuttavia, è ancora circondata da un alone di mistero per la maggior parte delle persone. Anche coloro che sono ben informati su di essa spesso faticano a formulare i suoi vantaggi e cosa rappresenti esattamente (compreso il vostro umile servitore). In questo articolo cercherò di rimediare alla situazione, elencando vari scenari di utilizzo delle «service mesh»*.

* Nota del traduttore: in questo articolo verrà utilizzata questa traduzione («service mesh») per il termine ancora nuovo di service mesh.

Ma prima voglio fare alcune osservazioni:

Non ho mai lavorato con le service mesh e non le ho usate al di fuori di progetti intrapresi per la mia formazione personale. D'altra parte, sono stato proprio io a scrivere un sacco di documentazione per la service mesh interna di Twitter nel 2015 (allora non si chiamava nemmeno «service mesh») e ho partecipato allo sviluppo del sito e della documentazione per Linkerd, quindi questo vuol dire qualcosa.
La mia lista è indicativa e incompleta. È del tutto possibile che ci siano scenari di utilizzo a me sconosciuti, e nel tempo sicuramente emergeranno nuove opzioni, man mano che la tecnologia si sviluppa e cresce in popolarità.
Allo stesso tempo, non tutte le implementazioni esistenti della service mesh supportano tutti i casi d'uso elencati. Pertanto, espressioni come «la service mesh può...» devono essere intese come «alcune, se non tutte, le implementazioni popolari della service mesh possono...».
L'ordine degli esempi non ha alcuna importanza.

Elenco breve:

scoperta dei servizi;
criptazione;
autenticazione e autorizzazione;
bilanciamento del carico;
circuit breaking;
autoscalabilità;
deployments a canarini;
deployments blue-green;
verifica della salute;
load shedding;
mirroring del traffico;
isolamento;
limitazione della frequenza delle richieste, ripetizioni e timeout;
telemetria;
audit;
visualizzazione.

1. Scoperta dei servizi

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

I servizi devono essere in grado di "trovare" automaticamente altri servizi utilizzando nomi adeguati, ad esempio, service.api.production, pets/staging o cassandra. Gli ambienti cloud si distinguono per la loro elasticità, e dietro a un nome può nascondersi più di un'istanza del servizio. È chiaro che in una situazione del genere è fisicamente impossibile hardcodare tutti gli indirizzi IP.

Inoltre, quando un servizio trova un altro servizio, deve essere in grado di inviare richieste a quel servizio, senza temere che queste possano arrivare all'istanza inattiva. In altre parole, il service mesh deve monitorare lo stato di salute di tutte le istanze dei servizi e mantenere un elenco di host il più aggiornato possibile.

Ogni service mesh implementa un meccanismo di scoperta dei servizi in modo diverso. Attualmente il metodo più comune è la delega a processi esterni come il DNS di Kubernetes. In passato, su Twitter, abbiamo utilizzato un sistema di nomi Finagle. Inoltre, la tecnologia del service mesh rende possibile l'emergere di meccanismi di denominazione personalizzati (anche se non ho ancora incontrato un'implementazione di SM con tale funzionalità).

2. Crittografia

TL;DR: Elimina il traffico non crittografato tra i servizi e fai in modo che questo processo sia automatizzato e scalabile.

È rassicurante sapere che gli hacker non possono infiltrarsi nella tua rete interna. I firewall fanno un ottimo lavoro in questo. Ma cosa succede se un hacker riesce comunque a entrare? Potrà fare con il traffico interno al servizio ciò che vuole? Speriamo che non accada. Per prevenire uno scenario simile, è necessario implementare una rete a fiducia zero, in cui tutto il traffico tra i servizi è crittografato. La maggior parte delle moderne reti di servizi raggiunge questo obiettivo tramite TLS mutuo TLS (mutual TLS, mTLS). In alcuni casi, il mTLS funziona in interi cloud e cluster (penso che anche le comunicazioni interplanetarie saranno organizzate in modo simile un giorno).

Ovviamente, per il mTLS, il service mesh non è obbligatorio.. Ogni servizio può occuparsi autonomamente del proprio TLS, ma ciò significa che sarà necessario trovare un modo per generare certificati, distribuirli tra gli host del servizio, e includere nel codice dell'applicazione il codice che caricherà questi certificati dai file. Inoltre, non dimenticate di aggiornare questi certificati a intervalli regolari. Le reti di servizio automatizzano l’mTLS utilizzando sistemi come SPIFFE, che, a loro volta, automatizzano il processo di emissione e rotazione dei certificati.

3. Autenticazione e autorizzazione

TL;DR: Stabilite chi è l'iniziatore della richiesta e definite cosa gli è consentito fare anche prima che la richiesta raggiunga il servizio.

I servizi vogliono spesso sapere chi esegue la richiesta (autenticazione), e utilizzando queste informazioni, decidono cosa è consentito a questo soggetto di fare (autorizzazione). In questo caso, la pronome "chi" può riferirsi a:

Altri servizi. Questo è chiamato "autenticazione peer". Ad esempio, un servizio web vuole accedere a un servizio db. Le reti di servizio di solito risolvono problemi simili utilizzando l’mTLS: i certificati in questo caso fungono da identificatore necessario.
Alcuni utenti umani. Questo è chiamato "autenticazione della richiesta".Ad esempio, un utente haxor69 vuole acquistare una nuova lampada. Le reti di servizio forniscono vari meccanismi, ad esempio, JSON Web Tokens.
Molti di noi hanno dovuto fare questo nel codice dell'applicazione. Arriva una richiesta, controlliamo la tabella users, troviamo l'utente e confrontiamo la password, poi verifichiamo la colonna permissions e così via. Nel caso della rete di servizi, ciò avviene anche prima che la richiesta raggiunga il servizio.

Dopo aver stabilito da chi è arrivata la richiesta, è necessario determinare cosa è consentito a questo soggetto di fare. Alcune reti di servizi consentono di impostare politiche di base (su chi e cosa può fare) sotto forma di file YAML o tramite la riga di comando, mentre altre offrono integrazione con framework come Open Policy Agent. L'obiettivo finale è fare in modo che i vostri servizi accettino qualsiasi richiesta, assumendo con sicurezza che provengano da una fonte affidabile e l'azione è consentita.

4. Bilanciamento del carico

TL;DR: Distribuite il carico tra le istanze del servizio secondo uno schema specificato.

Il «Servizio» all'interno di una sezione di servizio è spesso composto da numerosi esemplari identici. Ad esempio, oggi il servizio cache è costituito da 5 copie, mentre domani il numero potrebbe aumentare fino a 11. Le richieste dirette a cache, devono essere distribuite in base a un obiettivo specifico. Ad esempio, ridurre il ritardo o massimizzare la probabilità di accedere a un esemplare funzionante. Il più delle volte viene utilizzato l'algoritmo di round-robin, ma esistono anche molti altri, come il metodo delle richieste ponderate (weighted) , l'hashing circolare (ring) (utilizzo del consistent hashing per gli upstream-host) o il metodo del minor numero di richieste (preferenzialmente verso l'esemplare con il minor numero di richieste).

I bilanciatore classici hanno anche altre funzioni, come la cache HTTP e la protezione DDoS, ma non sono molto attuali per il traffico di tipo east-west (cioè per il traffico che scorre all'interno del datacenter - nota del traduttore) (tipica area di applicazione del service mesh). Certamente, non è necessario utilizzare il service mesh per la distribuzione del carico, tuttavia consente di definire e controllare le politiche di bilanciamento per ogni servizio da un layer di gestione centralizzato, eliminando così la necessità di avviare e configurare singoli bilanciatori nello stack di rete.

5. Interruzione del circuito (circuit breaking)

TL;DR: Interrompi il traffico verso il servizio problematico e controlla i danni nei peggiori scenari.

Se per qualche motivo il servizio non riesce a gestire il traffico, il service mesh offre diverse opzioni per risolvere questo problema (altre verranno trattate nelle sezioni corrispondenti). L'interruzione del circuito è l'opzione più severa per scollegare un servizio dal traffico. Tuttavia, di per sé, non ha senso - è necessario avere un piano alternativo. Può essere previsto un contro-pressione (backpressure) sui servizi che eseguono le richieste (solo non dimenticate di configurare il vostro service mesh per questo!), oppure, ad esempio, colorare la pagina di stato in rosso e reindirizzare gli utenti a una variante della pagina con il «ceto che affonda» («Twitter is down»).

Le reti di servizio consentono non solo di determinare quando segua l'interruzione e dovrà avvenire la disconnessione e cosa seguirà. In questo caso, "quando" può includere qualsiasi combinazione di parametri specificati: numero totale di richieste in un certo periodo, numero di connessioni parallele, richieste pendenti, tentativi attivi, ecc.

È improbabile che tu voglia abusare del circuito di interruzione, ma è piacevole sapere che c'è 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.

I service mesh non sono pianificatori, quindi non eseguono scalabilità autonomamente. Tuttavia, possono fornire informazioni su cui i pianificatori possono prendere decisioni. Poiché i service mesh hanno accesso a tutto il traffico tra i servizi, dispongono di ampie informazioni su ciò che sta accadendo: quali servizi stanno affrontando problemi, quali sono poco carichi (le risorse allocate vengono sprecate) e così via.

Ad esempio, Kubernetes scala i servizi in base all'uso della CPU e della memoria da parte dei pod (vedi la nostra relazione "Autoscaler e gestione delle risorse in Kubernetes» — nota del traduttore.)", ma se decidi di scalare in base a qualsiasi altro indicatore (nel nostro caso legato al traffico), sarà necessaria una metrica speciale. Una guida come questa mostra come farlo con Envoy, Istio e Prometheus, ma il processo stesso è piuttosto complesso. Ci piacerebbe che il service mesh lo semplificasse, consentendo di impostare semplicemente condizioni come "aumenta il numero di istanze del servizio auth, se il numero di richieste in attesa supera la soglia per un minuto".

7. Deployment canarini

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

Supponiamo che stiate sviluppando un certo prodotto SaaS e intendiate rilasciarne una nuova versione interessante. L'avete testata in staging e ha funzionato perfettamente. Tuttavia, ci sono delle preoccupazioni riguardo al suo comportamento in condizioni reali. In altre parole, è necessario testare la nuova versione su compiti reali, senza compromettere la fiducia degli utenti. Le distribuzioni canary sono perfette per questo. Permettono di dimostrare una nuova funzionalità a un sottoinsieme di utenti. Questo sottoinsieme può essere composto dai vostri utenti più fedeli, da quelli che utilizzano la versione gratuita del prodotto o da utenti che hanno espresso il desiderio di essere

I service mesh realizzano questo consentendo di specificare criteri che determinano chi e quale versione dell'applicazione vedrà, instradando il traffico di conseguenza. Per i servizi stessi, niente cambia. La versione 1.0 del servizio crede che tutte le richieste provengano da utenti che devono vederlo, mentre la versione 1.1 pensa lo stesso riguardo ai suoi utenti. E voi, nel frattempo, potete modificare la percentuale di traffico tra la vecchia e la nuova versione, reindirizzando un numero crescente di utenti alla nuova, se funziona in modo stabile e i vostri "cavie" danno il loro assenso.

8. Distribuzioni blu-verdi

TL;DR: Rilasciate una nuova funzionalità interessante, ma siate pronti a tornare indietro immediatamente.

Significato delle distribuzioni blu-verdi è quello di lanciare un nuovo servizio "blu", facendolo funzionare in parallelo con il vecchio "verde". Se tutto va bene e il nuovo servizio si comporta bene, il vecchio può essere gradualmente disattivato. (Purtroppo, un giorno anche questo nuovo servizio "blu" subirà la sorte del "verde" e scomparirà...) Le distribuzioni blu-verdi si differenziano da quelle canary in quanto la nuova funzionalità copre immediatamente tutti gli utenti (e non solo una parte); il concetto qui è avere una "riserva" pronta nel caso qualcosa vada storto.

I service mesh offrono un modo molto conveniente per testare il servizio "blu" e passare istantaneamente al "verde" attivo in caso di problemi. Per non parlare del fatto che forniscono una quantità incredibile di informazioni (vedi il punto "Telemetria" qui sotto) sul funzionamento del "blu", il che aiuta a capire se è pronto per un utilizzo completo.

Nota di traduzione.: Puoi leggere di più sulle diverse strategie di distribuzione in Kubernetes (inclusi i cosiddetti canary, blue/green e altri) in questo articolo.

9. Controllo dello stato

TL;DR: Tieni d'occhio quali istanze dei servizi sono funzionanti e rispondi a quelle che smettono di esserlo.

Controllo dello stato (health check) aiuta a decidere se le istanze del servizio sono pronte ad accettare e elaborare il traffico. Ad esempio, nel caso dei servizi HTTP, il controllo dello stato può apparire come una richiesta GET all'endpoint /health. La risposta 200 OK significherà che l'istanza è sana, qualsiasi altra cosa significa che non è pronta ad accettare traffico. I service mesh consentono di specificare sia il metodo con cui verrà controllato lo stato di funzionamento, sia la frequenza con cui verrà effettuato questo controllo. Queste informazioni possono poi essere utilizzate per altri scopi, come il bilanciamento del carico e il circuit breaking.

Pertanto, il controllo dello stato non è uno scenario d'uso a sé stante, ma viene generalmente utilizzato per raggiungere altri obiettivi. Inoltre, a seconda dei risultati dei health check, potrebbero essere necessarie azioni esterne (in relazione ad altri obiettivi delle reti di servizi): ad esempio, aggiornare la pagina di stato, creare un issue su GitHub o compilare un ticket JIRA. E il service mesh offre un meccanismo conveniente per automatizzare tutto questo.

10. Gestione del carico (load shedding)

TL;DR: Ridirigi il traffico in risposta a un picco temporaneo nell'uso.

Se un certo servizio risulta sovraccarico di traffico, puoi temporaneamente reindirizzare parte di quel traffico altrove (cioè "scaricare", "versare" (shed) là). Ad esempio, a un servizio di riserva o a un data center, o verso un costante Pulsar topic. Di conseguenza, il servizio continuerà a elaborare parte delle richieste invece di bloccarsi e smettere di elaborare completamente tutte. Il caricamento ridotto è preferibile rispetto alla rottura della catena, ma è comunque sconsigliabile abusarne. Permette di prevenire i fallimenti a catena, causando il guasto dei servizi downstream.

11. Parallelizzazione/duplicazione del traffico

TL;DR: Invia una richiesta contemporaneamente in più luoghi.

A volte è necessario inviare una richiesta (o un certo insieme di richieste) contemporaneamente a più servizi. Un esempio tipico è l'invio di parte del traffico di produzione al servizio di staging. Il server web principale della produzione invia una richiesta al servizio sottostante products.production e solo a lui. E il service mesh copia intelligentemente questa richiesta e la invia a products.staging, di cui il server web non sospetta nemmeno.

Un altro scenario d'uso collegato alla rete di servizi, che può essere implementato sopra la parallelizzazione del traffico, è il testing di regressione. Prevede l'invio delle stesse richieste a versioni diverse del servizio e il controllo del comportamento di tutte le versioni. Finora non ho incontrato implementazioni di service mesh con un sistema integrato di testing di regressione come Diffy, ma l'idea stessa sembra promettente.

12. Isolamento

TL;DR: Dividi la tua service mesh in mini-reti.

Conosciuto anche come segmentazione, l'isolamento è l'arte di dividere la rete di servizi in segmenti logicamente separati che non sanno nulla l'uno dell'altro. L'isolamento è un po' simile alla creazione di reti private virtuali. La differenza principale è che si possono ancora usufruire di tutti i vantaggi della service mesh (come la scoperta dei servizi), ma con una sicurezza aggiuntiva. Ad esempio, se un malintenzionato riesce a infiltrarsi in un servizio in una delle sottoreti, non può vedere quali servizi sono attivi nelle altre sottoreti o intercettare il loro traffico.

Inoltre, i vantaggi possono essere anche organizzativi. Potresti voler suddividere i servizi in sottoreti a seconda della struttura dell'azienda e liberare i programmatori dal carico cognitivo causato dalla necessità di tenere a mente l'intera service mesh.

13. Limitazione della frequenza delle richieste, ripetizioni e timeout

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

Tutte queste cose potrebbero essere considerate casi d'uso separati, ma ho deciso di unirle a causa di una caratteristica comune: si occupano della gestione del ciclo di vita delle richieste, normalmente gestito dalle librerie delle applicazioni. Se stai sviluppando un server web in Ruby on Rails (non integrato con un service mesh), che effettua richieste ai servizi di backend tramite gRPC, l'applicazione dovrà decidere autonomamente cosa fare se N richieste falliscono. Sarà inoltre necessario determinare quale volume di traffico questi servizi possono gestire e 'hardcode' questi parametri utilizzando una libreria specifica. Inoltre, l'applicazione dovrà decidere quando è ora di arrendersi e lasciare che la richiesta scada (per timeout). E per modificare uno qualsiasi dei parametri sopra citati, il server web dovrà essere arrestato, riconfigurato e riavviato.

Delegare queste attività alla service mesh significa non solo che gli sviluppatori dei servizi non dovranno pensarci, ma anche che potranno essere considerate in un contesto più globale. Se si utilizza una catena complessa di servizi, ad esempio, A → B → C → D → E, è necessario tenere conto dell'intero ciclo di vita della richiesta. Se l'obiettivo è prolungare i timeout nel servizio C, è logico farlo tutto in una volta, piuttosto che a pezzi: aggiornando il codice del servizio e aspettando che la pull request venga accettata e che il sistema CI distribuisca il servizio aggiornato.

14. Telemetria

TL;DR: Raccogli tutte le informazioni necessarie (e non) dai servizi.

La telemetria è un termine generico che comprende metriche, tracciamento distribuito e log. Le service mesh offrono meccanismi per raccogliere e trattare tutti e tre i tipi di dati. Qui le cose diventano un po' sfocate, poiché il numero di varianti possibili è troppo grande. Per raccogliere metriche ci sono Prometheus e altri strumenti, e per raccogliere log si può usare fluentd, Loki, Vector e altri. (ad esempio, ClickHouse con il nostro loghouse per K8s — n.d.t.), per il tracciamento distribuito c'è Jaeger e simili. Ogni service mesh può supportare alcuni strumenti e non supportarne altri. Sarà interessante vedere se il progetto Open Telemetry può garantire 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 sopra menzionati dai propri servizi. In altre parole, si dispone di un sistema unificato per la raccolta della telemetria e la service mesh può elaborare tutte queste informazioni in vari modi. Ad esempio:

monitorare i log di un certo servizio nel CLI;
tracciare il volume delle richieste dal pannello di monitoraggio della service mesh;
raccogliere tracciamenti distribuiti e reindirizzarli a un sistema come Jaeger.

Attenzione, giudizio soggettivo: In generale, la telemetria è un ambito in cui un forte intervento della service mesh è indesiderato. Raccogliere informazioni di base e monitorare in tempo reale alcune "metriche d'oro" come la percentuale di richieste riuscite e i ritardi è normale, ma speriamo di non diventare testimoni della nascita di stack alla Frankenstein, che cercherebbero di sostituire sistemi specializzati, alcuni dei quali hanno già dimostrato la loro validità e sono ben studiati.

15. Audit

TL;DR: Chi dimentica le lezioni della storia è destinato a ripeterle.

L'audit è l'arte di osservare eventi importanti nel sistema. Nel caso della service mesh, questo potrebbe significare monitorare chi ha effettuato richieste a specifici endpoint di determinati servizi o quante volte nell'ultimo mese è avvenuto un certo evento rilevante per la sicurezza.

È chiaro che l'audit è molto legato alla telemetria. La differenza sta nel fatto che la telemetria è solitamente associata a cose come le prestazioni e l'efficienza tecnica, mentre l'audit può riguardare questioni legali e altri aspetti che vanno oltre la sfera strettamente tecnica (ad esempio, la conformità al GDPR - Regolamento generale sulla protezione dei dati dell'UE).

16. Visualizzazione

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

Forse esiste un termine più appropriato, ma non lo conosco. Intendo semplicemente la rappresentazione grafica della service mesh o di alcuni dei suoi componenti. Queste visualizzazioni possono includere indicatori come ritardi medi, informazioni sulla configurazione dei contenitori sidecar, risultati dei controlli di salute e avvisi.

Lavorare in un ambiente orientato ai servizi comporta un carico cognitivo molto maggiore rispetto a Sua Maestà il Monolite. Pertanto, è fondamentale ridurre la pressione cognitiva a qualsiasi costo. Un'interfaccia grafica banale per service mesh che consente di cliccare su un pulsante e ottenere il risultato desiderato può essere decisiva per la crescita della popolarità di questa tecnologia.

Non sono stati inclusi nella lista

Inizialmente intendevo includere nella lista ancora alcuni casi d'uso, ma poi ho deciso di non farlo. Ecco l'elenco insieme alle ragioni della mia decisione:

Multi-data center. Nella mia visione, non si tratta tanto di un caso d'uso, quanto di un'area ristretta e specifica di applicazione delle service mesh o di un certo insieme di funzioni come la scoperta dei servizi.
Ingress ed egress. Questa è un'area correlata, ma mi sono limitato (forse in modo artificiale) al caso d'uso del traffico "east-west". Ingress ed egress meritano un articolo a parte.

Conclusione

Per ora è tutto! Ancora una volta, questa lista è piuttosto convenzionale e probabilmente incompleta. Se pensi che mi sia sfuggito qualcosa o che abbia commesso errori, contattami su Twitter (@lucperkins). Ti prego di mantenere le regole del buon comportamento.

P.S. dal traduttore

Per illustrare l'articolo è stata utilizzata un'immagine dall'articolo "What is a Service Mesh (and when to use one)?" (autore: Gregory MacKinnon). Mostra come parte delle funzionalità delle applicazioni (in verde) sia passata alla service mesh, che assicura le interconnessioni tra di esse (in blu).