Sistem terdistribusi bisa jadi sulit untuk dikelola karena terdapat banyak elemen yang bergerak dan berubah yang semuanya harus berfungsi dengan baik agar sistem dapat berfungsi. Jika salah satu elemen gagal, sistem harus mendeteksinya, melewatinya, dan memperbaikinya, dan semua ini harus dilakukan secara otomatis. Dalam seri Praktik Terbaik Kubernetes ini, kita akan mempelajari cara menyiapkan pengujian Kesiapan dan Keaktifan untuk menguji kesehatan cluster Kubernetes.
Pemeriksaan Kesehatan adalah cara sederhana untuk memberi tahu sistem apakah instance aplikasi Anda berjalan atau tidak. Jika instans aplikasi Anda tidak berfungsi, layanan lain tidak boleh mengaksesnya atau mengirimkan permintaan ke instans tersebut. Sebaliknya, permintaan tersebut harus dikirim ke aplikasi lain yang sudah berjalan atau akan diluncurkan nanti. Selain itu, sistem harus mengembalikan fungsionalitas aplikasi Anda yang hilang.
Secara default, Kubernetes akan mulai mengirimkan lalu lintas ke sebuah pod ketika semua container di dalam pod tersebut berjalan, dan melakukan boot ulang container ketika terjadi error. Perilaku sistem default ini mungkin cukup baik untuk memulai, namun Anda dapat meningkatkan keandalan penerapan produk Anda dengan menggunakan pemeriksaan kewarasan khusus.
Untungnya, Kubernetes membuat hal ini cukup mudah dilakukan, jadi tidak ada alasan untuk mengabaikan pemeriksaan ini. Kubernetes menyediakan dua jenis Pemeriksaan Kesehatan, dan penting untuk memahami perbedaan cara penggunaannya.
Tes Kesiapan dirancang untuk memberi tahu Kubernetes bahwa aplikasi Anda siap menangani lalu lintas. Sebelum mengizinkan layanan mengirimkan lalu lintas ke pod, Kubernetes harus memverifikasi bahwa pemeriksaan kesiapan berhasil. Jika pengujian Kesiapan gagal, Kubernetes akan berhenti mengirimkan lalu lintas ke pod hingga pengujian tersebut berhasil.
Uji Liveness memberi tahu Kubernetes apakah aplikasi Anda masih hidup atau sudah mati. Pada kasus pertama, Kubernetes akan membiarkannya, pada kasus kedua Kubernetes akan menghapus pod yang mati dan menggantinya dengan yang baru.
Bayangkan sebuah skenario ketika aplikasi Anda memerlukan waktu 1 menit untuk pemanasan dan peluncuran. Layanan Anda tidak akan mulai berfungsi hingga aplikasi dimuat dan berjalan sepenuhnya, meskipun alur kerja telah dimulai. Anda juga akan mengalami masalah jika ingin meningkatkan penerapan ini ke beberapa salinan, karena salinan tersebut tidak akan menerima lalu lintas sampai salinan tersebut sepenuhnya siap. Namun, secara default, Kubernetes akan mulai mengirimkan lalu lintas segera setelah proses di dalam container dimulai.
Saat menggunakan uji Kesiapan, Kubernetes akan menunggu hingga aplikasi berjalan sepenuhnya sebelum mengizinkan layanan mengirimkan lalu lintas ke salinan baru.
Mari kita bayangkan skenario lain di mana aplikasi hang dalam waktu lama, menghentikan permintaan layanan. Saat proses terus berjalan, secara default Kubernetes akan menganggap semuanya baik-baik saja dan terus mengirimkan permintaan ke pod yang tidak berfungsi. Namun saat menggunakan Liveness, Kubernetes akan mendeteksi bahwa aplikasi tidak lagi melayani permintaan dan akan memulai ulang pod yang mati secara default.
Mari kita lihat bagaimana kesiapan dan kelayakan diuji. Ada tiga metode pengujian - HTTP, Command dan TCP. Anda dapat menggunakan salah satu dari mereka untuk memeriksa. Cara paling umum untuk menguji pengguna adalah pemeriksaan HTTP.
Meskipun aplikasi Anda bukan server HTTP, Anda masih dapat membuat server HTTP ringan di dalam aplikasi Anda untuk berinteraksi dengan pengujian Liveness. Setelah ini, Kubernetes akan mulai melakukan ping ke pod, dan jika respons HTTP berada di kisaran 200 atau 300 ms, hal ini menunjukkan bahwa pod tersebut sehat. Jika tidak, modul akan ditandai sebagai "tidak sehat".
Untuk pengujian Command, Kubernetes menjalankan perintah di dalam container Anda. Jika perintah kembali dengan kode keluar nol, maka container akan ditandai sehat, sebaliknya, setelah menerima nomor status keluar dari 1 hingga 255, container akan ditandai βsakitβ. Metode pengujian ini berguna jika Anda tidak dapat atau tidak ingin menjalankan server HTTP, namun dapat menjalankan perintah yang akan memeriksa kesehatan aplikasi Anda.
Mekanisme verifikasi terakhir adalah tes TCP. Kubernetes akan mencoba membuat koneksi TCP pada port yang ditentukan. Jika hal ini dapat dilakukan maka wadah tersebut dianggap sehat, jika tidak maka dianggap tidak layak. Metode ini dapat berguna jika Anda menggunakan skenario di mana pengujian dengan permintaan HTTP atau eksekusi perintah tidak berfungsi dengan baik. Misalnya, layanan utama untuk verifikasi menggunakan TCP adalah gRPC atau FTP.
Pengujian dapat dikonfigurasi dalam beberapa cara dengan parameter berbeda. Anda dapat menentukan seberapa sering tindakan tersebut harus dijalankan, berapa ambang keberhasilan dan kegagalannya, dan berapa lama waktu menunggu tanggapan. Untuk informasi lebih lanjut, lihat dokumentasi tes Kesiapan dan Keaktifan. Namun, ada satu poin yang sangat penting dalam menyiapkan tes Liveness - pengaturan awal penundaan pengujian initialDelaySeconds. Seperti yang saya sebutkan, kegagalan pengujian ini akan mengakibatkan modul di-restart. Jadi, Anda perlu memastikan bahwa pengujian tidak dimulai sampai aplikasi siap dijalankan, jika tidak, maka aplikasi akan mulai berputar melalui restart. Saya sarankan menggunakan waktu startup P99 atau waktu startup aplikasi rata-rata dari buffer. Ingatlah untuk menyesuaikan nilai ini seiring waktu startup aplikasi Anda menjadi lebih cepat atau lebih lambat.
Kebanyakan ahli akan mengonfirmasi bahwa Pemeriksaan Kesehatan adalah pemeriksaan wajib untuk sistem terdistribusi apa pun, dan Kubernetes tidak terkecuali. Penggunaan pemeriksaan kesehatan layanan memastikan pengoperasian Kubernetes yang andal dan bebas masalah serta mudah bagi pengguna.
Akan segera dilanjutkan...
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