Pushimet mbaruan dhe ne jemi rikthyer me postimin tonë të dytë në serinë Istio Service Mesh.
Tema e sotme është Ndërprerësi, që përkthyer në rusisht inxhinieri elektrike do të thotë "ndërprerës qarku", në gjuhën e zakonshme - "ndërprerës qarku". Vetëm në Istio kjo makinë nuk shkëput qarkun e shkurtuar apo të mbingarkuar, por kontejnerët me defekt.
Si duhet të funksionojë kjo në mënyrë ideale
Kur mikroshërbimet menaxhohen nga Kubernetes, për shembull brenda platformës OpenShift, ato rriten dhe zvogëlohen automatikisht në varësi të ngarkesës. Për shkak se mikroshërbimet funksionojnë në pods, mund të ketë raste të shumta të një mikroshërbimi të kontejneruar në një pikë fundore dhe Kubernetes do të drejtojë kërkesat dhe do të ngarkojë balancën midis tyre. Dhe - në mënyrë ideale - e gjithë kjo duhet të funksionojë në mënyrë perfekte.
Kujtojmë se mikroshërbimet janë të vogla dhe kalimtare. Kalueshmëria, që këtu nënkupton lehtësinë e shfaqjes dhe zhdukjes, shpesh nënvlerësohet. Lindja dhe vdekja e një shembulli tjetër të një mikroshërbimi në një pod janë gjëra mjaft të pritshme, OpenShift dhe Kubernetes e trajtojnë mirë këtë, dhe gjithçka funksionon shkëlqyeshëm - por përsëri në teori.
Si funksionon në të vërtetë
Tani imagjinoni që një shembull specifik i një mikroservice, domethënë një kontejner, është bërë i papërdorshëm: ose nuk përgjigjet (gabimi 503), ose, çfarë është më e pakëndshme, përgjigjet, por shumë ngadalë. Me fjalë të tjera, ai bëhet me shkëlqim ose nuk i përgjigjet kërkesave, por nuk hiqet automatikisht nga pishina. Çfarë duhet bërë në këtë rast? Për të riprovuar? A duhet ta heq nga skema e rrugëzimit? Dhe çfarë do të thotë "shumë i ngadalshëm" - sa është në numër dhe kush i përcakton ato? Ndoshta thjesht jepni një pushim dhe provoni përsëri më vonë? Nëse po, sa më vonë?
Çfarë është Pool Ejection në Istio
Dhe këtu Istio vjen në ndihmë me makinat e tij të mbrojtjes Circuit Breaker, të cilat heqin përkohësisht kontejnerët me defekt nga rezervuari i burimeve të rrugëzimit dhe balancimit të ngarkesës, duke zbatuar procedurën Pool Ejection.
Duke përdorur një strategji zbulimi të jashtëzakonshëm, Istio zbulon grupet e kurbës që janë jashtë linjës dhe i heq ato nga grupi i burimeve për një kohë të caktuar, të quajtur dritare gjumi.
Për të treguar se si funksionon kjo në Kubernetes në platformën OpenShift, le të fillojmë me një pamje të mikroshërbimeve që funksionojnë normalisht nga shembulli në depo . Këtu kemi dy pods, v1 dhe v2, secila me një enë. Kur rregullat e rrugëtimit Istio nuk përdoren, Kubernetes vendos në mënyrë të paracaktuar një rrugëtim të balancuar në mënyrë të barabartë:
Duke u përgatitur për një përplasje
Përpara se të bëni Pool Ejection, duhet të krijoni një rregull të rrugëtimit Istio. Le të themi se duam të shpërndajmë kërkesat midis grupeve në një raport 50/50. Për më tepër, ne do të rrisim numrin e kontejnerëve v2 nga një në dy, si kjo:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Tani ne vendosim një rregull rrugëtimi në mënyrë që trafiku të shpërndahet midis pods në një raport 50/50.
Ja si duket rezultati i këtij rregulli:
Ju mund të gjeni gabime me faktin se ky ekran nuk është 50/50, por 14:9, por me kalimin e kohës situata do të përmirësohet.
Duke bërë një defekt
Tani le të çaktivizojmë një nga dy kontejnerët v2 në mënyrë që të kemi një kontejner v1 të shëndetshëm, një kontejner v2 të shëndetshëm dhe një kontejner v2 me defekt:
Rregullimi i defektit
Pra, ne kemi një enë të gabuar dhe është koha për Pool Ejection. Duke përdorur një konfigurim shumë të thjeshtë, ne do ta përjashtojmë këtë kontejner të dështuar nga çdo skemë rrugëtimi për 15 sekonda me shpresën se do të kthehet në një gjendje të shëndetshme (ose rinisni ose rivendosni performancën). Kjo është se si duket ky konfigurim dhe rezultatet e funksionimit të tij:
Siç mund ta shihni, kontejneri i dështuar v2 nuk përdoret më për kërkesat e rrugëtimit sepse është hequr nga grupi. Por pas 15 sekondash do të kthehet automatikisht në pishinë. Në fakt, ne sapo treguam se si funksionon Pool Ejection.
Le të fillojmë ndërtimin e arkitekturës
Pool Ejection, i kombinuar me aftësitë monitoruese të Istio, ju lejon të filloni të ndërtoni një kornizë për zëvendësimin automatik të kontejnerëve me defekt për të reduktuar, nëse jo eliminuar, kohën e ndërprerjes dhe dështimet.
NASA ka një moto me zë të lartë - Dështimi nuk është një opsion, autori i së cilës konsiderohet të jetë drejtori i fluturimit . Mund të përkthehet në Rusisht si "Dështimi nuk është një opsion" dhe kuptimi këtu është se gjithçka mund të funksionojë nëse keni vullnet të mjaftueshëm. Megjithatë, në jetën reale, dështimet nuk ndodhin thjesht, ato janë të pashmangshme, kudo dhe në çdo gjë. Dhe si t'i trajtojmë ato në rastin e mikroshërbimeve? Sipas mendimit tonë, është më mirë të mbështetemi jo në vullnetin, por në aftësitë e kontejnerëve, , Dhe .
Istio, siç kemi shkruar më lart, zbaton konceptin e ndërprerësve, i cili e ka dëshmuar veten mirë në botën fizike. Dhe ashtu si një ndërprerës elektrik fiket një seksion problemi të një qarku, softueri i Istio-s Circuit Breaker hap lidhjen midis një rryme kërkesash dhe një kontejneri problematik kur diçka nuk është në rregull me pikën përfundimtare, për shembull, kur serveri u rrëzua ose filloi të ngadalësoni.
Për më tepër, në rastin e dytë ka vetëm më shumë probleme, pasi frenat e një kontejneri jo vetëm që shkaktojnë një kaskadë vonesash në shërbimet që aksesojnë atë dhe, si rezultat, zvogëlojnë performancën e sistemit në tërësi, por gjithashtu gjenerojnë të përsëritura kërkesat për një shërbim tashmë të ngadaltë, gjë që vetëm sa e përkeqëson situatën.
Ndërprerës në teori
Ndërprerësi i qarkut është një përfaqësues që kontrollon rrjedhën e kërkesave në një pikë fundore. Kur kjo pikë ndalon së punuari ose, në varësi të cilësimeve të specifikuara, fillon të ngadalësohet, proxy ndërpret lidhjen me kontejnerin. Trafiku më pas ridrejtohet në kontejnerë të tjerë, thjesht për shkak të balancimit të ngarkesës. Lidhja mbetet e hapur për një dritare të caktuar gjumi, le të themi dy minuta, dhe më pas konsiderohet gjysmë e hapur. Një përpjekje për të dërguar kërkesën e radhës përcakton gjendjen e mëtejshme të lidhjes. Nëse gjithçka është në rregull me shërbimin, lidhja kthehet në gjendjen e punës dhe përsëri mbyllet. Nëse ka ende diçka që nuk shkon me shërbimin, lidhja shkëputet dhe dritarja e gjumit riaktivizohet. Ja se si duket një diagram i thjeshtuar i gjendjes së Ndërprerësit:
Është e rëndësishme të theksohet këtu se e gjithë kjo ndodh në nivelin e, si të thuash, arkitekturës së sistemit. Kështu që në një moment do t'ju duhet t'i mësoni aplikacionet tuaja të punojnë me Circuit Breaker, si p.sh. ofrimi i një vlere të paracaktuar në përgjigje ose, nëse është e mundur, injorimi i ekzistencës së shërbimit. Për këtë përdoret një model i pjesës më të madhe, por është përtej qëllimit të këtij artikulli.
Ndërprerës në praktikë
Për shembull, ne do të ekzekutojmë dy versione të mikroshërbimit tonë të rekomandimit në OpenShift. Versioni 1 do të funksionojë mirë, por në v2 ne do të ndërtojmë me një vonesë për të simuluar ngadalësimet në server. Për të parë rezultatet, përdorni mjetin :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Gjithçka duket se funksionon, por me çfarë kostoje? Në shikim të parë, ne kemi disponueshmërinë 100%, por hidhini një vështrim më të afërt - kohëzgjatja maksimale e transaksionit është deri në 12 sekonda. Kjo është padyshim një pengesë dhe duhet zgjeruar.
Për ta bërë këtë, ne do të përdorim Istio për të eliminuar thirrjet për kontejnerët e ngadaltë. Kjo është se si duket konfigurimi përkatës duke përdorur ndërprerësin e qarkut:
Linja e fundit me parametrin httpMaxRequestsPerConnection sinjalizon që lidhja me të duhet të shkëputet kur përpiqeni të krijoni një lidhje tjetër - një të dytë - përveç asaj ekzistuese. Meqenëse kontejneri ynë simulon një shërbim të ngadaltë, situata të tilla do të lindin periodikisht dhe më pas Istio do të kthejë një gabim 503, por ja çfarë do të tregojë rrethimi:
OK, ne kemi ndërprerësin e qarkut, çfarë është më pas?
Pra, ne zbatuam mbylljen automatike pa prekur fare kodin burimor të vetë shërbimeve. Duke përdorur Circuit Breaker dhe procedurën Pool Ejection të përshkruar më sipër, ne mund të heqim kontejnerët e frenave nga grupi i burimeve derisa të kthehen në normale dhe të kontrollojmë statusin e tyre në një frekuencë të caktuar - në shembullin tonë, kjo është dy minuta (parametri SleepWindow).
Vini re se aftësia e një aplikacioni për t'iu përgjigjur një gabimi 503 është vendosur ende në nivelin e kodit burimor. Ka shumë strategji për përdorimin e ndërprerësit, në varësi të situatës.
Në postimin e radhës: Ne do të flasim për gjurmimin dhe monitorimin që tashmë është i integruar ose i shtuar lehtësisht në Istio, si dhe për mënyrën e futjes së qëllimshme të gabimeve në sistem.
Burimi: www.habr.com