Paskirstytas sistemas gali būti sunku valdyti, nes jose yra daug judančių, besikeičiančių elementų, kurie visi turi tinkamai veikti, kad sistema veiktų. Sugedus vienam iš elementų, sistema turi jį aptikti, apeiti ir sutvarkyti, o visa tai turi būti daroma automatiškai. Šioje „Kubernetes“ geriausios praktikos serijoje sužinosime, kaip nustatyti pasirengimo ir gyvumo testus, kad būtų galima patikrinti „Kubernetes“ klasterio būklę.
Būklės patikrinimas yra paprastas būdas pranešti sistemai, ar jūsų programos egzempliorius veikia, ar ne. Jei jūsų programos egzempliorius neveikia, kitos paslaugos neturėtų jo pasiekti arba siųsti užklausų. Užklausa turi būti išsiųsta į kitą programos egzempliorių, kuris jau veikia arba bus paleistas vėliau. Be to, sistema turėtų atkurti prarastas programos funkcijas.
Pagal numatytuosius nustatymus „Kubernetes“ pradės siųsti srautą į grupę, kai veikia visi talpyklos konteineriai, ir iš naujo paleis konteinerius, kai jie sugenda. Šis numatytasis sistemos elgesys gali būti pakankamai geras pradžiai, tačiau galite pagerinti produkto diegimo patikimumą naudodami pasirinktinius sveikumo patikrinimus.
Laimei, „Kubernetes“ tai gana lengva padaryti, todėl nėra jokio pasiteisinimo ignoruoti šiuos patikrinimus. „Kubernetes“ teikia dviejų tipų sveikatos patikrinimus, todėl svarbu suprasti, kaip skiriasi jų naudojimas.
Pasirengimo testas skirtas pranešti Kubernetes, kad jūsų programa yra paruošta valdyti srautą. Prieš leisdama paslaugai siųsti srautą į podėlį, „Kubernetes“ turi patikrinti, ar pasirengimo patikra buvo sėkminga. Jei parengties testas nepavyks, Kubernetes nustos siųsti srautą į podėlį, kol testas bus sėkmingas.
Gyvumo testas parodo „Kubernetes“, ar jūsų programa gyva, ar mirusi. Pirmuoju atveju Kubernetes paliks jį ramybėje, antruoju ištrins negyvą podą ir pakeis nauju.
Įsivaizduokime scenarijų, kai programa sušils ir paleidžiama per 1 minutę. Jūsų paslauga nepradės veikti, kol programa nebus visiškai įkelta ir paleista, nors darbo eiga jau prasidėjo. Taip pat turėsite problemų, jei norite išplėsti šį diegimą iki kelių kopijų, nes šios kopijos neturėtų gauti srauto, kol nebus visiškai paruoštos. Tačiau pagal numatytuosius nustatymus „Kubernetes“ pradės siųsti srautą, kai tik prasidės procesai konteineryje.
Naudodama pasirengimo testą, „Kubernetes“ palauks, kol programa bus visiškai paleista, prieš leisdama paslaugai siųsti srautą į naują kopiją.
Įsivaizduokime kitą scenarijų, kai programa ilgą laiką kabo ir nustoja aptarnauti užklausas. Kai procesas tęsiasi, pagal numatytuosius nustatymus „Kubernetes“ manys, kad viskas gerai, ir toliau siųs užklausas į neveikiantį bloką. Tačiau naudojant „Liveness“, „Kubernetes“ aptiks, kad programa nebeaptarnauja užklausų, ir pagal numatytuosius nustatymus iš naujo paleis neveikiančią grupę.
Pažiūrėkime, kaip tikrinamas pasirengimas ir gyvybingumas. Yra trys testavimo metodai – HTTP, Command ir TCP. Norėdami patikrinti, galite naudoti bet kurį iš jų. Dažniausias būdas patikrinti vartotoją yra HTTP zondas.
Net jei jūsų programa nėra HTTP serveris, vis tiek galite sukurti lengvą HTTP serverį programoje, kad galėtumėte sąveikauti su gyvumo testu. Po to „Kubernetes“ pradės pinguoti podėlį, o jei HTTP atsakymas yra 200 arba 300 ms diapazone, tai parodys, kad podukas yra sveikas. Priešingu atveju modulis bus pažymėtas kaip „nesveikas“.
Atliekant komandų testus, „Kubernetes“ paleidžia komandą konteineryje. Jei komanda grįš su nuliniu išėjimo kodu, konteineris bus pažymėtas kaip sveikas, kitu atveju, gavus išėjimo būsenos numerį nuo 1 iki 255, konteineris bus pažymėtas kaip „serga“. Šis testavimo metodas yra naudingas, jei negalite arba nenorite paleisti HTTP serverio, bet galite paleisti komandą, kuri patikrins jūsų programos būklę.
Galutinis patikrinimo mechanizmas yra TCP testas. „Kubernetes“ bandys užmegzti TCP ryšį nurodytame prievade. Jei tai įmanoma, konteineris laikomas sveiku, o jei ne, jis laikomas neperspektyviu. Šis metodas gali būti naudingas, jei naudojate scenarijų, kai testavimas naudojant HTTP užklausą arba komandos vykdymas neveikia labai gerai. Pavyzdžiui, pagrindinės tikrinimo naudojant TCP paslaugos būtų gRPC arba FTP.
Testus galima konfigūruoti keliais būdais su skirtingais parametrais. Galite nurodyti, kaip dažnai jie turi būti vykdomi, kokie yra sėkmės ir nesėkmės slenksčiai ir kiek laiko laukti atsakymų. Daugiau informacijos rasite parengties ir gyvumo testų dokumentacijoje. Tačiau nustatant gyvumo testą yra vienas labai svarbus momentas – pradinis testavimo delsos inicialinisDelaySeconds nustatymas. Kaip jau minėjau, nepavykus šiam testui, modulis bus paleistas iš naujo. Taigi turite įsitikinti, kad bandymai neprasideda, kol programa nebus paruošta naudoti, kitaip ji pradės paleisti iš naujo. Rekomenduoju naudoti P99 paleidimo laiką arba vidutinį programos paleidimo laiką iš buferio. Nepamirškite pakoreguoti šios vertės, nes programos paleidimo laikas tampa greitesnis arba lėtesnis.
Dauguma ekspertų patvirtins, kad sveikatos patikrinimai yra privalomi bet kurios paskirstytos sistemos patikrinimas, o Kubernetes nėra išimtis. Paslaugų būklės patikrinimų naudojimas užtikrina patikimą, be problemų Kubernetes veikimą ir vartotojams nesukelia jokių pastangų.
Tęsinys bus labai greitai...
Kai kurie skelbimai 🙂
Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, , unikalus pradinio lygio serverių analogas, kurį mes sugalvojome jums: (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).
„Dell R730xd“ 2 kartus pigiau „Equinix Tier IV“ duomenų centre Amsterdame? Tik čia Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo 99 USD! Skaityti apie
Šaltinis: www.habr.com