Kaixo, Habr! Artikuluaren itzulpena aurkezten dizuet "Zerbitzu sareko datu-planoa vs kontrol-planoa" egilea Matt Klein.

Oraingoan, zerbitzu-sareko osagaien, datu-planoaren eta kontrol-planoaren deskribapena "nahi eta itzuli" nuen. Deskribapen hau ulergarriena eta interesgarriena iruditu zait, eta garrantzitsuena "Beharrezkoa al da?"

Azken bi urteetan "Zerbitzu sarearen" ideia gero eta ezagunagoa bihurtu denez (Jatorrizko artikulua 10ko urriaren 2017ean) eta espazioko parte-hartzaileen kopurua handitu denez, nahasmena neurri handi batean areagotu dela ikusi dut. teknologia-komunitateak irtenbide desberdinak nola alderatu eta kontrastatuz.

Egoera ondoen laburbiltzen da uztailean idatzi nuen honako txio sorta hauek:

Zerbitzuaren sareko nahasmena #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Horietako bat ere ez da Istioren parekoa. Istio guztiz bestelakoa da. 1/

Lehenengoak datu-planoak besterik ez dira. Berez ez dute ezer egiten. Zerbait gehiagorako gogoz egon behar dute. 2/

Istio piezak elkarrekin lotzen dituen kontrol-plano baten adibidea da. Hau beste geruza bat da. /amaiera

Aurreko txioek hainbat proiektu aipatzen dituzte (Linkerd, NGINX, HAProxy, Envoy eta Istio), baina are garrantzitsuagoa dena datu-planoaren, zerbitzu-sarearen eta kontrol-planoaren kontzeptu orokorrak aurkezten dituzte. Argitalpen honetan, urrats bat emango dut eta "datu-hegazkina" eta "kontrol-hegazkina" terminoekin esan nahi dudanari buruz hitz egingo dut maila oso altuan, eta gero hitz egingo dut terminoak txioetan aipatzen diren proiektuei nola aplikatzen zaizkien.

Zer da zerbitzu-sare bat, benetan?

1. irudia: Zerbitzu-sarearen ikuspegi orokorra

1 irudia zerbitzu-sarearen kontzeptua oinarrizko mailan erakusten du. Lau zerbitzu-kluster (AD) daude. Zerbitzu-instantzia bakoitza proxy zerbitzari lokal batekin lotuta dago. Aplikazio-instantzia bakarreko sareko trafiko guztia (HTTP, REST, gRPC, Redis, etab.) proxy lokal baten bidez pasatzen da kanpoko zerbitzu-kluster egokietara. Horrela, aplikazio-instantziak ez du sare osoa ezagutzen eta bere proxy lokalaren berri baino ez du ezagutzen. Izan ere, sistema banatutako sarea zerbitzutik kendu zen.

Datu-planoa

Zerbitzu sare batean, aplikaziorako lokalean kokatutako proxy zerbitzari batek zeregin hauek egiten ditu:

• Zerbitzuaren aurkikuntza. Zein zerbitzu/aplikazio daude eskuragarri zure aplikaziorako?
• Osasun egiaztapena. Zerbitzuaren aurkikuntzak itzultzen dituen zerbitzu-instantziak osasuntsu eta sareko trafikoa onartzeko prest al daude? Honek osasun egiaztapen aktiboak (adibidez, erantzuna/osasun-egiaztapena) eta pasiboak (adibidez, 3xx ondoz ondoko 5 errore erabiltzea zerbitzu-egoera ez-osasunaren adierazle gisa) sar ditzake.
• Bideratzea. REST zerbitzu batetik "/foo"-ri eskaera jasotzen duzunean, zein zerbitzu-klusterra bidali behar da eskaera?
• Karga orekatzea. Bideratzerakoan zerbitzu-kluster bat hautatu ondoren, zein zerbitzu instantziatara bidali behar da eskaera? Zein denbora-mugarekin? Zein zirkuitu eten ezarpenekin? Eskaerak huts egiten badu, berriro saiatu behar da?
• Autentifikazioa eta baimena. Jasotako eskaeretarako, dei-zerbitzua kriptografikoki identifikatu/baimendu al daiteke mTLS edo beste mekanismoren bat erabiliz? Aitortzen/baimenduta badago, baimenduta al dago eskatutako eragiketa (bukaerari) zerbitzuan deitzea edo autentifikatu gabeko erantzuna itzuli behar da?
• Behagarritasuna. Eskaera bakoitzerako estatistika zehatzak, erregistroak/erregistroak eta banatutako traza-datuak sortu behar dira, operadoreek banatutako trafiko-fluxua eta arazketa-arazoak sortzen diren heinean uler ditzaten.

Datu-planoa zerbitzu-sareko aurreko puntu guztien arduraduna da. Izan ere, zerbitzuko proxy lokala (sidecar) datu-planoa da. Beste era batera esanda, datu-planoa zerbitzu batera edo bertatik bidaltzen den sare-pakete bakoitza baldintzapean igortzeaz, birbidaltzeaz eta kontrolatzeaz arduratzen da.

Kontrol-planoa

Proxy lokal batek datu-planoan ematen duen sare-abstrakzioa magikoa da(?). Hala ere, nola daki proxyak B zerbitzurako "/foo" ibilbideari buruz? Nola erabil daitezke proxy-eskaerek betetzen dituzten zerbitzuen aurkikuntza-datuak? Nola konfiguratzen dira parametroak karga orekatzeko, denbora-mugarako, etenaldirako, etab.? Nola zabaldu aplikazio bat urdin/berdea metodoa edo trafikoaren trantsizio dotorearen metodoa erabiliz? Nork konfiguratzen ditu sistema osorako autentifikazio- eta baimen-ezarpenak?

Goiko elementu guztiak zerbitzu-sarearen kontrol-planoaren kontrolpean daude. Kontrol-planoak estaturik gabeko proxy isolatu multzo bat hartzen du eta sistema banatu batean bihurtzen ditu.

Uste dut teknologo askok datu-planoaren eta kontrol-planoaren kontzeptu bereiziak nahasten dituztelako jende gehienentzat datu-planoa ezaguna delako kontrol-planoa arrotza/ulertzen ez den bitartean. Aspaldi daramagu sare fisikoko bideratzaile eta etengailuekin lanean. Ulertzen dugu pakete/eskaerak A puntutik B puntura joan behar direla eta horretarako hardwarea eta softwarea erabil ditzakegula. Software proxien belaunaldi berria aspalditik erabiltzen ari garen tresnen bertsio dotoreak besterik ez dira.

2. irudia: Giza kontrol-planoa

Hala ere, kontrol-hegazkinak erabiltzen ari gara denbora luzez, nahiz eta sare-operadore gehienek sistemaren zati hori ez dute inolako osagai teknologikorekin lotu. Arrazoia sinplea da:
Gaur egun erabiltzen diren kontrol-hegazkin gehienak... gu.

On 2. irudia "Giza kontroleko planoa" deitzen dudana erakusten du. Inplementazio-mota honetan, oraindik oso ohikoa dena, ziurrenik giza-operadore maltzur batek konfigurazio estatikoak sortzen ditu - potentzialki scripten bidez - eta prozesu berezi batzuen bidez zabaltzen ditu proxy guztietara. Ondoren, proxyak konfigurazio hau erabiltzen hasten dira eta datu-planoa prozesatzen hasten dira eguneratutako ezarpenak erabiliz.

3. Irudia: Zerbitzu aurreratua sarearen kontrol-planoa

On 3. irudia zerbitzu-sarearen kontrol-plano "hedatua" erakusten du. Honako zati hauek osatzen dute:

• Gizakia: Oraindik badago pertsona bat (espero dugu gutxiago haserre) sistema osoari dagokionez maila altuko erabakiak hartzen dituena.
• Kontrol-planoaren interfazea: Pertsona batek erabiltzaile-interfaze mota batekin elkarreragiten du sistema kontrolatzeko. Web atari bat, komando lerroko aplikazio bat (CLI) edo beste interfazeren bat izan daiteke. Erabiltzaile interfazea erabiliz, operadoreak sistemaren konfigurazio-parametro globaletarako sarbidea du, hala nola:
  • Inplementazio kontrola, trantsizio urdina/berdea eta/edo pixkanaka trafikoa
  • Autentifikazio eta Baimen Aukerak
  • Bideratze-taularen zehaztapenak, adibidez A aplikazioak "/foo"-ri buruz gertatzen denari buruzko informazioa eskatzen duenean
  • Karga-orekatzailearen ezarpenak, hala nola, denbora-mugak, berriro saiakerak, zirkuitu-hausturaren ezarpenak, etab.
• Lan-kargaren programatzailea: Zerbitzuak azpiegituran exekutatzen dira programazio/orkestrazio sistemaren baten bidez, hala nola Kubernetes edo Nomad. Antolatzailea bere proxy lokalarekin batera zerbitzua kargatzeaz arduratzen da.
• Zerbitzuaren aurkikuntza. Antolatzaileak zerbitzu-instantziak abiarazten eta gelditzen dituenean, osasun-egoeraren berri ematen dio zerbitzuen aurkikuntza-sistemari.
• Sidecar proxy konfigurazio APIak : Tokiko proxyek sistemaren osagai ezberdinetatik egoera dinamikoki ateratzen dute azkenean eredu koherente bat erabiliz, operadorearen esku-hartzerik gabe. Sistema osoa, gaur egun martxan dauden zerbitzu-instantzia guztiek eta proxy-zerbitzari lokalek osatua, azkenean ekosistema batean bat egiten du. Envoy-en datu-plano unibertsalaren APIa praktikan funtzionatzen duenaren adibide bat da.

Funtsean, kontrol-planoaren helburua azken finean datu-planoak onartuko duen politika ezartzea da. Kontrol-hegazkin aurreratuagoek sistema batzuen zati gehiago kenduko dizkiote operadoreari eta eskuzko funtzionamendu gutxiago beharko dute, behar bezala funtzionatzen badute!...

Datu-planoa eta kontrol-planoa. Datu-planoa vs kontrol-planoaren laburpena

• Zerbitzu sareko datu-planoa: Sistemako pakete/eskaera guztiei eragiten die. Aplikazio/zerbitzuen aurkikuntza, osasun-egiaztapena, bideratzea, karga orekatzea, autentifikazioa/baimena eta behagarritasunaz arduratzen da.
• Zerbitzu-sarearen kontrol-hegazkina: Zerbitzu-sareko datu-plano guztien politika eta konfigurazioa eskaintzen ditu. Ez du sistemako pakete/eskaerarik ukitzen. Kontrol-planoak datu-plano guztiak sistema banatu batean bihurtzen ditu.

Egungo proiektuaren paisaia

Goiko azalpena ulertuta, ikus dezagun zerbitzu sarearen proiektuaren egungo egoera.

• Datu-planoak: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Kontrol-hegazkinak: Istio, Nelson, SmartStack

Goiko soluzio bakoitzaren azterketa sakonean sartu beharrean, oraintxe bertan ekosisteman nahasmen handia eragiten ari diren puntu batzuk labur-labur jorratuko ditut.

Linkerd zerbitzu sarerako datu-hegazkineko lehen proxy zerbitzarietako bat izan zen 2016 hasieran eta lan bikaina egin du zerbitzu sarearen diseinuaren ereduari buruzko kontzientzia eta arreta pizteko. Handik 6 hilabete inguru, Envoy Linkerd-ekin sartu zen (nahiz eta Lyft-ekin egon 2015 amaieratik). Linkerd eta Envoy dira zerbitzuen sareak eztabaidatzerakoan gehien aipatzen diren bi proiektuak.

Istio 2017ko maiatzean iragarri zen. Istio proiektuaren helburuak erakusten den kontrol hedatuaren planoaren oso antzekoak dira 3. irudia. Istiorako Envoy da proxy lehenetsia. Horrela, Istio da kontrol-hegazkina, eta Envoy-a datu-planoa. Denbora gutxian, Istio-k zirrara handia sortu zuen, eta beste datu-hegazkin batzuk Envoy-en ordezko gisa integratzen hasi ziren (Linkerdek eta NGINXek Istio-rekin integrazioa frogatu zuten). Kontrol-plano berean datu-plano desberdinak erabil daitezkeela esan nahi du kontrol-planoa eta datu-planoa ez daudela zertan estu lotuak. Envoy-en datu-plano generikoaren API bezalako API batek sistemaren bi atalen arteko zubi bat osa dezake.

Nelson eta SmartStack-ek kontrol-planoaren eta datu-planoaren bereizketa gehiago erakusten laguntzen dute. Nelsonek Envoy erabiltzen du proxy gisa eta HashiCorp pilan oinarritutako zerbitzu-sarerako kontrol-plano fidagarri bat eraikitzen du, hau da. Nomada, etab. SmartStack zerbitzu-sareen olatu berri baten lehena izan zen agian. SmartStack-ek HAProxy edo NGINX inguruan kontrol-plano bat eraikitzen du, zerbitzu-saretik kontrol-planoa datu-planotik desakoplatzeko gaitasuna erakutsiz.

Zerbitzu-sare bat duen mikrozerbitzuen arkitektura gero eta arreta handiagoa hartzen ari da (ondo dago!), eta gero eta proiektu eta saltzaile gehiago hasten dira norabide horretan lanean. Datozen urteetan berrikuntza asko ikusiko ditugu bai datu-planoan, bai kontrol-planoan, baita osagai ezberdinen nahasketa gehiago ere. Azken finean, mikrozerbitzuen arkitektura gardenagoa eta magikoagoa (?) bihurtu beharko litzateke operadorearentzat.
Zorionez, gero eta gutxiago haserretu.

Eramateko gakoak

• Zerbitzu-sare batek bi zati ezberdin ditu: datu-planoa eta kontrol-planoa. Bi osagaiak behar dira, eta horiek gabe sistemak ez du funtzionatuko.
• Guztiek ezagutzen dute kontrol-hegazkina, eta une honetan, kontrol-hegazkina zu izan zaitezke!
• Datu-plano guztiak elkarren artean lehiatzen dira ezaugarrietan, errendimenduan, konfiguragarritasunean eta hedagarritasunean.
• Kontrol-plano guztiak elkarren artean lehiatzen dira ezaugarrietan, konfiguragarritasunean, hedagarritasunean eta erabiltzeko erraztasunean.
• Kontrol-plano batek abstrakzio eta API egokiak izan ditzake, datu-plano anitz erabili ahal izateko.

Iturria: www.habr.com