Titik penting ing operasi sistem sing disebarake yaiku penanganan kegagalan. Kubernetes mbantu iki kanthi nggunakake pengontrol sing ngawasi kesehatan sistem sampeyan lan miwiti maneh layanan sing wis mandheg. Nanging, Kubernetes bisa kanthi paksa mungkasi aplikasi sampeyan kanggo njamin kesehatan sistem sakabehe. Ing seri iki, kita bakal ndeleng carane sampeyan bisa nulungi Kubernetes nindakake tugase kanthi luwih efisien lan nyuda wektu mandheg aplikasi.
Sadurunge kontaner, umume aplikasi mlaku ing mesin virtual utawa fisik. Yen aplikasi nabrak utawa beku, butuh wektu suwe kanggo mbatalake tugas sing lagi ditindakake lan muat ulang program kasebut. Ing skenario paling awon, wong kudu ngatasi masalah iki kanthi manual ing wayah wengi, ing jam paling ora cocog. Yen mung 1-2 mesin kerja sing nindakake tugas sing penting, gangguan kasebut ora bisa ditampa.
Mulane, tinimbang reboot manual, dheweke wiwit nggunakake pemantauan tingkat proses kanggo miwiti maneh aplikasi kanthi otomatis yen ana mandap ora normal. Yen program gagal, proses ngawasi njupuk kode metu lan reboots server. Kanthi tekane sistem kaya Kubernetes, jinis respon kanggo kegagalan sistem iki mung digabungake menyang infrastruktur.
Kubernetes nggunakake loop acara observe-difference-take-action kanggo mesthekake yen sumber daya tetep sehat nalika lelungan saka wadhah menyang simpul dhewe.
Iki tegese sampeyan ora perlu maneh ngawasi proses kanthi manual. Yen sumber gagal Priksa Kesehatan, Kubernetes mung bakal nyedhiyakake kanthi otomatis karo panggantos. Nanging, Kubernetes nindakake luwih saka mung ngawasi aplikasi sampeyan yen gagal. Bisa nggawe salinan aplikasi liyane kanggo mbukak ing macem-macem mesin, nganyari aplikasi, utawa mbukak macem-macem versi aplikasi sampeyan bebarengan.
Mulane, ana akeh alasan kenapa Kubernetes bisa mungkasi wadhah sing sehat. Contone, yen sampeyan nganyarke penyebaran sampeyan, Kubernetes bakal alon-alon mungkasi pod lawas nalika miwiti sing anyar. Yen sampeyan mateni simpul, Kubernetes bakal mandheg mbukak kabeh pod ing simpul kasebut. Pungkasan, yen simpul kehabisan sumber daya, Kubernetes bakal mateni kabeh pod kanggo mbebasake sumber daya kasebut.
Mula, penting yen aplikasi sampeyan mandheg kanthi pengaruh minimal kanggo pangguna pungkasan lan wektu pemulihan minimal. Iki tegese sadurunge mateni, kudu nyimpen kabeh data sing kudu disimpen, nutup kabeh sambungan jaringan, ngrampungake karya sing isih ana, lan ngatur tugas penting liyane.
Ing laku, iki tegese aplikasi sampeyan kudu bisa nangani pesen SIGTERM, sinyal mandap proses sing sinyal standar kanggo sarana matèni ing sistem operasi Unix. Sawise nampa pesen iki, aplikasi kudu mati.
Sawise Kubernetes mutusake kanggo mungkasi pod, sawetara acara kedadeyan. Ayo ndeleng saben langkah sing ditindakake Kubernetes nalika mateni wadhah utawa pod.
Ayo kita ngomong yen kita pengin mungkasi salah siji saka pods. Ing wektu iki, bakal mandheg nampa lalu lintas anyar - kontaner sing mlaku ing pod ora bakal kena pengaruh, nanging kabeh lalu lintas anyar bakal diblokir.
Ayo ndeleng pancing preStop, yaiku perintah khusus utawa panjaluk HTTP sing dikirim menyang wadhah ing pod. Yen aplikasi sampeyan ora mati kanthi bener nalika nampa SIGTERM, sampeyan bisa nggunakake preStop kanggo mateni kanthi bener.
Umume program bakal metu kanthi apik nalika nampa sinyal SIGTERM, nanging yen sampeyan nggunakake kode pihak katelu utawa sawetara sistem sing ora bisa dikontrol kanthi lengkap, pancing preStop minangka cara sing apik kanggo meksa mati tanpa ngganti aplikasi.
Sawise nglakokake pancing iki, Kubernetes bakal ngirim sinyal SIGTERM menyang wadhah ing polong, supaya dheweke ngerti manawa bakal diputus. Sawise nampa sinyal iki, kode sampeyan bakal nerusake proses mati. Proses iki bisa uga kalebu mungkasi sambungan sing wis suwe kayata sambungan database utawa stream WebSocket, nyimpen kahanan saiki, lan liya-liyane.
Malah yen sampeyan nggunakake pancing preStop, iku penting banget kanggo mriksa apa persis mengkono kanggo aplikasi nalika ngirim sinyal SIGTERM, lan carane tumindak, supaya acara utawa owah-owahan ing operasi sistem disebabake mati pod ora teka minangka. surprise kanggo sampeyan.
Ing wektu iki, Kubernetes bakal ngenteni wektu tartamtu, disebut terminationGracePeriodSecond, utawa wektu kanggo mateni kanthi apik nalika nampa sinyal SIGTERM, sadurunge njupuk tindakan luwih lanjut.
Secara default, wektu iki yaiku 30 detik. Wigati dimangerteni manawa mlaku kanthi sejajar karo pancing preStop lan sinyal SIGTERM. Kubernetes ora bakal ngenteni pancing preStop lan SIGTERM rampung-yen aplikasi sampeyan metu sadurunge TerminationGracePeriod rampung, Kubernetes bakal langsung nerusake menyang langkah sabanjure. Mulane, priksa manawa nilai periode iki ing detik ora kurang saka wektu sing dibutuhake kanggo nutup polong kanthi bener, lan yen ngluwihi 30s, tambah wektu menyang nilai sing dikarepake ing YAML. Ing conto diwenehi, iku 60s.
Lan pungkasane, langkah pungkasan yaiku yen kontaner isih mlaku sawise terminationGracePeriod, dheweke bakal ngirim sinyal SIGKILL lan bakal dibusak kanthi paksa. Ing wektu iki, Kubernetes uga bakal ngresiki kabeh obyek pod liyane.
Kubernetes mungkasi pods amarga akeh alasan, mula priksa manawa aplikasi sampeyan mungkasi kanthi apik ing kasus apa wae kanggo njamin layanan sing stabil.
Sawetara iklan π
Matur nuwun kanggo tetep karo kita. Apa sampeyan seneng karo artikel kita? Pengin ndeleng konten sing luwih menarik? Ndhukung kita kanthi nggawe pesenan utawa menehi rekomendasi menyang kanca, , analog unik saka server level entri, sing diciptakake kanggo sampeyan: (kasedhiya karo RAID1 lan RAID10, munggah 24 intine lan nganti 40GB DDR4).
Dell R730xd 2 kaping luwih murah ing pusat data Equinix Tier IV ing Amsterdam? Mung kene ing Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - saka $99! Maca babagan
Source: www.habr.com