Pühad on möödas ja oleme tagasi oma teise postitusega sarjas Istio Service Mesh.
Tänaseks teemaks on kaitselüliti, mis vene elektrotehnika keelde tõlgituna tähendab "kaitselülitit", tavakeeles "kaitselülitit". Ainult Istios ei ühenda see masin lahti lühises või ülekoormatud vooluringi, vaid vigaseid konteinereid.
Kuidas see peaks ideaalis töötama
Kui Kubernetes haldab mikroteenuseid, näiteks OpenShifti platvormil, skaleeruvad need sõltuvalt koormusest automaatselt üles ja alla. Kuna mikroteenused töötavad kaustades, võib ühes lõpp-punktis olla mitu konteinerisse paigutatud mikroteenuse eksemplari ning Kubernetes suunab päringud ja koormuse tasakaalu nende vahel. Ja ideaaljuhul peaks see kõik ideaalselt töötama.
Peame meeles, et mikroteenused on väikesed ja lühiajalised. Põgusus, mis siin tähendab ilmumise ja kadumise kergust, on sageli alahinnatud. Mikroteenuse järjekordse eksemplari sünd ja surm podis on üsna oodatud asjad, OpenShift ja Kubernetes saavad sellega hästi hakkama ning kõik toimib suurepäraselt – aga jällegi teoreetiliselt.
Kuidas see tegelikult töötab
Kujutage nüüd ette, et konkreetne mikroteenuse eksemplar, see tähendab konteiner, on muutunud kasutuskõlbmatuks: see kas ei reageeri (viga 503) või, mis veelgi ebameeldivam, reageerib, kuid liiga aeglaselt. Teisisõnu muutub see tõrgeteta või ei vasta päringutele, kuid seda ei eemaldata automaatselt basseinist. Mida tuleks sel juhul teha? Kas uuesti proovida? Kas ma peaksin selle marsruutimisskeemist eemaldama? Ja mida tähendab "liiga aeglane" – kui palju see arvudes on ja kes need määrab? Võib-olla teete pausi ja proovige hiljem uuesti? Kui jah, siis kui palju hiljem?
Mis on basseini väljatõmbamine Istios
Ja siin tuleb appi Istio oma Circuit Breaker kaitsemasinatega, mis eemaldavad ajutiselt vigased konteinerid marsruutimise ja koormuse tasakaalustamise ressursside kogumist, rakendades basseini väljutamise protseduuri.
Kasutades kõrvalekallete tuvastamise strateegiat, tuvastab Istio kõverad, mis on rivist väljas, ja eemaldab need teatud ajaks ressursside kogumist, mida nimetatakse uneaknaks.
Et näidata, kuidas see Kuberneteses OpenShifti platvormil töötab, alustame hoidlas olevast näitest tavaliselt töötavate mikroteenuste ekraanipildiga . Siin on meil kaks kausta, v1 ja v2, millest kumbki töötab ühte konteinerit. Kui Istio marsruutimise reegleid ei kasutata, kasutab Kubernetes vaikimisi ühtlaselt tasakaalustatud ümberringi marsruutimist:
Avariiks valmistumine
Enne basseini väljatõmbamist peate looma Istio marsruutimise reegli. Oletame, et tahame jaotada päringuid kaustade vahel suhtega 50/50. Lisaks suurendame v2 konteinerite arvu ühelt kahele järgmiselt:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Nüüd seadsime paika marsruutimise reegli, nii et liiklus jaotatakse kaustade vahel suhtega 50/50.
Selle reegli tulemus näeb välja järgmine:
Vigu võib leida sellest, et see ekraan ei ole 50/50, vaid 14:9, kuid aja jooksul olukord paraneb.
Vigade tegemine
Nüüd keelame ühe kahest v2 konteinerist, nii et meil oleks üks terve v1 konteiner, üks terve v2 konteiner ja üks vigane v2 konteiner:
Vigade parandamine
Niisiis, meil on vigane konteiner ja on aeg basseini väljutamiseks. Väga lihtsa konfiguratsiooni abil välistame selle ebaõnnestunud konteineri kõigist marsruutimisskeemidest 15 sekundiks, lootes, et see naaseb normaalsesse olekusse (kas taaskäivitab või taastab jõudluse). Selline näeb see konfiguratsioon välja ja selle töö tulemused:
Nagu näete, ei kasutata ebaõnnestunud v2 konteinerit enam taotluste marsruutimiseks, kuna see on kogumist eemaldatud. Kuid 15 sekundi pärast naaseb see automaatselt basseini. Tegelikult me lihtsalt näitasime, kuidas basseini väljutamine töötab.
Alustame arhitektuuri ehitamisega
Pool Ejection koos Istio jälgimisvõimalustega võimaldab teil alustada raamistiku ehitamist vigaste konteinerite automaatseks asendamiseks, et vähendada, kui mitte kõrvaldada, seisakuid ja tõrkeid.
NASA-l on üks kõlav moto - Failure Is Not An Option, mille autoriks peetakse lennurežissööri . Seda saab vene keelde tõlkida kui "Ebaõnnestumine pole valik" ja siin on tähendus, et kõik saab tööle panna, kui teil on piisavalt tahet. Kuid päriselus ei juhtu ebaõnnestumised lihtsalt, need on vältimatud, kõikjal ja kõiges. Ja kuidas nendega toime tulla mikroteenuste puhul? Meie arvates on parem loota mitte tahtejõule, vaid konteinerite võimalustele, , Ja .
Istio, nagu eespool kirjutasime, rakendab kaitselülitite kontseptsiooni, mis on ennast füüsilises maailmas hästi tõestanud. Ja nagu elektriline kaitselüliti lülitab välja vooluringi probleemse osa, avab Istio tarkvara Circuit Breaker ühenduse päringuvoo ja probleemse konteineri vahel, kui lõpp-punktiga on midagi valesti, näiteks kui server jooksis kokku või hakkas võta aeglasemalt.
Veelgi enam, teisel juhul on probleeme ainult rohkem, kuna ühe konteineri pidurid mitte ainult ei põhjusta sellele juurdepääsu teenustele viivituste kaskaadi ja vähendavad selle tulemusena kogu süsteemi jõudlust, vaid tekitavad ka korduvaid taotlusi juba aeglaselt töötavale teenusele, mis ainult halvendab olukorda .
Teoreetiliselt kaitselüliti
Circuit Breaker on puhverserver, mis juhib päringute voogu lõpp-punkti. Kui see punkt lakkab töötamast või, sõltuvalt määratud sätetest, hakkab aeglustuma, katkestab puhverserver ühenduse konteineriga. Seejärel suunatakse liiklus lihtsalt koormuse tasakaalustamise tõttu teistesse konteineritesse. Ühendus jääb avatuks teatud uneakna, näiteks kahe minuti jooksul, ja seejärel loetakse see pooleldi avatuks. Järgmise päringu saatmise katse määrab ühenduse edasise oleku. Kui teenusega on kõik korras, taastub ühendus töökorras ja suletakse uuesti. Kui teenusega on endiselt midagi valesti, katkestatakse ühendus ja unerežiimi aken lubatakse uuesti. Selline näeb välja lihtsustatud kaitselüliti olekuskeem:
Siinkohal on oluline märkida, et see kõik toimub nii-öelda süsteemiarhitektuuri tasemel. Nii et mingil hetkel peate õpetama oma rakendusi Circuit Breakeriga töötama, näiteks andma vastuseks vaikeväärtuse või võimaluse korral ignoreerima teenuse olemasolu. Selleks kasutatakse vaheseina mustrit, kuid see ei kuulu käesoleva artikli reguleerimisalasse.
Kaitselüliti praktikas
Näiteks käitame OpenShiftis meie soovitusliku mikroteenuse kahte versiooni. Versioon 1 töötab hästi, kuid versioonis 2 lisame viivituse, et simuleerida serveri aeglustumist. Tulemuste vaatamiseks kasutage tööriista :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Kõik näib toimivat, aga mis hinnaga? Esmapilgul on meil 100% saadavus, kuid vaadake lähemalt – tehingu maksimaalne kestus on lausa 12 sekundit. See on selgelt kitsaskoht ja seda tuleb laiendada.
Selleks kasutame Istiot, et kõrvaldada kõned aeglastele konteineritele. Nii näeb vastav konfiguratsioon Circuit Breakerit kasutades välja:
Viimane rida parameetriga httpMaxRequestsPerConnection annab märku, et ühendus tuleks katkestada, kui üritatakse lisaks olemasolevale ühendusele luua veel üks – teine – ühendus. Kuna meie konteiner simuleerib aeglast teenust, tekivad sellised olukorrad perioodiliselt ja siis Istio tagastab vea 503, kuid piiramine näitab seda:
OK, meil on Circuit Breaker, mis edasi?
Niisiis rakendasime automaatse väljalülitamise ilma teenuste endi lähtekoodi üldse puudutamata. Kasutades ülalkirjeldatud Circuit Breaker ja Pool Ejection protseduuri, saame pidurikonteinerid ressursside kogumist eemaldada, kuni need normaliseeruvad, ja kontrollida nende olekut kindlaksmääratud sagedusega – meie näites on see kaks minutit (sleepWindow parameeter).
Pange tähele, et rakenduse võime reageerida tõrkele 503 on endiselt seatud lähtekoodi tasemel. Sõltuvalt olukorrast on Circuit Breakeri kasutamiseks palju strateegiaid.
Järgmises postituses: Räägime jälgimisest ja jälgimisest, mis on juba sisseehitatud või Istiole hõlpsasti lisatavad, ning ka sellest, kuidas tahtlikult süsteemi vigu sisestada.
Allikas: www.habr.com