Tere, Habr! Esitan teile artikli tõlke «Teenuse mesh andmete tasand vs juhtimistasand» autori Matt Klein.

Seekord vabatahtlikult tõlgiti kahe teenuse mesh komponendi, andmete tasandi ja juhtimistasandi kirjeldust. See kirjeldus tundus mulle kõige arusaadavam ja huvitavam, ja mis kõige tähtsam, see toob arusaamise, et „kas on seda üldse vaja?”.

Kuna teenuse võrgu idee (Service mesh) on viimase kahe aasta jooksul muutunud üha populaarsemaks (originaalartikkel 10. oktoobrist 2017), ja osaliste arv selles ruumis on kasvanud, olen näinud vastavat segaduse kasvu kogu tehnilises kogukonnas seoses erinevate lahenduste võrdlemise ja vastandamisega.

Parim viis olukorra kirjeldamiseks on järgmised Twitteri seeriad, mille kirjutasin juulis:

Teenuse võrgu (service mesh) segadus nr 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ükski neist ei ole võrreldav Istio'ga. Istio on täiesti erinev asi. 1 /

Esimesed on lihtsalt andmete tasandid (data planes). Nad ei tee iseenesest midagi. Nad peavad olema seadistatud millegi suurema jaoks. 2 /

Istio on juhtimistasandi (control plane) näide, mis ühendab osi omavahel. See on teine kiht. /lõpp

Varasemates tweetides mainitakse mitmeid erinevaid projekte (Linkerd, NGINX, HAProxy, Envoy ja Istio), kuid veel olulisem on, et tuuakse sisse üldised mõisted andmeplaan (data plane), teenuste võrk (service mesh) ja juhtimisplaan (control plane). Selles postituses astun samm tagasi ja selgitan, mida mõtlen terminite "andmeplaan (data plane)" ja "juhtimisplaan (control plane)" all väga kõrgel tasemel ning seejärel seletan, kuidas need terminid on seotud tweetides mainitud projektidega.

Mis on teenuste võrk (What is a service mesh, really)?

Joonis 1: Teenuste võrgu ülevaade (Service mesh overview)

Joonis 1 ilustreerib teenuste võrgu (service mesh) kontseptsiooni kõige põhitasemel. On neli teenuse klastri (A-D). Iga teenuse eksemplar on seotud kohaliku proksi serveriga. Kogu võrku liikuv trafi (HTTP, REST, gRPC, Redis jne) edastatakse iga rakenduse eksemplari kaudu kohaliku proksi serveri kaudu vastavatesse välisteenuse klastritesse. Seega ei tea rakenduse eksemplar üldisest võrgust, vaid tunneb ainult oma kohalikku proksit. Tegelikult on jaotatud süsteemi võrk teenusest eemaldatud.

Andmeplaan (Data plane)

Teenindusvõrgus (service mesh) täidab rakendusele kohalikult asuv vaheserver järgmisi ülesandeid:

• Teenuste avastamine (Service discovery). Millised teenused / teenused / rakendused on teie rakendusele kättesaadavad?
• Töötamise kontroll (Health checking). Kas teenuste avastamise (service discovery) kaudu tagastatud teenuse eksemplarid on töövalmid ja valmis võrguliiklust vastu võtma? See võib hõlmata nii aktiivset (nt vastuse kontrollimine / healthcheck) kui ka passiivset (nt kasutades kolme järjestikuse 5xx vea näitena teenuse ebatervislikkuse määratlemiseks) töötamise kontrolli.
• Suunamine (Routing). Kui teenuselt saadeti REST-päring «/foo», kuhu teenuse klastrisse tuleks päring saata?
• Koormuse jaotamine (Load balancing). Pärast seda, kui suunamisel on valitud teenuse klaster, kuhu teenuse eksemplarile päring suunatakse? Millise aja piiranguga? Milliste ahelakatkestuse seadistustega (circuit breaking)? Kui päring ebaõnnestus, kas tuleks see uuesti proovida?
• Autentimine ja autoriseerimine (Authentication and authorization). Kas väljakutse teenus saab mTLS või mõne muu mehhanismi abil krüptograafiliselt tuvastada/autoriseerida? Kui see on tuvastatud/autoriseeritud, kas tal on lubatud teha soovitud toiming (endpoint) teenuses või peab olema tagastatud autendimata vastus?
• Jälgimine (Observability). Iga päringu jaoks peavad olema genereeritud üksikasjalikud statistilised andmed, logid ja jaotatud jälgimise andmed, et operaatorid saaksid mõista jaotatud liikluse voogu ja tõrkeid, kui need tekivad.

Kõikide eelnevalt nimetatud punktide eest teenuste võrgus (service mesh) vastutab andmete tasand (data plane). Sisuliselt on teenusele lokaalne (sidecar) proksi andmete tasand (data plane). Teisisõnu vastutab andmete tasand (data plane) iga võrkpaki tingimusliku edastamise, edastamise ja jälgimise eest, mis saadetakse teenusesse või saadetakse sealt välja.

Juhtimistase (The control plane)

Lokaalne proxy, mis pakub võrgu abstraktsiooni andmete tasandil, on tõeliselt muljetavaldav (?). Kuid kuidas suudab proxy-server tõeliselt tuvastada marsruuti „/foo” teenusele B? Kuidas saab teenuste avastamise (service discovery) andmeid, mis täidetakse proxy-päringutega, kasutada? Kuidas on seadistatud koormuse tasakaalustamise, ajaülesande (timeout), ahelakatkestuse (circuit breaking) jne parameetrid? Kuidas toimub rakenduse juurutamine sinise/roheline (blue/green) meetodi või järkjärgulise liikluse suunamise meetodi abil? Kes seadistab ühiskondlike autentimise ja autoriseerimise parameetrid?

Kõik ülaltoodud punktid kuuluvad teenuste võrgu (service mesh) juhtimistasandi (control plane) alla. Juhtimistasand (control plane) võtab komplekti isoleeritud, ilma olekuta proxy-serverite ja muundab need jaotatud süsteemiks..

Ma arvan, et põhjus, miks paljud tehnoloogid leiavad andmeplaani (data plane) ja juhtimissektori (control plane) mõisted segaseks, seisneb selles, et andmeplaan on enamikule tuttav, samas kui juhtimissektor on võõras või arusaamatu. Oleme juba ammu töötanud füüsiliste võrgu ruuterite ja lülititega. Me mõistame, et paketid/taotlused peavad liikuma punktist A punkti B ning et me saame seda saavutada riist- ja tarkvara abil. Uue põlvkonna tarkvaralised proksid on lihtsalt moes versioonid tööriistadest, mida oleme juba pikka aega kasutanud.

Joonis 2: Inimese juhtimisplaan (Human control plane)

Kuid me oleme juba kaua aega kasutanud juhtimissektorit (control plane), kuigi enamik võrguoperaatoreid ei pruugi seda süsteemi osa siduda ühegi tehnoloogilise komponendiga. Selle põhjuseks on lihtsus:
Enamiku tänapäeval kasutatavate juhtimissektorite (control plane) puhul on tegemist… meie.

VDS-l on võimalik installida: joonisel 2 näidatud on see, mida nimetan „Inimese juhtimisplatvormiks (Human control plane)“. Sellise juurutamise tüübi puhul, mis on endiselt väga levinud, loob inimene- operaator, tõenäoliselt ärritunud, staatilisi konfiguratsioone - potentsiaalselt skriptide abil - ja juurutab need moel, mis on mõeldud spetsiaalsetele protsessidele kõigil proksi-serveritel. Seejärel hakkavad proksid seda konfiguratsiooni kasutama ning alustavad andmepinna (data plane) töötlemist värskendatud seadistustega.

Joonis 3: Täiustatud teenuste võrgu juhtimisplatvorm (Advanced service mesh control plane)

VDS-l on võimalik installida: joonis 3 näidatud on „täiustatud“ juhtimisplatvorm (control plane) teenuste võrgus (service mesh). See koosneb järgmistest osadest:

• Inimene (The human): Endiselt on olemas inimene (loodetavasti vähem ärritunud), kes teeb süsteemi üldiste otsuste tasemel otsuseid.
• Juhtimisplatvormi kasutajaliides (Control plane UI): Inimene suhtleb mõne tüüpi kasutajaliidese kaudu süsteemi haldamiseks. See võib olla veebipõhine portaal, käsurea rakendus (CLI) või mõni teine liides. Kasutajaliidese kaudu on operaatoril juurdepääs selliste globaalsete süsteemi konfigureerimise parameetritele nagu:
  • Rakendamise haldamine, sinine/roheline (blue/green) ja/või järkjärguline liikluse üleviimine
  • Autentimise ja autoriseerimise seaded
  • Marshrutimise tabeli spetsifikatsioonid, näiteks kui rakendus A küsib teavet „/foo”, siis mis toimub
  • Koormuse tasakaalustaja seaded, näiteks ooteajad (timeouts), korduskatsetused (retries), vooluahela katkestamise seaded (circuit breaking) jne.
• Töökoormuse ajastaja (Workload scheduler): Teenused käivitatakse infrastruktuuris konkreetse tüüpi ajastus/orkestreerimise süsteemi kaudu, näiteks Kubernetes või Nomad. Ajastaja vastutab teenuse laadimise eest koos tema kohaliku vaheproksi serveriga.
• Teenuse avastamine (Service discovery). Kui planeerija käivitab ja peatab teenuse eksemplare, edastab ta tööseisundi teenuse avastamissüsteemi.
• Kohaliku vahe-teenuse konfiguratsiooni API (Sidecar proxy configuration APIs) : Kohalikud vahe-teenused ekstraheerivad dünaamiliselt oleku erinevatest süsteemi komponentidest „lõppkokkuvõttes järjekindla” mudeli kaudu ilma operaatori sekkumiseta. Kogu süsteem, mis koosneb hetkel töötavatest teenuse eksemplaridest ja kohalikest vahe-teenustest, jõuab lõpuks ühte ökosüsteemi. Envoy universaalse andmepinna API (data plane) on üks näide selle toimimisest praktikas.

Sisuliselt on kontrolli tasandi (control plane) eesmärk kehtestada poliitika, mida lõpuks rakendab andmepind (data plane). Tõhusamad kontrolli tasandid (control plane) kõrvaldatakse operaatorilt rohkem detailide kohta teatud süsteemide osas ja vajavad vähem käsitsi juhtimist, tingimusel et need töötavad õigesti!..

Andmepind ja kontrolli tasand. Kokkuvõte (Data plane vs. control plane summary)

• Teenuse võrgu andmepind (Service mesh data plane): mõjutab igat paketti / päringut süsteemis. Vastutab rakenduste / teenuste avastamise, töövõimekuse kontrollimise, marsruutimise, koormuse tasakaalustamise, autentimise / autoriseerimise ja jälgimise eest.
• Teenuste võrgu juhtplaan (Service mesh control plane): annab poliitika ja konfiguratsiooni kõigile andmeplaanidele, mis töötavad teenuste võrgus. Ei mõjuta süsteemis ühtegi paketti / päringut. Juhtplaan muudab kõik andmeplaanid jaotatud süsteemiks.

Praegune projekti seis (Current project landscape)

Olles aru saanud eespool toodud seletusest, vaatame praegust seisu projektis "teenuste võrk (service mesh)".

• Andmeplaanid (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
• Juhtplaanid (Control planes): Istio, Nelson, SmartStack

Selle asemel, et analüüsida süvitsi iga eelpool nimetatud lahendust, peatun lühidalt mõningatel punktidel, mis minu arvates põhjustavad praegu ökosüsteemis kõige enam segadust.

2016. aasta alguses oli Linkerd üks esimesi andmeplaani (data plane) pöördele (proxy) teenuste võrku (service mesh) ja tegi fantastilist tööd, et suurendada teadlikkust ning tõsta tähelepanu teenuste võrgu (service mesh) disainimudelile. Umbes 6 kuud pärast seda liitus Envoy Linkerdiga (kuigi töötas Lyftis alates 2015. aasta lõpust). Linkerd ja Envoy on kaks projekti, mida kõige sagedamini mainitakse teenuste võrkude (service mesh) aruteludes.

Istio kuulutati välja 2017. aasta maikuus. Istio projekti eesmärgid on väga sarnased laiendatud halduskihiga (control plane), nagu on näidatud joonis 3. Envoy Istio jaoks on vaikimisi pöördproksi server. Seetõttu on Istio juhtimisplaan (control plane) ja Envoy andmeplaan (data plane). Lühikese ajaga on Istio teinud palju laineid ning teised andmeplaanid (data plane) on alustanud integreerimist, et asendada Envoy (nii Linkerd kui ka NGINX on näidanud integreerimist Istio-ga). Fakt, et ühes juhtimisplaanis (control plane) saab kasutada erinevaid andmeplaane (data plane), tähendab, et juhtimisplaan (control plane) ja andmeplaan (data plane) ei pea olema tihedalt seotud. Selline API nagu universaalne andmeplaani (data plane) API Envoy võib moodustada silla kahe süsteemi osa vahel.

Nelson ja SmartStack aitavad veelgi selgemini illustreerida juhtimistasandi (control plane) ja andmetasandi (data plane) lahknevust. Nelson kasutab Envoyd oma vaheproksi ja loob usaldusväärse juhtimistasandi (control plane) teenuste võrgu (service mesh) põhjal HashiCorpi virnast, st Nomadist ja nii edasi. SmartStack on tõenäoliselt esimene uutest teenuste võrkudest (service mesh). SmartStack loob juhtimistasandi (control plane) ümber HAProxy või NGINX, demonstreerides juhtimistasandi (control plane) ja andmetasandi (data plane) eraldamise võimalust.

Mikroteenuste arhitektuur teenuste võrgu (service mesh) abil tõmbab endale üha enam tähelepanu (õigesti!), ja üha rohkem projekte ja tootjaid hakkavad selles suunas töötama. Järgnevatel aastatel näeme palju innovatsiooni nii andmetasanditel (data plane) kui ka juhtimistasanditel (control plane), samuti erinevate komponentide täiendavat segunemist. Lõpuks peab mikroteenuste arhitektuur muutuma läbipaistvamaks ja maagilisemaks (?) operaatori jaoks.
Loodan, et see muutub üha vähem ja vähem tüütuks.

Olulised järeldused (Key takeaways)

• Teenusevõrk (service mesh) koosneb kahest erinevast osast: andmeplatvormist (data plane) ja juhtimisplatvormist (control plane). Mõlemad komponendid on kohustuslikud, ilma nendeta süsteem ei tööta.
• Olete kõik tuttavad juhtimisplatvormiga (control plane), ja hetkel saate te ise olla juhtimisplatvorm (control plane)!
• Kõik andmeplatvormid (data plane) konkureerivad omavahel funktsioonide, jõudluse, konfigureeritavuse ja laiendatavuse osas.
• Kõik juhtimisplatvormid (control plane) konkureerivad omavahel funktsioonide, konfigureeritavuse, laiendatavuse ja kasutusmugavuse osas.
• Üks juhtimisplatvorm (control plane) võib sisaldada õigeid abstraktsioone ja API-sid, et saaks kasutada mitmeid andmeplatvorme (data plane).

Allikas: habr.com