Ciao, Habr! Vi presento la traduzione dell'articolo «Piano dati vs piano di controllo del service mesh» autore Matt Klein.

Questa volta ho «voluto e tradotto» la descrizione di entrambi i componenti del service mesh, piano dati e piano di controllo. Questa descrizione mi è sembrata la più chiara e interessante, e soprattutto conduce alla comprensione di «È davvero necessario?».

Poiché l'idea del «Service mesh» è diventata sempre più popolare negli ultimi due anni (articolo originale del 10 ottobre 2017), e il numero di partecipanti nello spazio è aumentato, ho notato una crescente confusione tra tutta la comunità tecnica su come confrontare e contrapporre le diverse soluzioni.

La situazione può essere meglio descritta dalle seguenti serie di tweet che ho scritto a luglio:

Confusione sul service mesh n. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Nessuno di essi è uguale a Istio. Istio è qualcosa di completamente diverso. 1 /

I primi sono semplici piani dati. Da soli non fanno nulla. Devono essere configurati per qualcosa di più grande. 2 /

Istio è un esempio di piano di controllo che collega le parti insieme. È un altro livello. /fine

Nei tweet precedenti vengono menzionati diversi progetti (Linkerd, NGINX, HAProxy, Envoy e Istio), ma, cosa più importante, vengono introdotti concetti comuni di piano dati, service mesh e piano di controllo. In questo post farò un passo indietro e spiegherò cosa intendo con i termini «piano dati» e «piano di controllo» a un livello molto alto, e poi parlerò di come i termini si riferiscono ai progetti menzionati nei tweet.

Che cos'è davvero un service mesh?

Figura 1: Panoramica del service mesh

Figura 1 illustra il concetto di service mesh a un livello molto basico. Ci sono quattro cluster di servizi (A-D). Ogni istanza di servizio è collegata a un proxy locale. Tutto il traffico di rete (HTTP, REST, gRPC, Redis, ecc.) da ciascuna istanza dell'applicazione viene instradato attraverso il proxy locale ai corrispondenti cluster di servizi esterni. In questo modo, l'istanza dell'applicazione non è a conoscenza della rete nel suo complesso e sa solo del proprio proxy locale. In effetti, la rete del sistema distribuito è stata rimossa dal servizio.

Piano dati

Nel service mesh, il proxy situato localmente per l'applicazione svolge le seguenti funzioni:

Scoperta dei servizi (Service discovery). Quali servizi/misure/applicazioni sono disponibili per la tua applicazione?
Controllo della salute (Health checking). Gli esemplari dei servizi restituiti dalla scoperta dei servizi (service discovery) sono operativi e pronti a ricevere traffico di rete? Questo può includere controlli sia attivi (ad esempio, verifica della risposta / health check) che passivi (ad esempio, utilizzando 3 errori consecutivi 5xx come indicazione dello stato non sano del servizio).
Instradamento (Routing). Ricevendo una richiesta REST dal servizio a «/foo», a quale cluster di servizio deve essere inviato il messaggio?
Bilanciamento del carico (Load balancing). Dopo che è stato scelto un cluster di servizio durante l'instradamento, a quale esemplare di servizio deve essere inviata la richiesta? Con quale timeout? Con quali impostazioni di interruzione del circuito (circuit breaking)? Se la richiesta non riesce, deve essere ripetuta?
Autenticazione e autorizzazione (Authentication and authorization). Per le richieste in entrata, il servizio chiamante può essere identificato/autorizzato crittograficamente utilizzando mTLS o qualche altro meccanismo? Se è identificato/autorizzato, gli è permesso invocare l'operazione richiesta (endpoint) nel servizio o deve essere restituita una risposta non autenticata?
Osservabilità (Observability). Per ogni richiesta devono essere generati dettagli statistici, log e dati di tracciamento distribuito in modo che gli operatori possano comprendere il flusso di traffico distribuito e i problemi di debug mentre si presentano.

Per tutti i punti precedenti nella rete di servizio (service mesh), è responsabile il piano dati (data plane). In sostanza, un proxy locale per il servizio (sidecar) è il piano dati (data plane). In altre parole, il piano dati (data plane) è responsabile della trasmissione condizionale, dell'inoltro e dell'osservazione di ogni pacchetto di rete che viene inviato al servizio o da esso.

Il piano di controllo (The control plane)

L'astrazione di rete fornita da un proxy locale nel piano dei dati è magica (?). Tuttavia, come fa realmente un server proxy a conoscere il percorso "/foo" verso il servizio B? Come possono essere utilizzati i dati di discovery dei servizi riempiti da richieste proxy? Come sono configurati i parametri di bilanciamento del carico, timeout, interruzione della circuitazione e così via? Come avviene il deployment dell'applicazione utilizzando il metodo blue/green o il metodo di migrazione graduale del traffico? Chi imposta i parametri di autenticazione e autorizzazione a livello di sistema?

Tutti i punti sopra menzionati sono sotto la responsabilità del piano di controllo della rete dei servizi. Il piano di controllo prende un insieme di proxy isolatiserver senza stato e li trasforma in un sistema distribuito..

Penso che il motivo per cui molti tecnici trovino complicati i concetti separati del piano dei dati e del piano di controllo sia che per la maggior parte delle persone il piano dei dati è familiare, mentre il piano di controllo è estraneo/incomprensibile. Lavoriamo con router e switch di rete fisici da molto tempo. Sappiamo che i pacchetti/richeste devono andare da un punto A a un punto B, e che possiamo utilizzare hardware e software per questo. La nuova generazione di proxy software è solo una versione alla moda degli strumenti che abbiamo usato per lungo tempo.

Figura 2: Piano di controllo umano

Tuttavia, utilizziamo i piani di controllo da molto tempo, anche se la maggior parte degli operatori di rete potrebbe non associare questa parte del sistema a un componente tecnologico. Il motivo è semplice:
La maggior parte dei piani di controllo utilizzati oggi è… noi.

A nella figura 2 viene mostrato quello che chiamo «Piano di controllo umano (Human control plane)». In questo tipo di distribuzione, che è ancora molto comune, un operatore umano, probabilmente brontolone, crea configurazioni statiche — potenzialmente con script — e le distribuisce attraverso un qualche processo speciale su tutti i server proxy. I proxy poi iniziano ad utilizzare questa configurazione e iniziano a elaborare il piano dati (data plane) utilizzando le impostazioni aggiornate.

Figura 3: Piano di controllo avanzato della rete di servizio (Advanced service mesh control plane)

A nella figura 3 viene mostrato il «piano di controllo» (control plane) avanzato della rete di servizio (service mesh). Esso è composto dalle seguenti parti:

Umano (The human): C'è ancora un umano (spero meno arrabbiato) che prende decisioni ad alto livello riguardo all'intero sistema.
Interfaccia utente del piano di controllo (Control plane UI): L'umano interagisce con un qualche tipo di interfaccia utente per gestire il sistema. Questo può essere un portale web, un'applicazione della riga di comando (CLI) o un altro tipo di interfaccia. Utilizzando l'interfaccia utente, l'operatore ha accesso a impostazioni globali di configurazione di sistema come:
- Gestione delle distribuzioni, blu/verde (blue/green) e/o il passaggio graduale del traffico
- Impostazioni di autenticazione e autorizzazione
- Specifiche della tabella di instradamento, ad esempio, cosa succede quando l'applicazione A richiede informazioni su «/foo»
- Impostazioni del bilanciatore di carico, come timeout, ritentativi, parametri di interruzione circuitale e così via.
Pianificatore di carico di lavoro (Workload scheduler): I servizi vengono avviati nell'infrastruttura tramite un sistema di pianificazione/orchestrazione di un certo tipo, come Kubernetes o Nomad. Il pianificatore è responsabile dell'avvio del servizio insieme al suo proxy locale.
Scoperta dei servizi (Service discovery). Quando il pianificatore avvia e ferma le istanze di servizio, comunica lo stato di disponibilità nel sistema di scoperta dei servizi.
API di configurazione del proxy locale (Sidecar proxy configuration APIs) : I proxy locali estraggono dinamicamente lo stato da vari componenti del sistema secondo il modello di «coerenza alla fine» (eventually consistent) senza intervento dell'operatore. L'intero sistema, composto da tutte le istanze di servizio e i proxy locali attualmente in esecuzione, converge infine in un'unica ecosistema. L'API del piano dati (data plane) universale in Envoy è un esempio di come ciò funzioni nella pratica.

In sostanza, l'obiettivo del piano di controllo (control plane) è quello di stabilire una politica che alla fine sarà accettata dal piano dati (data plane). Piani di controllo (control plane) più avanzati rimuoveranno più dettagli da alcuni sistemi dall'operatore e richiederanno meno gestione manuale, a condizione che funzionino correttamente!..

Piano dati e piano di controllo. Riepilogo (Data plane vs. control plane summary)

Piano dati della rete di servizi (Service mesh data plane): riguarda ogni pacchetto / richiesta nel sistema. Responsabile della scoperta delle applicazioni / servizi, del controllo della disponibilità, della routing, del bilanciamento del carico, dell'autenticazione / autorizzazione e dell'osservabilità.
Piano di controllo della rete di servizi (Service mesh control plane): fornisce politiche e configurazioni per tutti i piani dati funzionanti all'interno della rete di servizi. Non tocca nessun pacchetto / richiesta nel sistema. Il piano di controllo trasforma tutti i piani dati in un sistema distribuito.

Stato attuale del progetto (Current project landscape)

Dopo aver esaminato la spiegazione sopra, diamo un'occhiata allo stato attuale del progetto «rete di servizi (service mesh)».

Piani dati (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
Piani di controllo (Control planes): Istio, Nelson, SmartStack

Invece di condurre un'analisi approfondita di ciascuna delle soluzioni sopra elencate, mi fermerò brevemente su alcuni punti che, secondo me, suscitano la maggior parte della confusione nell'ecosistema in questo momento.

All'inizio del 2016, Linkerd era uno dei primi server proxy per il piano dati (data plane) per le reti di servizi (service mesh) e ha fatto un lavoro fantastico nel aumentare la consapevolezza e l'attenzione sul modello di progettazione «rete di servizi» (service mesh). Circa sei mesi dopo, Envoy si unì a Linkerd (anche se lavorava in Lyft dalla fine del 2015). Linkerd ed Envoy sono i due progetti più frequentemente menzionati quando si parla di reti di servizi (service mesh).

Istio è stato annunciato a maggio 2017. Gli obiettivi del progetto Istio sono molto simili a quelli di un piano di controllo (control plane) avanzato, mostrato su nella figura 3. Envoy per Istio è il server proxy «di default». Pertanto, Istio è un piano di controllo (control plane) e Envoy è un piano dati (data plane). In poco tempo, Istio ha suscitato molto interesse e altri piani dati (data plane) hanno iniziato a integrarsi come sostituti di Envoy (sia Linkerd che NGINX hanno dimostrato integrazione con Istio). Il fatto che in un piano di controllo (control plane) si possano utilizzare diversi piani dati (data plane) significa che il piano di controllo (control plane) e il piano dati (data plane) non sono necessariamente strettamente legati. Un API come l'API universale del piano dati (data plane) Envoy può fungere da ponte tra le due parti del sistema.

Nelson e SmartStack aiutano a illustrare ulteriormente la separazione tra piano di controllo (control plane) e piano dati (data plane). Nelson utilizza Envoy come suo proxy e costruisce un affidabile piano di controllo (control plane) per la rete di servizi (service mesh) basata su stack HashiCorp, cioè Nomad, ecc. SmartStack è probabilmente stato il primo di una nuova ondata di reti di servizi (service mesh). SmartStack forma un piano di controllo (control plane) attorno a HAProxy o NGINX, dimostrando la possibilità di disaccoppiare il piano di controllo (control plane) dalla rete di servizi (service mesh) e dal piano dati (data plane).

L'architettura a microservizi con una rete di servizi (service mesh) sta attirando sempre più attenzione (giustamente!), e sempre più progetti e fornitori stanno iniziando a lavorare in questa direzione. Nei prossimi anni vedremo molte innovazioni sia nel piano dati (data plane) che nel piano di controllo (control plane), così come una continua mescolanza di diversi componenti. In definitiva, l'architettura a microservizi deve diventare più trasparente e magica (?) per l'operatore.
Spero che sempre meno irritato.

Punti chiave (Key takeaways)

La rete di servizi (service mesh) è composta da due parti diverse: il piano dati (data plane) e il piano di controllo (control plane). Entrambi i componenti sono essenziali, e senza di essi il sistema non funzionerà.
Tutti sono familiari con il piano di controllo (control plane), e in questo momento il piano di controllo (control plane) potresti essere tu!
Tutti i piani dati (data plane) competono tra loro per funzionalità, prestazioni, configurabilità ed espandibilità.
Tutti i piani di controllo (control plane) competono tra loro per funzionalità, configurabilità, espandibilità e facilità d'uso.
Un piano di controllo (control plane) può contenere le giuste astrazioni e API per consentire l'utilizzo di più piani dati (data plane).

Fonte: habr.com