Praktik terbaik Kubernetes. Tes viabilitas Kubernetes dengan uji Readiness and Liveness

Praktik terbaik Kubernetes. Membuat Kontainer Kecil
Kubernetes Praktik Terbaik. Organisasi Kubernet dengan



sistem terdistribusi namespace mungkin sulit untuk dikelola karena faktanya mereka memiliki banyak elemen yang dapat dipindah-pindah, dan semuanya harus bekerja dengan baik untuk memastikan fungsionalitas sistem. Jika salah satu elemen gagal, maka sistem harus mendeteksi, memotong dan memperbaikinya, dan semua ini harus dilakukan secara otomatis. Dalam seri Praktik Terbaik Kubernetes ini, kita akan belajar cara mengonfigurasi tes Readiness and Liveness untuk menguji kelayakan cluster Kubernetes.

Pemeriksaan Kesehatan Pemeriksaan Kesehatan adalah cara mudah untuk memberi tahu sistem apakah instance aplikasi Anda sedang berjalan atau tidak. Jika instance aplikasi Anda tidak berfungsi, maka layanan lain tidak boleh mengaksesnya atau mengirim permintaan kepadanya. Sebagai gantinya, permintaan tersebut harus dikirim ke instance aplikasi lain yang sudah berjalan atau akan mulai nanti. Selain itu, sistem harus mengembalikan aplikasi Anda ke fungsi yang hilang.

Secara default, Kubernetes akan mulai mengirimkan lalu lintas ke pod ketika semua kontainer di dalam perapian berjalan, dan memuat kembali kontainer saat crash. Sebagai permulaan, perilaku default sistem ini bisa sangat baik, tetapi Anda dapat meningkatkan keandalan penyebaran produk Anda menggunakan pemeriksaan kesehatan khusus.



Untungnya, Kubernetes memungkinkan Anda melakukan ini dengan cukup sederhana, jadi tidak ada alasan untuk mengabaikan cek semacam itu. Kubernetes menyediakan dua jenis tes Pemeriksaan Kesehatan, dan penting untuk memahami perbedaan dalam setiap aplikasi.

The Readiness Readiness Test dirancang untuk memberi tahu Kubernetes bahwa aplikasi Anda siap melayani lalu lintas. Sebelum mengizinkan layanan untuk mengirim lalu lintas ke pod, Kubernetes harus memverifikasi bahwa pemeriksaan ketersediaan berhasil. Jika uji Kesiapan gagal, Kubernetes akan berhenti mengirimkan lalu lintas ke pod hingga pengujian berhasil.

Liveness Viability Test memberi tahu Kubernetes apakah aplikasi Anda hidup atau mati. Dalam kasus pertama, Kubernetes akan meninggalkannya sendirian, di yang kedua, ia akan menghapus pod yang mati dan menggantinya dengan yang baru.

Mari kita bayangkan sebuah skenario di mana aplikasi Anda perlu 1 menit untuk "menghangat" dan berlari. Layanan Anda tidak akan mulai bekerja sampai aplikasi sepenuhnya dimuat dan mulai, meskipun alur kerja sudah dimulai. Dan Anda juga akan mengalami masalah jika Anda ingin meningkatkan skala penyebaran ini menjadi beberapa salinan, karena salinan ini tidak boleh menerima lalu lintas sampai mereka benar-benar siap. Namun, secara default, Kubernetes akan mulai mengirimkan lalu lintas segera setelah dimulainya proses di dalam wadah.

Saat menggunakan uji kesiapan Kesiapan, Kubernetes akan menunggu sampai aplikasi sepenuhnya diluncurkan dan hanya setelah itu akan memungkinkan layanan untuk mengirim lalu lintas ke salinan baru.



Mari kita bayangkan skenario lain di mana aplikasi membeku untuk waktu yang lama, menghentikan permintaan servis. Karena proses terus berjalan, secara default Kubernetes akan mempertimbangkan bahwa semuanya sudah beres dan terus mengirim permintaan ke pod yang tidak berfungsi. Tetapi ketika menggunakan Liveness, Kubernetes akan mendeteksi bahwa aplikasi tidak lagi melayani permintaan, dan secara default akan memulai kembali pod yang tidak berfungsi.



Pertimbangkan cara menguji kesiapan dan vitalitas. Ada tiga metode pengujian - HTTP, ommommand, dan TCP. Anda dapat menggunakan salah satu dari mereka untuk verifikasi. Metode uji pengguna yang paling umum adalah probe HTTP.

Bahkan jika aplikasi Anda bukan server HTTP, Anda masih dapat membuat server HTTP ringan di dalam aplikasi Anda untuk berinteraksi dengan tes Liveness. Setelah itu, Kubernetes akan mulai melakukan ping pod, dan jika respons HTTP berada di kisaran 200 atau 300 ms, itu berarti pod tersebut “sehat”. Jika tidak, modul akan ditandai sebagai "tidak sehat".



Untuk tes menggunakan Command, Kubernetes mengeksekusi perintah di dalam wadah Anda. Jika perintah kembali dengan kode keluar nol, maka wadah akan ditandai sebagai sehat, jika tidak, ketika nomor status keluar dari 1 hingga 255, wadah akan ditandai sebagai "sakit". Metode pengujian ini berguna jika Anda tidak dapat atau tidak ingin memulai server HTTP, tetapi Anda dapat menjalankan perintah yang akan memeriksa kesehatan aplikasi Anda.



Mekanisme verifikasi terakhir adalah uji TCP. Kubernetes akan mencoba membuat koneksi TCP pada port yang ditentukan. Jika ini bisa dilakukan, wadah itu dianggap sehat, jika tidak, itu tidak layak. Metode ini mungkin berguna jika Anda menggunakan skrip di mana pengujian dengan permintaan HTTP atau eksekusi perintah tidak berfungsi dengan baik. Misalnya, layanan utama untuk memeriksa dengan TCP adalah gRPC atau FTP.



Tes dapat dikonfigurasi dalam beberapa cara dengan berbagai parameter. Anda dapat menentukan seberapa sering mereka harus dieksekusi, berapa ambang batas untuk keberhasilan dan kegagalan, dan berapa lama menunggu jawaban. Lihat dokumentasi uji Kesiapan dan Hidup untuk informasi lebih lanjut. Namun, ada satu hal yang sangat penting dalam menyiapkan uji Liveness - pengaturan awal dari keterlambatan tes initialDelaySeconds. Seperti yang saya sebutkan, gagal tes ini akan me-restart modul. Karena itu, Anda perlu memastikan bahwa pengujian tidak dimulai sampai aplikasi siap digunakan, jika tidak maka akan mulai melalui siklus. Saya sarankan menggunakan waktu startup P99 atau waktu startup aplikasi rata-rata dari buffer. Jangan lupa untuk menyesuaikan nilai ini sebagaikarena waktu peluncuran aplikasi Anda semakin cepat atau lambat.

Sebagian besar ahli akan mengonfirmasi bahwa Pemeriksaan Kesehatan adalah pemeriksaan wajib untuk sistem yang didistribusikan, dan Kubernetes tidak terkecuali. Menggunakan "kesehatan" pemeriksaan layanan memastikan Kubernetes dapat diandalkan dan uptime dan tidak membuat bekerja untuk pengguna.

Akan dilanjutkan segera ...

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, cloud VPS untuk pengembang dari $ 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?