Salut, Habr! Vă prezint traducerea articolului «Plan de date vs plan de control în rețelele de servicii» autor Matt Klein.

De data aceasta, am „vrut și am tradus” descrierea ambelor componente ale rețelei de servicii, planul de date și planul de control. Această descriere mi s-a părut cea mai clară și interesantă și, cel mai important, pregătește cititorul pentru întrebarea „Este necesară de fapt?”.

Deoarece conceptul de „Rețea de servicii (Service mesh)” devine din ce în ce mai popular în ultimii doi ani (Articolul original din 10 octombrie 2017), iar numărul participanților în acest domeniu a crescut, am observat o confuzie proporțională în cadrul întregului comunității tehnice cu privire la modul de comparare și contrastare a diferitelor soluții.

Situația este cel mai bine descrisă de următoarele serii de tweet-uri pe care le-am scris în iulie:

Confuzia cu rețeaua de servicii (service mesh) nr. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Niciunul dintre acestea nu este egal cu Istio. Istio este ceva complet diferit. 1 /

Primele sunt pur și simplu plane de date (data planes). Ele singure nu fac nimic. Trebuie configurate pentru ceva mai mare. 2 /

Istio este un exemplu de plan de control (control plane) care leagă părțile împreună. Este un alt strat. /sfârșit

În tweet-urile anterioare sunt menționate câteva proiecte diferite (Linkerd, NGINX, HAProxy, Envoy și Istio), dar, mai important, sunt introduse conceptele generale ale planului de date (data plane), rețelei de servicii (service mesh) și planului de control (control plane). În această postare, voi face un pas înapoi și voi explica ce înțeleg prin termenii „plan de date (data plane)” și „plan de control (control plane)” la un nivel foarte înalt, apoi voi explica modul în care acești termeni se raportează la proiectele menționate în tweet-uri.

Ce este, de fapt, rețeaua de servicii (What is a service mesh, really)?

Imaginea 1: Prezentarea generală a rețelei de servicii (Service mesh overview)

Figura 1 ilustrează conceptul rețelei de servicii (service mesh) la cel mai de bază nivel. Există patru clustere de servicii (A-D). Fiecare instanță de serviciu este conectată la un server proxy local. Tot traficul de rețea (HTTP, REST, gRPC, Redis etc.) de la o instanță separată a aplicației este trimis prin serverul proxy local către clusterele de servicii externe corespunzătoare. Astfel, instanța aplicației nu știe despre rețea în întregul ei și știe doar despre propriul său proxy local. De fapt, rețeaua sistemului distribuit a fost ascunsă de serviciu.

Plan de date (Data plane)

În rețeaua de servicii (service mesh), serverul proxy situat local pentru aplicație îndeplinește următoarele sarcini:

• Descoperirea serviciilor (Service discovery). Ce servicii / aplicații sunt disponibile pentru aplicația dumneavoastră?
• Verificarea sănătății (Health checking). Exemplarele serviciilor returnate de descoperirea serviciilor (service discovery) sunt funcționale și sunt pregătite să accepte trafic de rețea? Acest lucru poate include atât verificări active (de exemplu, verificarea răspunsului / healthcheck), cât și verificări passive (de exemplu, utilizând 3 erori 5xx consecutive ca indiciu al unui statut de sănătate nesatisfăcător al serviciului).
• Rutare (Routing). După primirea unei cereri REST către «/foo», în ce cluster de servicii ar trebui să fie trimisă cererea?
• Balansarea încărcăturii (Load balancing). După ce, în timpul rutării, a fost ales un cluster de servicii, în ce exemplar de serviciu ar trebui să fie trimisă cererea? Cu ce timeout? Cu ce setări de întrerupere a circuitului (circuit breaking)? Dacă cererea nu a reușit, ar trebui să fie repetată?
• Autentificare și autorizare (Authentication and authorization). Pentru cererile în incoming, poate serviciul apelant să fie identificat/autorized criptografic prin mTLS sau printr-un alt mecanism? Dacă este identificat/autorized, i se permite să invoce operația solicitată (endpoint) în serviciu sau ar trebui să fie returnat un răspuns neautentificat?
• Observabilitate (Observability). Pentru fiecare cerere, trebuie generate date statistice detaliate, jurnale și date de trasare distribuită, astfel încât operatorii să poată înțelege fluxul de trafic distribuit și problemele de depanare pe măsură ce acestea apar.

Pentru toate punctele anterioare din rețeaua de servicii (service mesh), răspunde planul de date (data plane). Practic, proxy-ul local pentru serviciu (sidecar) este planul de date (data plane). Cu alte cuvinte, planul de date (data plane) se ocupă de translatia condițională, redirecționarea și observarea fiecărui pachet de rețea care este trimis către un serviciu sau de la acesta.

Planul de control (The control plane)

Abstracția de rețea oferită de un proxy local în planul de date este magică (?). Totuși, cum află serverul proxy despre ruta "/foo" către serviciul B? Cum pot fi utilizate datele despre descoperirea serviciilor (service discovery) populată de solicitările proxy? Cum sunt setate parametrii pentru echilibrarea încărcăturii, timeout, circuit breaking etc.? Cum se desfășoară implementarea aplicației folosind metoda blue/green sau metoda de transfer treptat al traficului? Cine configurează parametrii pentru autentificarea și autorizarea la nivel general?

Toate punctele menționate mai sus se află în gestionarea planului de control (control plane) al rețelei de servicii (service mesh). Planul de control (control plane) primește un set de proxy-uri izolate,servere fără stare și le transformă într-un sistem distribuit.

Cred că motivul pentru care mulți tehnologi găsesc confuze conceptele distincte ale planului de date (data plane) și ale planului de control (control plane) este că, pentru majoritatea oamenilor, planul de date este familiar, în timp ce planul de control este străin/neclar. Lucrăm de mult timp cu routere și comutatoare de rețea fizice. Înțelegem că pachetele/solicitările trebuie să ajungă din punctul A în punctul B și ce hardware și software putem folosi pentru aceasta. Noua generație de proxy-uri software sunt doar versiuni la modă ale uneltelor pe care le-am folosit de mult timp.

Figura 2: Planul de control uman (Human control plane)

Cu toate acestea, am folosit planuri de control (control plane) de mult timp, deși majoritatea operatorilor de rețea ar putea să nu asocieze această parte a sistemului cu vreun component tehnologic. Motivul este simplu:
Majoritatea planurilor de control (control plane) utilizate astăzi sunt… noi.

Pe în figura 2 Aici este prezentată ceea ce numesc «Planul de control uman (Human control plane)». În acest tip de desfășurare, care este încă foarte frecvent întâlnit, un operator uman, probabil mai nervos, creează configurații statice - potențial cu ajutorul scripturilor - și le desfășoară printr-un proces special pe toate serverele proxy. Apoi, proxy-urile încep să folosească această configurație și încep să proceseze planul de date (data plane) folosind setările actualizate.

Figura 3: Planul de control avansat al rețelei de servicii (Advanced service mesh control plane)

Pe în figura 3 este prezentat «planul de control extins (control plane)» al rețelei de servicii (service mesh). Acesta este compus din următoarele părți:

• Omul (The human): Există încă un om (sperăm, mai puțin nervos) care ia decizii la un nivel înalt cu privire la întreaga sistem.
• Interfața utilizatorului a planului de control (Control plane UI): Omul interacționează cu un anumit tip de interfață utilizator pentru a gestiona sistemul. Aceasta poate fi un portal web, o aplicație de linie de comandă (CLI) sau o altă interfață. Prin intermediul interfeței utilizator, operatorul are acces la parametrii globali de configurare ai sistemului, cum ar fi:
  • Gestionarea desfășurării, albastru / verde (blue / green) și / sau trecerea graduală a traficului
  • Parametrii de autentificare și autorizare
  • Specificații ale tabelei de rutare, de exemplu, atunci când aplicația A solicită informații despre «/foo», ce se întâmplă
  • Setările balancerului de sarcină, cum ar fi delay-urile (timeouts), încercările repetate (retries), parametrii pentru întreruperea circuitului (circuit breaking) etc.
• Programul de lucru (Workload scheduler): Serviciile sunt desfășurate în infrastructură printr-un sistem de planificare / orchestrare de un anumit tip, de exemplu, Kubernetes sau Nomad. Programul este responsabil de încărcarea serviciului împreună cu proxy-ul său local.
• Descoperirea serviciului (Service discovery). Când programul de lucru pornește și oprește instanțele de serviciu, el raportează starea de funcționare în sistemul de descoperire a serviciului.
• API-urile de configurare ale proxy-ului local (Sidecar proxy configuration APIs) : Serverele proxy locale extrag dinamic starea din diferite componente ale sistemului conform modelului «consistență pe termen lung» (eventually consistent) fără intervenția operatorului. Întreaga sistemă, formată din toate instanțele de servicii și serverele proxy locale în funcțiune, converge în cele din urmă într-o ecosistemă. API-ul planei de date (data plane) din Envoy este un exemplu de cum funcționează acest lucru în practică.

Practic, scopul planei de control (control plane) este de a stabili o politică care va fi adoptată în cele din urmă de planul de date (data plane). Planele de control (control planes) mai avansate elimină mai multe detalii din sarcina operatorului și necesită mai puțin management manual, cu condiția să funcționeze corect!...

Plana de date și plana de control. Rezumat (Data plane vs. control plane summary)

• Plana de date a rețelei de servicii (Service mesh data plane): implică fiecare pachet / cerere din sistem. Este responsabilă pentru descoperirea aplicațiilor / serviciilor, verificarea disponibilității, rutarea, distribuția încărcăturii, autentificarea / autorizarea și observabilitatea.
• Plana de control a rețelei de servicii (Service mesh control plane): oferă politici și configurații pentru toate planurile de date active din rețeaua de servicii. Nu intervine în pachetele / cererile din sistem. Plana de control transformă toate planurile de date într-un sistem distribuit.

Starea actuală a proiectului (Current project landscape)

După ce am explicat cele de mai sus, să ne uităm la starea actuală a proiectului «rețelei de servicii (service mesh)».

• Planele de date (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
• Planele de control (Control planes): Istio, Nelson, SmartStack

În loc să fac o analiză detaliată a fiecărei dintre soluțiile menționate mai sus, voi aborda pe scurt câteva aspecte care, în opinia mea, generează cea mai mare parte a confuziei în ecosistemul actual.

La începutul anului 2016, Linkerd a fost unul dintre primele servere proxy pentru planul de date (data plane) pentru rețelele de servicii (service mesh) și a realizat o treabă fantastică în creșterea conștientizării și atragerea atenției asupra modelului de proiectare „rețea de servicii” (service mesh). Aproximativ șase luni mai târziu, Envoy s-a alăturat Linkerd (deși lucra la Lyft din sfârșitul anului 2015). Linkerd și Envoy sunt două proiecte care sunt adesea menționate în discuțiile despre rețelele de servicii (service mesh).

Istio a fost anunțat în mai 2017. Obiectivele proiectului Istio sunt foarte asemănătoare cu planul extins de control (control plane) arătat la în figura 3. Envoy pentru Istio este serverul proxy „implicit”. Astfel, Istio este planul de control (control plane), iar Envoy este planul de date (data plane). În scurt timp, Istio a generat multă agitație, iar alte planuri de date (data plane) au început integrarea ca înlocuitor pentru Envoy (atât Linkerd, cât și NGINX au demonstrat integrarea cu Istio). Faptul că într-un singur plan de control (control plane) se pot utiliza diferite planuri de date (data plane) înseamnă că planul de control (control plane) și planul de date (data plane) nu sunt neapărat strâns legate. Un API, cum ar fi API-ul universal pentru planul de date (data plane) Envoy, poate forma un pod între cele două părți ale sistemului.

Nelson și SmartStack ajută la ilustrarea suplimentară a separării planului de control (control plane) și a planului de date (data plane). Nelson folosește Envoy ca server proxy și construiește un plan de control (control plane) fiabil pentru rețeaua de servicii (service mesh) bazată pe stiva HashiCorp, adică Nomad etc. SmartStack a fost, poate, primul dintr-o nouă generație de rețele de servicii (service mesh). SmartStack formează un plan de control (control plane) în jurul HAProxy sau NGINX, demonstrând capacitatea decuplării planului de control (control plane) de rețeaua de servicii (service mesh) și a planului de date (data plane).

Arhitectura microserviciilor cu rețea de servicii (service mesh) atrage din ce în ce mai multă atenție (corect!), iar din ce în ce mai multe proiecte și furnizori încep să lucreze în această direcție. În următorii câțiva ani, vom vedea multe inovații atât în planurile de date (data plane), cât și în planurile de control (control plane), precum și o mai mare integrare a diverselor componente. În cele din urmă, arhitectura microserviciilor ar trebui să devină mai transparentă și magică (?) pentru operator.
Sper că devin tot mai puțin enervant.

Punctele cheie (Key takeaways)

• Rețeaua de servicii (service mesh) este alcătuită din două părți distincte: planul de date (data plane) și planul de control (control plane). Ambele componente sunt esențiale, fără ele sistemul nu va funcționa.
• Toată lumea este familiarizată cu planul de control (control plane), iar în acest moment planul de control (control plane) ai putea fi chiar tu!
• Toate planurile de date (data plane) concurează între ele în ceea ce privește funcționalitățile, performanța, configurabilitatea și scalabilitatea.
• Toate planurile de control (control plane) concurează între ele în funcționalități, configurabilitate, scalabilitate și ușurința în utilizare.
• Un plan de control (control plane) poate conține abstracții și API-uri corecte pentru a permite utilizarea mai multor planuri de date (data plane).

Sursa: habr.com