Sistem sing disebarake bisa angel diatur amarga akeh unsur sing obah lan ganti sing kabeh kudu bisa digunakake kanthi bener supaya sistem bisa digunakake. Yen salah sawijining unsur gagal, sistem kudu ndeteksi, ngliwati lan ndandani, lan kabeh iki kudu ditindakake kanthi otomatis. Ing seri Praktik Paling Apik Kubernetes iki, kita bakal sinau carane nyiyapake tes Kesiapan lan Keaktifan kanggo nguji kesehatan kluster Kubernetes.
Priksa Kesehatan minangka cara sing gampang supaya sistem ngerti apa conto aplikasi sampeyan mlaku utawa ora. Yen conto aplikasi sampeyan mudhun, mula layanan liyane ora kudu ngakses utawa ngirim panjalukan. Nanging, panjaluk kasebut kudu dikirim menyang conto aplikasi liyane sing wis mlaku utawa bakal diluncurake mengko. Kajaba iku, sistem kudu mulihake fungsi aplikasi sing ilang.
Kanthi gawan, Kubernetes bakal miwiti ngirim lalu lintas menyang pod nalika kabeh wadhah ing pod mlaku, lan wadhah urip maneh nalika nabrak. Prilaku sistem standar iki bisa uga cukup apik kanggo miwiti, nanging sampeyan bisa nambah linuwih panyebaran produk kanthi nggunakake pamriksa kewarasan khusus.
Untunge, Kubernetes nggawe iki gampang ditindakake, mula ora ana alesan kanggo ora nggatekake pamriksan kasebut. Kubernetes nyedhiyakake rong jinis Pemeriksa Kesehatan, lan penting kanggo ngerti bedane carane saben digunakake.
Tes Kesiapan dirancang kanggo ngandhani Kubernetes yen aplikasi sampeyan siyap nangani lalu lintas. Sadurunge ngidini layanan ngirim lalu lintas menyang pod, Kubernetes kudu verifikasi manawa mriksa kesiapan wis sukses. Yen tes Kesiapan gagal, Kubernetes bakal mandheg ngirim lalu lintas menyang pod nganti tes lulus.
Tes Liveness ngandhani Kubernetes apa aplikasi sampeyan urip utawa mati. Ing kasus sing sepisanan, Kubernetes bakal ninggalake, ing kasus liyane bakal mbusak pod sing mati lan ngganti karo sing anyar.
Coba bayangake skenario nalika aplikasi sampeyan butuh 1 menit kanggo anget lan diluncurake. Layanan sampeyan ora bakal bisa digunakake nganti aplikasi diisi lan mlaku kanthi lengkap, sanajan alur kerja wis diwiwiti. Sampeyan uga bakal nemoni masalah yen pengin nggedhekake penyebaran iki dadi pirang-pirang salinan, amarga salinan kasebut ora bakal nampa lalu lintas nganti siap. Nanging, kanthi gawan, Kubernetes bakal miwiti ngirim lalu lintas sanalika proses ing wadhah diwiwiti.
Nalika nggunakake tes Kesiapan, Kubernetes bakal ngenteni nganti aplikasi mlaku kanthi lengkap sadurunge ngidini layanan ngirim lalu lintas menyang salinan anyar.
Ayo bayangake skenario liyane ing ngendi aplikasi kasebut macet nganti suwe, mandhegake panjaluk layanan. Nalika proses terus mlaku, kanthi standar Kubernetes bakal nganggep kabeh apik lan terus ngirim panjaluk menyang pod sing ora bisa digunakake. Nanging nalika nggunakake Liveness, Kubernetes bakal ndeteksi manawa aplikasi kasebut ora lagi nglayani panjaluk lan bakal miwiti maneh pod mati kanthi standar.
Ayo goleki kepiye kesiapan lan daya tahan diuji. Ana telung cara testing - HTTP, Command lan TCP. Sampeyan bisa nggunakake salah siji saka wong-wong mau kanggo mriksa. Cara sing paling umum kanggo nguji pangguna yaiku probe HTTP.
Sanajan aplikasi sampeyan dudu server HTTP, sampeyan isih bisa nggawe server HTTP sing entheng ing aplikasi sampeyan kanggo sesambungan karo tes Liveness. Sawise iki, Kubernetes bakal miwiti ping pod, lan yen respon HTTP ana ing kisaran 200 utawa 300 ms, iku bakal nuduhake yen pod sehat. Yen ora, modul kasebut bakal ditandhani minangka "ora sehat".
Kanggo tes Command, Kubernetes nglakokake printah ing wadhah sampeyan. Yen printah bali karo kode metu nul, wadhah bakal ditandhani minangka sehat, yen ora, sawise nampa nomer status metu saka 1 kanggo 255, wadhah bakal ditandhani minangka "lara". Cara pangujian iki migunani yen sampeyan ora bisa utawa ora pengin mbukak server HTTP, nanging bisa mbukak printah sing bakal mriksa kesehatan aplikasi sampeyan.
Mekanisme verifikasi pungkasan yaiku tes TCP. Kubernetes bakal nyoba nggawe sambungan TCP ing port sing ditemtokake. Yen iki bisa ditindakake, wadhah kasebut dianggep sehat, yen ora, dianggep ora bisa ditindakake. Cara iki bisa migunani yen sampeyan nggunakake skenario ing ngendi tes karo panjalukan HTTP utawa eksekusi printah ora bisa digunakake kanthi apik. Contone, layanan utama kanggo verifikasi nggunakake TCP yaiku gRPC utawa FTP.
Tes bisa dikonfigurasi kanthi sawetara cara kanthi paramèter sing beda. Sampeyan bisa nemtokake sepira kerepe kudu dieksekusi, apa ambang sukses lan gagal, lan suwene ngenteni tanggapan. Kanggo informasi luwih lengkap, deleng dokumentasi kanggo tes Kesiapan lan Urip. Nanging, ana siji titik penting banget kanggo nyetel tes Liveness - setelan awal saka wektu tundha testing initialDelaySeconds. Kaya sing dakkandhakake, kegagalan tes iki bakal nyebabake modul diwiwiti maneh. Dadi, sampeyan kudu mesthekake yen tes ora diwiwiti nganti aplikasi wis siyap, yen ora bakal miwiti muter maneh. Aku nyaranake nggunakake wektu wiwitan P99 utawa wektu wiwitan aplikasi rata-rata saka buffer. Elinga nyetel nilai iki amarga wektu wiwitan aplikasi dadi luwih cepet utawa luwih alon.
Umume ahli bakal ngonfirmasi manawa Pemeriksa Kesehatan minangka pamriksa wajib kanggo sistem sing disebarake, lan Kubernetes ora kajaba. Nggunakake pamriksa kesehatan layanan njamin operasi Kubernetes sing dipercaya lan tanpa masalah lan gampang kanggo pangguna.
Diterusake kanthi cepet ...
Sawetara iklan π
Matur nuwun kanggo tetep karo kita. Apa sampeyan seneng karo artikel kita? Pengin ndeleng konten sing luwih menarik? Ndhukung kita kanthi nggawe pesenan utawa menehi rekomendasi menyang kanca, , analog unik saka server level entri, sing diciptakake kanggo sampeyan: (kasedhiya karo RAID1 lan RAID10, munggah 24 intine lan nganti 40GB DDR4).
Dell R730xd 2 kaping luwih murah ing pusat data Equinix Tier IV ing Amsterdam? Mung kene ing Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - saka $99! Maca babagan
Source: www.habr.com