Ciao, Habr! Ti presento la traduzione di un articolo «Service mesh data plane vs control plane» 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 porta a comprendere «Ma è davvero necessario?».

Poiché l'idea di «Service mesh» sta diventando sempre più popolare negli ultimi due anni (articolo originale del 10 ottobre 2017), e il numero di partecipanti nel settore è aumentato, ho notato una crescita proporzionale della confusione in tutto il panorama tecnico riguardo a 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 semplicemente piani dati. Da soli non fanno nulla. Devono essere configurati per qualcosa di più. 2 /

Istio è un esempio di piano di controllo, che collega le parti insieme. Questo è un altro strato. /fine

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

Cos'è una rete di servizi (What is a service mesh, really)?

Figura 1: Panoramica della rete di servizi (Service mesh overview)

Figura 1 illustra il concetto di rete di servizi (service mesh) al livello più fondamentale. Ci sono quattro cluster di servizi (A-D). Ogni istanza del servizio è collegata a un proxy locale. Tutto il traffico di rete (HTTP, REST, gRPC, Redis, ecc.) da ciascuna istanza dell'applicazione passa attraverso il proxy locale verso i corrispondenti cluster di servizi esterni. In questo modo, l'istanza dell'applicazione non è a conoscenza della rete nel suo complesso e conosce solo il suo proxy locale. Infatti, la rete del sistema distribuito è stata astratta dal servizio.

Piano dati (Data plane)

Nella rete di servizio (service mesh), un proxy locale per l'applicazione svolge le seguenti funzioni:

Scoperta dei servizi (Service discovery). Quali servizi/applicazioni sono disponibili per la tua applicazione?
Controllo dello stato (Health checking). Gli istanze dei servizi restituiti dalla scoperta dei servizi (service discovery) sono operative e pronte a ricevere traffico di rete? Questo può includere controlli sia attivi (ad esempio, controllo della risposta / healthcheck) che passivi (ad esempio, utilizzando 3 errori 5xx consecutivi come indicazione di uno stato di salute non ottimale).
Instradamento (Routing). Ricevendo dalla richiesta REST del servizio "/foo", in quale cluster di servizi dovrebbe essere inviata la richiesta?
Bilanciamento del carico (Load balancing). Dopo che è stato selezionato il cluster del servizio durante l'instradamento, in quale istanza del servizio deve essere inviata la richiesta? Con quale timeout? Con quali impostazioni di interruzione del circuito (circuit breaking)? Se la richiesta fallisce, deve essere ripetuta?
Autenticazione e autorizzazione (Authentication and authorization). Per le richieste in arrivo, il servizio chiamante può essere identificato/autenticato crittograficamente tramite mTLS o qualche altro meccanismo? Se è identificato/autenticato, è autorizzato a invocare l'operazione richiesta (endpoint) nel servizio o deve essere restituita una risposta non autenticata?
Osservabilità (Observability). Per ogni richiesta devono essere generati dettagliati dati statistici, registri e dati di tracciamento distribuito, affinché gli operatori possano comprendere il flusso di traffico distribuito e i problemi di debug man mano che si presentano.

Per tutti i punti precedenti nella rete di servizio (service mesh), è responsabile il piano dati (data plane). In sostanza, il proxy locale per il servizio (sidecar) costituisce il piano dati (data plane). In altre parole, il piano dati (data plane) è responsabile della traduzione condizionale, del re-instradamento e dell'osservazione di ogni pacchetto di rete inviato al servizio o da esso.

Il piano di controllo (The control plane)

L'astrazione di rete fornita dal proxy locale nel piano dati è magica (?). Tuttavia, come fa il proxy a conoscere il percorso "/foo" verso il servizio B? Come possono essere utilizzati i dati di discovery dei servizi riempiti dalle richieste del proxy? Come sono configurati i parametri di bilanciamento del carico, timeout, circuit breaking, ecc.? Come viene eseguito il deployment dell'applicazione utilizzando il metodo blue/green o il metodo di transizione graduale del traffico? Chi configura i parametri di autenticazione e autorizzazione a livello di sistema?

Tutti i punti sopra menzionati rientrano nella competenza del piano di controllo della rete di servizi. Il piano di controllo accetta un insieme di proxy isolati senza stato e li trasforma in un sistema distribuito.server senza stato..

Ritengo che la ragione per cui molti tecnologi trovano confusi i concetti separati di piano dati (data plane) e piano di controllo (control plane) sia che per la maggior parte delle persone il piano dati è familiare, mentre il piano di controllo risulta estraneo o incomprensibile. Lavoriamo da tempo con router e switch di rete fisici. Comprendiamo che pacchetti e richieste devono andare da un punto A a un punto B e quali hardware e software possiamo utilizzare per questo. La nuova generazione di proxy software è semplicemente una versione alla moda degli strumenti che abbiamo utilizzato per molto tempo.

Figura 2: Piano di controllo umano (Human control plane)

Tuttavia, abbiamo utilizzato i piani di controllo (control plane) per lungo tempo, anche se la maggior parte degli operatori di rete potrebbe non collegare questa parte del sistema a un componente tecnologico. La ragione è semplice:
La maggior parte dei piani di controllo (control plane) attualmente utilizzati sono… noi.

Su nella figura 2 Mostra ciò che chiamo «Piano di controllo umano (Human control plane)». In questo tipo di distribuzione, che è ancora molto comune, un operatore umano, probabilmente scostante, crea configurazioni statiche — potenzialmente tramite script — e le distribuisce utilizzando un processo speciale su tutti i server proxy. I proxy quindi iniziano a utilizzare questa configurazione e passano a elaborare il piano dati (data plane) utilizzando le impostazioni aggiornate.

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

Su nella figura 3 è mostrato il «piano di controllo avanzato (control plane)» della rete di servizi (service mesh). Esso consiste delle seguenti parti:

L'essere umano (The human): C'è ancora un umano (spero meno arrabbiato) che prende decisioni a un livello elevato riguardo all'intero sistema.
Interfaccia utente del piano di controllo (Control plane UI): Una persona interagisce con un tipo di interfaccia utente per gestire il sistema. Questo può essere un portale web, un'applicazione da riga di comando (CLI) o un'altra interfaccia. Attraverso l'interfaccia utente, l'operatore ha accesso a parametri di configurazione globale del sistema come:
- Gestione del deployment, blue/green e/o gradual traffic shifting
- Opzioni di autenticazione e autorizzazione
- Specifiche della tabella di routing, ad esempio, cosa succede quando l'applicazione A richiede informazioni su «/foo»
- Impostazioni del bilanciatore di carico, come timeouts, retries, circuit breaking, ecc.
Pianificatore di carico di lavoro (Workload scheduler): I servizi vengono avviati nell'infrastruttura tramite un sistema di pianificazione/orchestrazione specifico, come Kubernetes o Nomad. Il pianificatore è responsabile del caricamento del servizio insieme al suo proxy locale.
Scoperta del servizio (Service discovery)Quando il pianificatore avvia e ferma le istanze del servizio, comunica lo stato di disponibilità al sistema di rilevamento del servizio.
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 l'intervento dell'operatore. L'intero sistema, composto da tutte le istanze di servizio attualmente in esecuzione e proxy locali, converge infine in un'unica ecosistema. Le API della piana dati (data plane) in Envoy sono un esempio di come ciò funzioni nella pratica.

Fondamentalmente, l'obiettivo della piana di controllo (control plane) è di stabilire una politica che alla fine sarà accettata dalla piana dati (data plane). Piane di controllo più avanzate allontaneranno dall'operatore ulteriori dettagli di alcuni sistemi e richiederanno meno gestione manuale, a condizione che funzionino correttamente!..

Piana dati e piana di controllo. Sintesi (Data plane vs. control plane summary)

Piana dati della rete di servizio (Service mesh data plane): coinvolge ogni pacchetto / richiesta nel sistema. Si occupa della rilevazione di applicazioni / servizi, verifica dello stato, instradamento, bilanciamento del carico, autenticazione / autorizzazione e monitoraggio.
Piano di controllo della rete di servizi (Service mesh control plane): fornisce politiche e configurazioni per tutti i piani di dati attivi all'interno della rete di servizi. Non tocca pacchetti / richieste nel sistema. Il piano di controllo trasforma tutti i piani di dati in un sistema distribuito.

Stato attuale del progetto (Current project landscape)

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

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

Invece di analizzare in profondità ciascuna delle soluzioni sopra menzionate, mi soffermerò brevemente su alcuni punti che, a mio avviso, generano la maggior parte della confusione nell'ecosistema attualmente.

All'inizio del 2016, Linkerd è stato uno dei primi proxy del piano dati per le reti di servizi e ha fatto un ottimo lavoro nel sensibilizzare e aumentare l'attenzione sul modello di progettazione della rete di servizi. Circa sei mesi dopo, Envoy si è unito a Linkerd, anche se lavorava in Lyft dalla fine del 2015. Linkerd ed Envoy sono due progetti che vengono spesso citati quando si parla di reti di servizi.

Istio è stato annunciato a maggio 2017. Gli obiettivi del progetto Istio sono molto simili a quelli del piano di controllo ampliato. nella figura 3. Envoy per Istio è il proxy predefinito. Così, Istio funge da piano di controllo, mentre Envoy agisce come piano dati. In breve tempo, Istio ha suscitato molto interesse, e altri piani dati hanno iniziato a integrarsi come alternative a Envoy (sia Linkerd che NGINX hanno dimostrato integrazione con Istio). Il fatto che sia possibile utilizzare diversi piani dati all'interno di un unico piano di controllo implica che il piano di controllo e il piano dati non siano necessariamente strettamente correlati. Un'API come l'API universale del piano dati di Envoy può fungere da ponte tra le due parti del sistema.

Nelson e SmartStack aiutano a illustrare ulteriormente la separazione tra il piano di controllo (control plane) e il piano dati (data plane). Nelson utilizza Envoy come suo proxy e costruisce un piano di controllo (control plane) robusto per la rete di servizi (service mesh) utilizzando la stack di HashiCorp, ad esempio Nomad, e così via. SmartStack è diventato, probabilmente, 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 iniziano a lavorare in questo ambito. Nei prossimi anni vedremo molte innovazioni sia nei piani dati (data plane) che nei piani di controllo (control plane), oltre a un'ulteriore mescolanza di vari componenti. Alla fine, l'architettura a microservizi dovrebbe diventare più trasparente e magica (?) per l'operatore.
Spero che tutti siano sempre meno irritati.

Punti chiave (Key takeaways)

La rete di servizi (service mesh) è composta da due parti distinte: 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 conoscono il piano di controllo (control plane), e in questo momento il piano di controllo (control plane) puoi essere tu!
Tutti i piani dati (data plane) competono tra loro in termini di funzionalità, prestazioni, configurabilità e scalabilità.
Tutti i piani di controllo (control plane) competono tra loro in termini di funzionalità, configurabilità, scalabilità e facilità d'uso.
Un piano di controllo (control plane) può contenere astrazioni e API appropriate per consentire l'utilizzo di più piani dati (data plane).

Fonte: habr.com