Istio Circuit Breaker: lülitame välja rikki läinud konteinerid

Pühad on läbi, ja me naaseme oma teise postitusega Istio Service Meshi seerias.

Täna räägime Circuit Breaker'ist, mis tähendab eesti keeles 'automaatkaitse', slangikeeles - 'kaitseautomaat'. Ainult et Istios see automaat ei katkesta katkenud või ülekoormatud voolu, vaid riknenud konteinerid.

Nii peaks see ideaalis toimima

Kui mikroteenuseid haldab Kubernetes, näiteks platvormi OpenShift raames, siis need skaleeruvad automaatselt üles- ja allapoole vastavalt koormusele. Kuna mikroteenused töötavad pod'ides, võib ühel lõpp-punktil olla korraga mitu konteinerit, ning Kubernetes suunab päringud nende vahel ja tasakaalustab koormuse. Ja - ideaalis - peaks see kõik suurepäraselt toimima.

Meeles peate, et mikroteenused on väikesed ja mööduvad. Mööduvus, mis siin tähendab lihtsust tekkida ja kaduda, on sageli alahinnatud. Mikroteenuse sünd ja surm pod'is on täiesti ootuspärased, OpenShift ja Kubernetes saavad selle väga hästi hakkama ning kõik toimib suurepäraselt – kuid jälle teoorias.

Kuidas see tegelikult töötab

Nüüd kujutage ette, et mingi konkreetne mikroteenuse instants, ehk konteiner, on rikki läinud: kas ei vasta (vea 503) või – mis on veel hullem – reageerib, kuid liiga aeglaselt. Teisisõnu, ta käitub aeglaselt või ei vasta päringutele, kuid samas ei eemaldata teda automaatselt reservi. Mida sel juhul ette võtta? Korduskatse? Eemaldada see marsruudist? Ja mis tähendab „liiga aeglaselt” – kui palju see numbrites on ja kes määrab need? Kas võib-olla tuleks talle lihtsalt paus anda ja proovida hiljem? Kui jah, siis kui kaua hiljem?

Mis on Pool Ejection Istios

Ja siin tuleb appi Istio oma Circuit Breaker automaatidega, mis ajutiselt eemaldavad vigased konteinerid marsruutimise ja koormuse tasakaalustamise ressursside kassist, rakendades protseduuri Pool Ejection.

Kasutades kõrvalekallete tuvastamise strateegiat (outlier detection), tuvastab Istio ebaõiged pod’id, mis eristuvad tavalisest, ja eemaldab nad määratud ajaks ressursside kassist, mida nimetatakse 'unerežiimiks' (sleep window).

Küsimiseks, kuidas see Kuberneteses platvormil OpenShift töötab, alustame ekraanipildist normaalselt toimivatest mikroteenustest näites hoidlast. Red Hat Developer Demos. Siin on meil kaks pod’i, v1 ja v2, millest igas töötab üks konteiner. Kui Istio marsruutimise reegleid ei kasutata, rakendab Kubernetes vaikimisi ühtlaselt tasakaalustatud tsüklilist marsruuti:

Valmistume rikke jaoks

Enne Pool Ejection’it tuleb luua Istio marsruutimise reegel. Oletame, et soovime jaotada päringud pod’ide vahel suhtega 50/50. Lisaks suurendame konteinerite arvu v2-l ühest kahele, nagu siin:

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

Seame reeglid suunamiseks, et liiklus jaguneks-pod'ide vahel 50/50.

Nii näeb selle reegli töö tulemus välja:

Võib öelda, et sellel ekraanil ei ole 50/50, vaid 14:9, kuid aja jooksul olukord stabiliseerub.

Teeme rikke

Nüüd viime ühe kahest konteinerist v2 rikki, et meil oleks üks töötav konteiner v1, üks töötav konteiner v2 ja üks rikki minna konteiner v2:

Parandame rikke

Nii, meil on rikki läinud konteiner ja aeg on Pool Ejectiooni jaoks. Väga lihtsa konfiguraatori abil välistame selle rikki läinud konteineri mis tahes suunamisest 15 sekundiks, lootuses, et see taastub (kas ta taaskäivitub või taastab oma jõudluse). Nii näeb see konfiguratsioon välja ja millised on selle tulemused:

Nagu näha, ei kasutata rikki läinud konteinerit v2 enam päringute suunamiseks, kuna see on puul välja toodud. Kuid 15 sekundi möödumisega naaseb see automaatselt puusse. Tegelikult just näitasime, kuidas Pool Ejectioon töötab.

Alustame arhitektuuri loomist

Pool Ejection koos Istio jälgimisvõimalustega võimaldab luua automaatse rikke põhjustanud konteinerite asendamise raamistikku, et vähendada või isegi täielikult kõrvaldada seiskumisi ja tõrkeid.
 
NASA-l on üks tuntud moto – Failure Is Not an Option, mille autor on lennujuht. Gene Kranz. Selle tõlge eesti keelde on „Ebaõnnestumine ei ole variant“, ja mõte on selles, et kõik on võimalik tööle panna, kui on piisavalt tahet. Kuid tegelikus elus ei juhtu tõrked lihtsalt, need on vältimid, kõikjal ja igal pool. Kuidas nendega siis toime tulla mikroteenustes? Meie arvates on parem toetuda mitte tahtejõule, vaid konteinerite võimalustele. Kubernetes, Red Hat OpenShift, ja Istio.

Istio rakendab nagu eelpool nimetatud automaatse kaitselüliti kontseptsioon, mis on end füüsilises maailmas tõestanud. Nii nagu elektriline kaitselüliti katkestab probleemse ahela osa, katkestab programmi Circuit Breaker Istios ühenduse päringute voo ja probleemse konteineri vahel, kui lõpp-punktiga on midagi valesti, näiteks kui server on maha kukkunud või hakkab rahmeldama.

Teises olukorras on probleeme veelgi rohkem, kuna ühe konteineri pidurid mitte ainult ei põhjusta kaskaadset viivitust sellele juurdepääsuga teenustes, vähendades seeläbi süsteemi üldist jõudlust, vaid tekitavad ka korduvaid päringuid juba niigi aeglases teenuses, mis vaid süvendab olukorda.

Circuit Breaker teoorias

Circuit Breaker – see proxy, which controls the flow of requests to an endpoint. When this endpoint stops working or, depending on the configured settings, starts lagging, the proxy breaks the connection with the container. Traffic is then redirected to other containers simply due to load balancing. The connection remains open for a specified sleep window, say two minutes, after which it is considered half-open. An attempt to send the next request determines the further state of the connection. If everything is fine with the service, the connection returns to operational state and becomes closed again. If, however, there is still an issue with the service, the connection opens again and the sleep window is reactivated. Here’s a simplified state change diagram of the Circuit Breaker:

Siin on oluline märkida, et kogu see toimub süsteemi arhitektuuri tasemel. Seetõttu peate mingi hetk õpetama oma rakendusi töötama Circuit Breakeriga, näiteks andma vastuseks vaikimisi väärtuse või, kui see on võimalik, ignoreerima teenuse olemasolu. Selleks kasutatakse bulkhead pattern'i, kuid see jääb välja selle artikli raamist.

Circuit Breaker praktikas

Näiteks käivitame OpenShiftis kaks versiooni meie soovituste mikroteenusest. Versioon 1 töötab normaalselt, kuid v2-s lisame viivituse, et simuleerida serveri aeglustusi. Tulemuste vaatamiseks kasutatakse tööriista siege:

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

Kõik tundub töötavat, aga mis hinnaga? Esmapilgul on meil 100% kättesaadavus, kuid vaadake lähemalt – maksimumm aega tehingu jaoks on tervelt 12 sekundit. See on selgelt kitsaskohaks ja seda tuleb avardada.

Selleks välistame Istio abil ühendused aeglaste konteineritega. Niisiis, selline on vastav konfigureerimine, kasutades Circuit Breakerit:

Viimane rida parameetriga httpMaxRequestsPerConnection näitab, et ühendus tuleb katkestada, kui üritatakse luua veel üks – teine – ühendus olemasoleva kõrval. Kuna meie konteiner simuleerib aeglustavat teenust, esinevad sellised olukorrad perioodiliselt ja siis tagastab Istio vea 503, aga mida näitab siege:

Okei, meil on Circuit Breaker, mis edasi?

Nii et oleme rakendanud automaatse katkestamise, puutumatult muutmata teenuste algkoodi. Kasutades Circuit Breakerit ja eespool kirjeldatud protseduuri Pool Ejection, saame eemaldada aeglustavad konteinerid ressursi reservuaarist, kuni nad normaliseeruvad, ning kontrollida nende staatust määratud ajavahemiku järel – meie näites on see kaks minutit (parameeter sleepWindow).

Pange tähele, et rakenduse võime reageerida veale 503 määratakse endiselt selle algkoodi tasemel. On mitmeid Circuit Breakeri tööstrateegiaid, mida rakendatakse sõltuvalt olukorrast.

Järgmises postituses: räägime jälgimisest ja monitooringust, mis on juba sisseehitatud või kergesti lisatavad Istiosse, ning sellest, kuidas süsteemi vigu teadlikult sisestada.

Allikas: habr.com