Helló, Habr! Örömmel mutatom be az írás fordítását. „Service mesh data plane vs control plane” szerző Matt Klein.

Ezúttal szerettem volna lefordítani mindkét service mesh komponenst, az adat síkot és az irányító síkot. Ez a leírás számomra a legérthetőbb és legérdekesebb volt, és ami a legfontosabb, segített megérteni, hogy „Egyáltalán szükség van-e rá?”.

Mivel a „Szolgáltatási hálózat (Service mesh)” ötlete az elmúlt két évben egyre népszerűbbé vált (Eredeti cikk 2017. október 10-éről), és a résztvevők száma is megnőtt, észrevettem, hogy a technikai közösség körében arányos zűrzavar alakult ki arra vonatkozóan, hogy hogyan kell összehasonlítani és szembeállítani a különböző megoldásokat.

A helyzetet a legjobban a következő tweet sorozatokkal lehet leírni, amelyeket júliusban írtam:

Zűrzavar a szolgáltatási hálózával (service mesh) #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Egyik sem egyenlő az Istióval. Az Istio valami teljesen más.

Az elsődlegesek csupán adat síkok (data planes). Magukban véve semmit sem csinálnak. Valami többre kell őket konfigurálni. 2 /

Az Istio példája az irányító síknak (control plane), ami összekapcsolja a részeket. Ez egy másik réteg. / vég

A korábbi tweetekben néhány különböző projekt (Linkerd, NGINX, HAProxy, Envoy és Istio) említésre került, de ami ennél is fontosabb, bevezették az adat síkok (data plane), a szolgáltatási hálózat (service mesh) és az irányító sík (control plane) általános fogalmait. Ebben a bejegyzésben hátralépnék, és elmondom, mit értek az „adat sík (data plane)” és az „irányító sík (control plane)” kifejezések alatt nagyon magas szinten, majd elmondom, hogy ezek a fogalmak hogyan kapcsolódnak a tweetekben említett projektekhez.

Mi az a szolgáltatási hálózat (What is a service mesh, really)?

1. ábra: A szolgáltatási hálózat áttekintése (Service mesh overview)

1. ábra illusztrálja a szolgáltatási hálózat (service mesh) koncepcióját a legalapvetőbb szinten. Négy szolgáltatási klaszter (A-D) van. Minden szolgáltatás példányt egy helyi proxy szerver kapcsol össze. A különálló alkalmazás példányból származó összes hálózati forgalom (HTTP, REST, gRPC, Redis stb.) átkerül a helyi proxy szerveren keresztül a megfelelő külső szolgáltatási klaszterekbe. Így az alkalmazás példánya nem tud a hálózatról, és csak a saját helyi proxyjáról tud. Valójában a elosztott rendszer hálózata el lett távolítva a szolgáltatástól.

Adat sík (Data plane)

A szolgáltatási hálózaton (service mesh) a helyi proxy-szerver az alkalmazáshoz a következő feladatokat látja el:

• Szolgáltatások felfedezése (Service discovery). Milyen szolgáltatások/alkalmazások érhetők el az alkalmazásához?
• Egészségellenőrzés (Health checking). A szolgáltatásfelfedezés által visszaadott szolgáltatásminták működőképesek-e, és készen állnak-e a hálózati forgalom fogadására? Ez magában foglalhat aktív (pl. válasz ellenőrzés / healthcheck) és passzív (pl. 3 egymást követő 5xx hibakód) egészségellenőrzéseket.
• Útválasztás (Routing). Ha a REST szolgáltatástól kérés érkezik a "\/foo" címre, akkor melyik szolgáltatási klaszterhez kell küldeni a kérést?
• Terheléselosztás (Load balancing). Miután az útválasztás során egy szolgáltatási klaszter került kiválasztásra, melyik szolgáltatásmintába kell küldeni a kérést? Milyen időtúllépés mellett? Milyen áramkörmegszakítási beállításokkal? Ha a kérés nem sikerül, meg kell ismételni?
• Hitelesítés és engedélyezés (Authentication and authorization). A bejövő kérések esetén a hívó szolgáltatás az mTLS vagy valamilyen más mechanizmus segítségével kriptográfiai azonosítással rendelkezik-e? Ha azonosítva / engedélyezve van, megengedett-e, hogy a szolgáltatásban kérési műveletet hívjon, vagy nem azonosított választ kell visszaadni?
• Megfigyelhetőség (Observability). Minden kérés esetében részletes statisztikák, naplók és elosztott nyomkövetési adatok kell, hogy generálódjanak, hogy az üzemeltetők megérthessék az elosztott forgalom áramlását és a hibák problémáit, amint azok felmerülnek.

Mindezekért a korábbi pontokért a szolgáltatási hálózaton (service mesh) az adatlap (data plane) felel. Lényegében a szolgáltatás számára helyi (sidecar) proxy a míg az adatlap (data plane). Más szavakkal, az adatlap (data plane) felel minden hálózati csomag feltételes továbbításáért, továbbításáért és megfigyeléséért, amely a szolgáltatásra érkezik vagy abból kimegy.

A vezérlő sík (The control plane)

A hálózati absztrakció, amelyet a helyi proxy biztosít az adatlapon (data plane), varázslatos (?). Mégis, hogyan tud a proxy ténylegesen információt szerezni a "\/foo" útvonalról a B szolgáltatásra? Hogyan használhatók fel a szolgáltatás-keresés (service discovery) által proxy-kérések által feltöltött adatok? Hogyan vannak beállítva a terheléselosztás, időtúllépés (timeout), áramkör megszakítása (circuit breaking) stb. paraméterei? Hogyan történik az alkalmazás telepítése kék/zöld (blue/green) módszerrel vagy a forgalom fokozatos átirányításával? Ki állítja be a közrendszerszintű azonosítás és engedélyezés paramétereit?

Mindezek a kérdések a szolgáltatási hálózat (service mesh) vezérlési síkjának (control plane) a hatáskörébe tartoznak. A vezérlési sík (control plane) egy izolált proxy-készletetszerverek állapot nélküli rendszerré alakít..

Azt gondolom, hogy az oka annak, hogy sok technológus zavarba jön az adatsík (data plane) és a vezérlési sík (control plane) különböző fogalmaival, az, hogy a legtöbb ember számára az adatsík ismerős, míg a vezérlési sík idegen/érthetetlen. Régóta dolgozunk fizikai hálózati routerekkel és switch-ekkel. Megértjük, hogy a csomagok/kérések A pontból B pontba kell érkezzenek, és hogy miért használnak ehhez hardvert és szoftvert. Az új generációs szoftver proxy-k egyszerűen divatos verziói azoknak az eszközöknek, amelyeket már régóta használunk.

2. ábra: Emberi vezérlési sík (Human control plane)

Noha már régóta használjuk a vezérlési síkokat (control plane), a legtöbb hálózati üzemeltető talán nem köti ezt a rendszer részét semmilyen technológiai komponenshez. Ennek az az oka:
A mai környezetben használt legtöbb vezérlési sík (control plane) -ezek vagyunk mi.

Ezen ábrán Amit, amit én „Emberi vezérlő síknak” (Human control plane) nevezek. Ebben a telepítési típusban, amely még mindig nagyon gyakori, az emberi üzemeltető valószínűleg mérgesen, statikus konfigurációkat hoz létre – potenciálisan script segítségével – és ezeket egy különleges folyamat révén telepíti minden proxy szerverre. Ezután a proxyk elkezdik használni ezt a konfigurációt, és megkezdik az adat sík (data plane) feldolgozását a frissített beállításokkal.

3. ábra: Kiterjesztett vezérlő sík a szolgáltatási hálózaton (Advanced service mesh control plane)

Ezen 3. ábrán látható a „kiterjesztett” vezérlő sík (control plane) a szolgáltatási hálózaton (service mesh). Ez a következő részekből áll:

• Ember (The human): Még mindig van egy ember (remélhetőleg kevésbé dühös), aki magas szintű döntéseket hoz az egész rendszerrel kapcsolatban.
• A vezérlő sík felhasználói felülete (Control plane UI): Az ember valamilyen típusú felhasználói felületen keresztül lép kapcsolatba a rendszer kezelésével. Ez lehet webportál, parancssori alkalmazás (CLI) vagy valamilyen más felület. A felhasználói felület segítségével az üzemeltető hozzáférést kap olyan globális konfigurációs paraméterekhez, mint például:
  • Telepítési kezelés, kék/zöld (blue/green) és/vagy fokozatos forgalomirányítás
  • Hitelesítési és jogosultsági beállítások
  • Útvonal táblázat specifikációi, például, amikor az A alkalmazás információt kér a „/foo” címről, mi történik
  • Terheléselosztó beállítások, például időtúllépések (timeouts), újrapróbálkozások (retries), áramkör megszakító (circuit breaking) paraméterek stb.
• Feladat ütemező (Workload scheduler): A szolgáltatások egy adott típusú ütemező/orchestration rendszer segítségével indulnak el az infrastruktúrában, például Kubernetes vagy Nomad. Az ütemező felelős a szolgáltatás beindításáért a helyi proxy szerverével együtt.
• Szolgáltatás felfedezése (Service discovery). Amikor az ütemező indítja és leállítja a szolgáltatás példányait, tájékoztat a működési állapotukról a szolgáltatás felfedező rendszerbe.
• Helyi proxy konfiguráció API-k (Sidecar proxy configuration APIs) : A helyi proxyk dinamikusan kinyerik az állapotot a rendszer különböző komponenseiből az „végső következetesség” (eventually consistent) modell szerint, operátor beavatkozása nélkül. Az egész rendszer, amely a jelenleg futó szolgáltatások és helyi proxyk példányaiból áll, végül egy ökoszisztémává olvad össze. Az Envoy univerzális adatlapjának (data plane) API-ja az egyik példa arra, hogyan működik ez a gyakorlatban.

Lényegében a vezérlőlap (control plane) célja a politika meghatározása, amelyet végül az adatlap (data plane) elfogad. A kifinomultabb vezérlőlapok (control plane) eltávolítanak a kezelőtől több részletet bizonyos rendszerekből, és kevesebb kézi irányítást igényelnek, feltéve, hogy helyesen működnek!..

Adatlap és vezérlőlap. Összegzés (Data plane vs. control plane summary)

• Szolgáltatás hálózat adatlapja (Service mesh data plane): érinti a rendszer minden csomagját / kérését. Felelős az alkalmazások / szolgáltatások felfedezéséért, állapotellenőrzéséért, irányításáért, terheléselosztásért, hitelesítésért / jogosultságért és megfigyelhetőségért.
• Szolgáltatás hálózat vezérlőlapja (Service mesh control plane): politikát és konfigurációt biztosít a szolgáltatás hálózatban működő összes adatlap számára. Nem érinti a rendszer bármely csomagját / kérését. A vezérlőlap minden adatlapot egy elosztott rendszerré alakít.

A projekt aktuális állapota (Current project landscape)

Miután tisztáztuk a fenti magyarázatot, nézzük meg a „szolgáltatás hálózat” projekt aktuális állapotát.

• Adatlapok (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
• Vezérlőlapok (Control planes): Istio, Nelson, SmartStack

Ahelyett, hogy mélyreható elemzést végeznék az egyes felsorolt megoldásokról, röviden kitérnék néhány pontra, amelyek véleményem szerint a zűrzavar legnagyobb részét okozzák az ökoszisztémában éppen most.

2016 elején a Linkerd volt az egyik első adatlapú proxy (data plane) a szolgáltatás-hálózatokhoz (service mesh), és fantasztikus munkát végzett a szolgáltatás-hálózat koncepciójának népszerűsítésében. Körülbelül 6 hónappal később az Envoy csatlakozott a Linkerd-hez (bár a Lyftnél 2015 vége óta dolgozott). A Linkerd és az Envoy a két projekt, amelyeket leggyakrabban említenek a szolgáltatás-hálózatokkal (service mesh) kapcsolatban.

Az Istio-t 2017 májusában jelentették be. Az Istio projekt céljai nagyon hasonlóak a kiterjesztett vezérlőpályához (control plane), amit a 3. ábrán. Az Envoy az Istio alapértelmezett proxyja. Így az Istio a vezérlőpálya (control plane), míg az Envoy az adatlap (data plane). Rövid idő alatt az Istio nagy izgalmakat keltett, és más adatlapok (data plane) integrálni kezdték magukat az Envoy helyettesítésére (a Linkerd és az NGINX például már bemutatták az integrációt az Istio-val). Az a tény, hogy egy vezérlőpályán (control plane) különböző adatlapok (data plane) használhatók, azt jelenti, hogy a vezérlőpálya (control plane) és az adatlap (data plane) nem feltétlenül szorosan összefonódott. Egy ilyen API, mint az Envoy univerzális adatlap (data plane) API, hidat képezhet a rendszer két része között.

A Nelson és a SmartStack tovább illusztrálja a vezérlőpálya (control plane) és az adatlap (data plane) elválasztását. A Nelson az Envoy-t használja proxyjaként, és egy megbízható vezérlőpályát (control plane) épít a HashiCorp stack alapján, mint például a Nomad stb. A SmartStack talán az új szolgáltatás-hálózatok (service mesh) első képviselője lett. A SmartStack a HAProxy vagy NGINX köré építi a vezérlőpályát (control plane), bemutatva a szolgáltatás-hálózat (service mesh) vezérlőpályájának és adatlapjának (data plane) laza összekapcsolhatóságát.

A mikroszerviz-architektúra, a service mesh szolgáltatói hálózat egyre nagyobb figyelmet kap (jól van!), és egyre több projekt és szolgáltató kezd dolgozni ebben az irányban. A következő néhány évben sok innovációt látunk majd mind az adatsíkon (data plane), mind a vezérlési síkon (control plane), valamint különböző komponensek további keveredését. Végső soron a mikroszerviz-architektúráknak átláthatóbbnak és varázslatosabbnak (?) kell lenniük az üzemeltető számára.
Remélem, egyre kevésbé idegesítő.

Kulcsfontosságú pontok (Key takeaways)

• A service mesh két különböző részből áll: az adatsínből (data plane) és a vezérlési sínből (control plane). Mindkét komponens kötelező, és nélkülük a rendszer nem működik.
• Mindenki ismeri a vezérlési síkot (control plane), és jelen pillanatban Ön is lehet a vezérlési sík (control plane)!
• Az összes adatsík (data plane) versenyez egymással funkciók, teljesítmény, konfigurálhatóság és bővíthetőség terén.
• Az összes vezérlési sík (control plane) versenyez egymással funkciók, konfigurálhatóság, bővíthetőség és használhatóság alapján.
• Egy vezérlési sík (control plane) megfelelő absztrakciókat és API-kat tartalmazhat, amelyek lehetővé teszik több adatsík (data plane) használatát.

Forrás: habr.com