Oporrak amaitu dira eta Istio Service Mesh serieko bigarren mezuarekin itzuli gara.
Gaurko gaia Circuit Breaker da, errusieraz ingeniaritza elektrikora itzulita "disengailua" esan nahi du, hizkera arruntean - "disengailua". Istioan bakarrik makina honek ez du zirkuitu laburtu edo gainkargatuta deskonektatzen, akastun diren edukiontziak baizik.
Nola funtzionatu behar duen hau ezin hobean
Mikrozerbitzuak Kubernetes-ek kudeatzen dituenean, adibidez OpenShift plataformaren barruan, automatikoki igo eta behera egiten dute kargaren arabera. Mikrozerbitzuak podetan exekutatzen direnez, edukiontzidun mikrozerbitzu baten instantzia bat baino gehiago egon daitezke amaiera puntu batean, eta Kubernetes-ek eskaerak eta karga-oreka bideratuko ditu haien artean. Eta, hoberena, horrek guztiak primeran funtzionatu beharko luke.
Gogoratzen dugu mikrozerbitzuak txikiak eta iragankorrak direla. Efimerotasuna, hemen agertzeko eta desagertzeko erraztasuna esan nahi duena, gutxietsi ohi da. Pod batean mikrozerbitzu baten beste instantzia baten jaiotza eta heriotza nahiko espero diren gauzak dira, OpenShift-ek eta Kubernetes-ek ondo kudeatzen dute hori, eta dena ondo funtzionatzen du, baina berriro ere teorian.
Benetan nola funtzionatzen duen
Orain imajinatu mikrozerbitzu baten instantzia zehatz bat, hau da, edukiontzi bat, erabilezin bihurtu dela: edo ez duela erantzuten (503 errorea), edo, desatsegina dena, erantzuten duela, baina astiroegi. Beste era batera esanda, glitchy bihurtzen da edo ez die eskaerei erantzuten, baina ez da automatikoki igerilekutik kentzen. Zer egin behar da kasu honetan? Berriro saiatzeko? Bideratze-eskematik kendu behar al dut? Eta zer esan nahi du "motelegia": zenbat da kopurutan, eta nork zehazten ditu? Agian atseden bat eman eta berriro saiatu geroago? Hala bada, zenbat geroago?
Zer da Pool Ejection Istio-n
Eta hemen Istio erreskatatzera dator bere Circuit Breaker babesteko makinekin, bideratze eta karga orekatzeko baliabideen biltegitik aldi baterako edukiontzi akastunak kentzen dituztenak, Pool Ejection prozedura ezarriz.
Ezohikoak detektatzeko estrategia bat erabiliz, Istio-k lerrotik kanpo dauden kurba-potak detektatzen ditu eta baliabide-biltegitik kentzen ditu denbora jakin batean, lo-leiho deitzen dena.
Honek nola funtzionatzen duen Kubernetes-en OpenShift plataforman, has gaitezen normalean funtzionatzen duten mikrozerbitzuen pantaila-argazkia biltegiko adibidetik. . Hemen bi lekak ditugu, v1 eta v2, bakoitzak edukiontzi bat martxan jarrita. Istio bideratze-arauak erabiltzen ez direnean, Kubernetes-ek bideratze borobil orekatua du lehenetsita:
Porroterako prestatzen
Pool Ejection egin aurretik, Istio bideratze-arau bat sortu behar duzu. Demagun eskaerak leken artean banatu nahi ditugula 50/50 proportzioan. Gainera, v2 edukiontzien kopurua bat izatetik bi izatera igoko dugu, honela:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Orain bideratze-arau bat ezarri dugu, trafikoa poden artean 50/50 ratioan banatu dadin.
Hona hemen arau honen emaitza nolakoa den:
Pantaila hau 50/50 ez dela, 14:9 baizik eta denborarekin egoera hobetuko da akatsa aurki dezakezu.
Errore bat egitea
Orain desgaitu dezagun bi v2 edukiontzietako bat, v1 edukiontzi osasuntsu bat, v2 edukiontzi osasuntsu bat eta v2 edukiontzi akastun bat izan dezagun:
Akatsa konpontzen
Beraz, edukiontzi akastun bat dugu, eta igerilekuaren kanporaketa garaia da. Oso konfigurazio sinple bat erabiliz, huts egin duen edukiontzi hau edozein bideratze-eskemetatik baztertuko dugu 15 segundoz, egoera osasuntsu batera itzuliko den itxaropenarekin (berrabiarazi edo errendimendua berrezarri). Hau da konfigurazio honek eta bere lanaren emaitzak:
Ikus dezakezunez, huts egin duen v2 edukiontzia ez da gehiago bideratzeko eskaerak erabiltzen, igerilekutik kendu delako. Baina 15 segundoren buruan automatikoki itzuliko da igerilekura. Egia esan, Pool Ejection nola funtzionatzen duen erakutsi berri dugu.
Has gaitezen arkitektura eraikitzen
Pool Ejection, Istioren monitorizazio gaitasunekin konbinatuta, akatsak diren edukiontziak automatikoki ordezkatzeko esparru bat eraikitzen hasteko aukera ematen du, geldialdi-denbora eta akatsak murrizteko, ez bada ezabatzeko.
β
NASAk lelo ozen bat du - Porrota ez da aukera, horren egilea hegaldien zuzendaritzat hartzen da . Errusierara "Porrota ez da aukera" gisa itzul daiteke, eta hemen esanahia dena funtziona dezakeela da nahikoa borondate izanez gero. Hala ere, bizitza errealean porrotak ez dira bakarrik gertatzen, ezinbestekoak dira, nonahi eta denetan. Eta nola egin aurre mikrozerbitzuen kasuan? Gure ustez, hobe da ez borondatearengan fidatzea, edukiontzien gaitasunetan baizik, , Eta .
Istio, goian idatzi dugun bezala, etengailuen kontzeptua ezartzen du, mundu fisikoan ondo frogatu dena. Eta etengailu elektriko batek zirkuitu baten arazo-atal bat itzaltzen duen bezala, Istio-ren Circuit Breaker softwareak eskaera-korronte baten eta arazo-edukiontzi baten arteko konexioa irekitzen du amaierako puntuan zerbait gaizki dagoenean, adibidez, zerbitzaria huts egiten duenean edo hasten denean. lasaitu.
Gainera, bigarren kasuan arazo gehiago besterik ez daude, edukiontzi baten balaztek bertara iristen diren zerbitzuetan atzerapen-jauzi bat eragiten ez ezik, eta, ondorioz, sistema osoaren errendimendua murrizten baitute, baizik eta behin eta berriz errepikatzen dute. Dagoeneko motela martxan dagoen zerbitzu bati eskaerak egiten dizkio, eta horrek egoera larriagotu besterik ez du egiten.
Circuit Breaker teorian
Circuit Breaker amaiera puntu baterako eskaeren fluxua kontrolatzen duen proxy bat da. Puntu honek funtzionatzeari uzten dionean edo, zehaztutako ezarpenen arabera, moteltzen hasten denean, proxyak edukiontziarekiko konexioa hausten du. Ondoren, trafikoa beste edukiontzi batzuetara birbideratzen da, karga orekatzea dela eta. Konexioak irekita jarraitzen du lo-leiho jakin batean, demagun bi minututan, eta gero erdi irekitzat hartzen da. Hurrengo eskaera bidaltzeko saiakerak konexioaren egoera gehiago zehazten du. Zerbitzuarekin dena ondo badago, konexioa funtzionatzeko egoerara itzultzen da eta berriro itxi egiten da. Zerbitzuarekin oraindik zerbait gaizki badago, konexioa deskonektatu eta lo-leihoa berriro gaituko da. Hona hemen Circuit Breaker sinplifikatutako egoera diagrama baten itxura:
Garrantzitsua da hemen hau guztia sistema-arkitekturaren mailan gertatzen dela. Beraz, noizbait zure aplikazioei Circuit Breaker-ekin funtzionatzen irakatsi beharko diezu, esate baterako, erantzun gisa balio lehenetsi bat emanez edo, ahal bada, zerbitzua existitzen den alde batera utzita. Bulkhead eredua erabiltzen da horretarako, baina artikulu honen esparrutik kanpo dago.
Circuit Breaker praktikan
Adibidez, gure gomendioen mikrozerbitzuaren bi bertsio exekutatu egingo ditugu OpenShift-en. 1. bertsioak ondo funtzionatuko du, baina 2. bertsioan atzerapen bat eraikiko dugu zerbitzarian moteltzeak simulatzeko. Emaitzak ikusteko, erabili tresna :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Badirudi dena funtzionatzen duela, baina zer preziotan? Lehen begiratuan, % 100eko erabilgarritasuna dugu, baina begiratu arretaz: transakzioen gehienezko iraupena 12 segundokoa da. Hau, argi eta garbi, botila-lepo bat da eta zabaldu egin behar da.
Horretarako, Istio erabiliko dugu edukiontziak moteltzeko deiak ezabatzeko. Hau da dagokion konfigurazioa Circuit Breaker erabiliz:
httpMaxRequestsPerConnection parametroa duen azken lerroak konexioa deskonektatu behar dela adierazten du lehendik dagoenaz gain beste - bigarren - konexio bat sortzen saiatzean. Gure edukiontziak zerbitzu motela simulatzen duenez, horrelako egoerak aldian-aldian sortuko dira, eta orduan Istio-k 503 errore bat itzuliko du, baina hau da setioak erakutsiko duena:
Ados, Circuit Breaker dugu, zer da hurrengoa?
Beraz, itzaltze automatikoa ezarri dugu zerbitzuen iturburu kodea batere ukitu gabe. Circuit Breaker eta goian azaldutako Pool Ejection prozedura erabiliz, balazta-ontziak kendu ditzakegu baliabide-biltegitik normaltasunera itzuli arte, eta haien egoera egiaztatu maiztasun zehatz batean - gure adibidean, bi minutu dira (sleepWindow parametroa).
Kontuan izan aplikazio batek 503 errore bati erantzuteko duen gaitasuna iturburu-kode mailan ezarrita dagoela oraindik. Circuit Breaker erabiltzeko estrategia asko daude, egoeraren arabera.
Hurrengo mezuan: Dagoeneko Istio-n sartuta edo erraz gehitzen den trazadura eta monitorizazioari buruz hitz egingo dugu, baita nahita sisteman akatsak nola sartu ere.
Iturria: www.habr.com