Prázdniny sa skončili a my sme späť s naším druhým príspevkom v sérii Istio Service Mesh.
Dnešnou témou je Circuit Breaker, čo v preklade do ruštiny elektrotechnika znamená „istič“, v bežnej reči – „istič“. Iba v Istio tento stroj neodpojí skratovaný alebo preťažený okruh, ale chybné nádoby.
Ako by to malo v ideálnom prípade fungovať
Keď sú mikroslužby spravované Kubernetes, napríklad v rámci platformy OpenShift, automaticky sa škálujú nahor a nadol v závislosti od zaťaženia. Keďže mikroslužby bežia v podoch, na jednom koncovom bode môže byť viacero inštancií kontajnerovej mikroslužby a Kubernetes bude medzi nimi smerovať požiadavky a vyrovnávať zaťaženie. A – v ideálnom prípade – toto všetko by malo perfektne fungovať.
Pamätáme si, že mikroslužby sú malé a pominuteľné. Pominuteľnosť, ktorá tu znamená ľahkosť objavovania sa a miznutia, sa často podceňuje. Zrod a smrť ďalšej inštancie mikroslužby v pod sú celkom očakávané veci, OpenShift a Kubernetes to zvládajú dobre a všetko funguje skvele - ale opäť teoreticky.
Ako to naozaj funguje
Teraz si predstavte, že konkrétna inštancia mikroslužby, teda kontajner, sa stala nepoužiteľná: buď neodpovedá (chyba 503), alebo, čo je nepríjemnejšie, odpovedá, ale príliš pomaly. Inými slovami, stane sa chybným alebo nereaguje na požiadavky, ale automaticky sa neodstráni z fondu. Čo treba urobiť v tomto prípade? Chcete to skúsiť znova? Mám ho odstrániť zo schémy smerovania? A čo znamená „príliš pomalé“ – koľko je to v číslach a kto ich určuje? Možno len dať pauzu a skúsiť to znova neskôr? Ak áno, o koľko neskôr?
Čo je vyhadzovanie bazéna v Istiu
A tu prichádza na pomoc Istio so svojimi ochrannými strojmi Circuit Breaker, ktoré dočasne odstraňujú chybné kontajnery z fondu smerovania a vyrovnávania záťaže, pričom implementujú procedúru vysunutia bazéna.
Pomocou stratégie detekcie odľahlých hodnôt Istio deteguje krivky pod, ktoré sú mimo čiary, a odstraňuje ich z fondu zdrojov na vopred určený čas, ktorý sa nazýva okno spánku.
Aby sme ukázali, ako to funguje v Kubernetes na platforme OpenShift, začnime snímkou normálne fungujúcich mikroslužieb z príkladu v úložisku . Tu máme dva moduly, v1 a v2, z ktorých každý má jeden kontajner. Keď sa pravidlá smerovania Istio nepoužívajú, Kubernetes predvolene použije rovnomerne vyvážené kruhové smerovanie:
Príprava na haváriu
Pred vykonaním vysunutia bazéna musíte vytvoriť pravidlo smerovania Istio. Povedzme, že chceme rozdeliť požiadavky medzi moduly v pomere 50/50. Okrem toho zvýšime počet kontajnerov v2 z jedného na dva, a to takto:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Teraz nastavíme pravidlo smerovania tak, aby sa návštevnosť rozdelila medzi moduly v pomere 50/50.
Výsledok tohto pravidla vyzerá takto:
Môžete nájsť chybu v tom, že táto obrazovka nie je 50/50, ale 14:9, ale časom sa situácia zlepší.
Robiť poruchu
Teraz zakážme jeden z dvoch kontajnerov v2, aby sme mali jeden zdravý kontajner v1, jeden zdravý kontajner v2 a jeden chybný kontajner v2:
Oprava chyby
Takže máme chybný kontajner a je čas na vysunutie bazéna. Pomocou veľmi jednoduchej konfigurácie vylúčime tento neúspešný kontajner zo všetkých smerovacích schém na 15 sekúnd v nádeji, že sa vráti do zdravého stavu (buď reštart alebo obnovenie výkonu). Takto vyzerá táto konfigurácia a výsledky jej práce:
Ako vidíte, neúspešný kontajner v2 sa už nepoužíva na požiadavky smerovania, pretože bol odstránený z oblasti. Ale po 15 sekundách sa automaticky vráti do bazéna. V skutočnosti sme práve ukázali, ako funguje vyhadzovanie bazéna.
Začnime budovať architektúru
Pool Ejection v kombinácii s monitorovacími schopnosťami Istio vám umožňuje začať budovať rámec na automatickú výmenu chybných kontajnerov, aby sa znížili, ak nie úplne odstránili, prestoje a zlyhania.
NASA má jedno hlasné motto – Failure Is Not an Option, za ktorého autora sa považuje letový riaditeľ . Do ruštiny sa to dá preložiť ako „Neúspech nie je možnosť“ a znamená to, že všetko môže fungovať, ak máte dostatok vôle. V skutočnom živote sa však zlyhania nestávajú len tak, sú nevyhnutné, všade a vo všetkom. A ako si s nimi poradiť v prípade mikroslužieb? Podľa nášho názoru je lepšie spoliehať sa nie na vôľu, ale na schopnosti kontajnerov, , A .
Istio, ako sme písali vyššie, implementuje koncept ističov, ktorý sa dobre osvedčil vo fyzickom svete. A rovnako ako istič elektrického obvodu vypína problémovú časť obvodu, softvér Istio Circuit Breaker otvára spojenie medzi prúdom požiadaviek a problémovým kontajnerom, keď niečo nie je v poriadku s koncovým bodom, napríklad keď server zlyhá alebo sa začne Spomaľ.
Navyše, v druhom prípade je len viac problémov, pretože brzdy jedného kontajnera nielenže spôsobujú kaskádu oneskorení služieb, ktoré k nemu pristupujú, a v dôsledku toho znižujú výkon systému ako celku, ale vytvárajú aj opakované požiadavky na už pomaly bežiacu službu, čo situáciu len zhoršuje .
Istič teoreticky
Circuit Breaker je proxy server, ktorý riadi tok požiadaviek ku koncovému bodu. Keď tento bod prestane fungovať alebo sa v závislosti od zadaných nastavení začne spomaľovať, server proxy preruší spojenie s kontajnerom. Premávka je potom presmerovaná na iné kontajnery, jednoducho kvôli vyvažovaniu záťaže. Pripojenie zostane otvorené počas daného okna spánku, povedzme dve minúty, a potom sa považuje za polootvorené. Pokus o odoslanie ďalšej požiadavky určuje ďalší stav spojenia. Ak je so službou všetko v poriadku, spojenie sa vráti do funkčného stavu a opäť sa uzavrie. Ak so službou stále nie je niečo v poriadku, pripojenie sa odpojí a okno spánku sa znova povolí. Takto vyzerá zjednodušený diagram stavu ističa:
Tu je dôležité poznamenať, že toto všetko sa deje na úrovni takpovediac systémovej architektúry. Takže v určitom okamihu budete musieť naučiť svoje aplikácie pracovať s ističom, napríklad poskytnúť predvolenú hodnotu ako odpoveď alebo, ak je to možné, ignorovať existenciu služby. Používa sa na to prepážkový vzor, ktorý však presahuje rámec tohto článku.
Istič v praxi
Napríklad na OpenShift spustíme dve verzie našej odporúčacej mikroslužby. Verzia 1 bude fungovať dobre, ale vo verzii 2 zabudujeme oneskorenie na simuláciu spomalenia na serveri. Ak chcete zobraziť výsledky, použite nástroj :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Zdá sa, že všetko funguje, ale za akú cenu? Na prvý pohľad máme 100% dostupnosť, no pozrite sa bližšie – maximálne trvanie transakcie je až 12 sekúnd. Toto je jednoznačne prekážka a je potrebné ju rozšíriť.
Aby sme to dosiahli, použijeme Istio na odstránenie volaní do pomalých kontajnerov. Takto vyzerá zodpovedajúca konfigurácia pomocou Circuit Breaker:
Posledný riadok s parametrom httpMaxRequestsPerConnection signalizuje, že spojenie s by sa malo odpojiť pri pokuse o vytvorenie ďalšieho – druhého – pripojenia k existujúcemu. Keďže náš kontajner simuluje pomalú službu, takéto situácie budú nastať pravidelne a potom Istio vráti chybu 503, ale toto sa ukáže obliehaním:
OK, máme Circuit Breaker, čo ďalej?
Implementovali sme teda automatické vypnutie bez toho, aby sme sa vôbec dotkli zdrojového kódu samotných služieb. Pomocou Circuit Breaker a postupu vysunutia bazéna opísaného vyššie môžeme odstraňovať brzdové kontajnery z fondu zdrojov, kým sa nevrátia do normálu, a kontrolovať ich stav v určenej frekvencii – v našom príklade sú to dve minúty (parameter sleepWindow).
Všimnite si, že schopnosť aplikácie reagovať na chybu 503 je stále nastavená na úrovni zdrojového kódu. Existuje mnoho stratégií na používanie ističa v závislosti od situácie.
V ďalšom príspevku: Povieme si o sledovaní a monitorovaní, ktoré je už zabudované alebo jednoducho pridané do Istio, ako aj o tom, ako úmyselne zaviesť chyby do systému.
Zdroj: hab.com