Paylanmış sistemlərin işində mühüm məqam uğursuzluqların aradan qaldırılmasıdır. Kubernetes sisteminizin sağlamlığına nəzarət edən və işləməyi dayandıran xidmətləri yenidən işə salan nəzarətçilərdən istifadə etməklə buna kömək edir. Bununla belə, Kubernetes ümumi sistemin sağlamlığını təmin etmək üçün tətbiqlərinizi zorla dayandıra bilər. Bu seriyada biz Kubernetes-ə işini daha səmərəli yerinə yetirməyə və tətbiqin dayanma müddətini azaltmağa necə kömək edə biləcəyinizi nəzərdən keçirəcəyik.
Konteynerlərdən əvvəl əksər proqramlar virtual və ya fiziki maşınlarda işləyirdi. Tətbiq qəzaya uğrayıbsa və ya donubsa, icra olunan tapşırığı ləğv etmək və proqramı yenidən yükləmək uzun müddət çəkdi. Ən pis vəziyyətdə, kimsə bu problemi gecə, ən uyğun olmayan saatlarda əl ilə həll etməli idi. Cəmi 1-2 işləyən maşın vacib bir işi yerinə yetirirdisə, belə bir pozulma tamamilə yolverilməz idi.
Buna görə də, əl ilə yenidən yükləmələr əvəzinə, anormal xitam halında tətbiqi avtomatik olaraq yenidən başlatmaq üçün proses səviyyəsində monitorinqdən istifadə etməyə başladılar. Proqram uğursuz olarsa, monitorinq prosesi çıxış kodunu tutur və serveri yenidən işə salır. Kubernetes kimi sistemlərin yaranması ilə sistem nasazlıqlarına bu cür cavab sadəcə infrastruktura inteqrasiya olundu.
Kubernetes, ehtiyatların konteynerlərdən qovşaqların özlərinə keçdiyi zaman sağlam qalmasını təmin etmək üçün müşahidə-fərqi-fəaliyyət göstərmə hadisə dövrəsindən istifadə edir.
Bu o deməkdir ki, artıq prosesin monitorinqini əl ilə həyata keçirməyə ehtiyac yoxdur. Resurs Sağlamlıq Yoxlanışında uğursuz olarsa, Kubernetes onu sadəcə olaraq avtomatik olaraq əvəzedici ilə təmin edəcək. Bununla belə, Kubernetes tətbiqinizi uğursuzluqlar üçün izləməkdən daha çox şey edir. Birdən çox maşında işləmək, tətbiqi yeniləmək və ya tətbiqinizin birdən çox versiyasını eyni vaxtda işə salmaq üçün tətbiqin daha çox nüsxəsini yarada bilər.
Buna görə də, Kubernetesin mükəmməl sağlam konteyneri dayandıra bilməsinin bir çox səbəbi var. Məsələn, yerləşdirmənizi təkmilləşdirsəniz, Kubernetes yenilərini işə salarkən köhnə podları yavaş-yavaş dayandıracaq. Bir nodu bağlasanız, Kubernetes həmin qovşaqda bütün podların işləməsini dayandıracaq. Nəhayət, əgər node resursları tükənərsə, Kubernetes həmin resursları boşaltmaq üçün bütün podları bağlayacaq.
Buna görə də, tətbiqinizin son istifadəçiyə minimal təsir və minimum bərpa müddəti ilə başa çatması çox vacibdir. Bu o deməkdir ki, bağlanmadan əvvəl o, saxlanması lazım olan bütün məlumatları saxlamalı, bütün şəbəkə bağlantılarını bağlamalı, qalan işləri tamamlamalı və digər təcili tapşırıqları idarə etməlidir.
Praktikada bu o deməkdir ki, tətbiqiniz Unix əməliyyat sistemlərində kill utiliti üçün standart siqnal olan prosesin dayandırılması siqnalı olan SIGTERM mesajını idarə edə bilməlidir. Bu mesajı aldıqdan sonra proqram bağlanmalıdır.
Kubernetes podu dayandırmaq qərarına gəldikdən sonra bir sıra hadisələr baş verir. Gəlin bir konteyner və ya podu bağlayarkən Kubernetesin atdığı hər addıma nəzər salaq.
Tutaq ki, biz podlardan birini dayandırmaq istəyirik. Bu zaman o, yeni trafikin qəbulunu dayandıracaq - podda işləyən konteynerlər təsirlənməyəcək, lakin bütün yeni trafik bloklanacaq.
Poddakı konteynerlərə göndərilən xüsusi əmr və ya HTTP sorğusu olan preStop çəngəlinə baxaq. SIGTERM-i qəbul edərkən tətbiqiniz düzgün bağlanmırsa, düzgün şəkildə bağlamaq üçün preStop-dan istifadə edə bilərsiniz.
Əksər proqramlar SIGTERM siqnalı aldıqda zərif şəkildə çıxacaqlar, lakin əgər siz üçüncü tərəf kodundan və ya tam nəzarət etmədiyiniz bəzi sistemlərdən istifadə edirsinizsə, preStop çəngəl tətbiqi dəyişmədən zərif söndürməyə məcbur etmək üçün əla bir yoldur.
Bu qarmağı yerinə yetirdikdən sonra Kubernetes poddakı konteynerlərə SIGTERM siqnalı göndərərək, onların tezliklə əlaqəsinin kəsiləcəyini bildirəcək. Bu siqnalı aldıqdan sonra kodunuz bağlanma prosesinə keçəcək. Bu prosesə verilənlər bazası bağlantısı və ya WebSocket axını kimi hər hansı uzunömürlü əlaqələrin dayandırılması, cari vəziyyətin saxlanması və s. daxil ola bilər.
PreStop çəngəlindən istifadə etsəniz belə, SIGTERM siqnalı göndərdiyiniz zaman tətbiqinizə tam olaraq nə baş verdiyini və onun necə davrandığını yoxlamaq çox vacibdir ki, podun bağlanması nəticəsində baş verən hadisələr və ya sistemin işində dəyişikliklər baş verməsin. sənə sürpriz.
Bu nöqtədə, Kubernetes əlavə tədbirlər görməzdən əvvəl terminationGracePeriodSecond adlanan müəyyən bir vaxtı və ya SIGTERM siqnalını aldıqda zərif şəkildə bağlanma müddətini gözləyəcək.
Varsayılan olaraq bu müddət 30 saniyədir. Qeyd etmək lazımdır ki, o, preStop çəngəl və SIGTERM siqnalı ilə paralel işləyir. Kubernetes preStop çəngəlinin və SIGTERM-in bitməsini gözləməyəcək - əgər ərizəniz TerminationGracePeriod bitməmişdən əvvəl çıxsa, Kubernetes dərhal növbəti mərhələyə keçəcək. Buna görə də, bu müddətin saniyələrlə dəyərinin podun düzgün bağlanması üçün tələb olunan vaxtdan az olmadığını yoxlayın və 30 saniyədən çox olarsa, müddəti YAML-də istədiyiniz dəyərə qədər artırın. Verilən nümunədə 60-dır.
Və nəhayət, son addım odur ki, əgər konteynerlər terminationGracePerioddan sonra hələ də işləyirsə, onlar SIGKILL siqnalı göndərəcək və zorla silinəcək. Bu zaman Kubernetes bütün digər pod obyektlərini də təmizləyəcək.
Kubernetes bir çox səbəbə görə podları dayandırır, buna görə də sabit xidmət təmin etmək üçün tətbiqinizin istənilən halda zərif şəkildə dayandırıldığından əmin olun.
Bəzi reklamlar 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, , Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).
Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun
Mənbə: www.habr.com