🥇Scenariji uporabe service mesh

Op. prev.: avtor te članka (Luc Perkins) — zagovornik razvoja v organizaciji CNCF, ki je dom za projekte odprte kode, kot so Linkerd, SMI (Service Mesh Interface) in Kuma (mimogrede, ste se tudi vi kdaj vprašali, zakaj v tem seznamu ni Istio?..). Ponovno poskuša prinašati boljše razumevanje razburljivega pojava, imenovanega 'service mesh', v DevOps skupnost z navajanjem 16 značilnih možnosti, ki jih ponujajo taka rešitev.

Danes service mesh ― ena izmed najvročejših tem na področju programske inženiringa (in upravičeno!). Menim, da je ta tehnologija izjemno obetavna in sanjam o tem, da bi bil priča njenemu širokemu uvajanju (seveda, ko to ima smisel). Vendar pa je še vedno obkrožena s halo skrivnosti za večino ljudi. Hkrati pa tudi tisti, ki so dobro seznanjeni z njo, pogosto težko oblikujejo njene prednosti in kaj pravzaprav predstavlja (tudi vaš ponižni služabnik). V tem članku poskusim popraviti to situacijo z naštevanjem različnih scenarijev uporabe 'sistemskih omrežij'*.

* Opomba prevajalca: od tega in naprej v članku bo uporabljena ta prevod ('sistemska omrežja') za še vedno nov termin service mesh.

Toda najprej želim narediti nekaj opomb:

Nikoli nisem delal s sistemskimi omrežji in jih nisem uporabljal zunaj projektov, ki so bili zasnovani za lastno izobraževanje. Po drugi strani pa sem napisal precej dokumentacije za notranji service mesh podjetja Twitter leta 2015 (takrat še ni bilo imenovano 'sistemsko omrežje') in sodeloval pri razvoju spletne strani in dokumentacije za Linkerd, tako da to kaj pomeni.
Moj seznam je približen in nepopoln. Verjetno obstajajo tako neznani scenariji uporabe, novi pa se bodo zagotovo pojavili, ko se tehnologija razvija in postaja vse bolj priljubljena.
Hkrati pa ne podpira vsaka obstoječa izvedba service mesh vseh naštetih primerov uporabe. Zato je treba moje trditve, kot je 'service mesh lahko ...', brati kot 'posamezne, morda pa tudi vse priljubljene izvedbe service mesh lahko ...'.
Zaporedje primerov nima nobenega posebnega pomena.

Kratki seznam:

odkrivanje storitev;
šifriranjem;
avtentikacija in avtorizacija;
balansiranje obremenitve;
circuit breaking;
avtomatsko skaliranje;
kanarno uvajanje;
modra-zelena uvajanja;
preverjanje zdravja;
load shedding;
zrcaljenje prometa;
izolacija;
omejitev frekvence zahtevkov, ponovna poskusitev in časovni izpadi;
telemetrija;
revizija;
vizualizacija.

1. Odkritje storitev

TL;DR: Povežite se z drugimi storitvami v omrežju z enostavnimi imeni.

Storitve morajo biti sposobne samodejno 'odkriti' druga drugo z ustreznimi imeni - na primer, service.api.production, pets/staging ili cassandra. Oblakaste okolje se razlikujejo po svoji elastičnosti, in za enim imenom se lahko skriva več primerkov storitve. Razumljivo je, da v takšni situaciji fizično ni mogoče zakodirati vseh IP naslovov.

Poleg tega, ko ena storitev odkrije drugo, mora imeti možnost pošiljati zahteve tej storitvi, ne da bi se bala, da bodo končale pri njenem nedelujočem primeru. Drugimi besedami, service mesh mora spremljati delovanje vseh primerkov storitev in vzdrževati seznam gostiteljev v največji možni meri aktualen.

Vsaka service mesh implementira mehanizem odkrije storitev na svoj način. Trenutno je najpogostejši način delegacija zunanjim procesom, kot je DNS v Kubernetesu. V preteklosti smo v Twitterju za te namene uporabljali sistem imen Finagle. Poleg tega tehnologija service mesh omogoča pojav prilagojenih mehanizmov imenovanja (čeprav še nisem videl nobene implementacije SM s to funkcionalnostjo).

2. Šifriranje

TL;DR: Znebite se nezašifriranega prometa med storitvami in naj bo ta proces avtomatiziran in prilagodljiv.

Prijetno je vedeti, da hekerji ne morejo prodreti v vaše notranje omrežje. Omrežni požarni zidovi se s tem odlično spopadajo. Kaj pa, če heker vseeno pride notri? Bo lahko z notranjim prometom storitev počel, kar želi? Upajmo, da se to ne bo zgodilo. Da bi preprečili takšen scenarij, je treba implementirati omrežje z ničelnim zaupanjem (zero-trust), v katerem je ves promet med storitvami šifriran. Večina sodobnih storitvenih omrežij to doseže z medsebojno , čeprav se tega zelo sramuje. (mutual TLS, mTLS). V nekaterih primerih mTLS deluje v celotnih oblakih in grozdih (mislim, da bodo tudi interplanetarne komunikacije nekoč zasnovane podobno).

Seveda, za mTLS service mesh ni obvezna. Vsaka storitev lahko skrbi za svoj TLS, a to pomeni, da boste morali najti način za generiranje certifikatov, njihovo razporeditev po gostiteljih storitve in vključitev kode v aplikacijo, ki bo te certifikate nalagala iz datotek. In ne pozabite na obnovitev teh certifikatov po določenih časovnih intervalih. Storitevne mreže avtomatizirajo mTLS s pomočjo sistemov, kot je SPIFFE, ki prav tako avtomatizirajo postopek izdaje in obnavljanja certifikatov.

3. Avtentikacija in avtorizacija

TL;DR: Določite, kdo je pobudnik zahteve, in opredelite, kaj mu je dovoljeno delati še preden zahteva doseže storitev.

Storitev pogosto želi vedeti, uporabnik (ali napadalec) poskuša narediti, ampak tudi kdo izvaja zahtevo (avtentikacija), ter na podlagi teh informacij ugotoviti, To vam omogoča, da rekonstruirate ne le kaj je vlagatelju dovoljeno početi (avtorizacija). V tem primeru se lahko za zaimkom 'kdor' skriva:

Druge storitve. To se imenuje 'avtentikacija peerja'. Na primer, storitev web želi dostopati do storitve db. Storitevne mreže ponavadi rešejo take težave s pomočjo mTLS: certifikati v tem primeru služijo kot potrebna identifikacija.
Nekateri uporabniki-osebe. To se imenuje 'avtentikacija zahteve'. Na primer, uporabnik haxor69 želi pridobiti novo svetilko. Storitevne mreže ponujajo različne mehanizme, kot so JSON Web Tokens.
Mnogi od nas smo to počeli v kodi aplikacije. Pridobi se zahteva, pregledamo tabelo users, najdemo uporabnika in primerjamo geslo, nato preverimo stolpec permissions itd. V primeru storitvene mreže se to zgodi še preden zahteva doseže storitev.

Potem, ko smo ugotovili, od koga prihaja zahteva, je treba opredeliti, kaj je vlagatelju dovoljeno početi. Nekatere storitvene mreže omogočajo postavitev osnovnih politik (o tem, kdo in kaj lahko počne) v obliki YAML-datotek ali v ukazni vrstici, medtem ko druge ponujajo integracijo s okviri, kot je Open Policy Agent. Končni cilj je doseči, da vaše storitve sprejemajo kakršne koli zahteve, ne da bi dvomili, da izvirajo iz zanesljivega vira. in to dejanje je dovoljeno.

4. Obremenitvena uravnava

TL;DR: Pripravite obremenitev med primerki storitve po določenem vzorcu.

»Servis« v okviru storitvene sekte pogosto sestavljajo številne identične instance. Na primer, danes servis predpomnilnik sestavlja 5 kopij, jutri pa se lahko število poveča na 11. Zahteve, ki gredo v predpomnilnik, je treba razdeliti v skladu z določenim ciljem. Na primer, zmanjšati zakasnitev ali maksimirati verjetnost, da se pošlje na delujočo instanco. Najpogosteje se uporablja algoritem krožnega obvladovanja (Round-robin), vendar obstaja še mnogo drugih — na primer, metoda ponderiranih (weighted) zahtev (izbira prednostnih ciljev), obročasto (ring) hashiranje (uporaba usklajenega hashiranja za upstream gostitelje) ali metoda najmanjšega števila zahtevkov (prednost se daje instanci z najmanjšim številom zahtevkov).

Klasični uravnoteževalniki imajo tudi druge funkcije, kot so predpomnjenje HTTP in zaščita pred DDoS-om, vendar niso zelo relevantni za east-west promet (tj. promet, ki poteka znotraj podatkovnega centra - op. prev.) (tipična domena storitvene mreže). Seveda ni nujno uporabljati storitvene mreže za uravnoteženje obremenitev, vendar omogoča določitev in nadzor politik uravnoteženja za vsako storitev iz centralizirane upravljalske plasti, s čimer odpravlja potrebo po izvajanju in nastavljanju ločenih uravnoteževalnikov v omrežnem skladu.

5. Prekinitev vezja (circuit breaking)

TL;DR: Ustavite promet do težavne storitve in obvladujte škodo v najslabših scenarijih.

Če storitev iz kakršnegakoli razloga ne zmore obvladovati prometa, storitvena mreža ponuja več možnosti reševanja te težave (o drugih bo govora v ustreznih razdelkih). Prekinitev vezja je najstrožji način izklopa storitve od prometa. Vendar sama po sebi nima smisla — potreben je načrt B. Lahko je predvideno povratno delovanje (backpressure) na storitve, ki izvajajo zahteve (samo ne pozabite nastaviti svoje storitvene mreže za to!), ali pa, na primer, rdeče barvanje statusne strani in preusmeritev uporabnikov na drugo različico strani s »padajočim kitom« (»Twitter ne obratuje«).

Storitvene mreže omogočajo ne samo določitev, kdaj bo prišlo do izklopa in To vam omogoča, da rekonstruirate ne le S tem sledi. V tem primeru lahko »kadar« vključuje katerokoli kombinacijo določenih parametrov: skupno število zahtevkov v določenem času, število vzporednih povezav, čakajoče zahtevke, aktivne ponovne poizkuse itd.

Verjetno ne boste želeli zlorabljati circuit breaking-a, a prijetno je vedeti, da obstaja rezervni načrt za skrajne primere.

6. Samodejno prilagajanje

TL;DR: Povečujte ali zmanjšujte število primerkov storitve glede na določene kriterije.

Service mesh-i niso načrtovalci, zato ne izvajajo samodejnega prilagajanja. Vendar pa lahko zagotavljajo informacije, na podlagi katerih načrtovalci sprejemajo odločitve. Ker imajo service mesh-i dostop do vsega prometa med storitvami, imajo obsežne informacije o tem, kaj se dogaja: kateri storitvi se soočajo s težavami, kateri so zelo slabo obremenjeni (virusi na njih se zapravljajo) itd.

Na primer, Kubernetes prilagaja storitve glede na uporabo CPU in pomnilnika s strani pod-ov (glejte našo predstavitev »Automatsko skaliranje i upravljanje resursima u Kubernetesu“ — op. prev.)", vendar če se odločite za prilagajanje na podlagi kateregakoli drugega kazalnika (v našem primeru povezanega s prometom), bo potrebna posebna metrika. Navodila kot je to prikazujejo, kako to storiti z uporabo Envoy, Istio in Prometheus, vendar je sam postopek kar zapleten. Želeli bi, da bi service mesh to poenostavil in omogočil enostavno določanje pogojev, kot je »povečajte število primerkov storitve auth, če bo število zahtevkov, ki čakajo na izpolnitev, preseglo mejno vrednost v eni minuti.«

7. Kanarni razvoj

TL;DR: Preizkusite nove funkcije ali različice storitve na podmnožici uporabnikov.

Recimo, da razvijate nek SaaS izdelek in nameravate izdati njegovo novo različico. Preizkusili ste ga v stagingu in deluje odlično. Kljub temu pa vas obdajajo določene skrbi glede njegovega obnašanja v resničnih pogojih. Drugimi besedami, potrebno je preizkusiti novo različico na resničnih nalogah, ne da bi tvegali zaupanje uporabnikov. Kanarčine namestitve so odlične za to. Omogočajo vam, da novo funkcijo prikažete določenemu podnaboru uporabnikov. Ta podnabor je lahko sestavljen iz najzvestejših uporabnikov, tistih, ki uporabljajo brezplačno različico izdelka, ali uporabnikov, ki so izrazili željo, da bi bili 'poskusni zajčki'.

Service mesh-i to realizirajo, saj omogočajo, da določite merila, ki določajo, kdo in katero različico aplikacije bo videl, in ustrezno preusmerjajo promet. Pri tem se za same storitve nič ne spremeni. Različica 1.0 storitve predvideva, da vsi zahtevki prihajajo od uporabnikov, ki jo morajo videti, medtem ko različica 1.1 predvideva isto za svoje uporabnike. Medtem lahko vi spreminjate odstotek prometa med staro in novo različico, tako da preusmerite naraščajoče število uporabnikov na novo različico, če deluje stabilno in vaši 'poskusni' dajo zeleno luč.

8. Modro-zelene namestitve

TL;DR: Uvedite novo odlično funkcijo, vendar bodite pripravljeni, da jo takoj umaknete.

Smisel modro-zelene namestitve je v tem, da uvedete novo 'modro' storitev, jo hkrati z obstoječo 'zeleno' zaženete. Če gre vse gladko in se nova storitev dobro obnese, se bo stara lahko postopoma izklopila. (Žal bo tudi ta nova 'modra' storitev nekoč doživela usodo 'zelene' in izginila...) Modro-zelene namestitve se razlikujejo od kanarčnih, saj nova funkcija zajema takoj vse uporabnike (ne samo del); smisel je v tem, da imate pripravljeno 'varno pristanišče', če bi se slučajno kaj zalomilo.

Service mesh omogočajo zelo priročen način testiranja "modre" storitve in takojšnjega preklopa na delujočo "zeleno" v primeru težav. Poleg tega nudijo množico informacij (glejte razdelek "Telemetrija" spodaj) o delovanju "modre", ki pomagajo razumeti, ali je ta pripravljena za polno uporabo.

Op. prev.: O različnih strategijah uvajanja v Kubernetes (vključno z omembami canary, blue/green in drugimi) lahko preberete v this article.

9. Zdravstvena kontrola

TL;DR: Spremljajte, kateri primeri storitev so operativni, in ukrepajte glede tistih, ki niso več.

Zdravstvena kontrola (health check) pomaga pri odločanju, ali so primeri storitve pripravljeni sprejemati in obdelovati promet. Na primer, pri HTTP-storitvah lahko zdravstvena kontrola izgleda kot GET-poziv na endpoint /health. Odgovor 200 OK bo pomeni, da je primer zdrav, vsak drug odgovor pa, da ni pripravljen sprejemati prometa. Service mesh omogočajo natančno določanje, kako se bo preverjala delovanje, ter frekvenco, s katero se bo ta preveritev izvajala. Te informacije se lahko nato uporabijo za druge namene — na primer, za uravnoteženje obremenitve in circuit breaking.

Tako je zdravstvena kontrola v bistvu neodvisen scenarij uporabe, ampak se običajno uporablja za dosego drugih ciljev. Glede na rezultate zdravstvenih kontrol so lahko potrebne tudi zunanje (v povezavi z drugimi cilji storitvenih mrež) akcije: na primer, osvežiti stanje strani, ustvariti težavo na GitHubu ali izpolniti JIRA nalog. Service mesh ponuja priročen mehanizem za avtomatizacijo vsega tega.

10. Preusmerjanje obremenitve (load shedding)

TL;DR: Preusmerite promet kot odgovor na začasno povečanje uporabe.

Če se neka storitev izkaže za preobremenjeno s prometom, lahko začasno preusmerite del tega prometa na drugo mesto (tj. "sprostite", "prelijete" (shed) ga tja). Na primer, na rezervo storitev ali podatkovni center, ali v stalni Pulsar tema. Kot rezultat, storitev bo še naprej obravnavala del zahtevkov namesto, da bi se sesula in prenehala obravnavati vse. Ponovni zagon obremenitve je bolj zaželen kot prekinitev verige, a vseeno je treba previdno ravnati z njim. To preprečuje kaskadne okvare, ki povzročajo izpade odjemalskih storitev.

11. Paralelizacija/zrcaljenje prometa

TL;DR: Pošljite en zahtevek hkrati na več mest.

Včasih se pojavi potreba po pošiljanju zahtevka (ali nekega nabora zahtevkov) hkrati na več storitev. Značilna situacija je pošiljanje dela produkcijskega prometa na staging storitev. Glavni spletni strežnik produkcije pošlje zahtevek k spodnji storitvi products.production in samo tej. Storitvena mreža pametno kopira ta zahtevek in ga pošlje na products.staging, o čemer spletni strežnik niti ne sluti.

Še ena povezana uporaba storitvene mreže, ki jo je mogoče izvesti nad paralelizacijo prometa, je regresijsko testiranje. To predvideva pošiljanje istih zahtevkov različnim različicam storitve in preverjanje, ali se vse različice obnašajo enako. Do sedaj še nisem srečal storitvene mreže z integriranim sistemom regresijskega testiranja, kot je Diffy, toda sama ideja se zdi obetavna.

12. Izolacija

TL;DR: Razbijte svojo storitveno mrežo na mini-mreže.

Poznana tudi kot segmentacija, izolacija je umetnost razdeljevanja storitvene mreže na logično ločene segmente, ki ne vedo nič drug o drugem. Izolacija je nekoliko podobna ustvarjanju virtualnih zasebnih omrežij. A ključno razliko predstavlja dejstvo, da lahko še vedno izkoristite vse prednosti storitvene mreže (kot so odkrivanje storitev), a z dodatno varnostjo. Na primer, če zlonamerni napadalec uspe prodreti v storitev v enem od podomrežij, ne bo mogel videti, katere storitve delujejo v drugih podomrežjih, ali prestrezati njihovega prometa.

Poleg tega so lahko prednosti tudi organizacijske. Morda boste želeli razdeliti storitve na podomrežja glede na strukturo podjetja in obremeniti razvijalce z manjšim kognitivnim bremenom, ki ga povzroča potreba po obdržanju celotne storitvene mreže v mislih.

13. Omejevanje frekvence zahtevkov, ponovni poskusi in časovni izklopi

TL;DR: Ni vam več treba vključiti nujnih nalog za upravljanje zahtevkov v kodo.

Vse te zadeve bi lahko obravnavali kot posamezne primere uporabe, a sem se odločil, da jih združim zaradi skupne značilnosti: prevzemajo naloge upravljanja življenjskega cikla zahtevkov, ki jih običajno opravljajo knjižnice aplikacij. Če razvijate spletni strežnik z Ruby on Rails (ni integriran s service mesh), ki obravnava zahtevke za backend storitve preko gRPC, mora aplikacija sama rešiti, kaj storiti, če N zahtevkov ne uspe. Prav tako se bo morala ugotoviti, koliko prometa te storitve zmorejo obvladati in 'hardcode' te parametre z uporabo posebne knjižnice. Poleg tega bo morala aplikacija ugotoviti, kdaj je čas, da obupajo in dovoli, da se zahteva izteče (po timeoutu). In za spremenitev katerega koli od zgoraj navedenih parametrov bo treba ustaviti spletni strežnik, ponovno konfigurirati in ga zagnati.

Prenos teh nalog na storitveno mrežo ne pomeni le, da se razvijalci storitev ne bodo morali ukvarjati z njimi, temveč tudi, da jih je mogoče obravnavati na bolj globalen način. Če imate zapleteno verigo storitev, reči, A -> B -> C -> D -> E, je treba upoštevati celoten življenjski cikel zahtevka. Če imate nalogo podaljšati timeout v storitvi C, je smiselno to narediti naenkrat, ne delno: posodobite kodo storitve in počakajte, da se odobri pull request in CI-sistem razširi posodobljeno storitev.

14. Telemetrija

TL;DR: Zberite vse potrebne (in tudi nepomembne) informacije od storitev.

Telemetrija je splošni izraz, ki vključuje metrike, razdeljeno sledenje in dnevniške datoteke. Storitev mreže ponuja mehanizme za zbiranje in obdelavo vseh treh vrst podatkov. Tukaj postane vse nekoliko nejasno, saj je število možnih možnosti preveliko. Za zbiranje metrik obstajajo Prometheus in druga orodja, za zbiranje dnevniških datotek pa lahko uporabite fluentd, Loki, Vector i drugi. (na primer, ClickHouse z našim loghouse za K8s – op. prev.), za razdeljeno sledenje pa obstajajo Jaeger itd. Vsaka storitvena mreža lahko podpira nekatera orodja in ne podpira drugih. Zanimivo bo videti, ali bo projekt Open Telemetry zagotovil neko konvergenco.

V tem primeru je prednost tehnologije service mesh v tem, da lahko sidecar-kontejnerji načeloma zberejo vse zgoraj omenjene podatke iz svojih storitev. Z drugimi besedami, na voljo imate enotno sistem za zbiranje telemetrije, service mesh pa lahko obravnava vse te informacije na različne načine. Na primer:

ogledovanje logov nekega servisa v CLI;
sledenje količini zahtevkov na nadzorni plošči service mesh;
zbiranje razporejenih sledi in preusmerjanje v sistem, kot je Jaeger.

Opozorilo, subjektivno mnenje: Na splošno je telemetrija področje, kjer je močno posredovanje servisne mreže nezaželeno. Zbiranje osnovnih informacij in spremljanje nekaterih "zlatega meritev", kot so odstotek uspešnih zahtevkov in zamude, je sprejemljivo, a upajmo, da ne bomo priča nastanku Frankeštajnovega sklada, ki bo poskušal zamenjati specializirane sisteme, ki so se že dobro izkazali in so ustrezno raziskani.

15. Revizija

TL;DR: Tisti, ki pozabi lekcije zgodovine, je obsojen, da jih ponavlja.

Revizija je umetnost opazovanja pomembnih dogodkov v sistemu. V primeru service mesh to lahko pomeni sledenje temu, kdo je pošiljal zahtevke na določene endpoint-e nekaterih storitev ali kolikokrat se je v zadnjem mesecu zgodil določen dogodek, povezan z varnostjo.

Jasno je, da je revizija zelo tesno povezana s telemetrijo. Razlika pa je v tem, da se telemetrija običajno povezuje z stvarmi, kot so zmogljivost in tehnična integriteta, medtem ko ima revizija lahko povezave z pravnimi in drugimi vprašanji, ki presegajo strogo tehnično sfero (na primer skladnost z GDPR - Splošna uredba o varstvu podatkov EU).

16. Vizualizacija

TL;DR: Dolgovažna je React.js - neizčrpen vir nenavadnih vmesnikov.

Morda obstaja primernejši izraz, a ga ne poznam. Preprosto mislim na grafično predstavitev service mesh ali njenih nekaterih komponent. Te vizualizacije lahko vključujejo indikatorje, kot so povprečne zamude, informacije o konfiguraciji sidecar-kontejnerjev, rezultate zdravniških preverjanj in opozorila.

Delo v storitveno usmerjenem okolju zahteva bistveno večje kognitivne napore v primerjavi z Njegovo Visočnostjo Monolitom. Zato je treba kognitivni pritisk zmanjšati za vsako ceno. Preprost grafični vmesnik za service mesh, ki omogoča klik na gumb in pridobitev želenega rezultata, je lahko ključnega pomena za rast priljubljenosti te tehnologije.

Niso bili vključeni v seznam

Sprva sem nameraval vključiti še nekaj primerov uporabe na seznam, a sem se nato odločil, da tega ne storim. Tukaj so skupaj s razlogi za mojo odločitev:

Multi-data center. V mojem razumevanju to ni toliko primer uporabe, kot pa ozka in specifična področja uporabe servisnih mrež ali nekega nabora funkcij, kot je odkrivanje storitev.
Ingress in egress. To je povezano področje, vendar sem se (morda umetno) omejil na primer uporabe "east-west traffic". Ingress in egress si zaslužita poseben članek.

Zaključek

To je za zdaj vse! Še enkrat, ta seznam je precej условen in verjetno ni popoln. Če se vam zdi, da sem kaj izpustil ali naredil napako, me kontaktirajte na Twitterju (@lucperkins). Prosimo, upoštevajte pravila vljudnosti.

P.S. od prevajalca

Kot osnovo za naslovno ilustracijo članka sem vzel sliko iz članka „What is a Service Mesh (and when to use one)?“ (avtor — Gregory MacKinnon). Na njej je prikazano, kako je del funkcionalnosti iz aplikacij (zeleno) prešel na service mesh, ki zagotavlja povezave med njimi (modro).

Preberite tudi na našem blogu:

Izvor: habr.com