Istio Circuit Breaker: deaktiveerime riknenud konteinerid

Pühad on möödas ja naaseme oma teise postitusega Istio Service Mesh'i seeriast.

Täna käsitleme teemat – Circuit Breaker, mis elektritehnikas tähendab "automaatkatkestit" ja igapäevaselt "kaitseautomaat". Kuid Istio puhul katkestab see automaat mitte lühise või ülekoormatud ahela, vaid riknenud konteinerid.

Kuidas see ideaaljuhul tööle peaks minema

Kui mikroteenuseid haldab Kubernetes, näiteks OpenShift'i platvormil, skaleeruvad need automaatselt üles-alla sõltuvalt koormusest. Kuna mikroteenused töötavad pod'ides, võib ühel lõpp-punktil samal ajal olla mitu konteineriseeritud mikroteenuse eksemplari, ning Kubernetes suunab päringud ja tasakaalustab koormust nende vahel. Ja – ideaaljuhul – peaks kõik see toimima suurepäraselt.

Peame meeles, et mikroteenused on väikesed ja efemeersed. Efemeersus, mis siin tähendab kergust tekkimise ja kadumise osas, on sageli alahinnatud. Uue mikroteenuse juhusliku eksemplari sünn ja surm pod'is on ootuspärased, OpenShift ja Kubernetes haldavad seda hästi, ja kõik töötab imeliselt – kuid taaskord, vaid teoorias.

Kuidas see tegelikult töötab

Kujutage nüüd ette, et mingi konkreetne mikroteenuse eksemplar, nimelt konteiner, on rikki läinud: kas ei reageeri (viga 503) või, mis on veel hullem, reageerib, kuid liiga aeglaselt. Teisisõnu, ta jääb 'hanguma' või ei vasta päringutele, kuid ei kõrvaldata automaatselt ressursside hulgast. Mida siis teha? Korrata katset? Eemaldada see marsruutimisest? Ja mis tähendab "liiga aeglaselt" – kui suur on see number ja kes selle määrab? Kas tuleks lihtsalt anda talle pausi ja proovida hiljem? Kui kaua peaks ootama?

Mis on Pool Ejection Istios

Ja siin tuleb appi Istio oma Circuit Breaker'itega, mis ajutiselt eemaldavad riknenud konteinerid marsruudi ja koormuse tasakaalustamise ressurssidest, rakendades Pool Ejection'i protseduuri.

Kasutades kõrvalekallete tuvastamise strateegiat (outlier detection), tuvastab Istio kõrvalekaldeid näitavad pod'id, mis ei vasta üldisele mustrile, ja eemaldab need ressursside hulgast määratud ajaks, mida nimetatakse "uneaknaks" (sleep window).

Kuidas see OpenShift'i Kuberneteses töötab, näitame, alustades ekraanipildist hästi funktsioneerivatest mikroteenustest näites hoidlasse. Red Hat Developer DemosSiin on meil kaks pod'i, v1 ja v2, kus kummaski töötab üks konteiner. Kui Istio suunamisreegleid ei kasutata, rakendab Kubernetes vaikesena ühtlaselt tasakaalustatud ringikujulist suunamist:

Valmistume tõrkeks

Enne kui teeme Pool Ejection, peame looma Istio suunamisreeglid. Oletame, et tahame jagada päringud pod'ide vahel 50/50. Lisaks suurendame konteinerite v2 arvu ühelt kahele, nii et:

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

Nüüd määrame suunamisreegli, et liiklus jaguneks pod'ide vahel 50/50.

Nii näeb see reegli rakendamine välja:

Võib vaielda, et sellel ekraanil pole 50/50, vaid 14:9, kuid aja jooksul olukord stabiliseerub.

Teeme tõrke

Nüüd võtame välja ühe kahest konteinerist v2, et meil oleks üks töötav konteiner v1, üks töötav konteiner v2 ja üks rikki minev konteiner v2:

Parandame tõrke

Nüüd on meil rikki minev konteiner ja on aeg teha Pool Ejection. Väga lihtsa konfiguratsiooni abil eemaldame selle rikki mineva konteineri kõikidest suunamiskeemidest 15 sekundiks, lootuses, et see naaseb töökorda (kas siis taaskäivitudes või taastades oma jõudluse). Nii näeb see konfiguratsioon ja selle tulemused välja:

Nagu näha, ei kasutata rikki minevat konteinerit v2 enam päringute suunamisel, kuna see on eemaldatud grupist. 15 sekundi möödudes naaseb see automaatselt gruppi. Nii et me just näitasime, kuidas Pool Ejection töötab.

Alustame arhitektuuri loomist

Pool Ejection koos Istio jälgimisvõimalustega võimaldab alustada rikete automaatse asendamise raamistruktuuri loomist, et vähendada või isegi kõrvaldada seisakuid ja riketeid.
 
NASA-l on üks tuntud moto – Tõrge Pole Valik, mille autoriks peetakse lennujuhti Gene KranzEestikeelde võib selle tõlkida kui "Tõrje ei ole variant" ja selle mõte on, et kõike on võimalik tööle panna, kui on piisavalt tahtejõudu. Siiski juhtub tõelises elus tõrkeid mitte lihtsalt, vaid need on vältimatud, kõikjal ja igas asjas. Kuidas nende tõrgetega mikroteenuste puhul toime tulla? Meie arvates on parem toetuda mitte tahtejõule, vaid konteinerite võimalustele. Kubernetes, Red Hat OpenShift, ja Istio.

Istio, nagu me juba eespool kirjutasime, rakendab suurepäraselt tunnustatud füüsilise maailma automaatsete kaitselülitite kontseptsiooni. Nagu elektriline kaitselüliti katkestab probleemse ahela osa, katkestab programmiline Circuit Breaker Istios ühenduse päringute vooge ja probleemse konteineri vahel, kui lõpp-punktiga on midagi vale, näiteks kui server on kokku kukkunud või hakkab aeglustuma.

Teise puhul on probleeme isegi rohkem, kuna ühe konteineri aeglustamine mitte ainult ei põhjusta ahel-viivitusi, mis tekivad sellele suunatud teenustes ning seeläbi vähendab süsteemi tervikuna tootlikkust, vaid ka tekitab korduvaid päringuid juba aeglaselt töötavale teenusele, mis ainult halvendab olukorda.

Circuit Breaker teoorias

Circuit Breaker on proksi, mis kontrollib päringute voogu lõpp-punktile. Kui see punkt peatub töötamast või – sõltuvalt määratud seadistustest – hakkab aeglustuma, katkestab proksi ühenduse konteineriga. Pärast seda suunatakse liiklus teistesse konteineritesse lihtsalt koormuse tasakaalustamise tõttu. Ühendus jääb avatud (open) määratud uneakna, näiteks kahe minuti ajaks, ja seejärel muutub see poolavatuks (half-open). Järgmise päringu saatmise katse määrab edasise ühenduse seisundi. Kui teenusega on kõik korras, taastub ühendus ja muutub taas suletuks (closed). Kui aga teenusega on endiselt midagi valesti, katkestatakse ühendus ja uneaken aktiveeritakse uuesti. Nii näeb välja lihtsustatud Circuit Breaker'i oleku diagramm:

Siin on oluline märkida, et kõik see toimub nii-öelda süsteemi arhitektuuri tasandil. Seetõttu peate varem või hiljem õpetama oma rakendusi töötama Circuit Breaker'iga, näiteks tagastama vaikimisi väärtuse või, kui võimalik, ignoreerima teenuse olemasolu. Selleks kasutatakse bulkhead pattern'i, kuid see jääb sellest artiklist väljapoole.

Circuit Breaker praktikas

Näiteks käivitame OpenShift'is kaks versiooni meie soovituste mikroteenust. Versioon 1 töötab normaalselt, kuid v2-s lisame viivituse, et simuleerida serveri mahajäämust. Tulemuste vaatamiseks kasutatakse tööriista siege:

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

Kõik näib töötavat, kuid mis hinnaga? Esmapilgul on meil 100% kättesaadavus, kuid vaadake lähemalt – maksimaalne tehingu kestus on tervelt 12 sekundit. See on selge kitsaskoht ja seda tuleb laiendada.

Selleks välistame koos Istio'ga aeglased konteinerid. Nii näeb välja vastav konfigureerimine Circuit Breaker'iga:

Viimane rida, mille parameeter httpMaxRequestsPerConnection, signaliseerib, et ühendus peaks katkema, kui proovite luua veel ühe – teise – ühenduse juba olemasoleva kõrval. Kuna meie konteiner simuleerib aeglustavat teenust, esinevad sellised olukorrad perioodiliselt, ja sel juhul tagastab Istio vea 503, kuid siin on, mida siege näitab:

Okei, meil on Circuit Breaker, mis edasi?

Nii oleme rakendanud automaatse katkestamise, puudutamata teenuste lähtekoodi. Kasutades Circuit Breaker'it ja eespool kirjeldatud protseduuri Pool Ejection, saame eemaldada ressursipoolist aeglased konteinerid, kuni need on normaliseerunud, ja kontrollida nende seisundit etteantud ajavahemike järel – meie näites on see kaks minutit (parameeter sleepWindow).

Pange tähele, et rakenduse võime reageerida veale 503 on endiselt määratud tema lähtekoodis. Circuit Breaker'i toimimise strateegiaid on palju, mida rakendatakse sõltuvalt olukorrast.

Järgmises postituses: räägime jälgimisest ja monitooringust, mis on juba integreeritud või kergesti lisatavad Istio'sse, samuti sellest, kuidas süsteemi teadlikult vigu sisestada.

Allikas: habr.com