Tere, Habr! Esitlen teile tõlget artiklist „Teenuste võrkude andmeplaan vs juhtimiplaneer“ autor Matt Klein.

Seekord „soovisin ja tõlkisin“ mõlema teenuste võrgu komponente, andmeplaani ja juhtimiplaneerimist. See kirjeldus tundus mulle kõige arusaadavam ja huvitavam, ning mis kõige tähtsam, viib arusaamiseni „Kas see on üldse vajalik?“

Kuna idee „teenuste võrgust (service mesh)“ on viimase kahe aasta jooksul üha populaarsemaks muutunud (originaalartikkel 10. oktoobrist 2017), ja osalejate arv selles valdkonnas on kasvanud, olen märganud, et kogu tehnilises kogukonnas on tekkinud rohkem segadust selle üle, kuidas erinevaid lahendusi võrrelda ja vastandada.

Oma olukorda on kõige parem kirjeldada järgmiste tweetide seeriaga, mille kirjutasin juulis:

Teenuste võrgu (service mesh) segadus nr 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ükski neist ei ole võrdne Istio'ga. Istio on midagi hoopis muud. 1 /

Esimesed on lihtsalt andmeplaanid (data planes). Üksinda ei tee nad midagi. Need peavad olema konfigureeritud millekski enamaks. 2 /

Istio on näide juhtimiplaneerist (control plane), mis seob osad omavahel. See on erinev kiht. /lõpp

Varasemates tweetides mainitakse mitmeid erinevaid projekte (Linkerd, NGINX, HAProxy, Envoy ja Istio), kuid mis on veel olulisem, tutvustatakse üldisi mõisteid andmeplaani (data plane), teenuste võrgu (service mesh) ja juhtimiplaneerimise (control plane) kohta. Selles postituses astun sammu tagasi ja räägin, mida mõtlen terminite „andmeplaan (data plane)“ ja „juhtimiplaneer (control plane)“ all väga kõrgel tasemel, ning seejärel räägin, kuidas need terminid seonduvad 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 illustreerib teenuste võrgu (service mesh) kontseptsiooni kõige põhialustel. On neli teenuste klastrit (A-D). Iga teenuse eksemplar on seotud kohaliku proksiserveriga. Kogu võrgu liiklus (HTTP, REST, gRPC, Redis jne) eraldi rakenduse eksemplarist suunatakse kohaliku proksiserveri kaudu vastavatesse välistesse teenuste klastritesse. Seega ei tea rakenduse eksemplar võrgustiku üldisest toimimisest, vaid ainult oma kohalikust proksist. Tegelikult on jaotatud süsteemi võrk teenusest eemaldatud.

Andmeplaan (Data plane)

Teenuste võrgus (service mesh) täidab kohaliku proksiserveri rakenduse jaoks järgmisi ülesandeid:

• Teenuste avastamine (Service discovery). Millised teenused/teenused/rakendused on teie rakendusele saadaval?
• Tervise kontrollimine (Health checking). Kas teenuste eksemplarid, mida teenuste avastamine (service discovery) tagastab, on toimivad ja valmis võrguliiklust vastu võtma? See võib hõlmata nii aktiivset (nt vastuse kontrollimine / healthcheck) kui ka passiivset (nt kolme järjestikuse 5xx vea kasutamist teenuse ebatervislikuks seisundiks näitamiseks) tervise kontrollimist.
• Suunamine (Routing). Kui REST teenus on saanud päringu „/foo”, siis millisesse teenuste klastrisse tuleks päring edastada?
• Koormuse tasakaalustamine (Load balancing). Pärast teenuste klastri valimist suunamise käigus, millisele teenuse eksemplarile peaks päring olema edastatud? Millise ooteajaga? Milliste häirekatkestuse (circuit breaking) seadistustega? Kui päring ebaõnnestub, kas seda tuleks korrata?
• Ahnitsemine ja autoriseerimine (Authentication and authorization). Kas sissetulevate päringute korral saab kutsuv teenus krüptograafiliselt tuvastada/autoriseerida mTLS-i või mõne muu mehhanismi abil? Kui see on tuvastatud/autoriseeritud, kas tal on lubatud teha soovitud toiming (endpoint) teenuses või tuleb tagastada mitteautentseeritud vastus?
• Jälgitavus (Observability). Iga päringu puhul peaks olema genereeritud üksikasjalikud statistikaandmed, logid ja jaotatud jälgimisandmed, et operaatorid saaksid mõista jaotatud liiklusvoogu ning tõrkeotsinguprobleeme nende ilmnemisel.

Kõik eelnevad punktid teenuste võrgus (service mesh) on seotud andmete tasandi (data plane) funktsioonidega. Sisuliselt on teenusele kohalik (sidecar) proksid andmete tasand. Teisisõnu, andmete tasand (data plane) vastutab igasuguse kommunikatsiooni, edastamise ja jälgimise eest, mis toimub teenusele suunatud või sealt saadetud võrgu pakettide osas.

Juhtimis- ja kontrollitase (The control plane)

Võrguekraansus, mille lokaliseeritud proksi pakub andmete plaanis, on maagiline (?). Kuid kuidas proksi-server tegelikult teada saab marsruudi «/foo» suunas teenusele B? Kuidas saab kasutada teenuse avastamise andmeid, mis täidetakse proksi-päringutega? Kuidas on seadistatud koormuse tasakaalustamise, ajaülempiiri, ahelakatkestuse jne parameetrid? Kuidas rakendatakse jagatud rakenduse juurutamist sinise/rohelise meetodi või järkjärgulise liikluse suunamise meetodi kaudu? Kes seadistab kõigisüsteemite autentimise ja autoriseerimise parameetrid?

Kõik ülalnimetatud punktid kuuluvad teenusevõrgu (service mesh) juhtimistasandi (control plane) alla. Juhtimistasand (control plane) võtab rikka kogumi isoleeritud proksi-serverid ilma seisundita ja muudab need jaotatud süsteemiks.

Ma arvan, et põhjus, miks paljud tehnoloogid leiavad andmete plaani (data plane) ja juhtimistasandi (control plane) kontseptsioonid segadusse puutuvad, on see, et suurusele inimese plaan on tuttav, samas kui juhtimistasand on võõras/raske mõista. Me oleme juba pikka aega töötanud füüsiliste võrgu marsruuteritega ja lülititega. Me saame aru, et paketid/päringud peavad liikuma punktist A punkti B ja mis me võime selleks riist- ja tarkvara abil kasutada. Uue põlvkonna tarkvaraliseks proksiks on lihtsalt moekad versioonid tööriistadest, mida oleme juba pikka aega kasutanud.

Joonis 2: Inimese juhtimistasand (Human control plane)

Kuid oleme juba pikka aega kasutanud juhtimistasandeid (control plane), ehkki enamik võrguoperaatoreid ei pruugi seostada seda süsteemi osa konkreetse tehnilise komponendiga. Selle põhjuseks on lihtne:
Enamik täna kasutatavaid juhtimistasandeid (control plane) on... me.

Pealehe jooniselt 2 Näidatakse seda, mida ma nimetan „Inimese juhtimispinnaks (Human control plane)“. Selles tüüpi seadistuses, mis on endiselt väga levinud, loob inimene-operaator, ilmselt ärritunu, staatilisi konfiguratsioone — potentsiaalselt skriptide kaudu — ja rakendab neid mõne spetsiaalse protsessi abil kõikidele vahetusserveritele. Seejärel hakkavad vahetusserverid kasutama seda konfiguratsiooni ja asuvad töötlema andmepinda (data plane) uuendatud seadistuste abil.

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

Pealehe joonisel 3 on kujutatud „täiendav“ juhtimispind (control plane) teenuste võrgus (service mesh). See koosneb järgmistest osadest:

• Inimene (The human): Kuller on endiselt inimene (loodetavasti vähem ärritunud), kes teeb kõrgetasemelisi otsuseid kogu süsteemi kohta.
• Juhtimispinna kasutajaliides (Control plane UI): Inimene suhtleb mingi kasutajaliidese tüübiga süsteemi haldamiseks. See võib olla veebipood, käsurea rakendus (CLI) või muu liides. Kasutajaliidese kaudu on operaatoril juurdepääs sellistele globaalsetele süsteemi konfiguratsiooniparametritele nagu:
  • Käivitamise haldamine, sinine/roheline (blue/green) ja/või järk-järguline liikluse suunamine
  • Autentimise ja volitamise seadistused
  • Rohundustabeli spetsifikatsioonid, näiteks mis juhtub, kui rakendus A küsib teavet „/foo“
  • Laie tasakaalustaja seadistused, näiteks aegumise (timeouts), taasilmimise (retries), ahelakatkestuse (circuit breaking) parameetrid jne.
• Töökoormuse planeerija (Workload scheduler): Teenused käivitatakse infrastruktuuris teatud tüüpi planeerimis-/orkestreerimissüsteemi kaudu, näiteks Kubernetes või Nomad. Planeerija vastutab teenuse koormuse ja kohaliku vahetusserveri koormuse laadimise eest.
• Teenuse avastamine (Service discovery). Kui planeerija käivitab ja peatab teenuse eksemplare, teavitab ta teenuse avastamissüsteemi töökorrasolekust.
• Kohaliku vahetusserveri konfiguratsioon API-d (Sidecar proxy configuration APIs) : Kohalikud proxiserverid võtavad süsteemi erinevate komponentide seisundi dünaamiliselt, järgides mudelit "lõplikult ühtne" (eventually consistent) ilma operaatori osaluseta. Kogu see süsteem, mis koosneb hetkel käivitatud teenuste ja kohalike proxiserverite instantsidest, jõuab lõpuks ühte ökosüsteemi. Universaalse andmeplaani (data plane) API Envoy's on üks näide, kuidas see praktikas töötab.

Sisuliselt on juhtimistasandi (control plane) eesmärk kehtestada poliitika, mis lõpuks võetakse vastu andmeplaani (data plane) poolt. Täiustatud juhtimistasandid (control plane) eemaldavad operaatori käest rohkem üksikasju teatud süsteemide kohta ja nõuavad vähem käsitsi sekkumist, tingimusel et need töötab õigesti!..

Andmeplaanid ja juhtimistasandid. Kokkuvõte (Data plane vs. control plane summary)

• Teenuse võrgu andmeplaan (Service mesh data plane): käsitleb iga paketti / päringut süsteemis. Vastutab rakenduste/teenuste avastamise, töökindluse kontrollimise, marsruutimise, koormuse tasakaalustamise, autentimise / autoriseerimise ja jälgimise eest.
• Teenuse võrgu juhtimistasand (Service mesh control plane): pakub poliitikat ja konfiguratsiooni kõigile töötavatele andmeplaanidele teenuse võrgus. Ei puutu mingite pakkide / päringutega süsteemis. Juhtimistasand muudab kõik andmeplaanid jaotatud süsteemiks.

Praegune projekti seis (Current project landscape)

Mõistes eelnevat selgitust, vaatame projekti "teenuse võrgu (service mesh)" praegust seisu.

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

Kuna ei ole mõtet süvitsi analüüsida iga eeltoodud lahendust, tahan lühidalt peatuda mõningatel punktidel, mis, minu arvates, tekitavad praegu ökosüsteemis kõige rohkem segadust.

2016. aasta alguses oli Linkerd üks esimesi andmeplaani (data plane) võtmeproksi teenusevõrgus (service mesh) ning tegi fantastilist tööd teenusevõrgu (service mesh) kavandamismudeli teadlikkuse tõstmisel. Umbes kuus kuud hiljem liitus Envoy Linkerdiga (kuigi töötas Lyftis juba 2015. aasta lõpust). Linkerd ja Envoy on need kaks projekti, mida kõige sagedamini mainitakse teenusevõrkude (service mesh) aruteludes.

Istio kuulutati välja 2017. aasta mai. Istio projekti eesmärgid on väga sarnased laiendatud juhtimisplaaniga (control plane), nagu on näidatud joonisel 3. Envoy on Istio jaoks vaikimisi võtmeproksi. Seega on Istio juhtimisplaan (control plane) ja Envoy andmeplaan (data plane). Lühikese ajaga tekitas Istio palju elevust ning teised andmeplaanid (data plane) hakkasid integreeruma Envoy asendamiseks (nii Linkerd kui NGINX on demonstreerinud integreerimist Istiosse). See, et ühes juhtimisplaanis (control plane) saab kasutada erinevaid andmeplaanid (data plane), tähendas, et juhtimisplaan (control plane) ja andmeplaan (data plane) ei pruugi olla tihedalt seotud. Selline API nagu universaalne andmeplaani (data plane) API Envoy võib luua silda kahe süsteemi osa vahel.

Nelson ja SmartStack aitavad veelgi illustreerida juhtimisplaani (control plane) ja andmeplaani (data plane) eraldatust. Nelson kasutab Envoyd oma proksina ja loob usaldusväärse teenusevõrgu (service mesh) juhtimisplaani (control plane) HashiCorpi steki baasil, st Nomad jne. SmartStack on tõenäoliselt esimene uus laine teenusevõrkudest (service mesh). SmartStack loob juhtimisplaani (control plane) HAProxy või NGINXi ümber, demonstreerides teenusevõrgu (service mesh) juhtimisplaani (control plane) ja andmeplaani (data plane) eraldamise võimalust.

Mikroteenuse arhitektuur teenuste võrgustikuga (service mesh) tõmbab üha rohkem tähelepanu (õigesti!), ja üha rohkem projekte ja tarnijaid hakkavad selles suunas töötama. Järgnevatel aastatel näeme palju uuendusi nii andmeplaanides (data plane) kui ka juhtimisplaanides (control plane), samuti erinevate komponentide edasist segamist. Lõppkokkuvõttes peab mikroteenuse arhitektuur saama läbipaistvamaks ja maagilisemaks (?) operaatori jaoks.
Loodan, et kõik on järjest vähem häiritud.

Peamised punktid (Key takeaways)

• Teenuste võrgustik (service mesh) koosneb kahest erinevast osast: andmeplaan (data plane) ja juhtimisplaan (control plane). Mõlemad komponendid on kohustuslikud, ja ilma nendeta süsteem ei töötaks.
• Kõik on tuttavad juhtimisplaaniga (control plane), ja seni võib juhtimisplaan olla teie!
• Kõik andmeplaanid (data plane) konkureerivad omavahel funktsioonide, tootlikkuse, konfigureeritavuse ja skaleeritavuse poolest.
• Kõik juhtimisplaanid (control plane) konkureerivad omavahel funktsioonide, konfigureeritavuse, skaleeritavuse ja kasutusmugavuse poolest.
• Üks juhtimisplaan (control plane) võib sisaldada õigeid abstraktsioone ja API-sid, et kasutada mitmeid andmeplaane (data plane).

Allikas: habr.com