Poin penting dalam pengoperasian sistem terdistribusi adalah penanganan kegagalan. Kubernetes membantu dalam hal ini dengan menggunakan pengontrol yang memantau kesehatan sistem Anda dan memulai ulang layanan yang berhenti bekerja. Namun, Kubernetes dapat menghentikan aplikasi Anda secara paksa untuk memastikan kesehatan sistem secara keseluruhan. Dalam seri ini, kita akan melihat bagaimana Anda dapat membantu Kubernetes melakukan tugasnya dengan lebih efisien dan mengurangi waktu henti aplikasi.
Sebelum adanya container, sebagian besar aplikasi berjalan di mesin virtual atau fisik. Jika aplikasi mogok atau terhenti, diperlukan waktu lama untuk membatalkan tugas yang sedang berlangsung dan memuat ulang program. Dalam skenario terburuk, seseorang harus menyelesaikan masalah ini secara manual di malam hari, pada jam-jam yang paling tidak tepat. Jika hanya 1-2 mesin yang berfungsi melakukan tugas penting, gangguan seperti itu sama sekali tidak dapat diterima.
Oleh karena itu, alih-alih melakukan boot ulang secara manual, mereka mulai menggunakan pemantauan tingkat proses untuk memulai ulang aplikasi secara otomatis jika terjadi penghentian yang tidak normal. Jika program gagal, proses pemantauan menangkap kode keluar dan me-reboot server. Dengan munculnya sistem seperti Kubernetes, jenis respons terhadap kegagalan sistem ini diintegrasikan ke dalam infrastruktur.
Kubernetes menggunakan event loop observasi-perbedaan-ambil-tindakan untuk memastikan bahwa sumber daya tetap sehat saat berpindah dari container ke node itu sendiri.
Ini berarti Anda tidak perlu lagi menjalankan pemantauan proses secara manual. Jika suatu sumber daya gagal dalam Pemeriksaan Kesehatan, Kubernetes akan secara otomatis menyediakan sumber daya penggantinya. Namun, Kubernetes melakukan lebih dari sekadar memantau kegagalan aplikasi Anda. Itu dapat membuat lebih banyak salinan aplikasi untuk dijalankan di beberapa mesin, memperbarui aplikasi, atau menjalankan beberapa versi aplikasi Anda secara bersamaan.
Oleh karena itu, ada banyak alasan mengapa Kubernetes dapat menghentikan container yang sangat sehat. Misalnya, jika Anda mengupgrade penerapan Anda, Kubernetes akan menghentikan pod lama secara perlahan sambil memulai yang baru. Jika Anda mematikan sebuah node, Kubernetes akan berhenti menjalankan semua pod di node tersebut. Terakhir, jika sebuah node kehabisan sumber daya, Kubernetes akan mematikan semua pod untuk mengosongkan sumber daya tersebut.
Oleh karena itu, aplikasi Anda harus dihentikan dengan dampak minimal terhadap pengguna akhir dan waktu pemulihan minimal. Artinya sebelum dimatikan, ia harus menyimpan semua data yang perlu disimpan, menutup semua koneksi jaringan, menyelesaikan sisa pekerjaan, dan mengelola tugas mendesak lainnya.
Dalam praktiknya, ini berarti aplikasi Anda harus mampu menangani pesan SIGTERM, sinyal penghentian proses yang merupakan sinyal default untuk utilitas kill pada sistem operasi Unix. Setelah menerima pesan ini, aplikasi harus dimatikan.
Setelah Kubernetes memutuskan untuk menghentikan sebuah pod, sejumlah peristiwa terjadi. Mari kita lihat setiap langkah yang diambil Kubernetes saat mematikan sebuah container atau pod.
Katakanlah kita ingin menghentikan salah satu pod. Pada titik ini, ia akan berhenti menerima lalu lintas baru - kontainer yang berjalan di dalam pod tidak akan terpengaruh, namun semua lalu lintas baru akan diblokir.
Mari kita lihat hook preStop, yang merupakan perintah khusus atau permintaan HTTP yang dikirim ke container di dalam pod. Jika aplikasi Anda tidak dimatikan dengan benar saat menerima SIGTERM, Anda dapat menggunakan preStop untuk mematikan dengan benar.
Sebagian besar program akan keluar dengan baik ketika menerima sinyal SIGTERM, tetapi jika Anda menggunakan kode pihak ketiga atau sistem yang tidak sepenuhnya Anda kendalikan, hook preStop adalah cara terbaik untuk mematikan paksa secara paksa tanpa mengubah aplikasi.
Setelah mengeksekusi hook ini, Kubernetes akan mengirimkan sinyal SIGTERM ke container di dalam pod, memberi tahu mereka bahwa koneksinya akan segera terputus. Setelah menerima sinyal ini, kode Anda akan melanjutkan ke proses mematikan. Proses ini mungkin termasuk menghentikan koneksi yang berumur panjang seperti koneksi database atau aliran WebSocket, menyimpan status saat ini, dan sejenisnya.
Bahkan jika Anda menggunakan hook preStop, sangat penting untuk memeriksa apa yang sebenarnya terjadi pada aplikasi Anda ketika Anda mengirimkan sinyal SIGTERM, dan bagaimana perilakunya, sehingga kejadian atau perubahan dalam operasi sistem yang disebabkan oleh penutupan pod tidak terjadi. kejutan bagimu.
Pada titik ini, Kubernetes akan menunggu selama jangka waktu tertentu, yang disebut penghentianGracePeriodSecond, atau periode untuk dimatikan dengan baik ketika menerima sinyal SIGTERM, sebelum mengambil tindakan lebih lanjut.
Secara default periode ini adalah 30 detik. Penting untuk dicatat bahwa ini berjalan secara paralel dengan hook preStop dan sinyal SIGTERM. Kubernetes tidak akan menunggu hingga hook preStop dan SIGTERM berakhirβjika aplikasi Anda keluar sebelum TerminationGracePeriod berakhir, Kubernetes akan segera melanjutkan ke langkah berikutnya. Oleh karena itu, periksa apakah nilai periode ini dalam hitungan detik tidak kurang dari waktu yang diperlukan untuk mematikan pod dengan benar, dan jika melebihi 30 detik, tambah periode tersebut ke nilai yang diinginkan di YAML. Dalam contoh yang diberikan, ini adalah tahun 60an.
Dan terakhir, langkah terakhir adalah jika container masih berjalan setelah penghentianGracePeriod, maka container akan mengirimkan sinyal SIGKILL dan akan dihapus secara paksa. Pada tahap ini, Kubernetes juga akan membersihkan semua objek pod lainnya.
Kubernetes menghentikan pod karena berbagai alasan, jadi pastikan aplikasi Anda berhenti dengan baik untuk memastikan layanan yang stabil.
Beberapa iklan π
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x 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 - mulai $99! Membaca tentang
Sumber: www.habr.com