Sistem terdistribusi bisa sulit dikelola karena mengandung banyak elemen yang bergerak dan mudah berubah, yang semuanya harus berfungsi dengan baik untuk memastikan fungsionalitas sistem. Jika satu elemen gagal, sistem harus mendeteksi, menghindari, dan memperbaikinya, semuanya secara otomatis. Dalam seri "Praktik Terbaik Kubernetes" ini, kita akan mempelajari cara mengkonfigurasi pengujian kesiapan dan keaktifan untuk memverifikasi kesehatan klaster Kubernetes.
Pemeriksaan kesehatan adalah cara sederhana bagi sistem untuk mengetahui apakah sebuah instance aplikasi Anda sedang berjalan atau tidak. Jika sebuah instance aplikasi Anda sedang tidak aktif, layanan lain tidak boleh mengaksesnya atau mengirim permintaan ke instance tersebut. Sebaliknya, permintaan harus dikirim ke instance aplikasi lain yang sudah berjalan atau akan dimulai nanti. Selanjutnya, sistem harus mengembalikan aplikasi Anda ke keadaan normalnya.
Secara default, Kubernetes akan mulai mengirimkan trafik ke sebuah pod ketika semua kontainer di dalam pod tersebut berjalan dan akan memulai ulang kontainer ketika terjadi crash. Perilaku default ini mungkin cukup untuk deployment awal, tetapi Anda dapat meningkatkan keandalan deployment produk Anda dengan menggunakan pemeriksaan kesehatan khusus.
Untungnya, Kubernetes membuatnya cukup mudah, 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 melayani lalu lintas. Sebelum mengizinkan layanan untuk mengirim lalu lintas ke pod, Kubernetes harus memverifikasi bahwa pemeriksaan kesiapan berhasil. Jika tes Kesiapan gagal, Kubernetes akan berhenti mengirim lalu lintas ke pod hingga tes berhasil.
Tes liveness memberi tahu Kubernetes apakah aplikasi Anda aktif atau tidak. Jika aplikasi aktif, Kubernetes akan membiarkannya; jika aplikasi tidak aktif, Kubernetes akan menghapus pod yang tidak aktif dan menggantinya dengan yang baru.
Mari kita bayangkan sebuah skenario di mana aplikasi Anda membutuhkan waktu 1 menit untuk pemanasan dan peluncuran. Layanan Anda tidak akan mulai bekerja sampai aplikasi sepenuhnya dimuat dan berjalan, meskipun proses pekerja sudah dimulai. Anda juga akan mengalami masalah jika ingin menskalakan penyebaran ini ke beberapa instance, karena instance-instance ini seharusnya tidak menerima lalu lintas sampai sepenuhnya beroperasi. Namun, secara default, Kubernetes akan mulai mengirimkan lalu lintas segera setelah proses di dalam kontainer dimulai.
Saat menggunakan Readiness probe, Kubernetes akan menunggu hingga aplikasi berjalan sepenuhnya sebelum mengizinkan layanan mengirimkan trafik ke instance baru.
Mari kita bayangkan skenario yang berbeda: sebuah aplikasi mengalami hang dalam waktu lama, berhenti melayani permintaan. Karena proses terus berjalan, Kubernetes secara default akan menganggap semuanya baik-baik saja dan terus mengirimkan permintaan ke pod yang mati tersebut. Namun, dengan Liveness diaktifkan, Kubernetes akan mendeteksi bahwa aplikasi tersebut tidak lagi melayani permintaan dan akan memulai ulang pod yang mati tersebut secara default.
Mari kita lihat bagaimana kesiapan dan keaktifan diuji. Ada tiga metode pengujian: HTTP, Command, dan TCP. Anda dapat menggunakan salah satunya untuk verifikasi. Metode pengujian pengguna yang paling umum adalah probe HTTP.
Meskipun aplikasi Anda bukan server HTTP, Anda tetap dapat membuat server HTTP ringan di dalam aplikasi Anda untuk berinteraksi dengan pengujian keaktifan (liveness test). Kubernetes kemudian akan melakukan ping ke pod, dan jika respons HTTP berada dalam rentang 200 atau 300 ms, itu akan menunjukkan bahwa pod tersebut sehat. Jika tidak, pod akan ditandai sebagai tidak sehat.
Untuk pengujian berbasis perintah, Kubernetes menjalankan perintah di dalam kontainer Anda. Jika perintah tersebut mengembalikan kode keluar nol, kontainer akan ditandai sebagai sehat. Sebaliknya, jika menerima status keluar antara 1 dan 255, kontainer akan ditandai sebagai "sakit". Metode pengujian ini berguna jika Anda tidak dapat atau tidak ingin menjalankan server HTTP, tetapi dapat menjalankan perintah untuk memeriksa kesehatan aplikasi Anda.
Mekanisme verifikasi terakhir adalah pengujian TCP. Kubernetes akan mencoba membuat koneksi TCP pada port yang ditentukan. Jika berhasil, kontainer dianggap sehat; jika tidak, dianggap tidak sehat. Metode ini dapat berguna jika Anda memiliki skenario di mana pengujian dengan permintaan HTTP atau eksekusi perintah tidak berjalan dengan baik. Misalnya, gRPC atau FTP adalah layanan umum yang diuji menggunakan TCP.
Pengujian dapat dikonfigurasi dengan beberapa cara menggunakan berbagai parameter. Anda dapat menentukan seberapa sering pengujian harus dijalankan, berapa ambang batas keberhasilan dan kegagalan, dan berapa lama waktu tunggu respons. Informasi lebih detail tersedia dalam dokumentasi untuk pengujian Kesiapan dan Keaktifan. Namun, ada satu poin yang sangat penting dalam mengkonfigurasi pengujian Keaktifan: mengatur penundaan pengujian awal (initialDelaySeconds). Seperti yang saya sebutkan, kegagalan menjalankan pengujian ini akan menyebabkan modul memulai ulang. Oleh karena itu, Anda perlu memastikan bahwa pengujian tidak dimulai sampai aplikasi siap dijalankan, jika tidak, aplikasi akan mulai memulai ulang secara berulang. Saya merekomendasikan untuk menggunakan waktu startup P99 atau waktu startup aplikasi rata-rata dari buffer. Ingatlah untuk menyesuaikan nilai ini seiring dengan semakin cepat atau lambatnya waktu startup aplikasi Anda.
Sebagian besar ahli akan setuju bahwa pemeriksaan kesehatan sangat penting untuk sistem terdistribusi apa pun, dan Kubernetes tidak terkecuali. Menggunakan pemeriksaan kesehatan layanan memastikan pengoperasian Kubernetes yang andal dan bebas masalah serta mudah dilakukan oleh 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
