🥇Siasatan hidup di Kubernetes boleh berbahaya

Catatan. terjemah: Jurutera utama dari Zalando, Henning Jacobs, telah berulang kali melihat masalah dalam kalangan pengguna Kubernetes dalam memahami tujuan probe hidup (dan kesediaan) dan penggunaannya yang betul. Oleh itu, dia mengumpulkan pemikirannya dalam nota luas ini, yang akhirnya akan menjadi sebahagian daripada dokumentasi K8.

Pemeriksaan kesihatan, yang dikenali dalam Kubernetes sebagai kuar hidup (iaitu, secara literal, "ujian daya maju" - lebih kurang transl.), boleh menjadi agak berbahaya. Saya mengesyorkan untuk mengelakkannya jika boleh: satu-satunya pengecualian adalah apabila ia benar-benar diperlukan dan anda mengetahui sepenuhnya tentang spesifik dan akibat penggunaannya. Penerbitan ini akan bercakap tentang semakan keaktifan dan kesediaan, dan juga akan memberitahu anda dalam kes apa adalah dan anda tidak sepatutnya menggunakannya.

Rakan sekerja saya Sandor baru-baru ini berkongsi di Twitter ralat paling biasa yang dia hadapi, termasuk yang berkaitan dengan penggunaan probe kesediaan/kehidupan:

Dikonfigurasikan dengan salah livenessProbe boleh memburukkan lagi keadaan beban tinggi (penutupan bola salji + masa permulaan kontena/aplikasi yang berpotensi panjang) dan membawa kepada akibat negatif lain seperti penurunan pergantungan (lihat juga artikel terbaru saya tentang mengehadkan bilangan permintaan dalam gabungan K3s+ACME). Lebih teruk lagi apabila siasatan keaktifan digabungkan dengan pemeriksaan kesihatan, iaitu pangkalan data luaran: kegagalan DB tunggal akan memulakan semula semua bekas anda!

Mesej am "Jangan gunakan kuar hidup" dalam kes ini ia tidak banyak membantu, jadi mari kita lihat untuk apa pemeriksaan kesediaan dan keaktifan.

Nota: Kebanyakan ujian di bawah pada asalnya disertakan dalam dokumentasi pembangun dalaman Zalando.

Semakan Kesediaan dan Keaktifan

Kubernetes menyediakan dua mekanisme penting yang dipanggil kuar keaktifan dan kuar kesediaan. Mereka melakukan beberapa tindakan secara berkala—seperti menghantar permintaan HTTP, membuka sambungan TCP atau melaksanakan perintah dalam bekas—untuk mengesahkan bahawa aplikasi berfungsi seperti yang diharapkan.

Kubernetes menggunakan kuar kesediaanuntuk memahami apabila kontena bersedia untuk menerima lalu lintas. Pod dianggap sedia untuk digunakan jika semua bekasnya sudah sedia. Satu penggunaan mekanisme ini adalah untuk mengawal pod yang digunakan sebagai hujung belakang untuk perkhidmatan Kubernetes (dan terutamanya Ingress).

Kuar liveness membantu Kubernetes memahami bila masa untuk memulakan semula bekas. Sebagai contoh, semakan sedemikian membolehkan anda memintas kebuntuan apabila aplikasi tersekat di satu tempat. Memulakan semula bekas dalam keadaan ini membantu mengeluarkan aplikasi daripada asas walaupun terdapat ralat, tetapi ia juga boleh menyebabkan kegagalan berlatarkan (lihat di bawah).

Jika anda cuba menggunakan kemas kini aplikasi yang gagal dalam semakan keaktifan/kesediaan, pelancarannya akan terhenti apabila Kubernetes menunggu status Ready dari semua pod.

Contoh

Berikut ialah contoh siasatan kesediaan yang memeriksa laluan /health melalui HTTP dengan tetapan lalai (selang: 10 Saat, timeout: 1 saat, ambang kejayaan: 1, ambang kegagalan: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

Cadangan

Untuk perkhidmatan mikro dengan titik akhir HTTP (REST, dsb.) sentiasa tentukan probe kesediaan, yang menyemak sama ada aplikasi (pod) bersedia untuk menerima trafik.
Pastikan siasatan kesediaan meliputi ketersediaan port pelayan web sebenar:
- menggunakan port untuk tujuan pentadbiran, dipanggil "admin" atau "pengurusan" (contohnya, 9090), untuk readinessProbe, pastikan titik akhir hanya mengembalikan OK jika port HTTP utama (seperti 8080) sedia untuk menerima trafik*;
  *Saya mengetahui sekurang-kurangnya satu kes di Zalando di mana ini tidak berlaku, i.e. readinessProbe Saya menyemak port "pengurusan", tetapi pelayan itu sendiri tidak mula berfungsi kerana masalah memuatkan cache.
- melampirkan probe kesediaan ke port yang berasingan boleh membawa kepada fakta bahawa beban berlebihan pada port utama tidak akan ditunjukkan dalam pemeriksaan kesihatan (iaitu, kumpulan benang pada pelayan penuh, tetapi pemeriksaan kesihatan masih menunjukkan bahawa semuanya OK ).
Pastikan bahawa probe kesediaan membolehkan pemulaan/penghijrahan pangkalan data;
- Cara paling mudah untuk mencapai ini adalah dengan menghubungi pelayan HTTP hanya selepas permulaan selesai (contohnya, memindahkan pangkalan data dari Laluan terbang dan sebagainya.); iaitu, bukannya menukar status pemeriksaan kesihatan, cuma jangan mulakan pelayan web sehingga pemindahan pangkalan data selesai*.
  * Anda juga boleh menjalankan migrasi pangkalan data daripada bekas init di luar pod. Saya masih peminat aplikasi serba lengkap, iaitu, yang mana bekas aplikasi tahu cara membawa pangkalan data ke dalam keadaan yang dikehendaki tanpa penyelarasan luaran.
Gunakan httpGet untuk semakan kesediaan melalui titik akhir pemeriksaan kesihatan biasa (contohnya, /health).
Fahami parameter semakan lalai (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- pilihan lalai bermakna pod akan menjadi tidak bersedia selepas kira-kira 30 saat (3 pemeriksaan kewarasan gagal).
Gunakan port berasingan untuk "pentadbir" atau "pengurusan" jika tindanan teknologi (mis. Java/Spring) membenarkannya, untuk memisahkan pengurusan kesihatan dan metrik daripada trafik biasa:
- tetapi jangan lupa tentang point 2.
Jika perlu, probe kesediaan boleh digunakan untuk memanaskan/memuatkan cache dan mengembalikan kod status 503 sehingga bekas menjadi panas:
- Saya juga mengesyorkan anda membaca cek baharu startupProbe, muncul dalam versi 1.16 (kami menulis tentangnya dalam bahasa Rusia di sini - lebih kurang terjemah.).

Kaunter

Jangan bergantung pada kebergantungan luaran (seperti gudang data) apabila menjalankan ujian kesediaan/keaktifan - ini boleh menyebabkan kegagalan berlatarkan:
- Sebagai contoh, mari kita ambil perkhidmatan REST stateful dengan 10 pod bergantung pada satu pangkalan data Postgres: apabila semakan bergantung pada sambungan yang berfungsi ke DB, semua 10 pod mungkin gagal jika terdapat kelewatan pada bahagian rangkaian/DB - biasanya ia semua berakhir lebih teruk daripada yang boleh;
- Sila ambil perhatian bahawa Spring Data menyemak sambungan pangkalan data secara lalai*;
  * Ini ialah gelagat lalai Spring Data Redis (sekurang-kurangnya ia adalah kali terakhir saya menyemak), yang membawa kepada kegagalan "malapetaka": apabila Redis tidak tersedia untuk masa yang singkat, semua pod "terhempas".
- "luaran" dalam pengertian ini juga boleh bermaksud pod lain bagi aplikasi yang sama, iaitu, sebaik-baiknya semakan tidak boleh bergantung pada keadaan pod lain dalam kelompok yang sama untuk mengelakkan ranap sistem bertingkat:
  - keputusan mungkin berbeza untuk aplikasi dengan keadaan teragih (contohnya, caching dalam memori dalam pod).
Jangan gunakan kuar hidup untuk pod (pengecualian ialah kes apabila ia benar-benar diperlukan dan anda mengetahui sepenuhnya tentang spesifik dan akibat penggunaannya):
- Siasatan hidup boleh membantu memulihkan bekas yang digantung, tetapi memandangkan anda mempunyai kawalan penuh ke atas aplikasi anda, perkara seperti proses yang digantung dan jalan buntu sepatutnya tidak berlaku: alternatif terbaik adalah dengan sengaja merosakkan aplikasi dan mengembalikannya kepada keadaan mantap sebelumnya;
- siasatan keaktifan yang gagal akan menyebabkan bekas dimulakan semula, dengan itu berpotensi memburukkan lagi akibat ralat berkaitan pemuatan: memulakan semula bekas akan mengakibatkan masa henti (sekurang-kurangnya untuk tempoh permulaan aplikasi, katakan 30 saat ganjil), menyebabkan ralat baharu , meningkatkan beban pada bekas lain dan meningkatkan kemungkinan kegagalannya, dsb.;
- semakan keaktifan digabungkan dengan pergantungan luar adalah gabungan yang paling teruk, mengancam kegagalan berlatarkan: kelewatan sedikit pada bahagian pangkalan data akan membawa kepada permulaan semula semua bekas anda!
Parameter pemeriksaan keaktifan dan kesediaan mesti berbeza:
- anda boleh menggunakan siasatan keaktifan dengan pemeriksaan kesihatan yang sama, tetapi ambang tindak balas yang lebih tinggi (failureThreshold), sebagai contoh, tetapkan status tidak bersedia selepas 3 percubaan dan pertimbangkan bahawa siasatan keaktifan telah gagal selepas 10 percubaan;
Jangan gunakan semakan exec, kerana ia dikaitkan dengan masalah yang diketahui yang membawa kepada kemunculan proses zombi:
- butiran: lihat pembentangan oleh pakar Datadog.

Ringkasan

Gunakan probe kesediaan untuk menentukan bila pod sedia untuk menerima trafik.
Gunakan kuar hidup hanya apabila ia benar-benar diperlukan.
Penggunaan probe kesediaan/kehidupan yang tidak betul boleh menyebabkan ketersediaan berkurangan dan kegagalan berlatarkan.

Bahan tambahan mengenai topik tersebut

Dokumen Kubernetes: Konfigurasikan Siasatan Keaktifan dan Kesediaan;
Siasatan Keaktifan dan Kesediaan Kubernetes Disemak Semula: Cara Mengelakkan Menembak Diri Sendiri dengan Kaki Lain;
Post-Mortem Gangguan Makmal NRE (dia juga bercakap tentang livenessProbe).

Kemas kini No. 1 dari 2019-09-29

Mengenai bekas init untuk pemindahan pangkalan data: Nota kaki ditambah.

EJ mengingatkan saya tentang PDB: salah satu masalah dengan pemeriksaan keaktifan adalah kekurangan koordinasi antara pod. Kubernetes telah Belanjawan Gangguan Pod (PDB) untuk mengehadkan bilangan kegagalan serentak yang boleh dialami oleh aplikasi, namun semakan tidak mengambil kira PDB. Sebaik-baiknya, kami boleh memberitahu K8s untuk "Mulakan semula satu pod jika ujiannya gagal, tetapi jangan mulakan semula semuanya untuk mengelak daripada memburukkan lagi keadaan."

Bryan meletakkannya dengan sempurna: “Gunakan liveness probing apabila anda tahu apa yang sebenarnya perkara terbaik untuk dilakukan ialah mematikan aplikasi"(sekali lagi, jangan terbawa-bawa).

Kemas kini No. 2 dari 2019-09-29

Mengenai membaca dokumentasi sebelum digunakan: Saya mencipta permintaan yang sepadan (permintaan ciri) untuk menambah dokumentasi tentang probe keaktifan.

Probe liveness di Kubernetes boleh berbahaya