Z razpršenimi sistemi je težko upravljati, ker vsebujejo številne premične spremenljive elemente, ki morajo delovati brezhibno za zagotovitev funkcionalnosti sistema. Če eden od elementov odpove, ga mora sistem odkriti, obiti in popraviti, in to vse avtomatsko. V tej seriji „Best Practices Kubernetes“ bomo spoznali, kako nastaviti teste pripravljenosti (Readiness) in življenjske sposobnosti (Liveness) za preverjanje vitalnosti Kubernetes klasterja.
Preverjanje zdravja (Health Check) je preprost način, da sistemu sporočite, ali vaš aplikacijski primer deluje ali ne. Če vaš aplikacijski primer ne deluje, se druge storitve ne smejo obračati nanj ali mu pošiljati zahteve. Namesto tega mora biti zahteva poslana drugemu primerku aplikacije, ki že deluje ali se bo zagnal kasneje. Poleg tega mora sistem vrniti vaši aplikaciji izpadlo delovanje.
Privzeto Kubernetes začne pošiljati promet v pod, ko so vsi kontejnerji znotraj podov zagnani in ponovno zažene kontejnerje, ko ti nenadoma prenehajo delovati. Na začetku je lahko to obnašanje sistema dovolj dobro, vendar lahko povečate zanesljivost uvedbe svojega izdelka z uporabo prilagojenih testov zdravstvenega stanja.
Na srečo Kubernetes to omogoča precej enostavno, zato ni nobenega opravičila za ignoriranje takšnih testov. Kubernetes ponuja dva tipa Health Check testov, pomembno pa je razumeti razlike v uporabi vsakega od njih.
Test priprave (Readiness) služi za obveščanje Kubernetes o pripravljenosti vaše aplikacije, da obravnava promet. Preden dovoli storitvi pošiljati promet v pod, se mora Kubernetes prepričati o uspešnosti testa pripravljenosti. Če test Readiness ne uspe, Kubernetes preneha pošiljati promet v pod, dokler testiranje ne uspe.
Test življenjske sposobnosti (Liveness) obvešča Kubernetes o tem, ali vaša aplikacija živi ali ne. V prvem primeru Kubernetes pusti vašo aplikacijo pri miru, v drugem pa odstrani mrtvi pod in ga nadomesti z novim.
Predstavljajmo si scenarij, kjer vašemu aplikaciji za "ogrevanje" in zagon potrebuje 1 minuto. Vaša storitev ne začne delovati, dokler se aplikacija popolnoma ne naloži in ne zažene, čeprav je delovni proces že začel. Poleg tega se lahko pojavijo težave, če želite razširiti to uvedbo na več kopij, saj te kopije ne smejo prejemati prometa, dokler ne bodo popolnoma pripravljene. Vendar pa bo Kubernetes privzeto začel pošiljati promet takoj po začetku procesov znotraj kontejnerja.
Pri uporabi testa pripravljenosti Readiness bo Kubernetes čakal, dokler aplikacija ne bo popolnoma zagnana, in šele potem bo dovolil storitvi, da pošilja promet na novo kopijo.
Predstavljajmo si še en scenarij, v katerem se aplikacija ustavi za daljše časovno obdobje in preneha obravnavati poizvedbe. Ker proces še naprej teče, bo Kubernetes privzeto menil, da je vse v redu, in bo nadaljeval z pošiljanjem poizvedb na nedelujoči pod. Toda ob uporabi Liveness bo Kubernetes odkril, da aplikacija ne obravnava poizvedb, in privzeto ponovno zažene nedelujoči pod.
Poglejmo, kako testiramo pripravljenost in vitalnost. Obstajajo tri metode testiranja — HTTP, Command in TCP. Za preverjanje lahko uporabite katero koli od njih. Najbolj razširjena metoda uporabniškega testiranja je HTTP probe.
Tudi če vaša aplikacija ni HTTP strežnik, lahko še vedno ustvarite lahki HTTP strežnik znotraj vaše aplikacije za interakcijo s testom Liveness. Po tem bo Kubernetes začel pingati pod, in če bo HTTP odgovor v razponu 200 ali 300 ms, to pomeni, da je pod "zdrav". V nasprotnem primeru bo modul označen kot "nezdrav".
Za teste z uporabo Command Kubernetes izvede ukaz znotraj vašega kontejnerja. Če se ukaz vrne z ničelno izhodno kodo, bo kontejner označen kot zdrav, v nasprotnem primeru, ob prejemu izhodnega stanja od 1 do 255, bo kontejner označen kot "bolan". Ta način testiranja je koristen, če ne morete ali nočete zagnati HTTP strežnika, vendar lahko zaženete ukaz, ki preveri "zdravje" vaše aplikacije.
Zadnji mehanizem preverjanja je TCP test. Kubernetes bo poskušal vzpostaviti TCP povezavo na določenem vratih. Če uspe, je kontejner ocenjen kot zdrav, sicer kot nezmožen. Ta metoda je lahko uporabna, če uporabljate scenarij, kjer testiranje s HTTP zahtevkom ali izvrševanjem ukaza ne deluje najbolje. Na primer, glavne storitve za preverjanje prek TCP bodo gRPC ali FTP.
Teste je mogoče nastaviti na več načinov z različnimi parametri. Lahko opredelite, kako pogosto se morajo izvajati, kakšne so mejne vrednosti uspeha in neuspeha ter koliko časa čakati na odgovore. Podrobnejše informacije so navedene v dokumentaciji za teste Readiness in Liveness. Vendar pa je ena zelo pomembna točka pri nastavitvi Liveness testa - začetna zakasnitev testiranja initialDelaySeconds. Kot sem omenil, neuspešna izvedba tega testa vodi do ponovnega zagon modula. Zato se morate prepričati, da se testiranje ne začne, dokler aplikacija ni pripravljena na delovanje, sicer se bo začela ciklično ponovno zagnati. Priporočam uporabo P99 časa za zagon ali povprečnega časa zagona aplikacije iz predpomnilnika. Ne pozabite prilagoditi te vrednosti, saj se čas zagona vaše aplikacije skrajšuje ali podaljšuje.
Večina strokovnjakov bo potrdila, da so Health Check obvezni za katero koli porazdeljeno sistem, Kubernetes pa ni izjema. Uporaba 'zdravstvenega' preverjanja storitev zagotavlja zanesljivo in breznapak delovanje Kubernetesa in ne predstavlja nobenega dela za uporabnike.
Nadaljevanje kmalu...
Malo reklame 🙂
Hvala što ostajete s nama. Da li vam se sviđaju naši članci? Želite li videti više zanimljivih materijala? Podržite nas tako što ćete naručiti ili preporučiti prijateljima, , jedinstveni ekvivalent entry-level servera koji smo stvorili za vas: (options available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd je dvostruko jeftiniji u Equinix Tier IV data centru u Amsterdamu? Only with us in the Netherlands! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — from $99! Read about how
Izvor: habr.com
