Interneten (zerbitzu sare), eta hona hemen beste bat. Aupa! Baina zergatik? Orduan, nire iritzia adierazi nahi dut hobe litzatekeela zerbitzu-sareak duela 10 urte agertuko balira, Docker eta Kubernetes bezalako edukiontzien plataformak agertu baino lehen. Ez dut esaten nire ikuspuntua besteena baino hobea edo txarragoa denik, baina zerbitzu-sareak animalia nahiko konplexuak direnez, ikuspuntu anitzek hobeto ulertzen lagunduko dute.
DotCloud plataformari buruz hitz egingo dut, ehun mikrozerbitzu baino gehiagotan eraiki zen eta edukiontzidun milaka aplikazio onartzen zituen. Garatzeko eta abiarazteko izan ditugun erronkak azalduko ditut, eta zerbitzu-sareek nola lagundu dezaketen (edo ezin izan duten).
dotCloud-en historia
DotCloud-en historiari eta plataforma honen arkitektura-aukerei buruz idatzi dut, baina ez dut asko hitz egin sare-geruzari buruz. Irakurketan murgildu nahi ez baduzu dotCloud-i buruz, hona hemen mamia laburbilduz: bezeroei hainbat aplikazio (Java, PHP, Python...) exekutatzeko aukera ematen dien PaaS plataforma-zerbitzu bat da, datu-sorta zabala onartzen duena. zerbitzuak (MongoDB, MySQL, Redis...) eta Heroku bezalako lan-fluxu bat: Zure kodea plataformara igotzen duzu, edukiontzien irudiak eraikitzen ditu eta zabaltzen ditu.
Trafikoa dotCloud plataformara nola bideratu zen kontatuko dizut. Ez bereziki polita zelako (nahiz eta sistemak bere garaian ondo funtzionatu zuen!), baizik eta batez ere tresna modernoekin halako diseinua talde xume batek denbora laburrean erraz inplementa dezakeelako trafikoa mordo baten artean bideratzeko modua behar badute. mikrozerbitzuen edo aplikazio mordo bat. Modu honetan, aukerak alderatu ditzakezu: zer gertatzen da dena zuk zeuk garatzen baduzu edo lehendik dagoen zerbitzu-sare bat erabiltzen baduzu. Aukera estandarra zuk zeuk egitea edo erostea da.
Ostatatutako aplikazioetarako trafikoaren bideratzea
DotCloud-eko aplikazioek HTTP eta TCP amaierako puntuak azal ditzakete.
HTTP amaierako puntuak dinamikoki gehitu da karga-orekatzailearen kluster konfigurazioan . Gaur egun baliabideek egiten dutenaren antzekoa da Kubernetes-en eta antzeko karga-orekatzailea .
Bezeroak HTTP amaierako puntuetara domeinu egokien bidez konektatzen dira, baldin eta domeinuaren izenak dotCloud karga-orekatzaileetara seinalatzen badu. Ezer berezia.
TCP amaierako puntuak ataka-zenbaki batekin lotuta, eta gero pila horretako edukiontzi guztietara pasatzen da ingurune-aldagaien bidez.
Bezeroak TCP amaierako puntuetara konekta daitezke ostalari-izena (gateway-X.dotcloud.com bezalako zerbait) eta ataka-zenbakia erabiliz.
Ostalari-izen hau "nats" zerbitzari-klusterra ebazten da (ez dago lotuta ), sarrerako TCP konexioak edukiontzi egokira bideratuko dituena (edo, karga orekatuko zerbitzuen kasuan, edukiontzi egokietara).
Kubernetes ezagutzen baduzu, ziurrenik Zerbitzuak gogoraraziko dizkizu .
Ez zegoen zerbitzu baliokiderik dotCloud plataforman : Erraztasunerako, zerbitzuetara modu berean sartzen ziren plataformaren barrutik zein kanpotik.
Dena erraz antolatu zen: HTTP eta TCP bideratze-sareen hasierako inplementazioak Python-eko ehunka lerro batzuk baino ez ziren ziurrenik. Plataforma hazi ahala eta eskakizun gehigarriak agertu ahala findu ziren algoritmo sinpleak (ingozoak esango nuke).
Ez zen beharrezkoa lehendik dagoen kodearen birfactorizazio zabala. Zehazki, zuzenean erabil dezake ingurune-aldagaien bidez lortutako helbidea.
Zertan ezberdintzen da zerbitzu-sare moderno batetik?
Mugatua ikusgarritasuna. Ez genuen inongo metrikarik TCP bideratze sarerako. HTTP bideratzeari dagokionez, geroagoko bertsioek HTTP neurketa zehatzak sartu zituzten errore-kodeekin eta erantzun-denborekin, baina zerbitzu-sare modernoak are urrunago doaz, Prometheus bezalako metrika bilketa sistemekin integrazioa eskaintzen baitute, adibidez.
Ikusgarritasuna oso garrantzitsua da ikuspuntu operatibotik ez ezik (arazoak konpontzen laguntzeko), baita funtzio berriak askatzen direnean ere. Segurua da ΠΈ .
Bideratzearen eraginkortasuna mugatua ere bada. dotCloud bideratze sarean, trafiko guztiak bideratze-nodo dedikatuen multzo batetik pasatu behar izan zuen. Horrek AZ (Eskuragarritasun Gunea) muga anitz zeharkatzea eta latentzia nabarmen handitzea ekarri zuen. Oroitzen naiz orrialde bakoitzeko ehun SQL kontsulta baino gehiago egiten eta SQL zerbitzarirako konexio berri bat irekitzea kontsulta bakoitzerako arazoak konpontzea. Lokalean exekutatzen denean, orria berehala kargatzen da, baina dotCloud-en segundo batzuk behar dira kargatzeko, TCP konexio bakoitzak (eta ondorengo SQL kontsultak) hamarnaka milisegundo hartzen dituelako. Kasu zehatz honetan, etengabeko konexioek arazoa konpondu zuten.
Zerbitzu-sare modernoak hobeak dira arazo horiei aurre egiteko. Lehenik eta behin, konexioak bideratuta daudela egiaztatzen dute iturrian. Fluxu logikoa berdina da: ΠΊΠ»ΠΈΠ΅Π½Ρ β ΠΌΠ΅Ρ β ΡΠ΅ΡΠ²ΠΈΡ, baina orain sareak lokalean funtzionatzen du eta ez urruneko nodoetan, beraz, konexioa ΠΊΠ»ΠΈΠ΅Π½Ρ β ΠΌΠ΅Ρ lokala eta oso azkarra da (mikrosegundoak milisegundoen ordez).
Zerbitzu-sare modernoek karga orekatzeko algoritmo adimentsuak ere ezartzen dituzte. Backend-en osasuna kontrolatuz, trafiko gehiago bidal dezakete backend azkarragoetara, eta, ondorioz, errendimendu orokorra hobetuko da.
ΠΠ΅Π·ΠΎΠΏΠ°ΡΠ½ΠΎΡΡΡ hobeto ere. DotCloud bideratze-sarea EC2 Classic-en exekutatzen zen guztiz eta ez zuen trafikoa enkriptatu (norbaitek EC2 sareko trafikoan sniffer bat jartzea lortuko balu, arazo handiak izango zinela uste zuen). Zerbitzu-sare modernoek gure trafiko guztia modu gardenean babesten dute, adibidez, elkarrekiko TLS autentifikazioarekin eta ondorengo enkriptazioarekin.
Plataforma-zerbitzuetarako trafikoa bideratzea
Ados, aplikazioen arteko trafikoa eztabaidatu dugu, baina zer gertatzen da dotCloud plataforma bera?
Plataformak berak ehun bat mikrozerbitzuz osatuta zegoen hainbat funtzioz arduratzen ziren. Batzuek beste batzuen eskaerak onartu zituzten, eta beste batzuk beste zerbitzu batzuetara konektatzen ziren baina ez zuten konexiorik onartzen. Nolanahi ere, zerbitzu bakoitzak konektatu behar dituen helbideen amaiera-puntuak ezagutu behar ditu.
Goi-mailako zerbitzu askok goian azaldutako bideratze-sarea erabil dezakete. Izan ere, dotCloud-en ehunetik gora mikrozerbitzu asko aplikazio arrunt gisa zabaldu dira dotCloud plataforman bertan. Baina maila baxuko zerbitzu kopuru txiki batek (batez ere bideratze-sare hori inplementatzen dutenek) zerbait sinpleagoa behar zuten, mendekotasun gutxiagorekin (ez baitziren beren buruaren menpe funtzionatzeko - oilasko eta arrautzaren arazo zaharra).
Maila baxuko zerbitzu kritiko hauek edukiontziak zuzenean gako nodo gutxi batzuetan exekutatzen hasi ziren. Kasu honetan, plataforma-zerbitzu estandarrak ez dira erabili: linker, scheduler eta runner. Edukiontzi-plataforma modernoekin alderatu nahi baduzu, kontrol-hegazkina exekutatu bezala da docker run zuzenean nodoetan, zeregina Kubernetesen esku utzi beharrean. Kontzeptu aldetik nahiko antzekoa da , erabiltzen duena edo cluster autonomo bat abiaraztean.
Zerbitzu hauek modu sinple eta gordinean azaltzen ziren: YAML fitxategi batek haien izenak eta helbideak zerrendatzen zituen; eta bezero bakoitzak YAML fitxategi honen kopia bat hartu behar izan zuen zabaltzeko.
Alde batetik, oso fidagarria da, ez duelako kanpoko gako/balioen denda baten laguntza behar, esate baterako, Zookeeper (gogoratu, etcd edo Consul ez zegoela garai hartan). Bestalde, zerbitzuak mugitzea zaildu zuen. Mugimendu bat egiten zen bakoitzean, bezero guztiek YAML fitxategi eguneratua jasoko zuten (eta baliteke berrabiarazi). Ez oso erosoa!
Ondoren, eskema berri bat ezartzen hasi ginen, non bezero bakoitza proxy zerbitzari lokal batera konektatzen zen. Helbide eta ataka baten ordez, zerbitzuaren ataka-zenbakia bakarrik jakin behar du, eta bidez konektatu localhost. Tokiko proxyak konexio hau kudeatzen du eta benetako zerbitzarira birbidaltzen du. Orain, backend-a beste makina batera mugitzean edo eskalatzean, bezero guztiak eguneratu beharrean, tokiko proxy horiek guztiak eguneratu besterik ez dituzu behar; eta jada ez da beharrezkoa berrabiarazi.
(Trafikoa TLS konexioetan kapsulatzea eta hartzailearen aldean beste proxy zerbitzari bat jartzea ere aurreikusi zen, baita hartzailearen zerbitzuaren parte-hartzerik gabe TLS ziurtagiriak egiaztatzea ere, konexioak soilik onartzeko konfiguratuta dagoena. localhost. Honi buruz gehiago geroago).
Honen oso antzekoa da Airbnb-tik, baina diferentzia esanguratsua da SmartStack inplementatu eta ekoizpenean zabaltzen dela, dotCloud-en barne bideratze sistema dotCloud Docker bihurtu zenean bertan behera geratu zen bitartean.
Pertsonalki, SmartStack Istio, Linkerd eta Consul Connect bezalako sistemen aurrekoetako bat dela uste dut, guztiek eredu bera jarraitzen dutelako:
- Exekutatu proxy bat nodo bakoitzean.
- Bezeroak proxyra konektatzen dira.
- Kontrol-planoak proxy konfigurazioa eguneratzen du backendak aldatzen direnean.
- ... Irabazi!
Zerbitzu sare baten ezarpen modernoa
Gaur egun antzeko sare bat ezarri beharko bagenu, antzeko printzipioak erabil genitzake. Adibidez, konfiguratu barneko DNS eremu bat zerbitzuen izenak espazioko helbideekin mapatuz 127.0.0.0/8. Ondoren exekutatu HAProxy klusterreko nodo bakoitzean, konexioak onartuz zerbitzu-helbide bakoitzean (azpisare horretan 127.0.0.0/8) eta karga backend egokietara birbideratu/orekatzea. HAProxy konfigurazioa kontrolatu daiteke , backend informazioa etcd edo Consul-en gordetzeko eta automatikoki konfigurazio eguneratua HAProxyra bidali behar duzunean.
Horrela funtzionatzen du Istio! Baina desberdintasun batzuekin:
- Erabilerak HAProxy-ren ordez.
- Backend-aren konfigurazioa gordetzen du Kubernetes APIaren bidez, etcd edo Consul-en ordez.
- Zerbitzuak barne azpisarean esleitzen dira helbideak (Kubernetes ClusterIP helbideak) 127.0.0.0/8 beharrean.
- Osagai gehigarri bat du (Ziudadela) bezeroaren eta zerbitzarien artean TLS autentifikazio elkarrekikoa gehitzeko.
- Ezaugarri berriak onartzen ditu, hala nola, zirkuitu-haustura, traza banatua, canary inplementazioa, etab.
Ikus ditzagun desberdintasun batzuk azkar.
Envoy Proxy
Envoy Proxy Lyft-ek [Uber-en lehiakidea taxien merkatuan idatzi zuen - gutxi gorabehera. erreia]. Modu askotan antzekoa da beste proxy batzuen (adibidez, HAProxy, Nginx, Traefik...), baina Lyft-ek berea idatzi zuen, beste proxiek falta zituzten ezaugarriak behar zituztelako, eta adimentsuagoa zirudien berri bat egitea lehendik zegoena luzatzea baino.
Envoy bere kabuz erabil daiteke. Beste zerbitzu batzuetara konektatu behar duen zerbitzu espezifiko bat badut, Envoy-era konektatzeko konfiguratu dezaket, eta, ondoren, Envoy modu dinamikoan konfiguratu eta birkonfiguratu dezaket beste zerbitzu batzuen kokapenarekin, funtzionalitate osagarri handi asko lortuz, hala nola ikusgarritasuna. Bezero liburutegi pertsonalizatu baten ordez edo deien arrastoak kodean sartu beharrean, Envoy-era trafikoa bidaltzen dugu, eta neurketak biltzen dizkigu.
Baina Envoy gisa ere lan egiteko gai da datu-planoa (datu-planoa) zerbitzu-sarerako. Horrek esan nahi du Envoy zerbitzu-sare honetarako konfiguratuta dagoela kontrol-hegazkina (kontrol-hegazkina).
Kontrol-hegazkina
Kontrol-planorako, Istio Kubernetes APIan oinarritzen da. Hau ez da oso desberdina confd erabiltzearen aldean, etcd edo Consul-en oinarritzen dena datu biltegiko gakoen multzoa ikusteko. Istio-k Kubernetes APIa erabiltzen du Kubernetes baliabideen multzo bat ikusteko.
Honen eta geroaren artean: Pertsonalki hau erabilgarria iruditu zait hau dioena:
Kubernetes API Zerbitzaria "zerbitzari mutu" bat da, API baliabideetarako biltegiratzea, bertsioa, baliozkotzea, eguneratzea eta semantika eskaintzen duena.
Istio Kubernetesekin lan egiteko diseinatuta dago; eta Kubernetesetik kanpo erabili nahi baduzu, Kubernetes API zerbitzariaren instantzia bat exekutatu behar duzu (eta etcd laguntzaile zerbitzua).
Zerbitzu-helbideak
Istio Kubernetes-ek esleitzen dituen ClusterIP helbideetan oinarritzen da, beraz, Istio zerbitzuek barne helbide bat jasotzen dute (ez dago barrutian 127.0.0.0/8).
Istiorik gabeko Kubernetes kluster bateko zerbitzu zehatz baterako ClusterIP helbiderako trafikoa kube-proxy-k atzematen du eta proxy horren backend-era bidaltzen du. Xehetasun teknikoak interesatzen bazaizkizu, kube-proxy-k iptables arauak (edo IPVS karga-orekatzaileak, konfiguratzen denaren arabera) ezartzen ditu ClusterIP helbidera doazen konexioen helmugako IP helbideak berridazteko.
Istio Kubernetes kluster batean instalatuta dagoenean, ez da ezer aldatzen kontsumitzaile jakin baterako esplizituki gaitzen den arte, ezta izen-espazio osoa ere, edukiontzi bat sartuz. sidecar ontzi pertsonalizatuetan. Edukiontzi honek Envoy-en instantzia bat sortuko du eta iptables arau multzo bat ezarriko du beste zerbitzu batzuetara doan trafikoa atzemateko eta trafiko hori Envoy-era birbideratzeko.
Kubernetes DNS-ekin integratuta dagoenean, horrek esan nahi du gure kodea zerbitzu-izenaren arabera konektatu daitekeela eta dena "funtzionatzen du". Beste era batera esanda, gure kodeak bezalako kontsultak egiten ditu http://api/v1/users/4242gero api eskaera ebatzi 10.97.105.48, iptables-en arauek 10.97.105.48-ko konexioak atzeman eta tokiko Envoy proxyra birbidaliko dituzte, eta proxy lokal horrek benetako backend APIra bidaliko du eskaera. Uf!
Horma osagarriak
Istio-k muturreko enkriptatzea eta autentifikazioa ere eskaintzen ditu mTLS (elkarrekiko TLS) bidez. izeneko osagai bat Ziudadela.
Osagai bat ere badago Mixer, Envoy-ek eska dezakeena bakoitzeko eskaera horri buruzko erabaki berezi bat hartzeko eskaera hainbat faktoreren arabera, hala nola goiburuak, backend karga, etab... (ez kezkatu: Mixer martxan mantentzeko modu asko daude, eta huts egiten badu ere, Envoy-ek lanean jarraituko du. ondo proxy gisa).
Eta, noski, ikusgarritasuna aipatu dugu: Envoy-ek neurketa ugari biltzen ditu trazadura banatua eskaintzen duen bitartean. Mikrozerbitzuen arkitektura batean, API eskaera bakar batek A, B, C eta D mikrozerbitzuetatik pasatu behar badu, orduan saioa hasten denean, banatutako trazatzeak identifikatzaile esklusibo bat gehituko dio eskaerari eta identifikatzaile hori gordeko du mikrozerbitzu guztietarako azpieskaeren bidez, ahalbidetuz. atzeman beharreko erlazionatutako dei guztiak, atzerapenak, etab.
Garatu edo erosi
Istio konplexua izatearen fama du. Aitzitik, argitalpen honen hasieran deskribatu dudan bideratze-sarea eraikitzea nahiko erraza da lehendik dauden tresnak erabiliz. Beraz, zentzurik al du zure zerbitzu sarea sortzea ordez?
Behar xumeak baditugu (ez dugu ikusgarritasunik, etengailurik eta bestelako Γ±abardurarik behar), orduan pentsamenduak etortzen dira gure tresna propioa garatzeko. Baina Kubernetes erabiltzen badugu, agian ez da beharrezkoa izango, Kubernetes-ek dagoeneko oinarrizko tresnak eskaintzen dituelako zerbitzuak aurkitzeko eta karga orekatzeko.
Baina eskakizun aurreratuak baditugu, orduan zerbitzu-sare bat "erostea" aukera askoz hobea dela dirudi. (Hau ez da beti "erosketa" bat Istio kode irekia delako, baina oraindik ingeniaritza denbora inbertitu behar dugu hura ulertzeko, zabaldu eta kudeatzeko.)
Istio, Linkerd edo Consul Connect aukeratu behar dut?
Orain arte Istiori buruz bakarrik hitz egin dugu, baina hau ez da zerbitzu sare bakarra. Alternatiba ezaguna - , eta gehiago dago .
Zer aukeratu?
Egia esan, ez dakit. Momentuz ez dut nire burua galdera honi erantzuteko adina gaitasunik ikusten. Gutxi daude tresna hauen konparaketa batekin eta are .
Ikuspegi itxaropentsu bat bezalako tresna bat erabiltzea da . Abstrakzio-geruza bat inplementatzen du zerbitzu-sareek erakusten dituzten APIak sinplifikatzeko eta bateratzeko. Zerbitzu-sare ezberdinen API espezifikoak (eta, nire ustez, nahiko konplexuak) ikasi beharrean, SuperGloo-ren eraikuntza sinpleagoak erabil ditzakegu, eta erraz alda ditzakegu batetik bestera, HTTP interfazeak eta backend-ak deskribatzen dituen bitarteko konfigurazio formatua izango bagenu bezala. Nginx, HAProxy, Traefik, Apache... konfigurazio erreala sortzeko.
Istio eta SuperGloo-rekin pixka bat ibili naiz, eta hurrengo artikuluan Istio edo Linkerd lehendik dagoen kluster bati SuperGloo erabiliz nola gehitzen den erakutsi nahi dut, eta azken honek lana nola egiten duen, hau da, batetik bestera aldatzeko aukera ematen dizu. zerbitzu sare bat beste batera konfigurazioak gainidatzi gabe.
Iturria: www.habr.com