🥇Gebruiksgevalle vir diensmaas

Let wel. vertaal.: Die skrywer van hierdie artikel (Luc Perkins) is 'n ontwikkelaarsadvokaat by CNCF, die tuiste van oopbronprojekte soos Linkerd, SMI (Service Mesh Interface) en Kuma (terloops, het jy ook gewonder hoekom Istio nie op hierdie lys is nie ?...). Weereens probeer hy om 'n beter begrip van die nuwerwetse hype genaamd "service mesh" na die DevOps-gemeenskap te bring, lys hy 16 kenmerkende kenmerke wat sulke oplossings bied.

Vandag diensmaas is een van die warmste onderwerpe in sagteware-ingenieurswese (en met reg!). Ek sien hierdie tegnologie as ongelooflik belowend en droom daarvan om dit wyd aangeneem te sien (natuurlik, wanneer dit sin maak). Sy is egter steeds omring deur 'n stralekrans van misterie vir die meeste mense. Selfs diegene wat egter goed bekend met haar vind hulle dit dikwels moeilik om die voordele daarvan te formuleer en wat dit presies is (insluitend jou gehoorsame dienaar). In die artikel sal ek probeer om die situasie reg te stel deur verskeie op te noem gebruik gevalle "diensroosters" *.

* Ongeveer. transl.: hierna in die artikel sal so 'n vertaling (“diensmaas”) vir die nog nuwe term diensmaas gebruik word.

Maar eers wil ek 'n paar opmerkings maak:

Ek het nog nooit met diensmaskers gewerk nie en het dit nie buite my opvoedkundige projekte gebruik nie. Aan die ander kant was ek die een wat in 2015 'n klomp dokumentasie vir Twitter se interne diensnetwerk geskryf het (toe is dit nog nie eens 'n "diensmesh" genoem nie) en betrokke was by die ontwikkeling van die webwerf en dokumentasie vir Linkerdso dit beteken iets.
My lys is aanduidend en onvolledig. Gebruiksgevalle wat ek nie weet nie heeltemal moontlik is nie, en nuwes sal beslis mettertyd na vore kom soos die tegnologie vorder en die gewildheid daarvan toeneem.
Terselfdertyd ondersteun nie elke bestaande diensnetwerkimplementering al die bogenoemde gebruiksgevalle nie. Daarom moet my uitdrukkings soos "diensmaaskan ..." gelees word as "individueel, en moontlik kan alle gewilde diensnetwerkimplementerings ...".
Die volgorde van die voorbeelde maak nie saak nie.

Kort lys:

diensontdekking;
enkripsie;
stawing en magtiging;
vrag balansering;
stroombaanbreking;
outoskaling;
kanarie-ontplooiings;
blou-groen ontplooiings;
gesondheids ondersoek;
beurtkrag;
verkeersspieëling;
isolasie;
versoek koersbeperking, herprobasies en tyd-outs;
telemetrie;
oudit;
visualisering.

1. Diensontdekking

TL;DR: Koppel aan ander dienste op die netwerk deur eenvoudige name te gebruik.

Dienste moet mekaar outomaties kan "vind" deur gepaste name te gebruik - bv. service.api.production, pets/staging of cassandra. Wolkomgewings is veerkragtig, en 'n enkele naam kan baie gevalle van 'n diens versteek. Dit is duidelik dat dit in so 'n situasie fisies onmoontlik is om alle IP-adresse te hardkodeer.

Boonop, wanneer een diens 'n ander vind, moet dit versoeke na daardie diens kan stuur sonder om bang te wees dat dit by die insette van sy ledige instansie sal eindig. Met ander woorde, die diensnetwerk moet tred hou met die gesondheid van alle diensgevalle en die lys van gashere so op datum as moontlik hou.

Elke diensnetwerk implementeer 'n diensontdekkingsmeganisme op sy eie manier. Op die oomblik is die mees algemene manier om na eksterne prosesse soos DNS Kubernetes te delegeer. In die verlede het ons op Twitter 'n naamstelsel vir hierdie doel gebruik. Finagle. Boonop maak die diensnetwerktegnologie dit moontlik vir pasgemaakte benamingsmeganismes om te verskyn (alhoewel ek nog geen SM-implementering met sulke funksionaliteit gesien het nie).

2. Enkripsie

TL;DR: Raak ontslae van ongeënkripteerde verkeer tussen dienste en laat hierdie proses outomaties en skaalbaar wees.

Dit is lekker om te weet dat aanvallers nie by jou interne netwerk kan inkom nie. Firewalls is wonderlik hiervoor. Maar wat gebeur as 'n hacker wel inkom? Sal hy met intradiensverkeer kan doen wat hy wil? Kom ons hoop dit gebeur egter nie. Om hierdie scenario te voorkom, moet jy 'n zero-trust-netwerk implementeer waarin alle verkeer tussen dienste geïnkripteer is. Die meeste moderne diensmaskers bereik dit deur wedersydse TLS (onderlinge TLS, mTLS). In sommige gevalle werk mTLS in hele wolke en trosse (ek dink interplanetêre kommunikasie sal eendag soortgelyk wees).

Natuurlik, vir mTLS-diensnetwerk opsioneel. Elke diens kan vir sy eie TLS sorg, maar dit beteken dat dit 'n manier sal moet vind om sertifikate te genereer, dit na diensgashere te versprei, kode in die toepassing in te sluit wat hierdie sertifikate vanaf lêers sal laai. Ja, moenie vergeet om hierdie sertifikate met gereelde tussenposes te hernu nie. Diensnetwerke outomatiseer mTLS met stelsels soos SPIFFE, wat op sy beurt die proses van uitreiking en rotasie van sertifikate outomatiseer.

3. Stawing en magtiging

TL;DR: Stel vas wie die versoeker is en bepaal wat hulle mag doen voordat die versoek die diens bereik.

Dienste wil dikwels weet wat voer 'n versoek (stawing) uit en, met behulp van hierdie inligting, besluit of dat die gegewe vak toegelaat word om te doen (magtiging). In hierdie geval kan agter die voornaamwoord "wie" skuil:

Ander dienste. Dit word "verifikasie" genoem eweknie". Byvoorbeeld, diens web toegang tot die diens wil hê db. Diensnetwerke los gewoonlik hierdie probleme op met behulp van mTLS: sertifikate dien in hierdie geval as 'n noodsaaklike identifiseerder.
Sommige menslike gebruikers. Dit word "verifikasie" genoem navraag". Byvoorbeeld, gebruiker haxor69 wil 'n nuwe lamp koop. Diensmaskers verskaf verskeie meganismes, bv. JSON -webtoken.
Baie van ons het dit in toepassingskode gedoen. 'n Versoek kom in, ons skandeer die tabel users, vind die gebruiker en vergelyk die wagwoord, kontroleer dan die kolom permissions ens. In die geval van 'n diensnetwerk, gebeur dit voordat die versoek selfs die diens bereik.

Nadat ons vasgestel het van wie die versoek kom, moet ons bepaal wat hierdie vak toegelaat word om te doen. Sommige diensmaskers laat jou toe om basiese beleide (oor wie wat kan doen) op te stel as YAML-lêers of op die opdragreël, terwyl ander integrasie bied met raamwerke soos Maak Polisagent oop. Die uiteindelike doel is om te verseker dat u dienste enige versoeke aanvaar, met 'n veilige aanname dat dit van 'n betroubare bron af kom. и die aksie word toegelaat.

4. Lasbalansering

TL;DR: Versprei die las oor diensgevalle in 'n spesifieke patroon.

'n "Diens" binne 'n dienssekte bestaan baie dikwels uit baie identiese gevalle. Byvoorbeeld, vandag die diens cache bestaan uit 5 kopieë, en môre kan hul getal vermeerder tot 11. Versoeke gestuur na cache, moet volgens 'n spesifieke doel versprei word. Byvoorbeeld, die vermindering van latensie of die maksimalisering van die kans om 'n gesonde instansie te tref. Die mees gebruikte algoritme is round-robin, maar daar is baie ander, soos die geweegde metode. (geweeg) versoeke (jy kan voorkeurteikens kies), lui (ring) hashing (gebruik konsekwente hashing vir stroomop gashere) of minste versoeke metode (voorkeur word gegee aan die instansie met die minste versoeke).

Klassieke balanseerders het ander kenmerke soos HTTP-kas en DDoS-beskerming, maar hulle is nie baie relevant vir oos-wes verkeer nie. Natuurlik is dit nie nodig om 'n diensnetwerk vir lasbalansering te gebruik nie, maar dit laat jou toe om lasbalanseringsbeleide vir elke diens vanaf 'n gesentraliseerde beheerlaag op te stel en te beheer, en sodoende die behoefte om individuele lasbalanseerders in die netwerk uit te voer en op te stel, uitskakel stapel.

5. Kringbreek

TL;DR: Stop verkeer na 'n problematiese diens en beheer skade onder ergste scenario's.

As die diens om een of ander rede nie die verkeer kan hanteer nie, bied die diensnetwerk verskeie oplossings vir hierdie probleem (ander sal in die betrokke afdelings bespreek word). Stroomonderbreking is die moeilikste opsie om 'n diens van verkeer te ontkoppel. Dit maak egter nie sin op sy eie nie – ’n rugsteunplan is nodig. Terugdruk kan voorsien word (rug drukking) op dienste wat versoeke maak (moenie vergeet om jou diensnetwerk hiervoor op te stel nie!), of, byvoorbeeld, die statusbladsy rooi in te kleur en gebruikers na 'n ander weergawe van die "vallende walvis"-bladsy te herlei ("Twitter is af").

Diensroosters laat nie net toe om te bepaal nie waar gevolg deur afskakeling en dat dit sal volg. In hierdie geval kan "wanneer" enige kombinasie van gegewe parameters insluit: totale aantal versoeke vir 'n sekere tydperk, aantal gelyktydige verbindings, hangende versoeke, aktiewe herproberings, ens.

Jy wil nie stroomonderbreking te veel gebruik nie, maar dit is lekker om te weet daar is 'n rugsteunplan in geval van nood.

6. Outoskaal

TL;DR: Verhoog of verminder die aantal diensgevalle na gelang van die gegewe kriteria.

Diensnetwerke is nie skeduleers nie, so hulle is nie dra uit self skaal. Hulle kan egter inligting verskaf oor watter beplanners hul besluite sal grond. Omdat diensmaskers toegang het tot alle verkeer tussen dienste, het hulle 'n magdom inligting oor wat aangaan: watter dienste ondervind probleme, watter word onderbenut (krag wat aan hulle toegeken word, word vermors), ensovoorts.

Byvoorbeeld, Kubernetes skaal dienste op grond van peule se SVE en geheuegebruik. (sien ons verslag "Outoskaal en hulpbronbestuur in Kubernetes"- ongeveer. vertaal.), maar as jy kies om te skaal op grond van enige ander maatstaf (in ons geval verkeerverwant), sal jy 'n pasgemaakte maatstaf nodig hê. Bestuur soos hierdie wys hoe om dit te doen gesant, Istio и Prometheusmaar die proses self is taamlik ingewikkeld. Ons wil graag hê dat die diensnetwerk dit moet vereenvoudig, sodat u bloot voorwaardes kan stel soos "verhoog die aantal diensgevalle authas die aantal hangende versoeke die drempel binne 'n minuut oorskry."

7. Kanarie-ontplooiings

TL;DR: Toets nuwe kenmerke of diensweergawes op 'n subset van gebruikers.

Kom ons sê jy is besig om 'n SaaS-produk te ontwikkel en van plan is om 'n oulike nuwe weergawe daarvan uit te voer. Jy het dit in opvoering getoets en dit het uitstekend gewerk. Maar oorkom tog sekere kommer oor sy gedrag in werklike omstandighede. Met ander woorde, dit is nodig om die nuwe weergawe op werklike take te toets sonder om die vertroue van gebruikers te waag. Kanarie-ontplooiings is wonderlik hiervoor. Hulle laat jou toe om 'n nuwe kenmerk aan 'n subset van gebruikers te demonstreer. Hierdie subset kan bestaan uit die mees lojale gebruikers of diegene wat met die gratis weergawe van die produk werk, of gebruikers wat 'n begeerte uitgespreek het om "proefkonyne" te wees.

Diensnetwerke implementeer dit deur jou toe te laat om kriteria te spesifiseer vir wie watter weergawe van die toepassing sien, en die verkeer daarvolgens te stuur. Terselfdertyd verander niks vir die dienste self nie. Weergawe 1.0 van die diens glo dat alle versoeke kom van gebruikers wat dit moet sien, en weergawe 1.1 glo dieselfde oor sy gebruikers. En jy kan intussen die persentasie verkeer tussen die ou en die nuwe weergawe verander en 'n groeiende aantal gebruikers na die nuwe een herlei, as dit stabiel werk en jou "proefkonyne" gee die trekpas.

8. Blou-Groen Ontplooiings

TL;DR: Ontplooi 'n oulike nuwe kenmerk, maar wees voorbereid om dit alles onmiddellik terug te bring.

wat beteken blou-groen ontplooiings is om 'n nuwe "blou" diens uit te voer, wat dit parallel met die ou, "groen" een laat loop. As alles glad verloop en die nuwe diens goed presteer, kan die ou een uitgefaseer word. (Ai, eendag sal hierdie nuwe "blou" diens die lot van die "groen" herhaal en verdwyn ...) Blou-groen ontplooiings verskil van kanaries deurdat die nuwe funksie dek alles gelyktydig gebruikers (en nie 'n deel nie); die punt hier is om 'n "veilige hawe" gereed te hê vir ingeval iets verkeerd gaan.

Diensmaskers bied 'n baie gerieflike manier om 'n "blou" diens te toets en onmiddellik na 'n werkende "groen" oor te skakel in geval van probleme. Om nie te praat van die feit dat hulle langs die pad baie inligting gee (sien "Telemetrie" hieronder) oor die werk van die "blou", wat help om te verstaan of dit gereed is vir volle werking.

Let wel. vertaal.: Jy kan meer lees oor verskillende ontplooiingstrategieë in Kubernetes (insluitend die genoemde kanarie, blou / groen en ander) in Hierdie artikel.

9. Gesondheidsondersoek

TL;DR: Bly op hoogte van watter diensgevalle beskikbaar is en reageer op dié wat nie is nie.

Gesondheids ondersoek (gesondheids ondersoek) help om te besluit of diensgevalle gereed is om verkeer te ontvang en te verwerk. Byvoorbeeld, in die geval van HTTP-dienste, kan 'n gesondheidsondersoek soos 'n GET-versoek na 'n eindpunt lyk /health... Antwoord 200 OK sal beteken dat die instansie gesond is, enige ander - dat dit nie gereed is om verkeer te ontvang nie. Diensmaskers laat jou toe om beide die manier waarop die gesondheidsondersoek uitgevoer sal word, en die frekwensie waarmee hierdie ondersoek uitgevoer sal word, te spesifiseer. Hierdie inligting kan dan vir ander doeleindes gebruik word, soos lasbalansering en stroombaanbreking.

Die gesondheidsondersoek is dus nie 'n alleenstaande gebruiksgeval nie, maar word gewoonlik gebruik om ander doelwitte te bereik. Afhangende van die resultate van gesondheidsondersoeke, kan eksterne (met betrekking tot ander diensnetwerkteikens) aksies ook vereis word: byvoorbeeld die opdatering van 'n statusbladsy, die skep van 'n probleem op GitHub, of die invul van 'n JIRA-kaartjie. En die diensnetwerk bied 'n gerieflike meganisme om dit alles te outomatiseer.

10. Beurtkrag

TL;DR: Herlei verkeer in reaksie op 'n tydelike styging in gebruik.

As 'n sekere diens met verkeer oorlaai is, kan jy van hierdie verkeer tydelik na 'n ander plek herlei (d.w.s. "dump", "transfer" (skuur) hom daar). Byvoorbeeld, na 'n rugsteundiens of datasentrum, of na 'n permanente Druk onderwerp. As gevolg hiervan sal die diens voortgaan om sommige van die versoeke te verwerk in plaas daarvan om te verongeluk en op te hou om alles te verwerk. Beurtkrag is verkieslik bo stroombaanbreking, maar dit is steeds ongewens om dit te misbruik. Dit laat jou toe om te voorkom dat stroomafwaartse dienste val.

11. Verkeersparallellisering/spieëling

TL;DR: Stuur 'n enkele versoek na verskeie liggings gelyktydig.

Soms word dit nodig om 'n versoek (of 'n keuse van versoeke) na verskeie dienste tegelyk te stuur. 'n Tipiese voorbeeld is om 'n deel van die produksieverkeer na die verhoogdiens te stuur. Produksie se hoofwebbediener stuur 'n versoek na 'n stroomafdiens products.production en net aan hom. En die diensnetwerk kopieer hierdie versoek intelligent en stuur dit na products.staging, waarvan die webbediener nie eers bewus is nie.

Nog 'n verwante diensnetwerkgebruiksgeval wat bo-op verkeersparallellisering geïmplementeer kan word, is regressietoetsing. Dit behels die stuur van dieselfde versoeke na verskillende weergawes van die diens en kyk of alle weergawes dieselfde optree. Ek het nog nie 'n diensnetwerkimplementering gesien met 'n geïntegreerde regressietoetsstelsel soos Diffymaar die idee self lyk belowend.

12. Isolasie

TL;DR: Breek jou diensnetwerk in mini-netwerke op.

Ook bekend as segmentering, isolasie is die kuns om die diensnetwerk in logies aparte segmente te verdeel wat niks van mekaar weet nie. Isolasie is 'n bietjie soos om virtuele privaat netwerke te skep. Die fundamentele verskil is dat jy steeds al die voordele van 'n diensnetwerk (soos diensontdekking) kan geniet, maar met bykomende sekuriteit. Byvoorbeeld, as 'n aanvaller dit regkry om 'n diens op een van die subnette te infiltreer, sal hy nie in staat wees om te sien watter dienste op ander subnette loop of hul verkeer te onderskep nie.

Daarbenewens kan die voordele organisatories wees. U wil dalk subnetdienste op grond van maatskappystruktuur gebruik en ontwikkelaars bevry van die kognitiewe las om die hele diensnetwerk in gedagte te hou.

13. Koersbeperking, herprobasies en uitteltyd

TL;DR: Dit is nie meer nodig om dringende taak van versoekbestuur in die kodebasis in te sluit nie.

Al hierdie dinge kan as aparte gebruiksgevalle beskou word, maar ek het besluit om hulle te kombineer as gevolg van een algemene kenmerk: hulle neem die take oor om die versoeklewensiklus te bestuur, wat gewoonlik deur toepassingsbiblioteke hanteer word. As jy besig is om 'n Ruby on Rails-webbediener te ontwikkel (nie geïntegreer met 'n diensnetwerk nie) wat versoeke rig na backend-dienste via gRPC, sal die aansoek moet besluit wat om te doen as N versoeke misluk. Jy sal ook moet uitvind hoeveel verkeer hierdie dienste hierdie parameters sal kan hanteer en hardkodeer deur 'n spesiale biblioteek te gebruik. Boonop sal die aansoek moet besluit wanneer om tou op te gooi en die versoek te laat sterf (met time-out). En om enige van die bogenoemde parameters te verander, sal die webbediener gestop, herkonfigureer en herbegin moet word.

Delegering van hierdie take na die diensnetwerk beteken nie net dat diensontwikkelaars nie daaraan hoef te dink nie, maar dat dit op 'n meer globale manier oorweeg kan word. As 'n komplekse ketting van dienste gebruik word, sê A –> B –> C –> D –> E, moet die hele versoeklewensiklus oorweeg word. As die taak is om die time-outs in diens C te verleng, is dit logies om dit alles op een slag te doen, en nie in dele nie: deur die dienskode op te dateer en te wag dat die trekversoek aanvaar word en die CI-stelsel om die opgedateerde diens te ontplooi .

14. Telemetrie

TL;DR: Versamel al die nodige (en nie heeltemal) inligting van dienste.

Telemetrie is 'n algemene term wat metrieke, verspreide opsporing en logs insluit. Diensmaskers bied meganismes vir die insameling en verwerking van al drie tipes data. Dit is waar dinge 'n bietjie vaag raak, aangesien die aantal moontlike opsies te groot is. Metrieke in te samel Prometheus en ander gereedskap om logs te versamel wat jy kan gebruik vlot, Loki, Vector ens. (byvoorbeeld, ClickHouse met ons houthuis vir K8s - ongeveer. vertaal.), vir verspreide opsporing is daar Jaeger en so aan. Elke diensnetwerk kan sommige gereedskap ondersteun en ander nie. Dit sal interessant wees om te sien of die projek kan oop telemetrie bied 'n mate van konvergensie.

In hierdie geval is die voordeel van die diensmaastegnologie dat syspanhouers in beginsel al die bogenoemde data van hul dienste kan insamel. Met ander woorde, jy het 'n enkele stelsel vir die insameling van telemetrie tot jou beskikking, en die diensnetwerk kan al hierdie inligting op verskeie maniere verwerk. Byvoorbeeld:

tail'it logs van een of ander diens in die CLI;
monitor versoekvolume vanaf die diensmaaspaneelbord;
versamel verspreide spore en herlei dit na 'n stelsel soos Jaeger.

Aandag, subjektiewe oordeel: Oor die algemeen is telemetrie 'n gebied waarin 'n sterk ingryping van die diensnetwerk ongewens is. Dit is goed om basiese inligting in te samel en 'n paar goue maatstawwe soos sukseskoerse en latensie op te spoor, maar laat ons hoop ons sien nie die opkoms van Frankenstein-stapels wat probeer om gespesialiseerde stelsels te vervang nie, waarvan sommige reeds goed vaar. en goed bestudeer .

15. Oudit

TL;DR: Diegene wat die lesse van die geskiedenis vergeet, is gedoem om dit te herhaal.

Ouditering is die kuns om belangrike gebeurtenisse in 'n sisteem waar te neem. In die geval van 'n diensnetwerk, kan dit beteken dat u tred gehou moet word van wie versoeke na spesifieke eindpunte van sekere dienste gerig het, of hoeveel keer 'n sekere sekuriteitsverwante gebeurtenis in die afgelope maand plaasgevind het.

Dit is duidelik dat oudit baie nou verband hou met telemetrie. Die verskil is dat telemetrie gewoonlik geassosieer word met dinge soos werkverrigting en tegniese behendigheid, terwyl ouditering verband kan hou met wetlike en ander kwessies wat verder gaan as die streng tegniese gebied (byvoorbeeld, GDPR-nakoming). oor databeskerming.

16. Voorskou

TL;DR: Lank lewe React.js - 'n onuitputlike bron van fancy koppelvlakke.

Miskien is daar 'n beter term, maar ek ken dit nie. Ek bedoel net 'n grafiese voorstelling van die diensnetwerk of sommige van sy komponente. Hierdie visualisasies kan aanwysers soos gemiddelde latensie, syspanhouer-konfigurasie-inligting, gesondheidsondersoekresultate en waarskuwings insluit.

Werk in 'n diensgerigte omgewing kom met 'n baie hoër kognitiewe las as Sy Majesteit die Monoliet. Daarom moet kognitiewe druk ten alle koste verminder word. 'n Eenvoudige grafiese koppelvlak vir 'n diensnetwerk met die vermoë om op 'n knoppie te klik en die gewenste resultaat te kry, kan deurslaggewend wees vir die groei van hierdie tegnologie.

Was nie op die lys ingesluit nie

Ek was oorspronklik van plan om nog 'n paar gebruiksgevalle op die lys in te sluit, maar het toe besluit om nie. Hier is hulle, saam met die redes vir my besluit:

Multi-datasentrum. Na my mening is dit nie soseer 'n gebruiksgeval nie, maar 'n nou en spesifieke omvang van diensnetwerke of 'n stel funksies soos diensontdekking.
in- en uitgang. Dit is 'n verwante area, maar ek het myself (dalk kunsmatig) beperk tot die "oos-wes verkeer" gebruiksgeval. Ingang en uitgang verdien 'n aparte artikel.

Gevolgtrekking

Dit is al vir nou! Weereens, hierdie lys is hoogs arbitrêr en waarskynlik onvolledig. As jy dink dat ek iets gemis het, of 'n fout gemaak het in iets, kontak my op Twitter (@luckerkins). Respekteer asseblief die reëls van ordentlikheid.

PS van vertaler

As basis vir die titelillustrasie vir die artikel, 'n beeld uit die artikel "Wat is 'n Service Mesh (en wanneer om een te gebruik)?» (skrywer - Gregory MacKinnon). Dit wys hoe sommige van die funksionaliteit van die toepassings (in groen) verskuif het na die diensnetwerk wat onderlinge verbindings tussen hulle verskaf (in blou).