Perkara penting dalam operasi sistem teragih ialah pengendalian kegagalan. Kubernetes membantu dengan ini dengan menggunakan pengawal yang memantau kesihatan sistem anda dan memulakan semula perkhidmatan yang telah berhenti berfungsi. Walau bagaimanapun, Kubernetes boleh menghentikan aplikasi anda secara paksa untuk memastikan kesihatan sistem secara keseluruhan. Dalam siri ini, kami akan melihat cara anda boleh membantu Kubernetes melakukan tugasnya dengan lebih cekap dan mengurangkan masa henti aplikasi.
Sebelum bekas, kebanyakan aplikasi dijalankan pada mesin maya atau fizikal. Jika aplikasi ranap atau membeku, ia mengambil masa yang lama untuk membatalkan tugas yang sedang dijalankan dan memuatkan semula program. Dalam senario kes terburuk, seseorang terpaksa menyelesaikan masalah ini secara manual pada waktu malam, pada waktu yang paling tidak sesuai. Jika hanya 1-2 mesin yang berfungsi menjalankan tugas penting, gangguan seperti itu tidak boleh diterima sama sekali.
Oleh itu, bukannya but semula manual, mereka mula menggunakan pemantauan peringkat proses untuk memulakan semula aplikasi secara automatik sekiranya berlaku penamatan yang tidak normal. Jika program gagal, proses pemantauan menangkap kod keluar dan but semula pelayan. Dengan kemunculan sistem seperti Kubernetes, jenis tindak balas terhadap kegagalan sistem ini hanya disepadukan ke dalam infrastruktur.
Kubernetes menggunakan gelung peristiwa pemerhatian-perbezaan-tindakan untuk memastikan sumber kekal sihat semasa ia bergerak dari bekas ke nod itu sendiri.
Ini bermakna anda tidak perlu lagi menjalankan pemantauan proses secara manual. Jika sumber gagal Pemeriksaan Kesihatan, Kubernetes hanya akan menyediakannya secara automatik dengan pengganti. Walau bagaimanapun, Kubernetes melakukan lebih daripada sekadar memantau aplikasi anda untuk kegagalan. Ia boleh mencipta lebih banyak salinan aplikasi untuk dijalankan pada berbilang mesin, mengemas kini aplikasi atau menjalankan berbilang versi aplikasi anda secara serentak.
Oleh itu, terdapat banyak sebab mengapa Kubernetes boleh menamatkan bekas yang sihat sempurna. Contohnya, jika anda meningkatkan penggunaan anda, Kubernetes akan menghentikan pod lama secara perlahan sambil memulakan pod baharu. Jika anda menutup nod, Kubernetes akan berhenti menjalankan semua pod pada nod itu. Akhir sekali, jika nod kehabisan sumber, Kubernetes akan menutup semua pod untuk membebaskan sumber tersebut.
Oleh itu, adalah penting bahawa aplikasi anda ditamatkan dengan kesan minimum kepada pengguna akhir dan masa pemulihan yang minimum. Ini bermakna sebelum menutup, ia mesti menyimpan semua data yang perlu disimpan, menutup semua sambungan rangkaian, menyelesaikan kerja yang tinggal dan mengurus tugasan mendesak yang lain.
Dalam amalan, ini bermakna bahawa aplikasi anda mesti boleh mengendalikan mesej SIGTERM, isyarat penamatan proses yang merupakan isyarat lalai untuk utiliti bunuh pada sistem pengendalian Unix. Setelah menerima mesej ini, aplikasi harus ditutup.
Sebaik sahaja Kubernetes memutuskan untuk menamatkan pod, beberapa peristiwa berlaku. Mari lihat setiap langkah yang Kubernetes ambil semasa menutup bekas atau pod.
Katakan kita mahu menamatkan salah satu pod. Pada ketika ini, ia akan berhenti menerima trafik baharu - bekas yang berjalan dalam pod tidak akan terjejas, tetapi semua trafik baharu akan disekat.
Mari lihat cangkuk preStop, iaitu arahan khas atau permintaan HTTP yang dihantar ke bekas dalam pod. Jika aplikasi anda tidak ditutup dengan betul apabila menerima SIGTERM, anda boleh menggunakan preStop untuk menutup dengan betul.
Kebanyakan program akan keluar dengan anggun apabila mereka menerima isyarat SIGTERM, tetapi jika anda menggunakan kod pihak ketiga atau beberapa sistem yang anda tidak kawal sepenuhnya, cangkuk preStop ialah cara terbaik untuk memaksa penutupan yang anggun tanpa mengubah aplikasi.
Selepas melaksanakan cangkuk ini, Kubernetes akan menghantar isyarat SIGTERM kepada bekas dalam pod, memberitahu mereka bahawa ia akan diputuskan sambungannya tidak lama lagi. Setelah menerima isyarat ini, kod anda akan meneruskan ke proses penutupan. Proses ini mungkin termasuk menghentikan sebarang sambungan jangka panjang seperti sambungan pangkalan data atau aliran WebSocket, menyimpan keadaan semasa dan seumpamanya.
Walaupun anda menggunakan cangkuk praStop, adalah sangat penting untuk menyemak apa sebenarnya yang berlaku pada aplikasi anda apabila anda menghantarnya isyarat SIGTERM, dan cara ia berkelakuan, supaya peristiwa atau perubahan dalam operasi sistem yang disebabkan oleh penutupan pod tidak berlaku sebagai satu kejutan kepada anda.
Pada ketika ini, Kubernetes akan menunggu untuk tempoh masa tertentu, dipanggil penamatanGracePeriodSecond, atau tempoh untuk menutup secara anggun apabila ia menerima isyarat SIGTERM, sebelum mengambil tindakan selanjutnya.
Secara lalai tempoh ini ialah 30 saat. Adalah penting untuk ambil perhatian bahawa ia berjalan selari dengan cangkuk praStop dan isyarat SIGTERM. Kubernetes tidak akan menunggu cangkuk praStop dan SIGTERM tamatβjika permohonan anda keluar sebelum PenamatanGracePeriod tamat, Kubernetes akan terus ke langkah seterusnya. Oleh itu, pastikan nilai tempoh ini dalam saat tidak kurang daripada masa yang diperlukan untuk menutup pod dengan betul, dan jika melebihi 30s, tingkatkan tempoh kepada nilai yang dikehendaki dalam YAML. Dalam contoh yang diberikan, ia adalah 60s.
Dan akhirnya, langkah terakhir ialah jika kontena masih berjalan selepas penamatanGracePeriod, mereka akan menghantar isyarat SIGKILL dan akan dipadamkan secara paksa. Pada ketika ini, Kubernetes juga akan membersihkan semua objek pod lain.
Kubernetes menamatkan pod atas banyak sebab, jadi pastikan permohonan anda ditamatkan dengan baik dalam apa jua keadaan untuk memastikan perkhidmatan yang stabil.
Beberapa iklan π
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - daripada $99! Baca tentang
Sumber: www.habr.com