Jaotatud süsteemide haldamine võib olla keeruline, kuna neis on palju liikmeid, mis pidevalt muutuvad, ja kõik need peavad õigesti tööle minema, et tagada süsteemi funktsionaalsus. Kui üks elementidest rikki läheb, peab süsteem selle avastama, mööda minema ja parandama, kõik automaatselt. Käesolevas "Kubernetes Best Practices" sarjas uurime, kuidas seadistada Readiness ja Liveness teste Kubernetes klastrite elujõudluse kontrollimiseks.
Tervise kontroll (Health Check) on lihtne viis teavitada süsteemi, kas teie rakenduse eksemplar töötab või mitte. Kui teie rakenduse eksemplar ei tööta, ei peaks teised teenused sellele pöörduma ega päringuid saatma. Selle asemel peaks päring suunatama teisele rakenduse eksemplarile, mis on juba käivitunud või käivitatakse hiljem. Lisaks peab süsteem teie rakendusele tagastama kaotatud töövõime.
Kubernetes alustab vaikimisi liikluse suunamist pod'i, kui kõik pod'i sees olevad konteinerid on käivitatud, ja taaskäivitab konteinerid, kui need külmutavad. Esialgu võib see vaikimisi süsteemikäitumine olla piisav, kuid võite oma toote juurutamise usaldusväärsust suurendada, kasutades kohandatud töövõime kontrollimisi.
Õnneks võimaldab Kubernetes seda üsna lihtsalt teha, seega ei ole selliste kontrollide eiramisele mingeid õigustusi. Kubernetes pakub kahte tüüpi tervisekontrolle, kusjuures on oluline mõista igaühe rakendamise erinevusi.
Valmiduse test (Readiness) on mõeldud selleks, et teavitada Kubernetes't teie rakenduse valmisolekust liikluse teenindamiseks. Enne kui Kubernetese teenus lubab liikluse suunata pod'i, peab ta veenduma, et valmiduse kontroll on edukas. Kui valmiduse test ebaõnnestub, lõpetab Kubernetes liikluse suunamise pod'i, kuni testimine läbib edukalt.
Liveness test teatab Kubernetes'ile, kas teie rakendus on elus või surnud. Esimesel juhul jätab Kubernetes selle rahule, teisel juhul eemaldab see surnud pod'i ja asendab selle uuega.
Kujutame ette olukorda, kus teie rakendusel on "soojendamiseks" ja käivitamiseks vajalik 1 minut. Teie teenus ei alusta tööd, kuni rakendus on täielikult laaditud ja käivitatud, kuigi tööprotsess on juba alanud. Samuti tekivad teil probleeme, kui soovite seda juurutamist skaleerida mitme koopiana, kuna need koopiad ei tohi liiklust saada, kuni nad ei ole täielikult valmis. Siiski käivitab Kubernetes vaikimisi liikluse edastamise kohe pärast konteineris protsesside alustamist.
Valmiduse testi Readiness kasutamisel ootab Kubernetes, kuni rakendus on täielikult käivitatud ja alles siis lubab teenusel edastada liiklust uuele koopiale.
Kujutage ette teistsugust stsenaariumi, kus rakendus hangub pikaks ajaks, lõpetades päringute teenindamise. Kuna protsess jätkab töötamist, eeldab Kubernetes vaikimisi, et kõik on korras, ja jätkab päringute suunamist mitteaktiivsele podile. Kuid Liveness'i kasutamise korral tuvastab Kubernetes, et rakendus ei teeninda enam päringuid, ja vaikimisi mürgib mitteaktiivse pod'i uuesti käivitamiseks.
Vaatame, kuidas valmisolekut ja elujõudlust testitakse. On kolm testimise meetodit — HTTP, Command ja TCP. Kontrollimiseks võite kasutada ühte neist. Kõige levinum viis kasutajate testimiseks on HTTP probe.
Isegi kui teie rakendus ei ole HTTP-server, saate ikkagi luua kergekaalulise HTTP-serveri oma rakenduse sees, et suhelda Liveness testiga. Pärast seda hakkab Kubernetes pod'i pingima ja kui HTTP vastus jääb vahemikku 200 või 300 ms, tähendab see, et pod on „terve”. Vastasel juhul märgitakse moodul „haigeks”.
Kubernetesi testimise käigus täidab Command teie konteineris käskluse. Kui käsk tagastab nulli väljundkoodi, loetakse konteiner terveks; vastasel juhul, kui väljundkood on vahemikus 1 kuni 255, loetakse konteiner „haigeks“. See testimismeetod on kasulik, kui te ei saa või ei soovi käivitada HTTP-serverit, kuid suudate käivitada käsu, mis kontrollib teie rakenduse „tervishoiu“.
Viimane kontrollimehhanism on TCP test. Kubernetes püüab luua TCP-ühenduse määratud pordile. Kui see õnnestub, loetakse konteiner terveks; vastasel juhul loetakse see elujõuetuks. See meetod võib olla kasulik, kui teie kasutatav skript toetab TCP, kuid HTTP-päringute või käskude täitmise testimine ei toimi hästi. Näiteks gRPC või FTP on peamised teenused, mida saab kontrollida TCP kaudu.
Testid saab seadistada mitmel viisil erinevate parameetritega. Saate määrata, kui tihti need peaksid toimuma, millised on edukuse ja ebaõnnestumise läveväärtused ning kui kaua oodata vastuseid. Üksikasjalikum teave on esitatud Readiness ja Liveness testide dokumentatsioonis. Siiski on üks väga tähtis aspekt Liveness testi seadistamisel – testimise algse viivituse initialDelaySeconds seadistamine. Nagu ma mainisin, ebaõnnestunud test viib mooduli taaskäivitamiseni. Seetõttu peate veenduma, et testimine ei alga enne, kui rakendus on tööks valmis; vastasel juhul hakkab see tsükliliselt taaskäivituma. Soovitan kasutada P99 käivitusaega või keskmist rakenduse käivitusaega vahemikust. Ärge unustage seda väärtust kohandada, kui teie rakenduse käivitusaeg muutub kiiremini või aeglasemaks.
Enamik spetsialiste kinnitab, et Health Check on kohustuslik kontroll igasuguste hajutatud süsteemide jaoks ja Kubernetes ei ole erand. Teenuste 'tervishoiu' kontrollimise kasutamine tagab Kubernetes'i usaldusväärse ja tõrgeteta toimimise ning see ei ole kasutajatele mingit vaeva.
Peagi on see tulemas…
Veidi reklaami 🙂
Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. , ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).
Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas
Allikas: habr.com
