Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana

BrÄ«vdienas ir beiguŔās, un mēs esam atgriezuÅ”ies ar savu otro ierakstu Istio Service Mesh sērijā.

Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana

Å odienas tēma ir Circuit Breaker, kas tulkojumā krievu elektrotehnikā nozÄ«mē "automātiskais slēdzis", parastajā valodā - "automātiskais slēdzis". Tikai Istio Ŕī maŔīna atvieno nevis Ä«ssavienojumu vai pārslogotu ķēdi, bet gan bojātus konteinerus.

Kā tam vajadzētu darboties ideāli

Ja mikropakalpojumus pārvalda Kubernetes, piemēram, OpenShift platformā, tie automātiski palielinās un samazinās atkarÄ«bā no slodzes. Tā kā mikropakalpojumi darbojas podiņos, vienā galapunktā var bÅ«t vairāki konteinerizēta mikropakalpojuma gadÄ«jumi, un Kubernetes marÅ”rutēs pieprasÄ«jumus un slodzes lÄ«dzsvaru starp tiem. Un - ideālā gadÄ«jumā - tam visam vajadzētu darboties nevainojami.

Mēs atceramies, ka mikropakalpojumi ir mazi un Ä«slaicÄ«gi. ÄŖslaicÄ«gums, kas Å”eit nozÄ«mē parādÄ«Å”anās un pazuÅ”anas vieglumu, bieži tiek novērtēts par zemu. Vēl viena mikropakalpojuma gadÄ«juma raÅ”anās un nāve podā ir diezgan gaidÄ«tas lietas, OpenShift un Kubernetes tiek galā ar to labi, un viss darbojas lieliski, bet atkal teorētiski.

Kā tas īsti darbojas

Tagad iedomājieties, ka konkrēts mikropakalpojuma gadÄ«jums, tas ir, konteiners, ir kļuvis nelietojams: vai nu tas nereaģē (503. kļūda), vai, kas ir nepatÄ«kamāk, reaģē, bet pārāk lēni. Citiem vārdiem sakot, tas kļūst neveiksmÄ«gs vai nereaģē uz pieprasÄ«jumiem, taču tas netiek automātiski noņemts no kopas. Kas bÅ«tu jādara Å”ajā gadÄ«jumā? Vai mēģināt vēlreiz? Vai man vajadzētu to noņemt no marÅ”rutÄ“Å”anas shēmas? Un ko nozÄ«mē ā€œpārāk lēnsā€ ā€“ cik tas ir skaitļos, un kas tos nosaka? VarbÅ«t vienkārÅ”i atpÅ«tieties un vēlāk mēģiniet vēlreiz? Ja jā, tad cik vēlāk?

Kas ir baseina izgrūŔana Istio

Un Å”eit palÄ«gā nāk Istio ar savām Circuit Breaker aizsardzÄ«bas maŔīnām, kas uz laiku noņem bojātos konteinerus no marÅ”rutÄ“Å”anas un slodzes lÄ«dzsvaroÅ”anas resursu kopas, ievieÅ”ot Pool Ejection procedÅ«ru.

Izmantojot izņēmuma noteikÅ”anas stratēģiju, Istio nosaka lÄ«knes, kas ir ārpus lÄ«nijas, un uz noteiktu laiku noņem tos no resursu kopas, ko sauc par miega logu.

Lai parādÄ«tu, kā tas darbojas Kubernetes platformā OpenShift, sāksim ar parasti strādājoÅ”u mikropakalpojumu ekrānuzņēmumu no piemēra repozitorijā. Red Hat izstrādātāju demonstrācijas. Å eit mums ir divi podi, v1 un v2, katrs darbojas ar vienu konteineru. Ja Istio marÅ”rutÄ“Å”anas kārtulas netiek izmantotas, Kubernetes pēc noklusējuma izmanto vienmērÄ«gi lÄ«dzsvarotu apļveida marÅ”rutÄ“Å”anu:

Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana

Gatavojas avārijai

Pirms baseina izstumÅ”anas ir jāizveido Istio marÅ”rutÄ“Å”anas kārtula. Pieņemsim, ka vēlamies sadalÄ«t pieprasÄ«jumus starp aplikācijām proporcijā 50/50. Turklāt mēs palielināsim v2 konteineru skaitu no viena uz diviem, piemēram:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

Tagad mēs iestatām marÅ”rutÄ“Å”anas kārtulu, lai satiksme tiktu sadalÄ«ta starp podiem proporcijā 50/50.

Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana
Lūk, kā izskatās Ŕī noteikuma rezultāts:

Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana
Var atrast vainu tajā, ka Ŕis ekrāns ir nevis 50/50, bet 14:9, bet ar laiku situācija uzlabosies.

Kļūdas izveidoŔana

Tagad atspējosim vienu no diviem v2 konteineriem, lai mums būtu viens vesels v1 konteiners, viens veselīgs v2 konteiners un viens bojāts v2 konteiners:

Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana

Traucējuma novērÅ”ana

Tātad mums ir bojāts konteiners, un ir pienācis laiks baseina izmeÅ”anai. Izmantojot ļoti vienkārÅ”u konfigurāciju, mēs uz 15 sekundēm izslēgsim Å”o neveiksmÄ«go konteineru no marÅ”rutÄ“Å”anas shēmām, cerot, ka tas atgriezÄ«sies veselÄ«gā stāvoklÄ« (restartēs vai atjaunos veiktspēju). LÅ«k, kā izskatās Ŕī konfigurācija un tās darba rezultāti:

Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana
Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana
Kā redzat, neveiksmÄ«gais v2 konteiners vairs netiek izmantots marÅ”rutÄ“Å”anas pieprasÄ«jumiem, jo ā€‹ā€‹tas ir noņemts no pÅ«la. Bet pēc 15 sekundēm tas automātiski atgriezÄ«sies baseinā. PatiesÄ«bā mēs tikko parādÄ«jām, kā darbojas baseina izgrÅ«Å”ana.

Sāksim būvēt arhitektūru

Pool Ejection apvienojumā ar Istio pārraudzības iespējām ļauj sākt veidot sistēmu bojātu konteineru automātiskai nomaiņai, lai samazinātu, ja ne likvidētu, dīkstāves un atteices.
ā€ƒ
NASA ir viens skaļŔ moto - Failure Is Not An Option, kura autors tiek uzskatÄ«ts par lidojumu direktoru Džīns Krancs. Krievu valodā to var tulkot kā ā€œNeveiksme nav risinājumsā€, un Å”eit nozÄ«me ir tāda, ka visu var panākt, lai tas darbotos, ja jums ir pietiekami daudz gribas. Tomēr reālajā dzÄ«vē neveiksmes nenotiek vienkārÅ”i, tās ir neizbēgamas, visur un visā. Un kā ar tiem rÄ«koties mikropakalpojumu gadÄ«jumā? MÅ«suprāt, labāk paļauties nevis uz gribasspēku, bet gan uz konteineru iespējām, Kubernetes, Red Hat OpenShiftUn Istio.

Istio, kā mēs rakstÄ«jām iepriekÅ”, Ä«steno ķēdes pārtraucēju koncepciju, kas ir labi pierādÄ«jusi sevi fiziskajā pasaulē. Un tāpat kā elektriskais ķēdes pārtraucējs izslēdz ķēdes problēmu sadaļu, Istio programmatÅ«ra Circuit Breaker atver savienojumu starp pieprasÄ«jumu straumi un problēmu konteineru, ja kaut kas nav kārtÄ«bā ar beigu punktu, piemēram, kad serveris avarēja vai sāka lēnāk.

Turklāt otrajā gadÄ«jumā ir tikai vairāk problēmu, jo viena konteinera bremzes ne tikai rada kavējumu kaskādi dienestiem, kas tam piekļūst, un rezultātā samazina sistēmas darbÄ«bu kopumā, bet arÄ« rada atkārtotas pieprasÄ«jumus jau tā lēni strādājoÅ”am pakalpojumam, kas situāciju tikai pasliktina .

Strāvas slēdzis teorētiski

Circuit Breaker ir starpniekserveris, kas kontrolē pieprasÄ«jumu plÅ«smu uz galapunktu. Kad Å”is punkts pārstāj darboties vai, atkarÄ«bā no norādÄ«tajiem iestatÄ«jumiem, sāk palēnināties, starpniekserveris pārtrauc savienojumu ar konteineru. Pēc tam satiksme tiek novirzÄ«ta uz citiem konteineriem, vienkārÅ”i slodzes balansÄ“Å”anas dēļ. Savienojums paliek atvērts noteiktā miega logā, piemēram, divas minÅ«tes, un pēc tam tiek uzskatÄ«ts par pusatvērtu. Mēģinājums nosÅ«tÄ«t nākamo pieprasÄ«jumu nosaka turpmāko savienojuma stāvokli. Ja ar pakalpojumu viss ir kārtÄ«bā, savienojums atgriežas darba stāvoklÄ« un atkal tiek slēgts. Ja pakalpojumā joprojām ir kaut kas nepareizs, savienojums tiek atvienots un miega logs tiek atkārtoti iespējots. LÅ«k, kā izskatās vienkārÅ”ota ķēdes pārtraucēja stāvokļa diagramma:

Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana
Å eit ir svarÄ«gi atzÄ«mēt, ka tas viss notiek, tā sakot, sistēmas arhitektÅ«ras lÄ«menÄ«. Tāpēc kādā brÄ«dÄ« jums bÅ«s jāiemāca lietojumprogrammām strādāt ar Circuit Breaker, piemēram, atbildot uz noklusējuma vērtÄ«bu vai, ja iespējams, ignorējot pakalpojuma esamÄ«bu. Å im nolÅ«kam tiek izmantots starpsienu modelis, taču tas ir ārpus Ŕī raksta darbÄ«bas jomas.

Circuit Breaker praksē

Piemēram, OpenShift izmantosim divas mÅ«su ieteikumu mikropakalpojuma versijas. 1. versija darbosies labi, bet versijā 2 mēs ieviesÄ«sim aizkavi, lai simulētu servera palēninājumu. Lai skatÄ«tu rezultātus, izmantojiet rÄ«ku aplenkums:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana
Šķiet, ka viss darbojas, bet par kādu cenu? No pirmā acu uzmetiena mums ir 100% pieejamība, taču paskatieties uzmanīgāk - maksimālais darījuma ilgums ir pat 12 sekundes. Tas nepārprotami ir vājŔ kakls, un tas ir jāpaplaŔina.

Lai to izdarÄ«tu, mēs izmantosim Istio, lai novērstu zvanus uz lēnajiem konteineriem. LÅ«k, kā izskatās atbilstoŔā konfigurācija, izmantojot Circuit Breaker:

Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana
Pēdējā rindiņa ar parametru httpMaxRequestsPerConnection norāda, ka savienojums ar ir jāatvieno, mēģinot izveidot citu - otro - savienojumu papildus esoÅ”ajam. Tā kā mÅ«su konteiners simulē lēnu apkalpoÅ”anu, Ŕādas situācijas periodiski radÄ«sies, un tad Istio atgriezÄ«s 503 kļūdu, taču tas ir tas, ko parādÄ«s aplenkums:

Istio Circuit Breaker: bojātu konteineru atspējoÅ”ana

Labi, mums ir Circuit Breaker, kas tālāk?

Tātad, mēs ieviesām automātisku izslēgÅ”anu, vispār nepieskaroties paÅ”u pakalpojumu avota kodam. Izmantojot iepriekÅ” aprakstÄ«to Circuit Breaker un Pool Ejection procedÅ«ru, mēs varam noņemt bremžu konteinerus no resursu kopas, lÄ«dz tie atgriežas normālā stāvoklÄ«, un pārbaudÄ«t to statusu noteiktā frekvencē - mÅ«su piemērā tas ir divas minÅ«tes (sleepWindow parametrs).

Ņemiet vērā, ka lietojumprogrammas spēja reaģēt uz kļūdu 503 joprojām ir iestatÄ«ta avota koda lÄ«menÄ«. AtkarÄ«bā no situācijas Circuit Breaker izmantoÅ”anai ir daudz stratēģiju.

Nākamajā ierakstā: Mēs apskatÄ«sim izsekoÅ”anu un uzraudzÄ«bu, kas jau ir iebÅ«vēta vai viegli pievienojama Istio, kā arÄ« to, kā apzināti ieviest kļūdas sistēmā.

Avots: www.habr.com

Pievieno komentāru