Čau Habr! Do pozornosti dávam preklad článku autora Matt Klein.
Tentokrát som „chcel a preložil“ popis oboch komponentov siete, dátovej roviny a riadiacej roviny. Tento popis sa mi zdal najzrozumiteľnejší a najzaujímavejší, a čo je najdôležitejšie, vedie k pochopeniu „Je to vôbec potrebné?
Keďže myšlienka „Service mesh“ sa za posledné dva roky stala čoraz populárnejšou (Pôvodný článok 10. októbra 2017) a počet účastníkov v priestore sa zvýšil, zaznamenal som úmerný nárast zmätku medzi celým technickú komunitu o tom, ako porovnávať a porovnávať rôzne riešenia.
Situáciu najlepšie vystihuje nasledujúca séria tweetov, ktoré som napísal v júli:
Service mesh zmätok #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Nikto z nich sa Istiovi nevyrovná. Istio je niečo úplne iné. 1 /
Prvým sú jednoducho dátové roviny. Sami od seba nerobia nič. Musia mať náladu na niečo viac. 2/
Istio je príkladom riadiacej roviny, ktorá spája časti dohromady. Toto je ďalšia vrstva. /koniec
Predchádzajúce tweety spomínajú niekoľko rôznych projektov (Linkerd, NGINX, HAProxy, Envoy a Istio), ale čo je dôležitejšie, predstavujú všeobecné koncepty dátovej roviny, servisnej siete a riadiacej roviny. V tomto príspevku urobím krok späť a porozprávam o tom, čo myslím pod pojmami „údajová rovina“ a „riadiaca rovina“ na veľmi vysokej úrovni, a potom porozprávam o tom, ako sa výrazy vzťahujú na projekty uvedené v tweetoch.
Čo je to vlastne servisná sieť?
Obrázok 1: Prehľad servisnej siete
Obrázok 1 ilustruje koncepciu siete služieb na jej najzákladnejšej úrovni. Existujú štyri klastre služieb (AD). Každá inštancia služby je spojená s lokálnym proxy serverom. Všetka sieťová prevádzka (HTTP, REST, gRPC, Redis atď.) z jednej inštancie aplikácie prechádza cez lokálny proxy do príslušných klastrov externých služieb. Týmto spôsobom inštancia aplikácie nepozná sieť ako celok a pozná iba svoj lokálny proxy. V skutočnosti bola sieť distribuovaného systému odstránená zo služby.
Dátová rovina
V servisnej sieti proxy server umiestnený lokálne pre aplikáciu vykonáva tieto úlohy:
- Objavenie služby. Aké služby/aplikácie sú dostupné pre vašu aplikáciu?
- Kontrola zdravotného stavu. Sú inštancie služby vrátené zisťovaním služby zdravé a pripravené prijať sieťovú prevádzku? To môže zahŕňať aktívne (napr. odozva/kontrola stavu) aj pasívne (napr. použitie 3 po sebe idúcich chýb 5xx ako indikácie nezdravého stavu služby).
- Smerovanie. Pri prijatí požiadavky na „/foo“ zo služby REST, na ktorý klaster služieb sa má požiadavka odoslať?
- Rozdelenie výkonu. Po vybratí klastra služieb počas smerovania, do ktorej inštancie služby sa má odoslať požiadavka? S akým časovým limitom? S akými nastaveniami vypínania? Ak žiadosť zlyhá, treba ju zopakovať?
- Autentifikácia a autorizácia. Môže byť volacia služba pre prichádzajúce požiadavky kryptograficky identifikovaná/autorizovaná pomocou mTLS alebo iného mechanizmu? Ak je rozpoznaný/autorizovaný, je povolené volať požadovanú operáciu (koncový bod) v službe alebo by sa mala vrátiť neoverená odpoveď?
- Pozorovateľnosť. Pre každú požiadavku by sa mali generovať podrobné štatistiky, protokoly/protokoly a distribuované údaje sledovania, aby operátori mohli pochopiť distribuovaný tok prevádzky a problémy s ladením, keď sa vyskytnú.
Dátová rovina je zodpovedná za všetky predchádzajúce body v servisnej sieti. V skutočnosti je lokálnym proxy serverom pre službu (sidecar) dátová rovina. Inými slovami, dátová rovina je zodpovedná za podmienené vysielanie, preposielanie a monitorovanie každého sieťového paketu, ktorý je odoslaný do alebo zo služby.
Riadiaca rovina
Sieťová abstrakcia, ktorú poskytuje lokálny proxy v dátovej rovine, je magická(?). Ako však proxy skutočne vie o ceste „/foo“ k službe B? Ako možno použiť údaje zisťovania služby, ktoré sú vyplnené požiadavkami proxy? Ako sú nakonfigurované parametre pre vyrovnávanie záťaže, časový limit, prerušenie obvodu atď.? Ako nasadíte aplikáciu pomocou modrej/zelenej metódy alebo metódy elegantného prechodu premávky? Kto konfiguruje nastavenia autentifikácie a autorizácie v celom systéme?
Všetky vyššie uvedené položky sú pod kontrolou riadiacej roviny servisnej siete. Riadiaca rovina berie súbor izolovaných bezstavových proxy a mení ich na distribuovaný systém.
Myslím si, že dôvod, prečo mnohí technológovia považujú samostatné koncepty dátovej roviny a riadiacej roviny za mätúce, je ten, že pre väčšinu ľudí je dátová rovina známa, zatiaľ čo riadiaca rovina je cudzia/nepochopená. S fyzickými sieťovými smerovačmi a prepínačmi pracujeme už dlho. Chápeme, že pakety/požiadavky musia ísť z bodu A do bodu B a že na to môžeme použiť hardvér a softvér. Nová generácia softvérových proxy serverov sú jednoducho vymyslené verzie nástrojov, ktoré používame už dlho.
Obrázok 2: Rovina ovládania človeka
Riadiace roviny však používame už dlho, aj keď väčšina prevádzkovateľov sietí nemusí túto časť systému spájať so žiadnym technologickým komponentom. Dôvod je jednoduchý:
Väčšina riadiacich lietadiel, ktoré sa dnes používajú, sme... my.
Na Obrázok 2 ukazuje to, čo nazývam „rovina riadenia človeka“. Pri tomto type nasadenia, ktoré je stále veľmi bežné, pravdepodobne nevrlý ľudský operátor vytvára statické konfigurácie - potenciálne prostredníctvom skriptov - a nasadzuje ich pomocou nejakého špeciálneho procesu na všetky servery proxy. Proxy potom začnú používať túto konfiguráciu a začnú spracovávať dátovú rovinu pomocou aktualizovaných nastavení.
Obrázok 3: Pokročilá riadiaca rovina servisnej siete
Na Obrázok 3 ukazuje „predĺženú“ riadiacu rovinu servisnej siete. Pozostáva z nasledujúcich častí:
- Človek: Stále existuje osoba (dúfajme, že menej nahnevaná), ktorá robí rozhodnutia na vysokej úrovni týkajúce sa celého systému ako celku.
- Ovládacia rovina UI: Osoba komunikuje s určitým typom používateľského rozhrania na ovládanie systému. Môže to byť webový portál, aplikácia príkazového riadka (CLI) alebo nejaké iné rozhranie. Pomocou používateľského rozhrania má operátor prístup ku globálnym parametrom konfigurácie systému, ako sú:
- Riadenie rozmiestnenia, modrá/zelená a/alebo postupný prechod premávky
- Možnosti autentizácie a autorizácie
- Špecifikácie smerovacej tabuľky, napríklad keď aplikácia A požaduje informácie o tom, čo sa stane "/foo".
- Nastavenia vyrovnávača záťaže, ako sú časové limity, opakované pokusy, nastavenia prerušenia obvodu atď.
- Plánovač pracovného zaťaženia: Služby sú spustené na infraštruktúre prostredníctvom určitého typu plánovacieho/orchestračného systému, ako je Kubernetes alebo Nomad. Plánovač je zodpovedný za načítanie služby spolu s jej lokálnym proxy.
- Objavenie služby. Keď plánovač spustí a zastaví inštancie služby, nahlási zdravotný stav systému zisťovania služieb.
- Rozhrania API na konfiguráciu servera proxy postranného vozíka : Lokálne servery proxy dynamicky extrahujú stav z rôznych komponentov systému pomocou prípadne konzistentného modelu bez zásahu operátora. Celý systém, pozostávajúci zo všetkých aktuálne spustených inštancií služieb a lokálnych proxy serverov, sa nakoniec zbieha do jedného ekosystému. Envoy's universal data plane API je jedným z príkladov toho, ako to funguje v praxi.
Účelom riadiacej roviny je v podstate nastaviť politiku, ktorá bude v konečnom dôsledku akceptovaná dátovou rovinou. Pokročilejšie ovládacie roviny odstránia z operátora viac častí niektorých systémov a vyžadujú menej manuálnej obsluhy za predpokladu, že fungujú správne!...
Údajová rovina a riadiaca rovina. Súhrn dátovej roviny vs. kontrolnej roviny
- Servisná dátová rovina siete: Ovplyvňuje každý paket/požiadavku v systéme. Zodpovedá za zisťovanie aplikácií/služieb, kontrolu stavu, smerovanie, vyrovnávanie záťaže, autentifikáciu/autorizáciu a pozorovateľnosť.
- Riadiaca rovina servisnej siete: Poskytuje politiku a konfiguráciu pre všetky spustené dátové roviny v rámci servisnej siete. Nedotýka sa žiadnych balíkov/žiadostí v systéme. Riadiaca rovina premení všetky dátové roviny na distribuovaný systém.
Súčasný projektový priestor
Po pochopení vyššie uvedeného vysvetlenia sa pozrime na súčasný stav projektu service mesh.
- Dátové roviny: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Riadiace lietadlá: Istio, Nelson, SmartStack
Namiesto toho, aby som sa pustil do hĺbkovej analýzy každého z vyššie uvedených riešení, stručne sa budem venovať niektorým bodom, o ktorých si myslím, že práve teraz spôsobujú veľa zmätku v ekosystéme.
Linkerd bol začiatkom roka 2016 jedným z prvých proxy serverov dátovej roviny pre sieť služieb a odviedol fantastickú prácu pri zvyšovaní povedomia a pozornosti k modelu dizajnu siete služieb. Asi 6 mesiacov po tom sa Envoy pripojil k Linkerd (hoci bol v Lyft od konca roku 2015). Linkerd a Envoy sú dva projekty, ktoré sa najčastejšie spomínajú pri diskusii o servisných sieťach.
Istio bol ohlásený v máji 2017. Ciele projektu Istio sú veľmi podobné rozšírenej riadiacej rovine zobrazenej v Obrázok 3. Envoy for Istio je predvolený proxy server. Istio je teda riadiaca rovina a Envoy je dátová rovina. V krátkom čase Istio vyvolalo veľa vzrušenia a ďalšie dátové roviny sa začali integrovať ako náhrada za Envoy (Linkerd aj NGINX demonštrovali integráciu s Istio). Skutočnosť, že rôzne dátové roviny môžu byť použité v rámci tej istej riadiacej roviny znamená, že riadiaca rovina a dátová rovina nie sú nevyhnutne pevne spojené. Rozhranie API, ako je generické rozhranie API pre dátovú rovinu Envoy, môže tvoriť most medzi dvoma časťami systému.
Nelson a SmartStack pomáhajú ďalej ilustrovať oddelenie riadiacej roviny a dátovej roviny. Nelson používa Envoy ako svojho proxy a vytvára spoľahlivú riadiacu rovinu pre sieť služieb založenú na zásobníku HashiCorp, t.j. Nomád atď. SmartStack bol možno prvým z novej vlny servisných sietí. SmartStack vytvára riadiacu rovinu okolo HAProxy alebo NGINX, čím demonštruje schopnosť oddeliť riadiacu rovinu od servisnej siete od dátovej roviny.
Architektúra mikroservisov so sieťou služieb si získava čoraz väčšiu pozornosť (právom!) a týmto smerom začína pracovať čoraz viac projektov a predajcov. V priebehu niekoľkých nasledujúcich rokov uvidíme veľa inovácií v dátovej aj riadiacej rovine, ako aj ďalšie miešanie rôznych komponentov. V konečnom dôsledku by sa architektúra mikroslužieb mala stať pre operátora transparentnejšou a magickou (?).
Dúfajme, že menej a menej podráždený.
Kľúčové veci
- Servisná sieť pozostáva z dvoch rôznych častí: dátovej roviny a riadiacej roviny. Obidve komponenty sú potrebné a bez nich systém nebude fungovať.
- Každý je oboznámený s riadiacou rovinou a v tomto bode by ste ňou mohli byť vy!
- Všetky dátové roviny si navzájom konkurujú vo funkciách, výkone, konfigurovateľnosti a rozšíriteľnosti.
- Všetky riadiace roviny si navzájom konkurujú vo funkciách, konfigurovateľnosti, rozšíriteľnosti a jednoduchosti použitia.
- Jedna riadiaca rovina môže obsahovať správne abstrakcie a API, takže je možné použiť viacero dátových rovín.
Zdroj: hab.com