Ahoj, Habr! Predstavujem vám preklad článku „Service mesh data plane vs control plane“ autora Matt Klein.

Tentoraz som si „zapotreboval a preložil“ popis oboch komponentov service mesh, plochy údajov a plochy riadenia. Tento popis mi prišiel najzrozumiteľnejší a najzaujímavejší a hlavne priviedol k otázke „Je to vôbec potrebné?“

Keďže sa nápad „Služobnej siete (Service mesh)“ stáva čoraz populárnejším posledné dva roky (Pôvodný článok z 10. októbra 2017), a počet účastníkov v tomto priestore sa zvýšil, videl som úmerný rast zmätku v celom technickom spoločenstve ohľadom toho, ako porovnávať a kontrastovať rôzne riešenia.

Situáciu najlepšie opisujú nasledujúce série tweetov, ktoré som napísal v júli:

Zamieňanie so služobnou sieťou (service mesh) č. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Žiadny z nich nie je rovný Istio. Istio je úplne niečo iné. 1 /

Prvé sú len plochy údajov (data planes). Samé o sebe nič nerobia. Musia byť nastavené na niečo väčšie. 2 /

Istio je príklad plochy riadenia (control plane), ktorá spája časti dohromady. To je iná vrstva. /koniec

V predchádzajúcich tweetoch sa spomínajú niekoľko rôznych projektov (Linkerd, NGINX, HAProxy, Envoy a Istio), ale, čo je dôležitejšie, zavádzajú sa spoločné pojmy plochy údajov (data plane), služobnej siete (service mesh) a plochy riadenia (control plane). V tomto príspevku urobím krok späť a poviem, čo mám na mysli pod pojmami „plocha údajov (data plane)“ a „plocha riadenia (control plane)“ na veľmi vysokej úrovni, a potom poviem, ako sa pojmy týkajú projektov zmienených v tweetoch.

Čo je vlastne služobná sieť (What is a service mesh, really)?

Obrázok 1: Prehľad služobnej siete (Service mesh overview)

Obrázok 1 ilustruje koncept služobnej siete (service mesh) na najzákladnejšej úrovni. Existujú štyri služobné klastre (A-D). Každý príklad služby je spojený s lokálnym proxy serverom. Celý sieťový prenos (HTTP, REST, gRPC, Redis atď.) z jednotlivého príkladu aplikácie prechádza cez lokálny proxy server do príslušných externých služobných klastrov. Takto príklad aplikácie nevie o celej sieti a vie len o svojom lokálnom proxy. V skutočnosti bola sieť distribuovaného systému odstránená od služby.

Plocha údajov (Data plane)

V servisnej sieti (service mesh) proxy server, umiestnený lokálne pre aplikáciu, vykonáva nasledujúce úlohy:

• Objavovanie služieb (Service discovery). Aké služby/aplikácie sú dostupné pre vašu aplikáciu?
• Kontrola zdravotného stavu (Health checking). Sú inštancie služieb, ktoré vrátilo objavovanie služieb (service discovery), funkčné a pripravené prijímať sieťovú prevádzku? To môže zahŕňať aktívne (napríklad kontrola odpovede / healthcheck) aj pasívne (napríklad s použitím 3 po sebe idúcich 5xx chýb ako indikácie nezdravého stavu služby) overovanie funkčnosti.
• Smerovanie (Routing). Po obdržaní REST požiadavky na „/foo“, do ktorého servisného klastru by sa mala odoslať požiadavka?
• Záťažové vyváženie (Load balancing). Po výbere klastru služby počas smerovania, do ktorej inštancie služby by mala byť požiadavka odoslaná? S akým timeoutom? S akými nastaveniami prerušenia obvodu (circuit breaking)? Ak požiadavka zlyhala, mala by sa opakovať?
• Autentifikácia a autorizácia (Authentication and authorization). Pre prichádzajúce požiadavky môže byť volajúca služba kryptograficky identifikovaná/autorizačná pomocou mTLS alebo iného mechanizmu? Ak je identifikovaná/autorizačná, je jej povolené vykonávať požadovanú operáciu (endpoint) v službe, alebo by mala byť vrátená neautentifikovaná odpoveď?
• Pozorovateľnosť (Observability). Pre každú požiadavku musia byť generované podrobné štatistiky, záznamy a údaje distribuovaného trasovania, aby prevádzkovatelia mohli porozumieť distribuovanému toku prevádzky a problémom s ladením, keď sa vyskytnú.

Za všetky predchádzajúce body v servisnej sieti (service mesh) zodpovedá dátová rovina (data plane). V podstate, lokálny pre službu (sidecar) proxy je dátová rovina (data plane). Inými slovami, dátová rovina (data plane) zodpovedá za podmienenú transláciu, prenos a sledovanie každého sieťového paketu, ktorý je poslaný do služby alebo z nej.

Rovina riadenia (The control plane)

Sieťová abstrakcia, ktorú poskytuje lokálny proxy v dátovej rovine, je doslova magická (?). Ako však proxy server vlastne zisťuje trasu „/foo“ k službe B? Ako sa môžu využiť dáta o objavovaní služieb, ktoré sú doplnené požiadavkami proxy? Ako sú nastavené parametre vyrovnávania záťaže, časového limitu, prerušenia okruhu a podobne? Ako sa uskutočňuje nasadenie aplikácie pomocou metódy modro/zelený (blue/green) alebo metódy postupného presmerovania prevádzky? Kto nastavuje parametre systémovej autentifikácie a autorizácie?

Všetky vyššie uvedené body spadajú do pôsobnosti riadiacej roviny (control plane) servisnej siete (service mesh). Riadiaca rovina prijíma sadu oddelených proxy-serverov bez stavu a premieňa ich na distribuovaný systém..

Myslím, že dôvod, prečo mnohí technológovia považujú rozdelené pojmy 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/neznáma. Dlhú dobu sme pracovali s fyzickými sieťovými routre a prepínačmi. Rozumieme, že pakety/žiadané musia ísť z bodu A do bodu B a aký hardvér a softvér môžeme na to použiť. Nová generácia softvérových proxy je len módna verzia nástrojov, ktoré sme používali už dlhú dobu.

Obrázok 2: Ľudská riadiaca rovina (Human control plane)

Avšak, už dlhú dobu používame riadiace roviny, hoci väčšina sieťových operátorov si nemusí túto časť systému spájať s akýmkoľvek technologickým komponentom. Dôvod je jednoduchý:
Väčšina súčasných riadiacich rovín je… my.

Na na obrázku 2 Zobrazené je to, čo nazývam „Ľudská ovládacia rovina (Human control plane)“. V tomto type nasadenia, ktorý sa stále veľmi často vyskytuje, človek-operátor, pravdepodobne nabručený, vytvára statické konfigurácie — potenciálne pomocou skriptov — a nasadzuje ich pomocou nejakej špeciálne procesu na všetkých proxy serveroch. Následne proxy začínajú používať túto konfiguráciu a prechádzajú na spracovanie dátovej roviny (data plane) s aktualizovanými nastaveniami.

Obrázok 3: Rozšírená ovládacia rovina servisnej siete (Advanced service mesh control plane)

Na obrázku 3 je zobrazená „rozšírená“ ovládacia rovina (control plane) servisnej siete (service mesh). Skladá sa z nasledujúcich častí:

• Človek (The human): Stále je tu človek (dúfam, menej nahnevaný), ktorý prijíma rozhodnutia na vysokej úrovni ohľadom celej sústavy ako celku.
• Užívateľské rozhranie ovládacej roviny (Control plane UI): Človek interaguje s nejakým typom užívateľského rozhrania na správu systému. Môže to byť webový portál, príkazový riadok (CLI) alebo iné rozhranie. Pomocou užívateľského rozhrania má operátor prístup k takým globálnym parametroch konfigurácie systému, ako sú:
  • Správa nasadenia, modro/zelené (blue/green) a/alebo postupný prenos prevádzky
  • Parametre autentifikácie a autorizácie
  • Špecifikácie smerovacej tabuľky, napríklad, čo sa deje, keď aplikácia A požaduje informácie o „/foo“
  • Nastavenia vyváženia zaťaženia, napríklad timeouty (timeouts), opakované pokusy (retries), parametre prerušenia okruhu (circuit breaking) atď.
• Plánovač pracovného zaťaženia (Workload scheduler): Služby sú spúšťané v infraštruktúre prostredníctvom systému plánovania/orkestrovania určitého typu, napríklad Kubernetes alebo Nomad. Plánovač zodpovedá za načítanie služby spolu s jej lokálnym proxy serverom.
• Objavovanie služieb (Service discovery). Keď plánovač spúšťa a zastavuje inštancie služby, reportuje stav dostupnosti do systému objavovania služieb.
• API konfigurácie lokálneho proxy servera (Sidecar proxy configuration APIs) : Lokálne proxy servery dynamicky extrahujú stav z rôznych komponentov systému na základe modelu „konečná konzistencia“ (eventually consistent) bez účasti 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, nakoniec konverguje do jednej ekosystémy. API univerzálnej dátovej roviny (data plane) v Envoy je jedným z príkladov, ako to funguje v praxi.

V podstate cieľ kontrolnej roviny (control plane) spočíva v tom, aby stanovil politiku, ktorá bude nakoniec prijatá dátovou rovinou (data plane). Pokročilejšie kontrolné roviny (control plane) uvoľnia operátora od viacerých detailov niektorých systémov a vyžadujú menej ručného zásahu, pokiaľ fungujú správne!..

Dátová rovina a kontrolná rovina. Zhrnutie (Data plane vs. control plane summary)

• Dátová rovina služby siete (Service mesh data plane): zasahuje do každého paketu / požiadavky v systéme. Zodpovedá za objavovanie aplikácií / služieb, kontrolu dostupnosti, smerovanie, vyvažovanie záťaže, autentizáciu / autorizáciu a monitorovanie.
• Kontrolná rovina služby siete (Service mesh control plane): poskytuje politiku a konfiguráciu pre všetky fungujúce dátové roviny v rámci služby siete. Nezasahuje do žiadnych paketov / požiadaviek v systéme. Kontrolná rovina transformuje všetky dátové roviny na distribuovaný systém.

Aktuálny stav projektu (Current project landscape)

Po vysvetlení vyššie sa pozrime na aktuálny stav projektu „servisnej siete (service mesh)“.

• Dátové roviny (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
• Kontrolné roviny (Control planes): Istio, Nelson, SmartStack

Namiesto hlbokého analýzy každého z vyššie uvedených riešení sa stručne pozriem na niektoré aspekty, ktoré podľa môjho názoru spôsobujú väčšinu zmätku v ekosystéme práve teraz.

Na začiatku roku 2016 bol Linkerd jedným z prvých proxy serverov dátovej vrstvy (data plane) pre servisnú sieť (service mesh) a urobil fantastickú prácu pri zvyšovaní informovanosti a pozornosti k modelu návrhu „servisná sieť“ (service mesh). Približne o 6 mesiacov neskôr sa k Linkerd pridal Envoy (hoci pracoval 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 (service mesh).

Istio bolo vyhlásené v máji 2017. Ciele projektu Istio sú veľmi podobné rozšírenej funkcii riadenia (control plane), zobrazené na obrázku 3. Envoy pre Istio je predvoleným proxy serverom. Takže Istio je riadiaca vrstva (control plane) a Envoy je dátová vrstva (data plane). V krátkom čase Istio vyvolalo veľký rozruch a iné dátové vrstvy (data plane) začali integráciu ako náhradu za Envoy (Linkerd a NGINX predviedli integráciu s Istio). Skutočnosť, že v jednej riadiacej vrstve (control plane) je možné používať rôzne dátové vrstvy (data plane), znamená, že riadiaca vrstva (control plane) a dátová vrstva (data plane) nemusia byť nevyhnutne úzko prepojené. API ako univerzálne API dátovej vrstvy (data plane) Envoy môže tvoriť most medzi oboma časťami systému.

Nelson a SmartStack ďalej ilustrujú rozdelenie riadiacej vrstvy (control plane) a dátovej vrstvy (data plane). Nelson využíva Envoy ako svoj proxy a vytvára robustnú riadiacu vrstvu (control plane) servisnej siete (service mesh) na základe technológie HashiCorp, t.j. Nomad a pod. SmartStack sa stal pravdepodobne prvým zo novej vlny servisných sietí (service mesh). SmartStack vytvára riadiacu vrstvu (control plane) okolo HAProxy alebo NGINX, demonštrujúc možnosť odpojenia riadiacej vrstvy (control plane) servisnej siete (service mesh) a dátovej vrstvy (data plane).

Mikroslužbová architektúra so služobnou sieťou (service mesh) priťahuje čoraz väčšiu pozornosť (správne!), a čoraz viac projektov a dodávateľov začína pracovať týmto smerom. V priebehu nasledujúcich niekoľkých rokov uvidíme množstvo inovácií ako na úrovni dát (data plane), tak aj na úrovni riadenia (control plane), ako aj ďalšie kombinovanie rôznych komponentov. Nakoniec by mikroslužbová architektúra mala byť pre operátora transparentnejšia a zázračnejšia (?)
Dúfam, že všetko je čoraz menej a menej frustrujúce.

Kľúčové body (Key takeaways)

• Služobná sieť (service mesh) sa skladá z dvoch rôznych častí: úrovne dát (data plane) a úrovne riadenia (control plane). Obe komponenty sú nevyhnutné a bez nich systém nebude fungovať.
• Všetci poznáme úroveň riadenia (control plane), a momentálne môžete byť vy tou úrovňou riadenia (control plane)!
• Všetky úrovne dát (data plane) medzi sebou súťažia o funkcie, výkonnosť, prispôsobiteľnosť a rozšíriteľnosť.
• Všetky úrovne riadenia (control plane) medzi sebou súťažia o funkcie, prispôsobiteľnosť, rozšíriteľnosť a použiteľnosť.
• Jedna úroveň riadenia (control plane) môže obsahovať správne abstrakcie a API, aby mohlo byť použité viacero úrovní dát (data plane).

Zdroj: habr.com