Hej Habr! Predstavljam vam prevod članka "Podatkovna ravnina storitvene mreže proti nadzorni ravnini" avtor Matt Klein.

Tokrat sem “zaželel in prevedel” opis obeh komponent servisne mreže, podatkovne ravnine in nadzorne ravnine. Ta opis se mi je zdel najbolj razumljiv in zanimiv, in kar je najpomembneje, vodil do razumevanja "Ali je to sploh potrebno?"

Ker je ideja o "Service mesh" v zadnjih dveh letih postala vse bolj priljubljena (Izvirni članek 10. oktober 2017) in se je število udeležencev v prostoru povečalo, sem opazil sorazmerno povečanje zmede med celotno tehnološke skupnosti o tem, kako primerjati in primerjati različne rešitve.

Situacijo najbolje povzame naslednja serija tvitov, ki sem jih napisal julija:

Zmeda storitvenega omrežja #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Nobeden od njih ni enak Istiu. Istio je nekaj povsem drugega. 1 /

Prvi so preprosto podatkovne ravnine. Sami po sebi ne naredijo ničesar. Morajo biti razpoloženi za nekaj več. 2/

Istio je primer nadzorne ravnine, ki povezuje dele skupaj. To je druga plast. /konec

Prejšnji tviti omenjajo več različnih projektov (Linkerd, NGINX, HAProxy, Envoy in Istio), še pomembneje pa predstavljajo splošne koncepte podatkovne ravnine, storitvene mreže in nadzorne ravnine. V tej objavi bom stopil korak nazaj in govoril o tem, kaj mislim z izrazoma "podatkovna ravnina" in "nadzorna ravnina" na zelo visoki ravni, nato pa govoril o tem, kako se izrazi nanašajo na projekte, omenjene v tvitih.

Kaj je v resnici servisna mreža?

Slika 1: Pregled servisne mreže

Slika 1 ponazarja koncept storitvene mreže na najosnovnejši ravni. Obstajajo štiri storitvene gruče (AD). Vsak primerek storitve je povezan z lokalnim strežnikom proxy. Ves omrežni promet (HTTP, REST, gRPC, Redis itd.) iz ene instance aplikacije se prek lokalnega proxyja prenese v ustrezne zunanje storitvene gruče. Na ta način se primerek aplikacije ne zaveda omrežja kot celote in se zaveda samo svojega lokalnega posrednika. Dejansko je bilo omrežje porazdeljenega sistema odstranjeno iz storitve.

Podatkovna ravnina

V storitveni mreži proxy strežnik, ki se nahaja lokalno za aplikacijo, izvaja naslednje naloge:

• Odkrivanje storitve. Katere storitve/aplikacije so na voljo za vašo aplikacijo?
• Zdravstveni pregled. Ali so primerki storitve, vrnjeni z odkrivanjem storitve, zdravi in ​​pripravljeni na sprejem omrežnega prometa? To lahko vključuje aktivne (npr. odziv/zdravstveni pregled) in pasivne (npr. uporaba 3 zaporednih napak 5xx kot znak nezdravega stanja storitve) zdravstvene preglede.
• Usmerjanje. Ko prejmete zahtevo za "/foo" od storitve REST, kateri gruči storitev naj se pošlje zahteva?
• Izravnavanje obremenitve. Ko je med usmerjanjem izbrana storitvena gruča, kateremu primerku storitve naj se pošlje zahteva? S kakšno časovno omejitvijo? S kakšnimi nastavitvami prekinitve tokokroga? Če zahteva ne uspe, ali je treba poskusiti znova?
• Avtentikacija in avtorizacija. Ali je za dohodne zahteve mogoče klicno storitev kriptografsko identificirati/avtorizirati z uporabo mTLS ali kakšnega drugega mehanizma? Če je prepoznana/pooblaščena, ali je dovoljeno poklicati zahtevano operacijo (končno točko) v storitvi ali naj se vrne neoverjen odgovor?
• Opazljivost. Za vsako zahtevo je treba ustvariti podrobno statistiko, dnevnike/dnevnike in porazdeljene podatke o sledenju, tako da lahko operaterji razumejo porazdeljen tok prometa in težave z odpravljanjem napak, ko se pojavijo.

Podatkovna ravnina je odgovorna za vse prejšnje točke v servisni mreži. Pravzaprav je proxy, lokalni za storitev (sidecar), podatkovna ravnina. Z drugimi besedami, podatkovna ravnina je odgovorna za pogojno oddajanje, posredovanje in spremljanje vsakega omrežnega paketa, ki je poslan storitvi ali iz nje.

Nadzorna ravnina

Omrežna abstrakcija, ki jo lokalni proxy zagotavlja v podatkovni ravnini, je čarobna (?). Vendar, kako proxy dejansko ve za pot "/foo" do storitve B? Kako se lahko uporabijo podatki o odkrivanju storitve, ki jih zapolnijo zahteve proxy? Kako so konfigurirani parametri za uravnoteženje obremenitve, časovno omejitev, prekinitev tokokroga itd.? Kako uvedete aplikacijo z uporabo modro/zelene metode ali metode gracioznega prehoda prometa? Kdo konfigurira sistemske nastavitve preverjanja pristnosti in avtorizacije?

Vsi zgoraj navedeni elementi so pod nadzorom nadzorne ravnine servisne mreže. Nadzorna ravnina vzame nabor izoliranih posrednikov brez stanja in jih spremeni v porazdeljen sistem.

Menim, da je razlog, zakaj se mnogim tehnologom zdita ločena koncepta podatkovne ravnine in nadzorne ravnine zmedena, ta, da je večini ljudi podatkovna ravnina znana, medtem ko je nadzorna ravnina tuja/nerazumljena. S fizičnimi omrežnimi usmerjevalniki in stikali delamo že dolgo časa. Zavedamo se, da morajo paketi/zahteve iti od točke A do točke B in da lahko za to uporabimo strojno in programsko opremo. Nova generacija programskih posrednikov je preprosto modna različica orodij, ki jih uporabljamo že dolgo.

Slika 2: Krmilna ravnina človeka

Vendar že dolgo uporabljamo nadzorne ravnine, čeprav večina omrežnih operaterjev morda ne povezuje tega dela sistema z nobeno tehnološko komponento. Razlog je preprost:
Večina kontrolnih letal, ki so danes v uporabi, smo... mi.

Na Slika 2 prikazuje tisto, čemur jaz pravim »človeško nadzorno letalo«. Pri tej vrsti uvajanja, ki je še vedno zelo pogosta, verjetno zlovoljni človeški operater ustvari statične konfiguracije - potencialno prek skriptov - in jih prek nekega posebnega postopka uvede v vse strežnike proxy. Proxy nato začnejo uporabljati to konfiguracijo in začnejo obdelovati podatkovno ravnino s posodobljenimi nastavitvami.

Slika 3: Nadzorna ravnina napredne servisne mreže

Na Slika 3 prikazuje "razširjeno" nadzorno ravnino servisne mreže. Sestavljen je iz naslednjih delov:

• Človeško: Še vedno obstaja oseba (upam, da manj jezna), ki sprejema odločitve na visoki ravni glede celotnega sistema kot celote.
• Uporabniški vmesnik nadzorne ravnine: oseba komunicira z neko vrsto uporabniškega vmesnika za nadzor sistema. To je lahko spletni portal, aplikacija ukazne vrstice (CLI) ali kakšen drug vmesnik. Z uporabo uporabniškega vmesnika ima operater dostop do globalnih konfiguracijskih parametrov sistema, kot so:
  • Nadzor uvajanja, modro/zeleno in/ali postopen prometni prehod
  • Možnosti avtentikacije in avtorizacije
  • Specifikacije usmerjevalne tabele, na primer, ko aplikacija A zahteva informacije o "/foo", kaj se zgodi
  • Nastavitve izravnalnika obremenitve, kot so časovne omejitve, ponovni poskusi, nastavitve prekinitve tokokroga itd.
• Razporejevalnik delovne obremenitve: Storitve se izvajajo na infrastrukturi prek neke vrste sistema za razporejanje/orkestracijo, kot sta Kubernetes ali Nomad. Razporejevalnik je odgovoren za nalaganje storitve skupaj z njenim lokalnim posrednikom.
• Odkrivanje storitve. Ko razporejevalnik zažene in ustavi primerke storitve, sporoči zdravstveno stanje sistemu za odkrivanje storitev.
• API-ji za konfiguracijo proxy Sidecar : Lokalni posredniki dinamično izvlečejo stanje iz različnih sistemskih komponent z uporabo končno konsistentnega modela brez posredovanja operaterja. Celoten sistem, ki ga sestavljajo vse trenutno delujoče storitvene instance in lokalni proxy strežniki, se končno združi v en ekosistem. API univerzalne podatkovne ravnine Envoy je en primer, kako to deluje v praksi.

V bistvu je namen nadzorne ravnine nastaviti politiko, ki jo bo na koncu sprejela podatkovna ravnina. Naprednejša krmilna letala bodo operaterju odstranila več delov nekaterih sistemov in zahtevala manj ročnega upravljanja, pod pogojem, da delujejo pravilno!...

Podatkovna ravnina in nadzorna ravnina. Povzetek podatkovne ravnine proti nadzorni ravnini

• Podatkovna ravnina servisne mreže: Vpliva na vsak paket/zahtevo v sistemu. Odgovoren za odkrivanje aplikacij/storitev, preverjanje stanja, usmerjanje, uravnoteženje obremenitve, avtentikacijo/avtorizacijo in opazljivost.
• Krmilna ravnina servisne mreže: Zagotavlja politiko in konfiguracijo za vse tekoče podatkovne ravnine znotraj storitvenega omrežja. Ne dotika se nobenih paketov/zahtev v sistemu. Nadzorna ravnina spremeni vse podatkovne ravnine v porazdeljen sistem.

Trenutna pokrajina projekta

Ko smo razumeli zgornjo razlago, si poglejmo trenutno stanje storitvenega mrežnega projekta.

• Podatkovne ravnine: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Nadzorna letala: Istio, Nelson, SmartStack

Namesto da bi se lotil poglobljene analize vsake od zgornjih rešitev, bom na kratko obravnaval nekatere točke, za katere menim, da trenutno povzročajo veliko zmede v ekosistemu.

Linkerd je bil v začetku leta 2016 eden prvih posredniških strežnikov podatkovne ravnine za storitveno mrežo in je opravil fantastično delo pri ozaveščanju in povečanju pozornosti na modelu storitvene mreže. Približno 6 mesecev po tem se je Envoy pridružil Linkerdu (čeprav je bil pri Lyftu od konca leta 2015). Linkerd in Envoy sta dva projekta, ki se najpogosteje omenjata pri razpravah o servisnih mrežah.

Istio je bil objavljen maja 2017. Cilji projekta Istio so zelo podobni razširjeni nadzorni ravnini, prikazani v Slika 3. Envoy za Istio je privzeti proxy. Tako je Istio nadzorna ravnina, Envoy pa podatkovna ravnina. V kratkem času je Istio požel veliko navdušenja in druge podatkovne ravnine so se začele integrirati kot zamenjava za Envoy (tako, Linkerd kot NGINX sta pokazala integracijo z Istio). Dejstvo, da se znotraj iste nadzorne ravnine lahko uporabljajo različne podatkovne ravnine, pomeni, da nadzorna in podatkovna ravnina nista nujno tesno povezani. API, kot je generični API podatkovne ravnine podjetja Envoy, lahko tvori most med dvema deloma sistema.

Nelson in SmartStack pomagata nadalje ponazoriti ločitev nadzorne ravnine in podatkovne ravnine. Nelson uporablja Envoy kot svoj proxy in zgradi zanesljivo nadzorno ravnino za storitveno mrežo, ki temelji na skladu HashiCorp, tj. Nomad itd. SmartStack je bil morda prvi v novem valu storitvenih mrež. SmartStack zgradi nadzorno ravnino okoli HAProxy ali NGINX, s čimer dokazuje zmožnost ločevanja nadzorne ravnine od storitvene mreže od podatkovne ravnine.

Mikrostoritvena arhitektura s servisno mrežo (service mesh) dobiva vedno več pozornosti (upravičeno!), vse več projektov in prodajalcev pa začenja delovati v tej smeri. V naslednjih nekaj letih bomo priča številnim inovacijam tako na podatkovni ravni kot na ravni nadzora, pa tudi nadaljnjemu mešanju različnih komponent. Navsezadnje bi morala arhitektura mikrostoritev postati bolj pregledna in čarobna (?) za operaterja.
Upajmo, da vedno manj razdraženi.

Ključni povzetki

• Storitvena mreža je sestavljena iz dveh različnih delov: podatkovne ravnine in nadzorne ravnine. Obe komponenti sta potrebni in brez njiju sistem ne bo deloval.
• Vsi poznajo kontrolno ravnino in na tej točki ste lahko kontrolna ravnina vi!
• Vse podatkovne ravni tekmujejo med seboj glede funkcij, zmogljivosti, nastavljivosti in razširljivosti.
• Vse nadzorne ravni tekmujejo med seboj v funkcijah, konfigurabilnosti, razširljivosti in enostavnosti uporabe.
• Ena nadzorna ravnina lahko vsebuje prave abstrakcije in API-je, tako da je mogoče uporabiti več podatkovnih ravnin.

Vir: www.habr.com