Az elosztott rendszereket nehéz lehet kezelni, mert sok mozgó, változó elemük van, amelyek mindegyikének megfelelően kell működnie a rendszer működéséhez. Ha valamelyik elem meghibásodik, a rendszernek észlelnie kell, ki kell kerülnie és ki kell javítania, mindezt pedig automatikusan meg kell tenni. Ebben a Kubernetes bevált gyakorlatok sorozatban megtanuljuk, hogyan állíthat be készenléti és élőségi teszteket a Kubernetes-fürt állapotának tesztelésére.
Az állapotfelmérés egyszerű módja annak, hogy tudatja a rendszerrel, hogy az alkalmazáspéldány fut-e vagy sem. Ha az alkalmazáspéldány nem működik, akkor más szolgáltatások nem férhetnek hozzá, és nem küldhetnek kéréseket rá. Ehelyett a kérést el kell küldeni az alkalmazás egy másik példányába, amely már fut vagy később indul el. Ezenkívül a rendszernek vissza kell állítania az alkalmazás elveszett funkcióit.
Alapértelmezés szerint a Kubernetes akkor kezdi el a forgalmat küldeni egy podba, amikor a podokon belüli összes tároló fut, és újraindítja a konténereket, ha összeomlanak. Kezdetnek ez az alapértelmezett rendszerviselkedés elég jó lehet, de egyéni épségellenőrzésekkel javíthatja terméke üzembe helyezésének megbízhatóságát.
Szerencsére a Kubernetes ezt meglehetősen egyszerűvé teszi, így nincs mentség az ellenőrzések figyelmen kívül hagyására. A Kubernetes kétféle állapotellenőrzést kínál, és fontos megérteni az egyes használatának különbségeit.
A készenléti teszt célja, hogy közölje a Kubernetes-szel, hogy az alkalmazás készen áll a forgalom kezelésére. Mielőtt engedélyezné egy szolgáltatás számára, hogy forgalmat küldjön egy podba, a Kubernetesnek ellenőriznie kell, hogy a készenléti ellenőrzés sikeres-e. Ha a készenléti teszt sikertelen, a Kubernetes leállítja a forgalom küldését a pod-ra, amíg a teszt sikeres lesz.
A Liveness teszt megmondja a Kubernetesnek, hogy az alkalmazás él-e vagy halott. Az első esetben a Kubernetes békén hagyja, a másodikban pedig törli a halott pod-ot, és kicseréli egy újra.
Képzeljünk el egy olyan forgatókönyvet, amelyben az alkalmazás bemelegítése és elindítása 1 percet vesz igénybe. A szolgáltatás nem indul el, amíg az alkalmazás teljesen be nem töltődik és fut, bár a munkafolyamat már elindult. Problémák adódhatnak akkor is, ha ezt az üzembe helyezést több példányra szeretné bővíteni, mert ezek a példányok nem kaphatnak forgalmat, amíg teljesen készen nem állnak. Alapértelmezés szerint azonban a Kubernetes azonnal megkezdi a forgalom küldését, amint a tárolón belüli folyamatok elindulnak.
A Készenléti teszt használatakor a Kubernetes megvárja, amíg az alkalmazás teljesen lefut, mielőtt engedélyezné a szolgáltatásnak, hogy forgalmat küldjön az új példányra.
Képzeljünk el egy másik forgatókönyvet, amelyben az alkalmazás hosszú ideig lefagy, és leállítja a kiszolgálási kéréseket. A folyamat futása közben a Kubernetes alapértelmezés szerint azt feltételezi, hogy minden rendben van, és továbbra is kéréseket küld a nem működő podba. De a Liveness használatakor a Kubernetes észleli, hogy az alkalmazás már nem szolgál ki kéréseket, és alapértelmezés szerint újraindítja a halott pod.
Nézzük meg, hogyan tesztelik a felkészültséget és az életképességet. Három tesztelési módszer létezik - HTTP, Command és TCP. Az ellenőrzéshez bármelyiket használhatja. A felhasználók tesztelésének legáltalánosabb módja a HTTP-próba.
Még ha az alkalmazás nem is HTTP-kiszolgáló, akkor is létrehozhat egy egyszerű HTTP-kiszolgálót az alkalmazáson belül, hogy együttműködjön a Liveness-teszttel. Ezt követően a Kubernetes elkezdi pingelni a pod-ot, és ha a HTTP-válasz 200 vagy 300 ms tartományba esik, akkor azt jelzi, hogy a pod egészséges. Ellenkező esetben a modul „egészségtelen”-ként lesz megjelölve.
A parancstesztekhez a Kubernetes a parancsot a tárolón belül futtatja. Ha a parancs nulla kilépési kóddal tér vissza, akkor a konténer egészségesnek lesz megjelölve, ellenkező esetben az 1-től 255-ig terjedő kilépési állapotszám érkezésekor a konténer „betegként” lesz megjelölve. Ez a tesztelési módszer akkor hasznos, ha nem tud vagy nem akar HTTP-kiszolgálót futtatni, de képes futtatni egy parancsot, amely ellenőrzi az alkalmazás állapotát.
A végső ellenőrzési mechanizmus a TCP-teszt. A Kubernetes megpróbál TCP-kapcsolatot létesíteni a megadott porton. Ha ez megtehető, a tartály egészségesnek, ha nem, életképtelennek minősül. Ez a módszer akkor lehet hasznos, ha olyan forgatókönyvet használ, ahol a HTTP-kéréssel vagy parancsvégrehajtással végzett tesztelés nem működik túl jól. Például a TCP használatával végzett ellenőrzés fő szolgáltatásai a gRPC vagy az FTP.
A tesztek többféleképpen konfigurálhatók különböző paraméterekkel. Megadhatja, hogy milyen gyakran legyenek végrehajtva, mi legyen a siker és kudarc küszöbértéke, és mennyi ideig kell várni a válaszokra. További információkért tekintse meg a Készenléti és Életképességi tesztek dokumentációját. Van azonban egy nagyon fontos pont az Élességteszt beállításánál – a kezdeti tesztkésleltetés kezdeti DelaySeconds beállítása. Mint említettem, a teszt sikertelensége a modul újraindítását eredményezi. Ezért gondoskodnia kell arról, hogy a tesztelés ne induljon el addig, amíg az alkalmazás készen áll az indulásra, ellenkező esetben újraindul az újraindítás. Azt javaslom, hogy használja a P99 indítási időt vagy az átlagos alkalmazásindítási időt a pufferből. Ne felejtse el módosítani ezt az értéket, mivel az alkalmazás indítási ideje gyorsabban vagy lassabb lesz.
A legtöbb szakértő megerősíti, hogy az állapotfelmérés kötelező minden elosztott rendszeren, és a Kubernetes sem kivétel. A szolgáltatás állapotellenőrzésének használata biztosítja a Kubernetes megbízható, problémamentes működését, és a felhasználók számára könnyű feladat.
Folytatás hamarosan...
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com