Az elosztott rendszerek működésének fontos pontja a hibakezelés. A Kubernetes a rendszer állapotát figyelő vezérlők és a leállt szolgáltatások újraindításával segít ebben. A Kubernetes azonban erőszakkal leállíthatja az alkalmazásait a rendszer általános állapotának biztosítása érdekében. Ebben a sorozatban megvizsgáljuk, hogyan segíthet a Kubernetesnek hatékonyabban végezni munkáját, és hogyan csökkentheti az alkalmazások leállási idejét.
A konténerek előtt a legtöbb alkalmazás virtuális vagy fizikai gépeken futott. Ha az alkalmazás összeomlott vagy lefagyott, sokáig tartott a folyamatban lévő feladat törlése és a program újratöltése. A legrosszabb esetben valakinek kézzel kellett megoldania ezt a problémát éjszaka, a legalkalmatlanabb órákban. Ha csak 1-2 működő gép látott el fontos feladatot, akkor az ilyen zavarás teljességgel elfogadhatatlan volt.
Ezért a kézi újraindítások helyett folyamatszintű figyelést kezdtek használni, hogy rendellenes leállás esetén automatikusan újraindítsák az alkalmazást. Ha a program meghiúsul, a megfigyelési folyamat rögzíti a kilépési kódot, és újraindítja a kiszolgálót. A Kuberneteshez hasonló rendszerek megjelenésével a rendszerhibákra adott válasz egyszerűen beépült az infrastruktúrába.
A Kubernetes megfigyelés-különbség-cselekvés eseményhurkot használ annak biztosítására, hogy az erőforrások egészségesek maradjanak, miközben a tárolókból magukhoz a csomópontokhoz jutnak.
Ez azt jelenti, hogy többé nem kell manuálisan futtatnia a folyamatfigyelést. Ha egy erőforrás nem felel meg az állapotellenőrzésen, a Kubernetes egyszerűen automatikusan ellátja azt egy cserével. A Kubernetes azonban sokkal többet tesz, mint egyszerűen csak figyeli az alkalmazást a hibák miatt. Létrehozhat több példányt az alkalmazásból, hogy több gépen fusson, frissítheti az alkalmazást, vagy futtathatja az alkalmazás több verzióját egyidejűleg.
Ezért számos oka van annak, hogy a Kubernetes miért képes megszüntetni egy tökéletesen egészséges tárolót. Például, ha frissíti a központi telepítést, a Kubernetes lassan leállítja a régi podokat, miközben újakat indít el. Ha leállít egy csomópontot, a Kubernetes leállítja az összes pod futtatását azon a csomóponton. Végül, ha egy csomópont kifogy az erőforrásokból, a Kubernetes leállítja az összes pod-ot, hogy felszabadítsa ezeket az erőforrásokat.
Ezért nagyon fontos, hogy az alkalmazás a végfelhasználóra gyakorolt minimális hatással és minimális helyreállítási idővel fejeződjön be. Ez azt jelenti, hogy a leállítás előtt el kell mentenie az összes menteni kívánt adatot, be kell zárnia az összes hálózati kapcsolatot, be kell fejeznie a hátralévő munkát, és kezelnie kell az egyéb sürgős feladatokat.
A gyakorlatban ez azt jelenti, hogy az alkalmazásnak képesnek kell lennie a SIGTERM üzenet kezelésére, a folyamatlezáró jelre, amely a Unix operációs rendszereken a kill segédprogram alapértelmezett jele. Az üzenet megérkezésekor az alkalmazásnak le kell állnia.
Amint a Kubernetes úgy dönt, hogy megszünteti a pod-ot, számos esemény történik. Nézzük meg a Kubernetes minden egyes lépését, amikor leállít egy tárolót vagy pod.
Tegyük fel, hogy le akarjuk állítani az egyik pod-ot. Ezen a ponton leállítja az új forgalom fogadását – a podban futó konténereket ez nem érinti, de minden új forgalom blokkolva lesz.
Nézzük a preStop hook-ot, amely egy speciális parancs vagy HTTP-kérés, amelyet egy podban lévő konténerekhez küldenek. Ha az alkalmazás nem áll le megfelelően a SIGTERM fogadásakor, használhatja a preStopot a megfelelő leállításhoz.
A legtöbb program kecsesen kilép, ha SIGTERM jelet kap, de ha harmadik féltől származó kódot vagy olyan rendszert használ, amelyet nem teljesen irányít, a preStop hook nagyszerű módja annak, hogy kecses leállítást kényszerítsen ki az alkalmazás megváltoztatása nélkül.
A hook végrehajtása után a Kubernetes SIGTERM jelet küld a podban lévő konténereknek, tudatva velük, hogy hamarosan lekapcsolják őket. Miután megkapta ezt a jelet, a kód folytatja a leállítási folyamatot. Ez a folyamat magában foglalhatja a hosszú élettartamú kapcsolatok, például az adatbázis-kapcsolat vagy a WebSocket adatfolyam leállítását, az aktuális állapot mentését és hasonlókat.
Még ha preStop hook-ot használ is, nagyon fontos ellenőrizni, hogy pontosan mi történik az alkalmazással, amikor SIGTERM jelet küld neki, és hogyan viselkedik, hogy a pod leállás miatti események vagy a rendszer működésében bekövetkezett változások ne következzenek be. meglepetés számodra.
Ezen a ponton a Kubernetes egy meghatározott ideig vár, amelyet terminationGracePeriodSecond-nak neveznek, vagy arra az időszakra, amíg SIGTERM jelet kap, mielőtt további lépéseket tenne.
Alapértelmezés szerint ez az időtartam 30 másodperc. Fontos megjegyezni, hogy párhuzamosan működik a preStop horoggal és a SIGTERM jellel. A Kubernetes nem várja meg a preStop hook és a SIGTERM végét – ha az alkalmazás a TerminationGracePeriod lejárta előtt kilép, a Kubernetes azonnal a következő lépésre lép. Ezért ellenőrizze, hogy ennek az időtartamnak a másodpercben megadott értéke nem kevesebb-e, mint a pod helyes leállításához szükséges idő, és ha meghaladja a 30 másodpercet, növelje az időtartamot a kívánt értékre a YAML-ben. A megadott példában a 60-as évek.
És végül az utolsó lépés, ha a tárolók a terminationGracePeriod után is futnak, akkor SIGKILL jelet küldenek, és erőszakkal törlődnek. Ezen a ponton a Kubernetes az összes többi pod objektumot is megtisztítja.
A Kubernetes számos okból leállítja a podokat, ezért ügyeljen arra, hogy az alkalmazás minden esetben kecsesen leálljon a stabil szolgáltatás biztosítása érdekében.
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