Bok, Habr! Predstavljam vam prijevod članka «Podaci servisne mreže naspram kontrolne mreže» autor Matt Klein.

Ovaj put sam "zaželeo i preveo" opis oba komponenta servisne mreže, data plane i control plane. Ovaj opis mi se učinio najjasnijim i najzanimljivijim, a najvažnije, dovodi do razumevanja „Da li je to uopšte potrebno?“.

Budući da je ideja "Servisne mreže (Service mesh)" postala sve popularnija tokom poslednje dve godine (Izvorni članak od 10. oktobra 2017.), a broj učesnika u ovom prostoru je porastao, primetio sam proporcionalan porast konfuzije među celokupnom tehničkom zajednicom u vezi s tim kako uporediti i suprotstaviti različita rešenja.

Situaciju najbolje opisuje nekoliko serija tvitova koje sam napisao u julu:

Konfuzija sa servisnom mrežom (service mesh) br. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Nijedna od njih nije jednaka Istio. Istio je nešto potpuno drugačije. 1 /

Prvi su samo data plane. Sami po sebi ne rade ništa. Moraju biti konfigurirani za nešto više. 2 /

Istio je primer kontrolne mreže (control plane) koja povezuje delove zajedno. To je drugi sloj. /kraj

U prethodnim tvitovima spominje se nekoliko različitih projekata (Linkerd, NGINX, HAProxy, Envoy i Istio), ali što je još važnije, uvode se opšti pojmovi data plane, servisne mreže i kontrolne mreže. U ovom postu ću se povući i objasniti šta mislim pod terminima „data plane“ i „control plane“ na veoma visokom nivou, a zatim objasniti kako se termini odnose na projekte spomenute u tvitovima.

Šta je zapravo servisna mreža (What is a service mesh, really)?

Slika 1: Pregled servisne mreže (Service mesh overview)

Slika 1 ilustrira koncept servisne mreže (service mesh) na najosnovnijem nivou. Postoje četiri klastera usluga (A-D). Svaki primerak usluge povezan je sa lokalnim proxy serverom. Sav mrežni saobraćaj (HTTP, REST, gRPC, Redis itd.) od pojedinačnog primerka aplikacije prolazi kroz lokalni proxy server do odgovarajućih spoljašnjih klastera usluga. Tako, primerak aplikacije ne zna za mrežu u celini i zna samo za svoj lokalni proxy. U suštini, mreža distribuiranog sistema je uklonjena od usluge.

Data plane

U servisnoj mreži (service mesh), lokalni proxy server za aplikaciju obavlja sledeće zadatke:

Otkrivanje usluga (Service discovery). Koje su usluge/aplikacije dostupne za vašu aplikaciju?
Provjera dostupnosti (Health checking). Jesu li instancije usluga koje se vraćaju putem otkrivanja usluga (service discovery) dostupne i spremne za primanje mrežnog prometa? To može uključivati aktivne (npr. provjeru odgovora / healthcheck) i pasivne (npr. korištenje 3 uzastopne 5xx pogreške kao indikacije nezdravog stanja usluge) provjere dostupnosti.
Usmjeravanje (Routing). Kada od usluge REST zatražite "\/foo", u koji servisni klaster treba poslati zahtjev?
Raspodjela opterećenja (Load balancing). Nakon što je tijekom usmjeravanja odabran klaster usluga, u koju instancu usluge treba poslati zahtjev? S kojim vremenskim ograničenjem? Sa kojim postavkama prekidača (circuit breaking)? Ako zahtjev ne uspije, treba li ga ponoviti?
Autentifikacija i autorizacija (Authentication and authorization). Mogu li se za dolazne zahtjeve pozivajuća usluga kriptografski identificirati/autorizirati pomoću mTLS-a ili nekog drugog mehanizma? Ako je identificirana/odobrena, je li joj dopušteno pozvati traženu operaciju (endpoint) u usluzi ili treba biti vraćen neautentificirani odgovor?
Promatranje (Observability). Za svaki zahtjev trebaju biti generirani detaljni statistički podaci, dnevnici/logovi i podaci o distribuiranom praćenju kako bi operatori mogli razumjeti distribuirani protok prometa i probleme s ispravljanjem grešaka dok se javljaju.

Za sve prethodne točke u mreži usluga (service mesh) odgovorna je podatkovna ravnina (data plane). U suštini, lokalni proxy za uslugu (sidecar) predstavlja podatkovnu ravninu (data plane). Drugim riječima, podatkovna ravnina (data plane) odgovara za uvjetnu translaciju, prosljeđivanje i praćenje svakog mrežnog paketa koji se šalje u uslugu ili iz nje.

Ravnina upravljanja (The control plane)

Mrežna apstrakcija koju pruža lokalni proxy u sloju podataka (data plane) je čudesna (?). Međutim, kako proxy server zapravo saznaje za rutu "/foo" prema usluzi B? Kako se podaci o otkrivanju usluga (service discovery) koji se pune proxy zahtevima mogu koristiti? Kako se postavljaju parametri balansiranja opterećenja, vremenskog ograničenja (timeout), prekida skupa (circuit breaking) itd.? Kako se vrši implementacija aplikacije korišćenjem plavog/zelenog (blue/green) metoda ili metode postepenog prebacivanja prometa? Tko postavlja parametre opće sistemske autentifikacije i autorizacije?

Sve navedene tačke su pod kontrolom sloja upravljanja (control plane) uslužne mreže (service mesh). Sloj upravljanja (control plane) prihvaća skup izolovanih proksi-poslužitelja bez stanja i pretvara ih u distribuirani sistem.

Mislim da je razlog zašto mnogi tehnolozi smatraju podeljene pojmove sloja podataka (data plane) i sloja upravljanja (control plane) zbunjujućim to što je sloj podataka poznat većini ljudi, dok je sloj upravljanja stran i/neobičan. Već dugo radimo s fizičkim mrežnim usmjerivačima i prekidačima. Razumemo da paketi/zahtjevi moraju ići od tačke A do tačke B i da možemo koristiti hardver i softver za to. Nova generacija softverskih proksija su jednostavno modernije verzije alata koje koristimo već dugo vremena.

Slika 2: Ljudski sloj upravljanja (Human control plane)

Međutim, već dugo koristimo slojeve upravljanja (control plane), iako većina mrežnih operatera možda ne povezuje ovaj deo sistema s bilo kojim tehnološkim komponentom. Razlog je jednostavan:
Većina danas korišćenih slojeva upravljanja (control plane) -to smo mi.

Na na slici 2 Prikazano je ono što nazivam 'Ljudskom ravninom kontrole (Human control plane)'. U ovom tipu implementacije, koji se još uvijek vrlo često susreće, ljudski operater, vjerojatno mrzovoljan, stvara statičke konfiguracije — potencijalno, uz pomoć skripti — i implementira ih putem nekog specijalnog procesa na svim proxy poslužiteljima. Zatim proxy početni koriste ovu konfiguraciju i počinju obrađivati ravninu podataka (data plane) koristeći ažurirane postavke.

Slika 3: Proširena ravnina kontrole uslužne mreže (Advanced service mesh control plane)

Na slika 3 prikazana je 'proširena' ravnina kontrole (control plane) uslužne mreže (service mesh). Sastoji se od sljedećih dijelova:

Čovjek (The human): I dalje postoji čovjek (nadam se, manje ljut), koji donosi odluke na visokom nivou u vezi cijelog sustava u cjelini.
Korisničko sučelje ravnine kontrole (Control plane UI): Čovjek se povezuje s nekim oblikom korisničkog sučelja za upravljanje sustavom. To može biti web portal, aplikacija za upravljanje putem naredbenog retka (CLI) ili neki drugi sučelje. Uz pomoć korisničkog sučelja, operater ima pristup globalnim konfiguracijskim parametrima sustava, kao što su:
- Upravljanje implementacijom, plavo/zeleno (blue/green) i/ili postepeno preusmjeravanje prometa
- Parametri autentifikacije i autorizacije
- Specifikacije tablice usmjeravanja, na primjer, što se događa kada aplikacija A zatraži informacije o '/foo'
- Postavke balansiranja opterećenja, kao što su tajmeri (timeouts), ponovni pokušaji (retries), parametri prekidači krugova (circuit breaking) itd.
Planer radnog opterećenja (Workload scheduler): Usluge se pokreću u infrastrukturi putem sustava planiranja/orchestracije određenog tipa, na primjer, Kubernetes ili Nomad. Planer je odgovoran za pokretanje usluge zajedno s njenim lokalnim proxy poslužiteljem.
Otkrivanje usluga (Service discovery). Kada planer pokrene i zaustavi instance usluge, javlja stanje radne sposobnosti sustavu za otkrivanje usluga.
API konfiguracije lokalnog proxy poslužitelja (Sidecar proxy configuration APIs) : Lokalne proxy-serveri dinamički izvode stanje iz različitih komponenti sustava prema modelu „konačne dosljednosti” bez sudjelovanja operatera. Cjeli sustav, koji se sastoji od svih trenutno pokrenutih instanci usluga i lokalnih proxy-servera, na kraju se usklađuje u jedan ekosustav. API univerzalne ravnine podataka (data plane) u Envoyu jedan je od primjera kako to funkcionira u praksi.

U suštini, cilj ravnine upravljanja (control plane) je uspostaviti politiku koja će konačno biti prihvaćena od strane ravnine podataka (data plane). Naprednije ravnine upravljanja (control plane) uklanjaju više detalja o nekim sustavima od operatera i zahtijevaju manje ručnog upravljanja, pod uvjetom da rade ispravno!..

Ravnina podataka i ravnina upravljanja. Sažetak (Data plane vs. control plane summary)

Ravnina podataka servisne mreže (Service mesh data plane): obuhvaća svaki paket / zahtjev u sustavu. Odgovorna je za otkrivanje aplikacija / usluga, provjeru radne sposobnosti, usmjeravanje, raspodjelu opterećenja, autentifikaciju / autorizaciju i praćenje.
Ravnina upravljanja servisne mreže (Service mesh control plane): pruža politiku i konfiguraciju za sve aktivne ravnine podataka unutar servisne mreže. Ne dodiruje nijedan paket / zahtjev u sustavu. Ravnina upravljanja pretvara sve ravnine podataka u distribuirani sustav.

Trenutno stanje projekta (Current project landscape)

Razjasnivši objašnjenje iznad, pogledajmo trenutno stanje projekta „servisne mreže (service mesh).

Ravnoteže podataka (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
Ravnoteže upravljanja (Control planes): Istio, Nelson, SmartStack

Umjesto da provodim temeljitu analizu svake od gore navedenih rješenja, ukratko ću se osvrnuti na nekoliko točaka koje, po mom mišljenju, izazivaju najveću zabunu u ekosustavu upravo sada.

Početkom 2016. godine, Linkerd je bio jedan od prvih proxy poslužitelja podatkovne ravnine (data plane) za servisne mreže (service mesh) i napravio je fantastičan posao u podizanju svijesti i povećanju pažnje na model dizajniranja "servisna mreža" (service mesh). Otprilike šest mjeseci kasnije, Envoy se pridružio Linkerd-u (iako je radio u Lyft-u od kraja 2015. godine). Linkerd i Envoy su dva projekta koja se najčešće spominju u raspravama o servisnim mrežama (service mesh).

Istio je proglašeno u svibnju 2017. godine. Ciljevi Istio projekta vrlo su slični proširenoj ravnini upravljanja (control plane) prikazanoj na slika 3. Envoy za Istio je proxy "po defaultu". Tako je Istio ravnina upravljanja (control plane), dok je Envoy podatkovna ravnina (data plane). U kratkom vremenu, Istio je izazvalo puno uzbuđenja, a druge podatkovne ravnine (data plane) su počele integraciju kao zamjenu za Envoy (i Linkerd i NGINX su pokazali integraciju s Istio). Činjenica da se u jednoj ravnini upravljanja (control plane) mogu koristiti različite podatkovne ravnine (data plane) znači da ravnina upravljanja (control plane) i podatkovna ravnina (data plane) nisu nužno usko povezane. Takav API kao univerzalni API podatkovne ravnine (data plane) Envoy može stvoriti most između dva dijela sustava.

Nelson i SmartStack dodatno pomažu ilustrirati razdvajanje ravnine upravljanja (control plane) i podatkovne ravnine (data plane). Nelson koristi Envoy kao svoj proxy i gradi pouzdanu ravninu upravljanja (control plane) za servisnu mrežu (service mesh) na bazi HashiCorp stoga, tj. Nomad itd. SmartStack postao je, možda, prvi iz novog vala servisnih mreža (service mesh). SmartStack oblikuje ravninu upravljanja (control plane) oko HAProxy ili NGINX, pokazujući mogućnost odvajanja ravnine upravljanja (control plane) od servisne mreže (service mesh) i podatkovne ravnine (data plane).

Mikroservisna arhitektura s mrežom usluga (service mesh) privlači sve više pažnje (to je ispravno!), a sve više projekata i dobavljača počinje raditi u tom smjeru. U sljedećih nekoliko godina vidjet ćemo mnogo inovacija kako u plohama podataka (data plane), tako i u plohama upravljanja (control plane), kao i daljnje miješanje različitih komponenti. Na kraju, mikroservisna arhitektura trebala bi postati transparentnija i čarobnija (?) za operatore.
Nadam se da smo svi sve manje iritirani.

Ključne točke (Key takeaways)

Mreža usluga (service mesh) sastoji se od dva različita dijela: plohe podataka (data plane) i plohe upravljanja (control plane). Oba komponenta su obavezna i bez njih sustav neće raditi.
Svi ste upoznati s plohom upravljanja (control plane), a trenutno možete biti ploha upravljanja (control plane) vi!
Sve plohe podataka (data plane) natječu se međusobno po funkcijama, performansama, konfigurabilnosti i skalabilnosti.
Sve plohe upravljanja (control plane) natječu se međusobno po funkcijama, konfigurabilnosti, skalabilnosti i lakoći korištenja.
Jedna ploha upravljanja (control plane) može sadržavati ispravne apstrakcije i API-je, kako bi se mogle koristiti višestruke plohe podataka (data plane).

Izvor: habr.com