Dreifð kerfi geta verið erfið í umsjón vegna þess að þau hafa marga hreyfanlega, breytilega þætti sem allir þurfa að virka rétt til að kerfið virki. Ef einn af þáttunum bilar verður kerfið að greina það, framhjá því og laga það og allt þetta verður að gerast sjálfkrafa. Í þessari Kubernetes Best Practices röð, munum við læra hvernig á að setja upp viðbúnaðar- og líffærnipróf til að prófa heilsu Kubernetes klasa.
Heilsuskoðun er einföld leið til að láta kerfið vita hvort forritatilvikið þitt sé í gangi eða ekki. Ef umsóknartilvikið þitt er niðri ætti önnur þjónusta ekki að fá aðgang að því eða senda beiðnir til þess. Þess í stað verður að senda beiðnina til annars tilviks forritsins sem er þegar í gangi eða verður opnað síðar. Að auki ætti kerfið að endurheimta glataða virkni forritsins þíns.
Sjálfgefið er að Kubernetes mun byrja að senda umferð í hólf þegar allir gámar innan hólfanna eru í gangi og endurræsa gáma þegar þeir hrynja. Þessi sjálfgefna kerfishegðun gæti verið nógu góð til að byrja með, en þú getur bætt áreiðanleika vöruuppsetningar þinnar með því að nota sérsniðna geðheilsupróf.
Sem betur fer gerir Kubernetes þetta frekar auðvelt að gera, svo það er engin afsökun fyrir að hunsa þessar athuganir. Kubernetes býður upp á tvenns konar heilsufarsskoðanir og það er mikilvægt að skilja muninn á því hvernig hver þeirra er notuð.
Viðbúnaðarprófið er hannað til að segja Kubernetes að forritið þitt sé tilbúið til að takast á við umferð. Áður en þjónustu er leyft að senda umferð í hólf verður Kubernetes að staðfesta að viðbúnaðarathugunin hafi tekist. Ef viðbúnaðarprófið mistekst mun Kubernetes hætta að senda umferð í hólfið þar til prófið stenst.
Liveness prófið segir Kubernetes hvort forritið þitt sé lifandi eða dautt. Í fyrra tilvikinu mun Kubernetes láta það í friði, í öðru tilvikinu mun það eyða dauða belgnum og skipta um það með nýjum.
Við skulum ímynda okkur atburðarás þar sem forritið þitt tekur 1 mínútu að hita upp og ræsa. Þjónustan þín mun ekki byrja að virka fyrr en forritið er að fullu hlaðið og keyrt, þó að verkflæðið sé þegar hafið. Þú munt líka lenda í vandræðum ef þú vilt stækka þessa dreifingu í mörg eintök, því þessi eintök ættu ekki að fá umferð fyrr en þau eru að fullu tilbúin. Hins vegar, sjálfgefið, mun Kubernetes byrja að senda umferð um leið og ferlar inni í gámnum hefjast.
Þegar viðbúnaðarprófið er notað mun Kubernetes bíða þar til forritið er að fullu keyrt áður en hún leyfir þjónustunni að senda umferð á nýja eintakið.
Við skulum ímynda okkur aðra atburðarás þar sem forritið hangir í langan tíma og hættir þjónustubeiðnum. Þegar ferlið heldur áfram að keyra, mun Kubernetes sjálfgefið gera ráð fyrir að allt sé í lagi og halda áfram að senda beiðnir til hólfsins sem ekki virkar. En þegar Liveness er notað mun Kubernetes uppgötva að forritið þjónar ekki lengur beiðnum og mun endurræsa dauða belgurinn sjálfgefið.
Við skulum skoða hvernig viðbúnaður og hagkvæmni er prófuð. Það eru þrjár prófunaraðferðir - HTTP, Command og TCP. Þú getur notað hvaða þeirra sem er til að athuga. Algengasta leiðin til að prófa notanda er HTTP rannsaka.
Jafnvel þó að forritið þitt sé ekki HTTP netþjónn geturðu samt búið til léttan HTTP netþjón inni í forritinu þínu til að hafa samskipti við Liveness prófið. Eftir þetta mun Kubernetes byrja að pinga fræbelginn og ef HTTP svarið er á bilinu 200 eða 300 ms mun það gefa til kynna að fræbelgurinn sé heilbrigður. Annars verður einingin merkt sem „óholl“.
Fyrir stjórnunarpróf keyrir Kubernetes skipunina inni í ílátinu þínu. Ef skipunin kemur til baka með núllútgöngukóða verður gámurinn merktur sem heilbrigður, annars verður gámurinn merktur sem „veikur“ þegar hann fær útgöngustöðunúmer frá 1 til 255. Þessi prófunaraðferð er gagnleg ef þú getur ekki eða vilt ekki keyra HTTP netþjón, en getur keyrt skipun sem mun athuga heilsu forritsins þíns.
Síðasti sannprófunarbúnaðurinn er TCP prófið. Kubernetes mun reyna að koma á TCP tengingu á tilgreindu tengi. Ef það er hægt að gera það er ílátið talið heilbrigt, ef ekki er það talið ólífvænlegt. Þessi aðferð getur verið gagnleg ef þú ert að nota atburðarás þar sem prófun með HTTP beiðni eða framkvæmd skipana virkar ekki mjög vel. Til dæmis væri aðalþjónustan fyrir staðfestingu með TCP gRPC eða FTP.
Hægt er að stilla próf á nokkra vegu með mismunandi breytum. Þú getur tilgreint hversu oft ætti að framkvæma þær, hver árangurs- og bilunarmörkin eru og hversu lengi á að bíða eftir svörum. Nánari upplýsingar er að finna í skjölunum fyrir viðbúnaðar- og líffærniprófin. Hins vegar er einn mjög mikilvægur punktur við að setja upp Liveness prófið - upphafsstillingin á prófunartöfinni initialDelaySeconds. Eins og ég nefndi mun bilun í þessu prófi leiða til þess að einingin verður endurræst. Svo þú þarft að ganga úr skugga um að prófun hefjist ekki fyrr en forritið er tilbúið til notkunar, annars byrjar það að hjóla í gegnum endurræsingar. Ég mæli með að nota P99 ræsingartímann eða meðal ræsingartíma forritsins frá biðminni. Mundu að stilla þetta gildi þar sem ræsingartími forritsins verður hraðari eða hægari.
Flestir sérfræðingar munu staðfesta að heilsufarsskoðanir séu skyldueftirlit fyrir öll dreifð kerfi og Kubernetes er engin undantekning. Notkun á heilsufarsskoðun þjónustu tryggir áreiðanlega, vandræðalausa notkun Kubernetes og er áreynslulaus fyrir notendur.
Framhald mjög fljótlega...
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com