Përshëndetje, Habr! Ju prezantoj përkthimin e artikullit «Planeja e kontrollit të mesh-it të shërbimeve» autori Matt Klein.

Këtë herë, përshkrimi i të dy componenteve të mesh-it të shërbimeve, planeve të dhënash dhe planeve të kontrollit, më dukej më i qartë dhe interesant, e më e rëndësishme, që ndihmon në kuptimin e «A është e nevojshme në të vërtetë?»

Të mendosh për mesh-in e shërbimeve (Service mesh) po bëhet gjithnjë e më i popullarizuar gjatë dy viteve të fundit (artikulli origjinal nga 10 tetori 2017), dhe numri i pjesëmarrësve në këtë hapësirë është rritur, kam vërejtur një rritje të ngjashme të konfuzionit midis tërë komunitetit teknik në lidhje me mënyrën e krahasimit dhe diferenciimit të zgjidhjeve të ndryshme.

Situatën mund ta përshkruajmë më mirë me një seri tweet-esh që kam shkruar në korrik:

Konfuzioni në lidhje me mesh-in e shërbimeve (service mesh) #1: Linkerd ~ = Nginx ~ = HAProxy ~ = Envoy. Asnjëra nga këto nuk është e barabartë me Istio. Istio është diçka krejtësisht tjetër. 1 /

Të parat janë thjesht plane të dhënash (data planes). Ato vetë nuk bëjnë asgjë. Ato duhet të konfigurohen për diçka më të madhe. 2 /

Istio është një shembull i një plani kontrolli (control plane), që lidh pjesët së bashku. Ky është një nivel tjetër. /fund

Në tweet-et e mëparshme përmenden disa projekte të ndryshme (Linkerd, NGINX, HAProxy, Envoy dhe Istio), por më e rëndësishmja, futen konceptet e përgjithshme të planeve të dhënash (data plane), mesh-it të shërbimeve (service mesh) dhe planeve të kontrollit (control plane). Në këtë post do të heq një hap prapa dhe do të shpjegoj çfarë nënkuptoj me termin «plane të dhënash (data plane)» dhe «plan kontrolli (control plane)» në një nivel shumë të lartë, dhe pastaj do të shpjegoj se si këto terma lidhen me projektet që janë përmendur në tweet-et.

Çfarë është me të vërtetë një mesh shërbimesh (What is a service mesh, really)?

Figura 1: Përshtypje e mesh-it të shërbimeve (Service mesh overview)

Figura 1 ilustron konceptin e mesh-it të shërbimeve (service mesh) në nivelin më bazik. Ka katër klasterë shërbimesh (A-D). Çdo instancë shërbimi është e lidhur me një server proxy lokal. I gjithë trafi kyç (HTTP, REST, gRPC, Redis, etj.) nga instancat e veçanta të aplikacionit dërgohet përmes serverit proxy lokal në klasterët shërbimorë të jashtëm përkatës. Kështu, instanca e aplikacionit nuk e di për rrjetin në tërësi dhe njeh vetëm serverin e saj lokal proxy. Në fakt, rrjeti i sistemit të distribuar është hequr nga shërbimi.

Plani i të dhënave (Data plane)

Në mesh-in e shërbimeve (service mesh), serveri proxy i vendosur lokal për aplikacionin kryen këto detyra:

• Zbulesa e shërbimeve (Service discovery). Cilat shërbime/funksione/aplikacione janë të disponueshme për aplikacionin tuaj?
• Kontrolli i shëndetit (Health checking). A janë instancat e shërbimeve, të rikthyera nga zbulesa e shërbimeve (service discovery), në gjendje të shëndoshë dhe gati për të pranuar trafik në rrjet? Kjo mund të përfshijë si kontroll aktiv (p.sh., verifikimi i përgjigjes / healthcheck), ashtu edhe të pasiv (p.sh., duke përdorur 3 gabime 5xx rresht si një tregues të gjendjes së keqe të shërbimit).
• Routimi (Routing). Pas marrjes së një kërkese REST nga shërbimi për «/foo», në cilin klaster shërbimi duhet dërguar kërkesa?
• Balancimi i ngarkesës (Load balancing). Pas përzgjedhjes së klasterit të shërbimit gjatë rrugës, në cilin instancë shërbimi duhet dërguar kërkesa? Me cilin afat? Me cilat parametra të ndalimit të qarkut (circuit breaking)? Nëse kërkesa dështon, a duhet ta ripërsërisim atë?
• Autentifikimi dhe autorizimi (Authentication and authorization). Për kërkesat e ardhshme, mund të identifikohet/autorizohet shërbimi thirrës në mënyrë kriptografike përmes mTLS ose ndonjë mekanizmi tjetër? Nëse është identifikuar/autorizar, a i lejohet të thërrasë operacionin (endpoint) në shërbim ose duhet të kthehet një përgjigje e paautorizuar?
• Vëzhgueshmëria (Observability). Për secilën kërkesë, duhet të gjenerohen të dhëna të detajuara statistikore, logje/raporte dhe të dhëna të gjurmimit të shpërndarë, që operatorët të mund të kuptojnë rrugën e shpërndarë të trafik dhe problemet e zgjidhjes së gabimeve ndërsa ato ndodhin.

Për të gjitha pikat e përmendura më sipër, përgjigjen e ka plani i të dhënave (data plane) në mesh-in e shërbimeve (service mesh). Në thelb, proxy lokal për shërbimin (sidecar) është plani i të dhënave (data plane). Në terma të tjerë, plani i të dhënave (data plane) përgjigjet për transmetimin, dërgimin dhe vëzhgimin e çdo pakete rrjeti që dërgohet në shërbim ose dërgohet prej tij.

Plani i kontrollit (The control plane)

Abstraksioni rrjetësor që ofrohet nga proxy lokal në nivelin e të dhënave (data plane) është magjik. Megjithatë, si e di një server proxy në të vërtetë rrugën "/foo" për shërbimin B? Si mund të përdoren të dhënat e zbulimit të shërbimeve (service discovery), të cilat mbushen nga kërkesat e proxy? Si janë të konfiguruara parametrat e balancimit të ngarkesës, skadimit (timeout), thyerjes së qarkut (circuit breaking) etj.? Si është implementimi i aplikacioneve duke përdorur metodën blu/jeshile (blue/green) ose metodën e kalimit gradual të trafikut? Kush i konfigurën parametrat e autentifikimit dhe autorizimit të sistemit tërësor?

Të gjitha çështjet e lartpërmendura janë nën menaxhimin e nivelit të kontrollit (control plane) të rrjetit të shërbimeve (service mesh). Niveli i kontrollit (control plane) merr një grup proxy-esh të izoluar,servera pa gjendje dhe i kthen ato në një sistem të shpërndarë..

Mendoj se arsyeja pse shumë teknologë e gjejnë të ndërlikuar konceptin e ndarë të nivelit të të dhënave (data plane) dhe nivelit të kontrollit (control plane) është se niveli i të dhënave është i njohur, ndërsa niveli i kontrollit është i huaj/i paqartë. Ne kemi punuar për një kohë të gjatë me ruterë dhe kalues fizikë rrjetesh. Ne e kuptojmë që paketat/kërkesat duhet të shkojnë nga pika A në pikën B, dhe se çfarë mund të përdorim për këtë është harduer dhe softuer. Brezi i ri i proxy-ve programore është thjesht moda e instrumenteve që kemi përdorur për një kohë të gjatë.

Figura 2: Niveli i menaxhimit njerëzor (Human control plane)

Megjithatë, ne kemi përdorur nivelet e kontrollit (control plane) për një kohë të gjatë, edhe pse shumica e operatorëve të rrjetit mund të mos lidhen këtë pjesë të sistemit me ndonjë komponent teknologjik. Arsyeja për këtë është e thjeshtë:
Shumica e niveleve të kontrollit (control plane) të përdorura sot janë... ne.

Në në figurën 2 kam ilustruar atë që e quaj "Niveli i Menaxhimit Njerëzor (Human control plane)". Në këtë lloj implementimi, që ndodhet ende shumë shpesh, operatori njerëzor, ndoshta me një humor të keq, krijon konfiguracione statike — potencialisht, me ndihmën e skripteve — dhe i implementon ato nëpërmjet një procesi të veçantë në të gjitha serverat proxy. Më pas, proxy-t fillojnë të përdorin këtë konfigurim dhe fillojnë të trajtojnë nivelin e të dhënave (data plane) duke përdorur cilësimet e azhurnuara.

Figura 3: Niveli i avancuar i kontrollit të rrjetit të shërbimeve (Advanced service mesh control plane)

Në në figurën 3 është ilustruar niveli "i avancuar" i kontrollit (control plane) të rrjetit të shërbimeve (service mesh). Ai përbëhet nga pjesët e mëposhtme:

• Njeriu (The human): Akoma ka një njeri (shpresoj, më pak i mërzitur) që merr vendime në nivel të lartë për tërë sistemin.
• Ndërfaqja e përdoruesit të nivelit të kontrollit (Control plane UI): Njeriu ndërvepron me ndonjë lloj ndërfaqeje për të menaxhuar sistemin. Kjo mund të jetë një portal web, një aplikacion komandë (CLI) ose ndonjë ndërfaqe tjetër. Me anë të ndërfaqes, operatori ka qasje në parametrat globalë të konfigurimit të sistemit, si:
  • Menaxhimi i implementimit, blu/jeshile (blue/green) dhe/ose me kalimin gradual të trafikut
  • Parametrat e autentifikimit dhe autorizimit
  • Specifikimet e tabelës së ruterëve, për shembull, kur aplikacioni A kërkon informacion mbi "/foo", çfarë ndodh
  • Cilësimet e balancuesit të ngarkesës, për shembull, skadimet (timeouts), përpjekjet (retries), parametrat e thyerjes së qarkut (circuit breaking) etj.
• Planifikuesi i ngarkesave (Workload scheduler): Shërbimet fillojnë në infrastrukturë përmes një sistemi planifikimi/orkestrimi të caktuar, për shembull, Kubernetes ose Nomad. Planifikuesi është përgjegjës për ngarkimin e shërbimit me serverin e tij lokal proxy.
• Zbulimi i shërbimit (Service discovery). Kur planifikuesi aktivizon dhe ndalon instancat e shërbimit, ai raporton gjendjen e punës në sistemin e zbulimit të shërbimit.
• API të konfigurimit të proxy-t lokal (Sidecar proxy configuration APIs) : Proxy-t lokal tërheqin dinamik gjendjen nga komponentët e ndryshëm të sistemit sipas modelit "fundosja në fund" (eventually consistent) pa ndërhyrjen e operatorit. E gjithë sistemi, që përbëhet nga të gjitha instancat aktualisht të aktivizuara të shërbimeve dhe proxy-ve lokal, përfundimisht përcjell në një ekosistem. API e nivelit universal të të dhënave (data plane) në Envoy është një nga shembujt se si funksionon në praktikë.

Në thelb, qëllimi i planit të kontrollit (control plane) është të vendosë politikën që në fund do të miratohet nga plani i të dhënave (data plane). Planet më të avancuara të kontrollit (control plane) do të largojnë më shumë detaje të disa sistemeve nga operatori dhe do të kërkojnë më pak menaxhim manual, me kusht që ato të funksionojnë siç duhet!..

Plani i të dhënave dhe plani i kontrollit. Përmbledhje (Data plane vs. control plane summary)

• Plani i të dhënave të rrjetit të shërbimit (Service mesh data plane): prek çdo paketë / kërkesë në sistem. Përcakton zbulimin e aplikacioneve / shërbimeve, kontrollin e funksionalitetit, rrugëzimin, shpërndarjen e ngarkesës, autentikimin / autorizimin dhe monitorimin.
• Plani i kontrollit të rrjetit të shërbimit (Service mesh control plane): ofron politikat dhe konfigurimin për të gjitha planet e të dhënave që funksionojnë brenda rrjetit të shërbimit. Nuk prek asnjë paketë / kërkesë në sistem. Plani i kontrollit e kthen të gjitha planet e të dhënave në një sistem të shpërndarë.

Gjendja aktuale e projektit (Current project landscape)

Pas shpjegimit të mësipërm, le të shikojmë gjendjen aktuale të projektit "rrjeti i shërbimeve (service mesh)".

• Planet e të dhënave (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
• Planet e kontrollit (Control planes): Istio, Nelson, SmartStack

Në vend të analizimit të thelluar të secilit nga zgjidhjet e lartpërmendura, unë do të ndalem shkurtimisht në disa pika që, sipas mendimit tim, shkaktojnë shumicën e konfuzionit në ekosistemin aktual.

Në fillim të vitit 2016, Linkerd ishte një nga proxy-t e parë të planit të të dhënave (data plane) për rrjetin e shërbimeve (service mesh) dhe bëri një punë të shkëlqyer në rritjen e vetëdijes dhe përqendrimit mbi modelin e projektimit "rrjeti i shërbimeve" (service mesh). Rreth 6 muaj më pas, Envoy i bashkëngjiti Linkerd (ndonëse kishte punuar në Lyft që nga fundi i vitit 2015). Linkerd dhe Envoy janë dy projekte që përmenden shpesh në diskutimet mbi rrjetet e shërbimeve (service mesh).

Istio u shpall në maj 2017. Qëllimet e projektit Istio janë të ngjashme me planet e zgjeruara të kontrollit (control plane) që janë treguar në në figurën 3. Envoy për Istio është proxy "për default". Kështu, Istio është plani i kontrollit (control plane), ndërsa Envoy është plani i të dhënave (data plane). Në një kohë shumë të shkurtër, Istio shkaktoi shumë zhurmë, dhe planet e tjera të të dhënave (data plane) filluan integrimin si zëvendës të Envoy (dhe Linkerd dhe NGINX kanë demonstruar integrimin me Istio). Fakti që në një plan të kontrollit (control plane) mund të përdoren disa plane të të dhënave (data plane) tregon se plani i kontrollit (control plane) dhe plani i të dhënave (data plane) nuk janë domosdoshmërisht të lidhur ngushtë. Një API si API-universali i planit të të dhënave (data plane) Envoy mund të formojë një urë midis dy pjesëve të sistemit.

Nelson dhe SmartStack ndihmojnë për të ilustruar më tej ndarjen e planit të kontrollit (control plane) dhe planit të të dhënave (data plane). Nelson përdor Envoy si proxy-në e tij dhe ndërton një plan të besueshëm të kontrollit (control plane) të rrjetit të shërbimit (service mesh) mbi bazën e stack-ut të HashiCorp, dmth. Nomad etj. SmartStack është bërë, ndoshta, i pari nga vala e re e rrjeteve të shërbimeve (service mesh). SmartStack formon një plan të kontrollit (control plane) rreth HAProxy ose NGINX, duke demonstruar mundësinë e lirshmërisë së planit të kontrollit (control plane) të rrjetit të shërbimit (service mesh) dhe planit të të dhënave (data plane).

Arkitektura mikroshërbimit me rrjetin e shërbimeve (service mesh) po tërheq gjithnjë e më shumë vëmendje (me të drejtë!), dhe gjithnjë e më shumë projekte dhe shitës po fillojnë të punojnë në këtë drejtim. Në vitet në vijim, ne do të shohim shumë inovacione si në planet e të dhënave (data plane) ashtu edhe në planet e kontrollit (control plane), si dhe përzierje të mëtejshme të komponentëve të ndryshëm. Në fund të fundit, arkitektura mikroshërbimit duhet të bëhet më e qartë dhe më magjike (?) për operatorin.
Shpresoj, gjithnjë e më pak e irrituar.

Pikat kryesore (Key takeaways)

• Rrjeti i shërbimeve (service mesh) përbëhet nga dy pjesë të ndryshme: plani i të dhënave (data plane) dhe plani i kontrollit (control plane). Të dy komponentët janë të domosdoshëm, dhe pa ta sistemi nuk do të funksionojë.
• Të gjithë janë të njohur me planin e kontrollit (control plane), dhe për momentin plani i kontrollit (control plane) mund të jeni ju!
• Të gjithë planet e të dhënave (data plane) konkurrojnë midis tyre për funksionalitet, performancë, konfigurueshmëri dhe zgjerueshmëri.
• Të gjithë planet e kontrollit (control plane) konkurrojnë midis tyre për funksionalitet, konfigurueshmëri, zgjerueshmëri dhe lehtësinë e përdorimit.
• Një plan kontrolli (control plane) mund të përmbajë abstraksionet dhe API-të e duhura, në mënyrë që të mundësojë përdorimin e disa planeve të të dhënave (data plane).

Burimi: habr.com