Sistem teragih boleh menjadi sukar untuk diurus kerana ia mempunyai banyak elemen yang bergerak dan berubah-ubah yang semuanya perlu berfungsi dengan betul untuk sistem berfungsi. Jika salah satu elemen gagal, sistem mesti mengesannya, memintas dan membetulkannya, dan semua ini mesti dilakukan secara automatik. Dalam siri Amalan Terbaik Kubernetes ini, kita akan mempelajari cara menyediakan ujian Kesediaan dan Keaktifan untuk menguji kesihatan gugusan Kubernetes.
Pemeriksaan Kesihatan ialah cara mudah untuk memberitahu sistem sama ada tika aplikasi anda sedang berjalan atau tidak. Jika contoh aplikasi anda tidak berfungsi, maka perkhidmatan lain tidak boleh mengaksesnya atau menghantar permintaan kepadanya. Sebaliknya, permintaan mesti dihantar ke contoh lain aplikasi yang sudah berjalan atau akan dilancarkan kemudian. Di samping itu, sistem harus memulihkan kefungsian aplikasi anda yang hilang.
Secara lalai, Kubernetes akan mula menghantar trafik ke pod apabila semua bekas dalam pod sedang berjalan dan but semula bekas apabila ia ranap. Tingkah laku sistem lalai ini mungkin cukup baik untuk bermula, tetapi anda boleh meningkatkan kebolehpercayaan penggunaan produk anda dengan menggunakan semakan kewarasan tersuai.
Nasib baik, Kubernetes menjadikannya agak mudah untuk dilakukan, jadi tidak ada alasan untuk mengabaikan semakan ini. Kubernetes menyediakan dua jenis Pemeriksaan Kesihatan, dan adalah penting untuk memahami perbezaan cara setiap satunya digunakan.
Ujian Kesediaan direka bentuk untuk memberitahu Kubernetes bahawa aplikasi anda bersedia untuk mengendalikan trafik. Sebelum membenarkan perkhidmatan menghantar trafik ke pod, Kubernetes mesti mengesahkan bahawa semakan kesediaan berjaya. Jika ujian Kesediaan gagal, Kubernetes akan berhenti menghantar trafik ke pod sehingga ujian itu lulus.
Ujian Liveness memberitahu Kubernetes sama ada permohonan anda masih hidup atau mati. Dalam kes pertama, Kubernetes akan membiarkannya begitu sahaja, dalam kes kedua ia akan memadamkan pod yang mati dan menggantikannya dengan yang baru.
Mari bayangkan senario di mana aplikasi anda mengambil masa 1 minit untuk memanaskan badan dan dilancarkan. Perkhidmatan anda tidak akan mula berfungsi sehingga aplikasi dimuatkan dan dijalankan sepenuhnya, walaupun aliran kerja telah pun bermula. Anda juga akan menghadapi masalah jika anda ingin meningkatkan penggunaan ini kepada berbilang salinan, kerana salinan tersebut tidak seharusnya menerima trafik sehingga ia bersedia sepenuhnya. Walau bagaimanapun, secara lalai, Kubernetes akan mula menghantar trafik sebaik sahaja proses di dalam bekas bermula.
Apabila menggunakan ujian Kesediaan, Kubernetes akan menunggu sehingga aplikasi berjalan sepenuhnya sebelum membenarkan perkhidmatan menghantar trafik ke salinan baharu.
Mari bayangkan satu lagi senario di mana aplikasi digantung untuk masa yang lama, menghentikan permintaan servis. Memandangkan proses terus berjalan, secara lalai Kubernetes akan menganggap semuanya baik-baik saja dan terus menghantar permintaan ke pod yang tidak berfungsi. Tetapi apabila menggunakan Liveness, Kubernetes akan mengesan bahawa aplikasi tidak lagi melayani permintaan dan akan memulakan semula pod mati secara lalai.
Mari kita lihat bagaimana kesediaan dan daya maju diuji. Terdapat tiga kaedah ujian - HTTP, Command dan TCP. Anda boleh menggunakan mana-mana daripada mereka untuk menyemak. Cara paling biasa untuk menguji pengguna ialah probe HTTP.
Walaupun aplikasi anda bukan pelayan HTTP, anda masih boleh membuat pelayan HTTP ringan di dalam aplikasi anda untuk berinteraksi dengan ujian Liveness. Selepas ini, Kubernetes akan mula melakukan ping pada pod, dan jika respons HTTP berada dalam julat 200 atau 300 ms, ia akan menunjukkan bahawa pod itu sihat. Jika tidak, modul tersebut akan ditandakan sebagai "tidak sihat".
Untuk ujian Perintah, Kubernetes menjalankan arahan di dalam bekas anda. Jika arahan kembali dengan kod keluar sifar, maka kontena akan ditandakan sebagai sihat, jika tidak, apabila menerima nombor status keluar dari 1 hingga 255, kontena akan ditandakan sebagai "sakit". Kaedah ujian ini berguna jika anda tidak boleh atau tidak mahu menjalankan pelayan HTTP, tetapi dapat menjalankan arahan yang akan menyemak kesihatan aplikasi anda.
Mekanisme pengesahan terakhir ialah ujian TCP. Kubernetes akan cuba mewujudkan sambungan TCP pada port yang ditentukan. Jika ini boleh dilakukan, bekas itu dianggap sihat; jika tidak, ia dianggap tidak berdaya maju. Kaedah ini boleh berguna jika anda menggunakan senario di mana ujian dengan permintaan HTTP atau pelaksanaan perintah tidak berfungsi dengan baik. Sebagai contoh, perkhidmatan utama untuk pengesahan menggunakan TCP ialah gRPC atau FTP.
Ujian boleh dikonfigurasikan dalam beberapa cara dengan parameter yang berbeza. Anda boleh menentukan berapa kerap ia harus dilaksanakan, apakah ambang kejayaan dan kegagalan, dan berapa lama untuk menunggu respons. Untuk maklumat lanjut, lihat dokumentasi untuk ujian Kesediaan dan Keaktifan. Walau bagaimanapun, terdapat satu perkara yang sangat penting dalam menyediakan ujian Liveness - tetapan awal kelewatan ujian initialDelaySeconds. Seperti yang saya nyatakan, kegagalan ujian ini akan menyebabkan modul dimulakan semula. Oleh itu, anda perlu memastikan bahawa ujian tidak bermula sehingga aplikasi sedia untuk digunakan, jika tidak, ia akan mula berbasikal melalui permulaan semula. Saya mengesyorkan menggunakan masa permulaan P99 atau purata masa permulaan aplikasi daripada penimbal. Ingat untuk melaraskan nilai ini kerana masa permulaan aplikasi anda menjadi lebih cepat atau lebih perlahan.
Kebanyakan pakar akan mengesahkan bahawa Pemeriksaan Kesihatan adalah pemeriksaan wajib untuk mana-mana sistem yang diedarkan, dan Kubernetes tidak terkecuali. Menggunakan pemeriksaan kesihatan perkhidmatan memastikan operasi Kubernetes yang boleh dipercayai dan bebas masalah dan mudah untuk pengguna.
Akan diteruskan tidak lama lagi...
Beberapa iklan π
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali 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 - daripada $99! Baca tentang
Sumber: www.habr.com