Hajutatud süsteeme võib olla keeruline hallata, kuna neis on palju liikuvaid ja muutuvaid elemente, mis kõik peavad süsteemi toimimiseks korralikult töötama. Kui mõni elementidest ebaõnnestub, peab süsteem selle tuvastama, sellest mööda minema ja parandama ning kõik see peab toimuma automaatselt. Selles Kubernetese parimate tavade seerias õpime seadistama valmisoleku ja elujõulisuse teste, et testida Kubernetese klastri tervist.
Tervisekontroll on lihtne viis anda süsteemile teada, kas teie rakenduse eksemplar töötab või mitte. Kui teie rakenduse eksemplar ei tööta, ei tohiks teised teenused sellele juurde pääseda ega sellele päringuid saata. Selle asemel tuleb päring saata rakenduse mõnele teisele eksemplarile, mis juba töötab või käivitatakse hiljem. Lisaks peaks süsteem taastama teie rakenduse kaotatud funktsionaalsuse.
Vaikimisi hakkab Kubernetes liiklust kaustale saatma, kui kõik kaustades olevad konteinerid töötavad, ja taaskäivitab konteinerid, kui need kokku jooksevad. See süsteemi vaikekäitumine võib alustuseks olla piisavalt hea, kuid saate kohandatud mõistlikkuse kontrolli abil oma toote juurutamise usaldusväärsust parandada.
Õnneks teeb Kubernetes selle üsna lihtsaks, nii et nende kontrollide ignoreerimiseks pole vabandust. Kubernetes pakub kahte tüüpi tervisekontrolle ja on oluline mõista nende kasutamise erinevusi.
Valmisoleku test on loodud selleks, et öelda Kubernetesile, et teie rakendus on liikluseks valmis. Enne kui lubab teenusel liiklust podi saata, peab Kubernetes kontrollima, kas valmisoleku kontroll on edukas. Kui valmisoleku test ebaõnnestub, peatab Kubernetes liikluse saatmise podisse, kuni test läbib.
Elavsuse test ütleb Kubernetesile, kas teie rakendus on elus või surnud. Esimesel juhul jätab Kubernetes selle rahule, teisel juhul kustutab surnud kauna ja asendab selle uuega.
Kujutagem ette stsenaariumi, kus teie rakenduse soojendamiseks ja käivitamiseks kulub 1 minut. Teie teenus ei hakka tööle enne, kui rakendus on täielikult laaditud ja töötab, kuigi töövoog on juba alanud. Probleemid tekivad ka siis, kui soovite selle juurutuse laiendada mitmele eksemplarile, kuna need koopiad ei tohiks liiklust vastu võtta enne, kui need on täielikult valmis. Vaikimisi hakkab Kubernetes aga liiklust saatma kohe, kui konteineris olevad protsessid käivituvad.
Valmisoleku testi kasutamisel ootab Kubernetes, kuni rakendus hakkab täielikult tööle, enne kui lubab teenusel uude koopiasse liiklust saata.
Kujutagem ette teist stsenaariumi, kus rakendus hangub pikka aega, peatades teenindustaotluste teenindamise. Kui protsess jätkub, eeldab Kubernetes vaikimisi, et kõik on korras, ja jätkab päringute saatmist mittetöötavasse kausta. Kuid Livenessi kasutamisel tuvastab Kubernetes, et rakendus ei teeninda enam taotlusi, ja taaskäivitab vaikimisi surnud podi.
Vaatame, kuidas testitakse valmisolekut ja elujõulisust. Testimismeetodeid on kolm – HTTP, Command ja TCP. Kontrollimiseks võite kasutada mõnda neist. Kõige tavalisem viis kasutaja testimiseks on HTTP-sond.
Isegi kui teie rakendus ei ole HTTP-server, saate Livenessi testiga suhtlemiseks oma rakenduse sees siiski luua kerge HTTP-serveri. Pärast seda hakkab Kubernetes podi pingima ja kui HTTP-vastus on vahemikus 200 või 300 ms, näitab see, et pod on terve. Vastasel juhul märgitakse moodul kui "ebatervislik".
Käsutestide jaoks käivitab Kubernetes käsu teie konteineris. Kui käsk naaseb nulli väljumiskoodiga, märgitakse konteiner terveks, vastasel juhul märgitakse väljumisoleku numbri 1 kuni 255 saamisel konteiner kui “haige”. See testimismeetod on kasulik, kui te ei saa või ei taha HTTP-serverit käitada, kuid saate käivitada käsu, mis kontrollib teie rakenduse tervist.
Lõplik kontrollimehhanism on TCP-test. Kubernetes proovib luua TCP-ühenduse määratud pordiga. Kui seda saab teha, loetakse konteiner terveks, kui ei, siis elujõuetuks. See meetod võib olla kasulik, kui kasutate stsenaariumi, kus HTTP-päringu või käsu täitmisega testimine ei tööta kuigi hästi. Näiteks TCP-ga kinnitamise peamised teenused on gRPC või FTP.
Teste saab erinevate parameetritega mitmel viisil konfigureerida. Saate määrata, kui sageli neid tuleks täita, millised on õnnestumise ja ebaõnnestumise künnised ning kui kaua vastuseid oodata. Lisateabe saamiseks vaadake valmisoleku ja elavuse testide dokumentatsiooni. Siiski on Livenessi testi seadistamisel üks väga oluline punkt – testimise viivituse esialgne seadistus inicialDelaySeconds. Nagu mainisin, põhjustab selle testi ebaõnnestumine mooduli taaskäivitamise. Seega peate veenduma, et testimine ei algaks enne, kui rakendus on töövalmis, vastasel juhul hakkab see taaskäivitama. Soovitan kasutada P99 käivitusaega või keskmist rakenduse käivitusaega puhvrist. Ärge unustage seda väärtust kohandada, kuna teie rakenduse käivitusaeg muutub kiiremaks või aeglasemaks.
Enamik eksperte kinnitab, et tervisekontroll on iga hajutatud süsteemi jaoks kohustuslik kontroll ja Kubernetes pole erand. Teenuse tervisekontrolli kasutamine tagab Kubernetese usaldusväärse ja tõrgeteta töö ning on kasutajatele vaevatu.
Jätkub peagi...
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com