Počitnic je konec in vračamo se z drugo objavo v seriji Istio Service Mesh.
Današnja tema je Circuit Breaker, ki v prevodu v rusko elektrotehniko pomeni "odklopnik", v običajnem jeziku - "odklopnik". Samo v Istio ta stroj ne odklopi kratkotrajnega ali preobremenjenega tokokroga, ampak okvarjene vsebnike.
Kako naj bi to idealno delovalo
Ko mikrostoritve upravlja Kubernetes, na primer znotraj platforme OpenShift, se samodejno povečajo in zmanjšajo glede na obremenitev. Ker se mikrostoritve izvajajo v sklopih, je lahko na eni končni točki več primerkov kontejnerske mikrostoritve, Kubernetes pa bo usmerjal zahteve in uravnaval obremenitev med njimi. In - v idealnem primeru - bi moralo vse to delovati brezhibno.
Spomnimo se, da so mikrostoritve majhne in kratkotrajne. Minljivost, ki tu pomeni lahkotnost pojavljanja in izginjanja, je pogosto podcenjena. Rojstvo in smrt še enega primerka mikrostoritve v podu sta povsem pričakovani stvari, OpenShift in Kubernetes to dobro obvladata in vse deluje odlično - a spet v teoriji.
Kako v resnici deluje
Zdaj pa si predstavljajte, da je določena instanca mikrostoritve, torej vsebnik, postala neuporabna: ali se ne odziva (napaka 503) ali pa, kar je bolj neprijetno, se odziva, a prepočasi. Z drugimi besedami, postane moten ali se ne odziva na zahteve, vendar ni samodejno odstranjen iz bazena. Kaj storiti v tem primeru? Da poskusim znova? Ali naj ga odstranim iz sheme usmerjanja? In kaj pomeni »prepočasi« – koliko jih je v številkah in kdo jih določa? Morda samo oddahnite in poskusite znova pozneje? Če da, koliko kasneje?
Kaj je Pool Ejection v Istio
In tukaj Istio priskoči na pomoč s svojimi napravami za zaščito pred prekinjevalci tokokroga, ki začasno odstranijo vsebnike z napako iz bazena virov za usmerjanje in uravnoteženje obremenitve, pri čemer izvajajo postopek izmeta bazena.
S strategijo zaznavanja izstopnih vrednosti Istio zazna krivulje, ki so izven linije, in jih odstrani iz zbirke virov za določen čas, ki se imenuje okno mirovanja.
Da pokažemo, kako to deluje v Kubernetesu na platformi OpenShift, začnimo s posnetkom zaslona normalno delujočih mikrostoritev iz primera v repozitoriju . Tukaj imamo dva sklopa, v1 in v2, od katerih vsak poganja en vsebnik. Ko pravila usmerjanja Istio niso uporabljena, Kubernetes privzeto nastavi enakomerno uravnoteženo krožno usmerjanje:
Priprave na neuspeh
Preden izvedete Pool Ejection, morate ustvariti pravilo usmerjanja Istio. Recimo, da želimo porazdeliti zahteve med sklope v razmerju 50/50. Poleg tega bomo povečali število vsebnikov v2 z enega na dva, takole:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Zdaj smo postavili pravilo usmerjanja, tako da je promet porazdeljen med sklopi v razmerju 50/50.
Rezultat tega pravila je videti tako:
Lahko bi zamerili, da ta zaslon ni 50/50, ampak 14:9, a sčasoma se bo stanje izboljšalo.
Ustvarjanje napake
Zdaj pa onemogočimo enega od dveh vsebnikov v2, tako da bomo imeli en zdrav vsebnik v1, en zdrav vsebnik v2 in en pokvarjen vsebnik v2:
Odpravljanje napake
Torej, imamo pokvarjen vsebnik in čas je za izmet iz bazena. Z uporabo zelo preproste konfiguracije bomo ta neuspeli vsebnik za 15 sekund izključili iz vseh shem usmerjanja v upanju, da se bo vrnil v zdravo stanje (bodisi znova zagnal ali obnovil delovanje). Tako izgleda ta konfiguracija in rezultati njenega dela:
Kot lahko vidite, se neuspeli vsebnik v2 ne uporablja več za zahteve za usmerjanje, ker je bil odstranjen iz področja. Toda po 15 sekundah se samodejno vrne v bazen. Pravzaprav smo pravkar pokazali, kako deluje Pool Ejection.
Začnimo graditi arhitekturo
Pool Ejection vam v kombinaciji z zmožnostmi spremljanja Istio omogoča, da začnete graditi okvir za samodejno zamenjavo okvarjenih vsebnikov, da zmanjšate, če ne odpravite, izpade in okvare.
NASA ima en glasen moto - Neuspeh ni možnost, katerega avtor velja za direktorja poletov. . V ruščino se lahko prevede kot »Neuspeh ni možnost«, pomen pa je, da je vse mogoče doseči, če imate dovolj volje. Vendar pa se v resničnem življenju neuspehi ne zgodijo kar tako, ampak so neizogibni, povsod in v vsem. In kako z njimi ravnati v primeru mikrostoritev? Po našem mnenju se je bolje zanašati ne na moč volje, temveč na zmogljivosti vsebnikov, , In .
Istio, kot smo zapisali zgoraj, izvaja koncept odklopnikov, ki se je v fizičnem svetu dobro izkazal. In tako kot odklopnik električnega tokokroga izklopi problematični odsek tokokroga, Istiova programska oprema Circuit Breaker odpre povezavo med tokom zahtev in vsebnikom težav, ko je s končno točko nekaj narobe, na primer, ko se strežnik zruši ali začne upočasni.
Še več, v drugem primeru je težav samo še več, saj zavore enega vsebnika ne povzročajo samo kaskade zamud pri storitvah, ki dostopajo do njega, in posledično zmanjšujejo delovanje sistema kot celote, ampak povzročajo tudi ponavljajoče se zahteve do že tako počasi delujoče storitve, kar samo poslabša situacijo.
Odklopnik v teoriji
Circuit Breaker je posrednik, ki nadzoruje pretok zahtev do končne točke. Ko ta točka preneha delovati ali se, odvisno od navedenih nastavitev, začne upočasnjevati, proxy prekine povezavo z vsebnikom. Promet se nato preusmeri na druge kontejnerje, preprosto zaradi uravnoteženja obremenitve. Povezava ostane odprta za dano okno mirovanja, recimo dve minuti, nato pa velja za napol odprto. Poskus pošiljanja naslednje zahteve določa nadaljnje stanje povezave. Če je s storitvijo vse v redu, se povezava vrne v delovno stanje in se ponovno zapre. Če je s storitvijo še vedno nekaj narobe, se povezava prekine in okno spanja je ponovno omogočeno. Evo, kako izgleda poenostavljeni diagram stanja odklopnika:
Pri tem je pomembno opozoriti, da se vse to dogaja na ravni tako rekoč sistemske arhitekture. Zato boste morali na neki točki svoje aplikacije naučiti delati z odklopnikom, na primer zagotoviti privzeto vrednost kot odgovor ali, če je mogoče, ignorirati obstoj storitve. Za to se uporablja pregradni vzorec, vendar je izven obsega tega članka.
Odklopnik v praksi
Na primer, na OpenShift bomo izvajali dve različici naše priporočilne mikrostoritve. Različica 1 bo delovala dobro, v različici 2 pa bomo vgradili zakasnitev za simulacijo upočasnitve strežnika. Za ogled rezultatov uporabite orodje :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Zdi se, da vse deluje, a za kakšno ceno? Na prvi pogled imamo 100% razpoložljivost, a poglejmo podrobneje - maksimalno trajanje transakcije je kar 12 sekund. To je očitno ozko grlo in ga je treba razširiti.
Za to bomo uporabili Istio za odpravo klicev počasnih vsebnikov. Takole izgleda ustrezna konfiguracija z odklopnikom:
Zadnja vrstica s parametrom httpMaxRequestsPerConnection signalizira, da je treba povezavo z prekiniti, ko poskušate ustvariti drugo - drugo - povezavo poleg obstoječe. Ker naš vsebnik simulira počasno storitev, se bodo takšne situacije pojavile občasno, nato pa bo Istio vrnil napako 503, vendar bo obleganje pokazalo tole:
V redu, imamo odklopnik, kaj je naslednje?
Tako smo uvedli samodejno zaustavitev, ne da bi se sploh dotaknili izvorne kode samih storitev. Z zgoraj opisanim odklopnikom in postopkom izmeta iz bazena lahko odstranimo zavorne vsebnike iz bazena virov, dokler se ne vrnejo v normalno stanje, in preverjamo njihov status ob določeni pogostosti - v našem primeru je to dve minuti (parameter sleepWindow).
Upoštevajte, da je zmožnost aplikacije, da se odzove na napako 503, še vedno nastavljena na ravni izvorne kode. Obstaja veliko strategij za uporabo odklopnika, odvisno od situacije.
V naslednji objavi: Govorili bomo o sledenju in spremljanju, ki je že vgrajeno ali preprosto dodano v Istio, pa tudi o tem, kako namerno vnesti napake v sistem.
Vir: www.habr.com