Atostogos baigėsi ir mes grįžtame su savo antruoju įrašu iš „Istio Service Mesh“ serijos.
Šiandienos tema yra grandinės pertraukiklis, kuris išvertus į rusų elektros inžineriją reiškia „grandinės pertraukiklis“, bendrinėje kalboje – „grandinės pertraukiklis“. Tik Istio ši mašina atjungia ne trumpą ar perkrautą grandinę, o sugedusius konteinerius.
Kaip tai turėtų veikti idealiai
Kai mikropaslaugos valdo „Kubernetes“, pavyzdžiui, „OpenShift“ platformoje, jos automatiškai didina ir mažina dydį, priklausomai nuo apkrovos. Kadangi mikropaslaugos veikia blokuose, viename galutiniame taške gali būti keli konteinerinės mikropaslaugos egzemplioriai, o „Kubernetes“ nukreips užklausas ir apkrovos balansą tarp jų. Ir – idealiu atveju – visa tai turėtų veikti puikiai.
Prisimename, kad mikropaslaugos yra mažos ir trumpalaikės. Efemeriškumas, kuris čia reiškia atsiradimo ir išnykimo lengvumą, dažnai yra neįvertinamas. Kito mikropaslaugos egzemplioriaus atsiradimas ir mirtis yra gana laukiami dalykai, „OpenShift“ ir „Kubernetes“ su tuo susitvarko puikiai, ir viskas veikia puikiai – bet vėlgi teoriškai.
Kaip tai iš tikrųjų veikia
Dabar įsivaizduokite, kad konkretus mikropaslaugos egzempliorius, tai yra konteineris, tapo nebenaudojamas: arba nereaguoja (503 klaida), arba, kas nemaloniausia, reaguoja, bet per lėtai. Kitaip tariant, jis tampa trikdis arba nereaguoja į užklausas, tačiau jis nėra automatiškai pašalinamas iš baseino. Ką reikėtų daryti šiuo atveju? Bandyti dar kartą? Ar turėčiau jį pašalinti iš maršruto schemos? O ką reiškia „per lėtas“ – kiek tai skaičiais ir kas juos nustato? Gal tiesiog padaryti pertrauką ir vėliau bandyti dar kartą? Jei taip, po kiek laiko?
Kas yra baseino išmetimas iš Istio
Ir štai Istio į pagalbą ateina su savo Circuit Breaker apsaugos mašinomis, kurios laikinai pašalina sugedusius konteinerius iš maršrutų parinkimo ir apkrovos balansavimo resursų telkinio, įgyvendinant Pool Ejection procedūrą.
Naudodamas nuokrypių aptikimo strategiją, „Istio“ aptinka kreivės blokus, kurie neatitinka linijos, ir pašalina juos iš išteklių telkinio nurodytam laikui, vadinamam miego langu.
Norėdami parodyti, kaip tai veikia „Kubernetes“ „OpenShift“ platformoje, pradėkime nuo įprastai veikiančių mikro paslaugų ekrano kopijos iš saugykloje esančio pavyzdžio. . Čia turime dvi talpyklas, v1 ir v2, kurių kiekvienoje veikia vienas konteineris. Kai Istio maršruto parinkimo taisyklės nenaudojamos, Kubernetes nustato tolygiai subalansuotą apvalų maršrutą:
Ruošiasi avarijai
Prieš atlikdami baseino išstūmimą, turite sukurti Istio maršruto parinkimo taisyklę. Tarkime, kad norime paskirstyti užklausas tarp rinkinių santykiu 50/50. Be to, padidinsime v2 konteinerių skaičių nuo vieno iki dviejų, kaip nurodyta toliau:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Dabar nustatome maršruto parinkimo taisyklę, kad srautas būtų paskirstytas tarp blokų santykiu 50/50.
Štai kaip atrodo šios taisyklės rezultatas:
Priekaištų galite rasti tame, kad šis ekranas yra ne 50/50, o 14:9, tačiau laikui bėgant situacija gerės.
Padaro gedimą
Dabar išjunkite vieną iš dviejų v2 sudėtinių rodinių, kad turėtume vieną sveiką v1 sudėtinį rodinį, vieną sveiką v2 sudėtinį rodinį ir vieną sugedusį v2 sudėtinį rodinį:
Gedimo taisymas
Taigi, turime sugedusį konteinerį ir atėjo baseino išmetimo laikas. Naudodami labai paprastą konfigūraciją, 15 sekundžių pašalinsime šį nepavykusį konteinerį iš bet kokių maršruto parinkimo schemų, tikėdamiesi, kad jis grįš į sveiką būseną (arba paleis iš naujo, arba atkurs veikimą). Štai kaip atrodo ši konfigūracija ir jos darbo rezultatai:
Kaip matote, nepavykęs v2 konteineris nebenaudojamas užklausoms nukreipti, nes buvo pašalintas iš telkinio. Tačiau po 15 sekundžių jis automatiškai grįš į baseiną. Tiesą sakant, mes ką tik parodėme, kaip veikia baseino išmetimas.
Pradėkime kurti architektūrą
Baseino išmetimas kartu su „Istio“ stebėjimo galimybėmis leidžia pradėti kurti sistemą, skirtą automatiškai pakeisti sugedusius konteinerius, kad būtų sumažinta, o ne visiškai pašalinta, prastovos ir gedimai.
NASA turi vieną skambų šūkį – Failure Is Not an Option, kurio autorius laikomas skrydžių vadovu. . Į rusų kalbą jis gali būti išverstas kaip „nesėkmės nėra išeitis“, o čia esmė ta, kad viską galima sutvarkyti, jei turi pakankamai valios. Tačiau realiame gyvenime nesėkmės ne šiaip nutinka, jos yra neišvengiamos visur ir visame kame. O kaip su jais elgtis mikropaslaugų atveju? Mūsų nuomone, geriau pasikliauti ne valia, o konteinerių galimybėmis, , Ir .
Istio, kaip rašėme aukščiau, įgyvendina grandinės pertraukiklių koncepciją, kuri puikiai pasitvirtino fiziniame pasaulyje. Ir kaip elektros grandinės pertraukiklis išjungia probleminę grandinės dalį, Istio programinė įranga Circuit Breaker atidaro ryšį tarp užklausų srauto ir probleminio konteinerio, kai kažkas negerai su galutiniu tašku, pavyzdžiui, kai serveris sugenda arba pradėjo veikti. lėčiau.
Be to, antruoju atveju kyla tik daugiau problemų, nes vieno konteinerio stabdžiai ne tik sukelia vėlavimų kaskadą prie jo besikreipiančioms tarnyboms ir dėl to sumažina visos sistemos našumą, bet ir generuoja pasikartojančius kreipiasi į jau lėtai veikiančią paslaugą, o tai tik pablogina situaciją.
Grandinės pertraukiklis teoriškai
Circuit Breaker yra tarpinis serveris, valdantis užklausų srautą į galutinį tašką. Kai šis taškas nustoja veikti arba, priklausomai nuo nurodytų nustatymų, pradeda lėtėti, tarpinis serveris nutraukia ryšį su konteineriu. Tada eismas nukreipiamas į kitus konteinerius, tiesiog dėl apkrovos balansavimo. Ryšys išlieka atidarytas tam tikrą miego langą, tarkime, dvi minutes, ir tada laikomas pusiau atidarytu. Bandymas išsiųsti kitą užklausą nustato tolesnę ryšio būseną. Jei su paslauga viskas gerai, ryšys grįžta į veikiančią būseną ir vėl uždaromas. Jei paslauga vis tiek negerai, ryšys atjungiamas ir miego langas vėl įjungiamas. Štai kaip atrodo supaprastinta grandinės pertraukiklio būsenos diagrama:
Čia svarbu pažymėti, kad visa tai vyksta, taip sakant, sistemos architektūros lygyje. Todėl tam tikru momentu turėsite išmokyti savo programas dirbti su Circuit Breaker, pavyzdžiui, atsakydami į numatytąją reikšmę arba, jei įmanoma, ignoruodami paslaugos buvimą. Tam naudojamas pertvaros raštas, tačiau jis nepatenka į šio straipsnio taikymo sritį.
Grandinės pertraukiklis praktikoje
Pvz., „OpenShift“ paleisime dvi mūsų rekomenduojamos mikro paslaugos versijas. 1 versija veiks gerai, tačiau 2 versijoje įdiegsime delsą, kad imituosime serverio sulėtėjimą. Norėdami peržiūrėti rezultatus, naudokite įrankį :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Atrodo, viskas veikia, bet kokia kaina? Iš pirmo žvilgsnio turime 100% prieinamumą, tačiau pažiūrėkite atidžiau – maksimali operacijos trukmė yra net 12 sekundžių. Akivaizdu, kad tai yra kliūtis ir ją reikia išplėsti.
Norėdami tai padaryti, naudosime „Istio“, kad pašalintume skambučius į lėtus konteinerius. Taip atrodo atitinkama konfigūracija naudojant Circuit Breaker:
Paskutinė eilutė su parametru httpMaxRequestsPerConnection signalizuoja, kad reikia atjungti ryšį, kai bandoma sukurti kitą – antrą – ryšį šalia esamo. Kadangi mūsų konteineris imituoja lėtą aptarnavimą, tokių situacijų pasitaikys periodiškai, o tada Istio grąžins 503 klaidą, bet štai ką parodys apgultis:
Gerai, mes turime grandinės pertraukiklį, kas toliau?
Taigi, mes įdiegėme automatinį išjungimą, visiškai neliesdami pačių paslaugų šaltinio kodo. Naudodami aukščiau aprašytą grandinės pertraukiklį ir baseino išstūmimo procedūrą, galime išimti stabdžių konteinerius iš išteklių telkinio, kol jie grįš į normalią būseną, ir tikrinti jų būseną nurodytu dažnumu – mūsų pavyzdyje tai yra dvi minutės (parametras „sleepWindow“).
Atminkite, kad programos gebėjimas reaguoti į 503 klaidą vis tiek nustatomas šaltinio kodo lygiu. Priklausomai nuo situacijos, yra daug strategijų, kaip naudoti „Circuit Breaker“.
Kitame įraše: Aptarsime sekimą ir stebėjimą, kurie jau yra įtaisyti arba lengvai pridedami prie „Istio“, taip pat apie tai, kaip sąmoningai įvesti klaidas sistemoje.
Šaltinis: www.habr.com
