"Arriskua da nire bigarren izena", esaten zuen Austin Powersek, nazioarteko gizon misteriotsu batek. Baina super agenteek eta inteligentzia zerbitzuek estimu handia dutena ez da batere egokia zerbitzu informatikoetarako, non aspertzea arriskua baino askoz hobea baita.
Eta Istio, OpenShift eta Kubernetesekin batera, mikrozerbitzuak zabaltzea benetan aspergarria eta aurreikusgarria da, eta hori bikaina da. Horretaz eta askoz gehiagoz hitz egingo dugu Istio serieko laugarren eta azken postuan.
Aspertzea egokia denean
Gure kasuan, asperdura azken fasean baino ez da gertatzen, prozesua eseri eta ikustea besterik ez dagoenean. Baina horretarako dena konfiguratu behar duzu lehenik, eta gauza interesgarri asko zain dituzu hemen.
Zure softwarearen bertsio berri bat zabaltzean, arriskuak gutxitzeko aukera guztiak kontuan hartzea merezi du. Paraleloan exekutatu probak egiteko modu oso indartsua eta frogatua da, eta Istio-k "zerbitzu sekretua" (zure mikrozerbitzuaren ezkutuko bertsioa) erabiltzeko aukera ematen dizu, ekoizpen-sistema oztopatu gabe. Epe berezi bat ere badago horretarako - "Dark Launch", zeina, aldi berean, "trafikoaren ispilu" izen espioitza duen funtzio batek aktibatzen duena.
Kontuan izan aurreko paragrafoko lehen esaldiak "zabaldu" terminoa erabiltzen duela "askatu" beharrean. Benetan zure mikrozerbitzua nahi adina zabaldu eta, noski, erabili ahal izango zenuke. Zerbitzu honek trafikoa jaso eta prozesatu, emaitzak ekoizteko eta erregistroetan idatzi eta monitorizatu ahal izan behar du. Baina, aldi berean, zerbitzu honek berak ez du zertan produkzioan kaleratu behar. Softwarea zabaltzea eta askatzea ez dira beti gauza bera. Nahi duzunean inplementa dezakezu, baina prest zaudenean bakarrik askatu.
Asperdura antolatzea interesgarria da
Begiratu hurrengo Istio bideratze-arauari, HTTP eskaera guztiak mikrozerbitzuen gomendioa v1 bideratzen dituena (adibide guztiak ), aldi berean gomendioa v2 mikrozerbitzuan islatzen dituen bitartean:
Erreparatu etiketari mirror: pantailaren behealdean - hau da trafikoaren ispilua ezartzen duena. Bai, hain erraza da!
Arau honen emaitza izango da zure ekoizpen-sistemak (v1) sarrerako eskaerak prozesatzen jarraituko duela, baina eskaerak beraiek modu asinkronoan islatuko dira v2-ra, hau da, haien bikoiztu osoak hara joango dira. Horrela, v2 baldintza errealetan probatu dezakezu - datu errealetan eta trafikoan - ekoizpen-sistemaren funtzionamenduan inolako interferentziarik gabe. Horrek probak antolatzea aspergarria egiten al du? Bai, zalantzarik gabe. Baina modu interesgarri batean egin da.
Gehi dezagun drama
Kontuan izan v2 kodean beharrezkoa dela sarrerako eskaerek datu aldaketak ekar ditzaketen egoeretarako. Eskaerak berak erraz eta garden islatzen dira, baina proban prozesatzeko metodoa aukeratzea zure esku dago, eta hori pixka bat kezkagarria da.
Errepikatu dezagun puntu garrantzitsu bat
Sekretua abiarazteko trafikoaren ispiluarekin (Dark Launch/Request Mirroring) egin daiteke kodeari inola ere eragin gabe.
Pentsatzeko janaria
Zer gertatzen da eskaerak islatzen diren lekuak horietako batzuk ez v1era, baizik eta v2ra bidaltzen baditu? Adibidez, eskaera guztien ehuneko bat edo erabiltzaile talde jakin baten eskaerak soilik. Eta gero, jada v2 nola funtzionatzen duen aztertzen, pixkanaka-pixkanaka transferitu eskaera guztiak bertsio berrira. Edo alderantziz, itzuli dena v1-era v2-rekin zerbait gaizki gertatzen bada. Uste dut Canary Deployment deitzen dela. , eta errusiar jatorrikoa izango balitz, ziurrenik erreferentzia bat izango luke ), eta orain zehatzago aztertuko dugu.
Kanariar Inplementazioa Istio-n: martxan jartzea sinplifikatuz
Kontuz eta pixkanaka
Canary Deployment hedapen-ereduaren funtsa oso erraza da: zure softwarearen bertsio berri bat abiarazten duzunean (gure kasuan, mikrozerbitzu bat), lehenik eta behin erabiltzaile talde txiki bati ematen diozu sarbidea. Dena ondo badoa, poliki-poliki talde hau handitzen duzu bertsio berria funtzionatzen hasi arte, edo, hala ez bada, erabiltzaile guztiak bertara migratzen dituzu. Bertsio berri bat arretaz eta pixkanaka sartuz eta erabiltzaileak modu kontrolatuan aldatuz gero, arriskuak murrizteko eta feedbacka maximizatu dezakezu.
Noski, Istio-k Canary Deployment errazten du eskaerak bideratze adimentsurako hainbat aukera on eskainiz. Eta bai, hori guztia zure iturburu kodea inola ere ukitu gabe egin daiteke.
Arakatzailea iragaztea
Bideratze-irizpide errazenetako bat arakatzailean oinarritutako birbideratzea da. Demagun Safari arakatzaileen eskaerak soilik v2ra joatea nahi duzula. Hona hemen nola egiten den:
Aplikatu dezagun bideratze-arau hau eta, ondoren, erabili komandoa curl Mikrozerbitzuari benetako eskaerak simulatuko dizkiogu begizta batean. Pantaila-argazkian ikus dezakezun bezala, guztiak v1era doaz:
Non dago trafikoa v2-n? Gure adibidean eskaera guztiak gure komando-lerrotik bakarrik etorri zirenez, besterik gabe, ez da existitzen. Baina erreparatu goiko pantailako beheko lerroei: Safari arakatzailearen eskaera bat exekutatu izanaren erreakzioa da, eta horrek hau sortu zuen:
Potentzia mugagabea
Dagoeneko idatzi dugu adierazpen erregularrek eskaerak bideratzeko gaitasun oso indartsuak ematen dituztela. Begiratu hurrengo adibideari (zer egiten duen ulertuko duzula uste dugu):
Honezkero ziurrenik adierazpen erregularrek zer egin dezaketen ideia bat izango duzu.
Jokatu Smart
Bideratze adimentsuak, batez ere esamolde erregularrak erabiliz paketeen goiburuak prozesatzeari esker, trafikoa nahi duzun moduan bideratzeko aukera ematen du. Eta horrek asko errazten du kode berriaren ezarpena - erraza da, ez du kodea bera aldatzea behar, eta beharrezkoa izanez gero, dena azkar itzul daiteke lehen bezala.
Interesatuta?
Irrikitan al zaude Istio, Kubernetes eta OpenShift-ekin zure ordenagailuan esperimentatzeko? Taldea bikaina prestatu zuen gai honi buruz eta horrekin batera doan fitxategi guztiak jendaurrean jarri zituen. Beraz, aurrera eta ez ezazu ezer ukatu zeure buruari.
β
Istio Irteera: irteera oroigarri dendatik
Istio Red Hat OpenShift eta Kubernetesekin batera erabiliz gero, zure bizitza askoz erraztu dezakezu mikrozerbitzuekin. Istio-ren zerbitzu-sarea Kubernetes-en ontzien barruan ezkutatuta dago, eta zure kodea modu isolatuan exekutatzen da (gehienetan). Errendimendua, aldatzeko erraztasuna, trazadura, etab. β hau guztia erraza da erabiltzeko alboko edukiontzien erabilerari esker. Baina zer gertatzen da zure mikrozerbitzuak zure OpenShift-Kubernetes sistematik kanpo dauden beste zerbitzu batzuekin komunikatu behar badu?
Hemen da Istio Egress erreskatatzera. Laburbilduz, Kubernetes-en sistemaren parte ez diren baliabideak (irakurri: "zerbitzuak") sartzeko aukera ematen dizu. Ez baduzu konfigurazio gehigarririk egiten, Istio Egress ingurunean trafikoa pod-kluster baten barruan eta barne IP tauletan oinarritutako klusterren artean soilik bideratzen da. Eta horrelako pupazioak oso ondo funtzionatzen du kanpotik zerbitzuetarako sarbidea behar ez duzun bitartean.
Irteerak goiko IP taulak saihesteko aukera ematen du, Irteera arauetan edo IP helbide sorta batean oinarrituta.
Demagun Java programa bat dugula httpbin.org/headers helbidera GET eskaera bat egiten duena.
(httpbin.org irteerako zerbitzu-eskaerak probatzeko baliabide erosoa besterik ez da.)
Komando-lerroan sartzen bazara curl http://httpbin.org/headers, honako hauek ikusiko ditugu:
Edo helbide bera ireki dezakezu arakatzailean:
Ikus dezakezunez, bertan kokatutako zerbitzuak hari pasatu zaizkion goiburuak besterik gabe itzultzen ditu.
Inportazioak buru-belarri ordezkatzen ari gara
Orain har dezagun zerbitzu honen Java kodea, gure sistematik kanpokoa, eta exekutatu dezagun gure kabuz, non, gogoratu, Istio instalatuta dagoen. (Zuk egin dezakezu kontaktuan jarriz .) Irudi egokia eraiki eta OpenShift plataforman abiarazi ondoren, zerbitzu honi komandoarekin deituko diogu. curl egresshttpbin-istioegress.$(minishift ip).nip.io, ondoren hau ikusiko dugu pantailan:
Aupa, zer gertatu da? Dena funtzionatu zuen. Zer esan nahi du Ez aurkitu abizenak? Berarentzat besterik ez dugu egin curl.
IP taulak Internet osora hedatzea
Honen errua (edo eskertu) behar zaio Istio. Azken finean, Istio detekzioaz eta bideratzeaz arduratzen diren sidecar edukiontziak besterik ez dira (eta lehen hitz egin ditugun beste gauza asko). Hori dela eta, IP taulek zure kluster sistemaren barruan zer dagoen baino ez dakite. Eta httpbin.org kanpoan kokatuta dago eta, beraz, eskuraezina. Eta hemen da Istio Egress erreskatatzera - zure iturburu-kodean aldaketa txikienik gabe.
Beheko Egress arauak Istio behartzen du (beharrezkoa bada, gero Internet osoan) behar den zerbitzua bilatzeko, kasu honetan, httpbin.org. Fitxategi honetan (egress_httpbin.yml) ikus dezakezunez, hemengo funtzionaltasuna nahiko erraza da:
Arau hau aplikatzea besterik ez da geratzen:
istioctl create -f egress_httpbin.yml -n istioegress
Komandoarekin Irteera arauak ikus ditzakezu istioctl get egressrules:
Eta azkenik, komandoa berriro exekutatzen dugu curl - eta dena funtzionatzen duela ikusten dugu:
Argi eta garbi pentsatzen dugu
Ikus dezakezunez, Istiok kanpoko munduarekiko interakzioa antolatzeko aukera ematen du. Beste era batera esanda, oraindik OpenShift zerbitzuak sor ditzakezu eta Kubernetes-en bidez kudeatu, dena behar den neurrian gora eta behera eskalatzen duten podetan gordez. Eta, aldi berean, zure ingurunetik kanpoko zerbitzuetara segurtasunez sar zaitezke. Eta bai, berriro errepikatzen dugu hori guztia egin daitekeela zure kodea inola ere ukitu gabe.
Hau izan da Istioko serieko azken mezua. Egon adi - gauza interesgarri asko daude aurretik!
Iturria: www.habr.com