Praktik terbaik Kubernetes. Nonaktifkan Akhiri Nonaktif

Praktik terbaik Kubernetes. Membuat Kontainer Kecil
Kubernetes Praktik Terbaik. Organisasi Kubernetes dengan Kubernetes
Best Practices Namespace. Uji Kelayakan Kubernetes dengan Tes Kesiapan dan Uji Kekuatan
Praktik Terbaik Kubernetes . Mengkonfigurasi permintaan dan batasan sumber daya



Poin penting dalam pengoperasian sistem terdistribusi adalah menangani kegagalan. Kubernet membantu dengan ini dengan menggunakan pengontrol yang memantau keadaan sistem Anda dan memulai kembali layanan yang telah berhenti berfungsi. Namun, Kubernetes secara paksa dapat mematikan aplikasi Anda untuk memastikan kelangsungan sistem secara keseluruhan. Dalam seri ini, kami akan melihat bagaimana Anda dapat membantu Kubernetes melakukan tugasnya dengan lebih efisien dan mengurangi waktu henti aplikasi.

Sebelum menggunakan wadah, sebagian besar aplikasi berjalan pada mesin virtual atau fisik. Jika aplikasi macet atau macet, butuh waktu lama untuk menghapus tugas yang sedang berlangsung dan mengunduh ulang program. Dalam kasus terburuk, seseorang harus menyelesaikan masalah ini secara manual di malam hari, pada waktu yang paling tidak tepat. Jika hanya 1-2 mesin yang bekerja melakukan tugas penting, kerusakan seperti itu benar-benar tidak dapat diterima.
Oleh karena itu, alih-alih memulai ulang secara manual, mereka mulai menggunakan pemantauan pada tingkat proses untuk secara otomatis memulai ulang aplikasi jika terjadi pemutusan yang tidak normal. Jika program macet, proses pemantauan menangkap kode keluar dan mem-boot ulang server. Dengan munculnya sistem seperti Kubernetes, jenis respons kegagalan sistem ini telah diintegrasikan ke dalam infrastruktur.

Kubernetes menggunakan loop acara "mengamati - melakukan perbedaan - melakukan tindakan" untuk memastikan bahwa sumber daya tetap beroperasi sepanjang jalan dari wadah ke node itu sendiri.



Ini berarti Anda tidak perlu lagi memulai pemantauan proses secara manual. Jika sumber daya gagal dalam Pemeriksaan Kesehatan, Kubernetes akan secara otomatis memberikan pengganti. Kubernetes tidak hanya memonitor crash aplikasi Anda. Ini dapat membuat lebih banyak salinan aplikasi untuk bekerja pada beberapa mesin, memperbarui aplikasi, atau secara bersamaan menjalankan beberapa versi aplikasi Anda.
Oleh karena itu, ada banyak alasan mengapa Kubernetes dapat mengganggu wadah yang sangat sehat. Misalnya, jika Anda meningkatkan penyebaran Anda, Kubernetes perlahan akan menghentikan pod lama saat meluncurkan yang baru. Jika Anda memutuskan suatu simpul, Kubernetes akan menghentikan semua perapian di simpul itu. Akhirnya, jika node kehabisan sumber daya, Kubernetes akan menonaktifkan semua pod untuk membebaskan sumber daya ini.

Karena itu, sangat penting bahwa aplikasi Anda berhenti bekerja dengan dampak minimal pada pengguna akhir dan waktu pemulihan minimum. Ini berarti bahwa sebelum memutuskan sambungan harus menyimpan semua data yang perlu disimpan, tutup semua koneksi jaringan, selesaikan pekerjaan yang tersisa dan punya waktu untuk menyelesaikan tugas mendesak lainnya.

Dalam praktiknya, ini berarti bahwa aplikasi Anda harus dapat memproses pesan SIGTERM - sinyal penghentian proses, yang merupakan sinyal default untuk utilitas mematikan di OS Unix family. Setelah menerima pesan ini, aplikasi harus terputus.

Setelah Kubernetes memutuskan untuk menyelesaikan pod, serangkaian acara berlangsung. Mari kita lihat setiap langkah yang diambil Kubernetes saat sebuah wadah atau perapian selesai.

Misalkan kita ingin menyelesaikan salah satu perapian. Pada titik ini, itu akan berhenti menerima lalu lintas baru - kontainer yang bekerja di perapian tidak akan terpengaruh, tetapi semua lalu lintas baru akan diblokir.



Mari kita lihat kait preStop - ini adalah perintah khusus atau permintaan HTTP yang dikirim ke kontainer di perapian. Jika aplikasi Anda tidak mati dengan benar ketika SIGTERM diterima, Anda dapat menggunakan preStop untuk keluar dengan benar.



Sebagian besar program ketika mereka menerima sinyal SIGTERM selesai dengan benar, tetapi jika Anda menggunakan kode pihak ketiga atau beberapa sistem yang tidak dapat Anda kontrol sepenuhnya, kait preStop adalah cara yang bagus untuk menyebabkan shutdown yang anggun tanpa mengubah aplikasi.

Setelah mengeksekusi kait ini, Kubernetes akan mengirimkan sinyal SIGTERM ke kontainer di perapian, yang akan membuat mereka tahu bahwa mereka akan segera terputus. Setelah menerima sinyal ini, kode Anda akan melanjutkan ke proses mematikan. Proses ini dapat termasuk menghentikan koneksi yang berumur panjang, seperti menghubungkan ke database atau aliran WebSocket, menyimpan keadaan saat ini, dan sejenisnya.

Bahkan jika Anda menggunakan kait preStop, sangat penting untuk memeriksa apa yang sebenarnya terjadi dengan aplikasi Anda ketika Anda mengirimnya sinyal SIGTERM, bagaimana ia berperilaku sedemikian rupa sehingga peristiwa atau perubahan dalam operasi sistem yang disebabkan oleh penutupan perapian bukan kejutan bagi Anda.

Pada titik ini, sebelum mengambil tindakan lebih lanjut, Kubernetes akan menunggu waktu yang ditentukan, yang disebut terminationGracePeriodSecond, atau periode untuk dimatikan dengan benar ketika menerima sinyal SIGTERM.



Secara default, periode ini adalah 30 detik. Penting untuk dicatat bahwa itu berlangsung paralel dengan kait preStop dan sinyal SIGTERM. Kubernetes tidak akan menunggu kait preStop dan SIGTERM berakhir - jika aplikasi Anda keluar sebelum TerminationGracePeriod berakhir, Kubernetes akan segera melanjutkan ke langkah berikutnya. Oleh karena itu, periksa bahwa nilai periode ini dalam detik tidak kurang dari waktu yang diperlukan untuk perapian mati dengan benar, dan jika melebihi 30 detik, tambah periode ke nilai yang diinginkan dalam YAML. Dalam contoh di atas, ini adalah 60-an.

Dan akhirnya, langkah terakhir - jika kontainer masih terus bekerja setelah terminationGracePeriod berakhir, mereka akan mengirim sinyal SIGKILL dan akan dihapus secara paksa. Pada titik ini, Kubernetes juga akan membersihkan semua objek pod lainnya.



Kubernet mematikan perapian karena berbagai alasan, jadi pastikan bahwa dalam hal apa pun aplikasi Anda akan diselesaikan dengan benar untuk memastikan operasi layanan yang stabil.

Praktik terbaik Kubernetes. Memetakan layanan eksternal

Sedikit iklan :)

Terima kasih untuk tetap bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda VPS berbasis cloud untuk pengembang mulai $ 4,99 , analog unik dari server entry-level yang diciptakan oleh kami untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps mulai dari $ 19 atau cara membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya kami yang memiliki 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang Cara Membangun Infrastruktur Bldg. kelas c menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?