Lomat ovat ohi ja olemme palanneet Istio Service Mesh -sarjan toisella postauksellamme.
Tämän päivän aiheena on Circuit Breaker, joka käännettynä venäjäksi sähkötekniikaksi tarkoittaa "katkaisijaa", yleisessä kielessä - "katkaisija". Vain Istiossa tämä kone ei katkaise oikosulkua tai ylikuormitettua piiriä, vaan viallisia säiliöitä.
Miten tämän pitäisi toimia ihanteellisesti
Kun Kubernetes hallitsee mikropalveluita esimerkiksi OpenShift-alustalla, ne skaalautuvat automaattisesti ylös ja alas kuormituksen mukaan. Koska mikropalvelut toimivat koteloissa, yhdessä päätepisteessä voi olla useita säiliöitä sisältävää mikropalvelua, ja Kubernetes reitittää pyynnöt ja kuormituksen tasapainon niiden välillä. Ja - ihannetapauksessa - kaiken tämän pitäisi toimia täydellisesti.
Muistamme, että mikropalvelut ovat pieniä ja ohimeneviä. Efemeriteetti, joka tarkoittaa tässä ilmaantumisen ja katoamisen helppoutta, on usein aliarvioitu. Toisen mikropalvelun synty ja kuolema podissa ovat melko odotettuja asioita, OpenShift ja Kubernetes hoitavat tämän hyvin, ja kaikki toimii hienosti - mutta jälleen teoriassa.
Miten se todella toimii
Kuvittele nyt, että mikropalvelun tietty esiintymä eli kontti on muuttunut käyttökelvottomaksi: joko se ei vastaa (virhe 503), tai mikä pahinta, se vastaa, mutta liian hitaasti. Toisin sanoen siitä tulee häiritsevä tai se ei vastaa pyyntöihin, mutta sitä ei poisteta automaattisesti poolista. Mitä tässä tapauksessa pitäisi tehdä? Yritätkö uudelleen? Pitäisikö minun poistaa se reitityskaaviosta? Ja mitä "liian hidas" tarkoittaa – kuinka monta se on numeroina ja kuka ne määrittää? Ehkä vain pidä tauko ja yritä myöhemmin uudelleen? Jos on, kuinka paljon myöhemmin?
Mikä on uima-altaan poisto Istiossa
Ja tässä Istio tulee apuun Circuit Breaker -suojakoneineen, jotka poistavat väliaikaisesti vialliset säiliöt reititys- ja kuormantasausresurssipoolista toteuttaen Pool Ejection -menettelyn.
Käyttämällä outlier-tunnistusstrategiaa Istio havaitsee rivistä poikkeavat käyrätyypit ja poistaa ne resurssivarannosta tietyksi ajaksi, jota kutsutaan lepotilaikkunaksi.
Jos haluat näyttää, kuinka tämä toimii Kubernetesissa OpenShift-alustalla, aloitetaan kuvakaappauksella normaalisti toimivista mikropalveluista arkiston esimerkistä . Tässä meillä on kaksi podia, v1 ja v2, joissa molemmissa on yksi kontti. Kun Istio-reitityssääntöjä ei käytetä, Kubernetes käyttää oletuksena tasaisesti tasapainotettua round-robin-reititystä:
Valmistautuminen kolariin
Ennen kuin teet Pool Ejection -toiminnon, sinun on luotava Istio-reitityssääntö. Oletetaan, että haluamme jakaa pyynnöt podien välillä suhteessa 50/50. Lisäksi lisäämme v2-säilöjen määrää yhdestä kahteen seuraavasti:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Nyt asetamme reitityssäännön niin, että liikenne jakautuu podien kesken suhteessa 50/50.
Tämän säännön tulos näyttää tältä:
Voit löytää vikaa siitä, että tämä näyttö ei ole 50/50, vaan 14:9, mutta ajan myötä tilanne paranee.
Vian tekeminen
Poistetaan nyt toinen kahdesta v2-säilöstä, jotta meillä on yksi terve v1-säilö, yksi terve v2-säilö ja yksi viallinen v2-säilö:
Vian korjaaminen
Meillä on siis viallinen kontti, ja on aika altaan poistoon. Käyttämällä hyvin yksinkertaista konfiguraatiota suljemme tämän epäonnistuneen säilön kaikista reititysjärjestelmistä 15 sekunnin ajaksi siinä toivossa, että se palaa terveeseen tilaan (joko käynnistää uudelleen tai palauttaa suorituskyvyn). Tältä tämä asetus näyttää ja sen työn tulokset:
Kuten näet, epäonnistunutta v2-säilöä ei enää käytetä reitityspyyntöihin, koska se on poistettu poolista. Mutta 15 sekunnin kuluttua se palaa automaattisesti altaaseen. Itse asiassa näytimme vain, kuinka altaan poisto toimii.
Aloitetaan arkkitehtuurin rakentaminen
Pool Ejection yhdistettynä Istion valvontaominaisuuksiin mahdollistaa puitteiden rakentamisen viallisten säiliöiden automaattiselle vaihtamiselle, mikä vähentää, ellei jopa eliminoida, seisokkeja ja vikoja.
NASA:lla on yksi äänekäs motto - Failure Is Not an Option, jonka kirjoittajaa pidetään lennonjohtajana . Se voidaan kääntää venäjäksi "Epäonnistuminen ei ole vaihtoehto", ja tässä on tarkoitus, että kaikki voidaan saada toimimaan, jos sinulla on tarpeeksi tahtoa. Todellisessa elämässä epäonnistumiset eivät kuitenkaan vain tapahdu, ne ovat väistämättömiä, kaikkialla ja kaikessa. Ja kuinka käsitellä niitä mikropalvelujen tapauksessa? Mielestämme on parempi luottaa ei tahdonvoimaan, vaan konttien kykyihin, , Ja .
Kuten edellä kirjoitimme, Istio toteuttaa katkaisijoiden konseptia, joka on osoittautunut hyvin fyysisessä maailmassa. Ja aivan kuten sähkökatkaisija sammuttaa piirin ongelmaosan, Istion ohjelmisto Circuit Breaker avaa yhteyden pyyntövirran ja ongelmasäiliön välillä, kun jokin on vialla päätepisteessä, esimerkiksi kun palvelin kaatui tai alkoi hidasta.
Lisäksi toisessa tapauksessa on vain enemmän ongelmia, koska yhden kontin jarrut eivät ainoastaan aiheuta viiveitä siihen pääsyssä olevissa palveluissa ja heikentävät sen seurauksena koko järjestelmän suorituskykyä, vaan myös synnyttävät toistuvia pyytää jo hitaita palvelua, mikä vain pahentaa tilannetta .
Circuit Breaker teoriassa
Circuit Breaker on välityspalvelin, joka ohjaa pyyntöjen kulkua päätepisteeseen. Kun tämä piste lakkaa toimimasta tai, määritetyistä asetuksista riippuen, alkaa hidastua, välityspalvelin katkaisee yhteyden säilöön. Liikenne ohjataan sitten muihin kontteihin yksinkertaisesti kuormituksen tasapainottamisen vuoksi. Yhteys pysyy auki tietyn lepotilaikkunan, esimerkiksi kahden minuutin ajan, ja sen jälkeen katsotaan puoliavoin. Yritys lähettää seuraava pyyntö määrittää yhteyden lisätilan. Jos kaikki on kunnossa palvelun kanssa, yhteys palaa toimintakuntoon ja sulkeutuu jälleen. Jos palvelussa on edelleen jotain vikaa, yhteys katkeaa ja lepotilaikkuna otetaan uudelleen käyttöön. Tältä näyttää yksinkertaistettu katkaisijan tilakaavio:
Tässä on tärkeää huomata, että kaikki tämä tapahtuu niin sanotusti järjestelmäarkkitehtuurin tasolla. Joten jossain vaiheessa sinun on opetettava sovelluksesi toimimaan Circuit Breakerin kanssa, esimerkiksi antamaan oletusarvo vastauksena tai, jos mahdollista, jättämään huomioimatta palvelun olemassaolo. Tätä varten käytetään laipiokuviota, mutta se ei kuulu tämän artikkelin soveltamisalaan.
Katkaisija käytännössä
Suoritamme esimerkiksi kaksi versiota suositusmikropalvelustamme OpenShiftissä. Versio 1 toimii hyvin, mutta v2:ssa lisäämme viiveen simuloidaksemme palvelimen hidastuksia. Käytä työkalua nähdäksesi tulokset :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Kaikki näyttää toimivan, mutta millä hinnalla? Ensi silmäyksellä meillä on 100 % käytettävyys, mutta katso tarkemmin - tapahtuman maksimikesto on jopa 12 sekuntia. Tämä on selkeästi pullonkaula ja sitä on laajennettava.
Tätä varten käytämme Istioa poistamaan puhelut hidastettuihin kontteihin. Tältä vastaava konfiguraatio näyttää Circuit Breakeria käytettäessä:
Viimeinen rivi httpMaxRequestsPerConnection-parametrilla ilmaisee, että yhteys tulee katkaista, kun yritetään luoda toinen - toinen - yhteys olemassa olevan lisäksi. Koska konttimme simuloi hidasta palvelua, tällaisia tilanteita tulee ajoittain, ja sitten Istio palauttaa 503-virheen, mutta piiritys näyttää tämän:
OK, meillä on Circuit Breaker, mitä seuraavaksi?
Joten toteutimme automaattisen sammutuksen koskematta itse palveluiden lähdekoodiin. Käyttämällä Circuit Breakeria ja yllä kuvattua Pool Ejection -menettelyä voimme poistaa jarrusäiliöt resurssipoolista, kunnes ne palaavat normaaliksi, ja tarkistaa niiden tilan tietyllä taajuudella - esimerkissämme tämä on kaksi minuuttia (sleepWindow-parametri).
Huomaa, että sovelluksen kyky vastata 503-virheeseen on edelleen asetettu lähdekooditasolla. Circuit Breakerin käyttämiseen on olemassa monia strategioita tilanteesta riippuen.
Seuraavassa postauksessa: Puhumme Istioon jo sisäänrakennetusta tai helposti lisättävästä jäljityksestä ja valvonnasta sekä siitä, miten virheitä voidaan tarkoituksellisesti tuoda järjestelmään.
Lähde: will.com