Az ünnepek véget értek, és visszatérünk második bejegyzésünkkel az Istio Service Mesh sorozatban.
A mai téma a Circuit Breaker, ami orosz elektrotechnikára fordítva „megszakítót”, a köznyelvben „megszakítót” jelent. Csak az Istióban ez a gép nem zárlatos vagy túlterhelt áramkört kapcsol le, hanem hibás konténereket.
Hogyan kellene ennek ideálisan működnie
Amikor a mikroszolgáltatásokat a Kubernetes kezeli, például az OpenShift platformon belül, a terheléstől függően automatikusan felfelé és lefelé lépkednek. Mivel a mikroszolgáltatások podokban futnak, egy végponton több konténeres mikroszolgáltatás is előfordulhat, és a Kubernetes átirányítja a kéréseket és a terheléselosztást közöttük. És - ideális esetben - mindeznek tökéletesen működnie kell.
Emlékezzünk arra, hogy a mikroszolgáltatások kicsik és átmenetiek. A mulandóságot, amely itt a megjelenés és az eltűnés könnyűségét jelenti, gyakran alábecsülik. A mikroszolgáltatás újabb példányának megszületése és halála egy podban teljesen várt dolog, az OpenShift és a Kubernetes jól kezeli ezt, és minden remekül működik – de elméletileg.
Hogyan működik valójában
Most képzeljük el, hogy egy mikroszolgáltatás egy adott példánya, vagyis egy konténer használhatatlanná vált: vagy nem válaszol (503-as hiba), vagy ami még kellemetlen, válaszol, de túl lassan. Más szavakkal, hibássá válik, vagy nem válaszol a kérésekre, de nem távolítja el automatikusan a készletből. Mit kell tenni ebben az esetben? Újrapróbálni? Távolítsam el az útválasztási sémából? És mit jelent a „túl lassú” – számokban kifejezve hány, és ki határozza meg őket? Esetleg hagyj egy kis szünetet, és próbáld újra később? Ha igen, mennyivel később?
Mi az a medencekidobás Istióban?
És itt jön a segítség az Istio a Circuit Breaker védelmi gépeivel, amelyek ideiglenesen eltávolítják a hibás konténereket az útválasztási és terheléselosztási erőforráskészletből, megvalósítva a Pool Ejection eljárást.
Egy outlier-észlelési stratégia használatával az Istio észleli a soron kívüli görbesorokat, és meghatározott ideig eltávolítja őket az erőforráskészletből, amelyet alvásablaknak neveznek.
Hogy megmutassuk, hogyan működik ez a Kubernetesben az OpenShift platformon, kezdjük egy képernyőképpel a tárolóban található példából a normálisan működő mikroszolgáltatásokról. . Itt van két pod, a v1 és a v2, amelyek mindegyike egy tárolót futtat. Ha nem használ Istio útválasztási szabályokat, a Kubernetes alapértelmezés szerint egyenletesen kiegyensúlyozott kör-robin útválasztást alkalmaz:
Felkészülés a balesetre
A Pool Ejection végrehajtása előtt létre kell hoznia egy Istio útválasztási szabályt. Tegyük fel, hogy 50/50 arányban szeretnénk elosztani a kéréseket a pod-ok között. Ezenkívül a v2-es tárolók számát egyről kettőre növeljük, így:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Most beállítunk egy útválasztási szabályt, hogy a forgalom 50/50 arányban oszlik el a podok között.
Így néz ki a szabály eredménye:
Lehet hibát találni abban, hogy ez a képernyő nem 50/50, hanem 14:9, de idővel javulni fog a helyzet.
Hiba készítése
Most tiltsuk le a két v2 tároló egyikét, hogy legyen egy egészséges v1 tárolónk, egy egészséges v2 tárolónk és egy hibás v2 tárolónk:
A hiba javítása
Tehát van egy hibás konténerünk, és itt az ideje a medence kilökésének. Egy nagyon egyszerű konfigurációval ezt a meghibásodott tárolót 15 másodpercre kizárjuk az útválasztási sémákból, abban a reményben, hogy visszaáll az egészséges állapotba (vagy újraindul, vagy visszaállítja a teljesítményt). Így néz ki ez a konfiguráció és a munkájának eredménye:
Amint láthatja, a meghibásodott v2-tárolót már nem használják az átirányítási kérésekhez, mert eltávolították a készletből. De 15 másodperc elteltével automatikusan visszatér a medencébe. Valójában csak megmutattuk, hogyan működik a medencekidobás.
Kezdjük az építészet építését
A Pool Ejection az Istio felügyeleti képességeivel kombinálva lehetővé teszi a hibás konténerek automatikus cseréjét lehetővé tévő keretrendszer felépítését az állásidő és a meghibásodások csökkentése, ha nem kiküszöbölése érdekében.
A NASA-nak egy hangos mottója van - a kudarc nem opció, amelynek szerzője a repülési igazgató. . Oroszra úgy fordítható, hogy „A kudarc nem opció”, és itt az a jelentése, hogy mindent meg lehet tenni, ha van elég akarat. A való életben azonban a kudarcok nem csak megtörténnek, hanem elkerülhetetlenek, mindenhol és mindenben. És hogyan kezeljük ezeket a mikroszolgáltatások esetében? Véleményünk szerint jobb nem az akaraterőre hagyatkozni, hanem a konténerek képességeire, , És .
Az Istio, ahogy fentebb írtuk, a megszakítók koncepcióját valósítja meg, ami a fizikai világban is jól bevált. És ahogy az elektromos megszakító kikapcsolja az áramkör egy problémás részét, az Istio Circuit Breaker szoftvere megnyitja a kapcsolatot a kérések folyama és a problématároló között, ha valami nem stimmel a végponttal, például amikor a szerver összeomlik vagy lassíts.
Sőt, a második esetben csak több a probléma, mivel egy konténer fékjei nem csak az azt elérő szolgáltatások kaszkádos késését okozzák, és ennek eredményeként csökkentik a rendszer egészének teljesítményét, hanem ismétléseket is generálnak. egy már lassan futó szolgáltatást kér, ami csak súlyosbítja a helyzetet .
Áramköri megszakító elméletben
A Circuit Breaker egy proxy, amely vezérli a kérések áramlását egy végponthoz. Amikor ez a pont leáll, vagy a megadott beállításoktól függően lassulni kezd, a proxy megszakítja a kapcsolatot a tárolóval. A forgalmat ezután más konténerekre irányítják át, egyszerűen a terheléselosztás miatt. A kapcsolat egy adott alvási ablakon keresztül nyitva marad, mondjuk két percig, majd félig nyitottnak minősül. A következő kérés elküldésének kísérlete meghatározza a kapcsolat további állapotát. Ha minden rendben van a szolgáltatással, a kapcsolat visszatér működőképes állapotba, és ismét bezárul. Ha továbbra is probléma van a szolgáltatással, a kapcsolat megszakad, és az alvó ablak újra engedélyezve lesz. Így néz ki egy egyszerűsített áramkör-megszakító állapotdiagram:
Itt fontos megjegyezni, hogy mindez úgymond rendszerarchitektúra szintjén történik. Tehát egy bizonyos ponton meg kell tanítania alkalmazásait a Circuit Breakerrel való együttműködésre, például válaszként megadnia egy alapértelmezett értéket, vagy ha lehetséges, figyelmen kívül kell hagynia a szolgáltatás létezését. Ehhez válaszfalmintát használnak, de ez túlmutat e cikk keretein.
Áramköri megszakító a gyakorlatban
Például az ajánlási mikroszolgáltatásunk két verzióját fogjuk futtatni az OpenShift-en. Az 1-es verzió jól fog működni, de a v2-ben késleltetést építünk be, hogy szimuláljuk a szerver lassulását. Az eredmények megtekintéséhez használja az eszközt :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Úgy tűnik, minden működik, de milyen áron? Első pillantásra 100%-os rendelkezésre állással rendelkezünk, de nézze meg közelebbről – a tranzakció maximális időtartama akár 12 másodperc is lehet. Ez egyértelműen szűk keresztmetszet, és bővítésre szorul.
Ehhez az Istio-t használjuk a lassú konténerek hívásainak megszüntetésére. Így néz ki a megfelelő konfiguráció a Circuit Breaker használatával:
Az utolsó sor a httpMaxRequestsPerConnection paraméterrel azt jelzi, hogy a kapcsolatot meg kell szakítani, amikor a meglévő mellett egy másik - második - kapcsolatot próbálunk létrehozni. Mivel a konténerünk lassú szolgáltatást szimulál, ilyen helyzetek időnként előfordulnak, majd az Istio 503-as hibát ad vissza, de az ostrom ezt fogja mutatni:
Rendben, megvan a Circuit Breaker, mi a következő lépés?
Tehát automatikus leállítást valósítottunk meg anélkül, hogy maguknak a szolgáltatásoknak a forráskódjához nyúltunk volna. A Circuit Breaker és a fent leírt Pool Ejection eljárás segítségével eltávolíthatjuk a féktárolókat az erőforráskészletből, amíg vissza nem térnek normál állapotba, és meghatározott gyakorisággal ellenőrizhetjük állapotukat - példánkban ez két perc (sleepWindow paraméter).
Vegye figyelembe, hogy az alkalmazás 503-as hibára való reagálási képessége továbbra is a forráskód szintjén van beállítva. A szituációtól függően számos stratégia létezik a Circuit Breaker használatára.
A következő bejegyzésben: Szó lesz a már beépített vagy könnyen hozzáadható nyomkövetésről és figyelésről, valamint arról, hogyan lehet szándékosan hibákat bevinni a rendszerbe.
Forrás: will.com