🥇Penyelidikan keaktifan di Kubernetes bisa berbahaya

Catatan. terjemahan: Insinyur utama dari Zalando, Henning Jacobs, telah berulang kali menyadari adanya masalah di antara pengguna Kubernetes dalam memahami tujuan probe keaktifan (dan kesiapan) dan penggunaannya yang benar. Oleh karena itu, dia mengumpulkan pemikirannya dalam catatan luas ini, yang pada akhirnya akan menjadi bagian dari dokumentasi K8.

Pemeriksaan kesehatan, yang di Kubernetes dikenal sebagai probe keaktifan (yaitu, secara harfiah, “uji kelayakan” - kira-kira terjemahan), bisa sangat berbahaya. Saya menyarankan untuk menghindarinya jika memungkinkan: satu-satunya pengecualian adalah ketika hal tersebut benar-benar diperlukan dan Anda sepenuhnya menyadari secara spesifik dan konsekuensi penggunaannya. Publikasi ini akan membahas tentang pemeriksaan keaktifan dan kesiapan, dan juga akan memberi tahu Anda dalam kasus apa adalah dan Anda tidak boleh menggunakannya.

Rekan saya Sandor baru-baru ini membagikan di Twitter kesalahan paling umum yang dia temui, termasuk kesalahan yang terkait dengan penggunaan pemeriksaan kesiapan/kehidupan:

Konfigurasinya salah livenessProbe dapat memperburuk situasi beban tinggi (penonaktifan secara besar-besaran + kemungkinan waktu startup container/aplikasi yang lama) dan menyebabkan konsekuensi negatif lainnya seperti penurunan ketergantungan (Lihat juga artikel terbaru saya tentang membatasi jumlah permintaan dalam kombinasi K3s+ACME). Lebih buruk lagi bila pemeriksaan keaktifan digabungkan dengan pemeriksaan kesehatan, yang merupakan database eksternal: satu kegagalan DB akan memulai ulang semua container Anda!

Pesan umum "Jangan gunakan probe keaktifan" dalam hal ini tidak banyak membantu, jadi mari kita lihat apa gunanya cek kesiapan dan keaktifan.

Catatan: Sebagian besar pengujian di bawah ini awalnya disertakan dalam dokumentasi pengembang internal Zalando.

Pemeriksaan Kesiapan dan Keaktifan

Kubernetes menyediakan dua mekanisme penting yang disebut probe keaktifan dan probe kesiapan. Mereka secara berkala melakukan beberapa tindakan—seperti mengirim permintaan HTTP, membuka koneksi TCP, atau menjalankan perintah dalam container—untuk mengonfirmasi bahwa aplikasi berfungsi seperti yang diharapkan.

Kubernet menggunakan pemeriksaan kesiapanuntuk memahami kapan kontainer siap menerima lalu lintas. Sebuah pod dianggap siap digunakan jika semua wadahnya telah siap. Salah satu kegunaan mekanisme ini adalah untuk mengontrol pod mana yang digunakan sebagai backend untuk layanan Kubernetes (dan khususnya Ingress).

Pemeriksaan keaktifan membantu Kubernetes memahami kapan waktunya memulai ulang container. Misalnya, pemeriksaan semacam itu memungkinkan Anda mencegat kebuntuan ketika aplikasi macet di satu tempat. Memulai ulang penampung dalam keadaan ini membantu menjalankan aplikasi meskipun ada kesalahan, tetapi juga dapat menyebabkan kegagalan berjenjang (lihat di bawah).

Jika Anda mencoba menerapkan pembaruan aplikasi yang gagal dalam pemeriksaan keaktifan/kesiapan, peluncurannya akan terhenti karena Kubernetes menunggu statusnya. Ready dari semua pod.

Contoh

Berikut adalah contoh pemeriksaan kesiapan yang memeriksa suatu jalur /health melalui HTTP dengan pengaturan default (selang: 10 detik, batas waktu: 1 detik, ambang batas keberhasilan: 1, ambang kegagalan: 3):

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

Rekomendasi

Untuk layanan mikro dengan titik akhir HTTP (REST, dll.) selalu menentukan pemeriksaan kesiapan, yang memeriksa apakah aplikasi (pod) siap menerima lalu lintas.
Pastikan pemeriksaan kesiapan mencakup ketersediaan port server web yang sebenarnya:
- menggunakan port untuk tujuan administratif, yang disebut "admin" atau "manajemen" (misalnya, 9090), untuk readinessProbe, pastikan titik akhir hanya mengembalikan OK jika port HTTP utama (seperti 8080) siap menerima lalu lintas*;
  *Saya mengetahui setidaknya satu kasus di Zalando di mana hal ini tidak terjadi, yaitu. readinessProbe Saya memeriksa port "manajemen", tetapi server itu sendiri tidak mulai berfungsi karena masalah memuat cache.
- melampirkan pemeriksaan kesiapan ke port terpisah dapat mengakibatkan kelebihan beban pada port utama tidak akan tercermin dalam pemeriksaan kesehatan (yaitu, kumpulan thread di server penuh, tetapi pemeriksaan kesehatan masih menunjukkan bahwa semuanya baik-baik saja ).
Pastikan bahwa pemeriksaan kesiapan memungkinkan inisialisasi/migrasi database;
- Cara termudah untuk mencapai hal ini adalah dengan menghubungi server HTTP hanya setelah inisialisasi selesai (misalnya, memigrasi database dari jalur terbang dan seterusnya.); yaitu, alih-alih mengubah status pemeriksaan kesehatan, jangan memulai server web hingga migrasi database selesai*.
  * Anda juga dapat menjalankan migrasi database dari container init di luar pod. Saya masih penggemar aplikasi mandiri, yaitu aplikasi yang wadah aplikasinya tahu cara membawa database ke keadaan yang diinginkan tanpa koordinasi eksternal.
Gunakan httpGet untuk pemeriksaan kesiapan melalui titik akhir pemeriksaan kondisi umum (misalnya, /health).
Pahami parameter pemeriksaan default (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- opsi default berarti pod akan menjadi belum siap setelah sekitar 30 detik (3 pemeriksaan kewarasan gagal).
Gunakan port terpisah untuk "admin" atau "manajemen" jika tumpukan teknologi (misalnya Java/Spring) mengizinkannya, untuk memisahkan manajemen kesehatan dan metrik dari lalu lintas reguler:
- tapi jangan lupakan poin 2.
Jika perlu, pemeriksaan kesiapan dapat digunakan untuk menghangatkan/memuat cache dan mengembalikan kode status 503 hingga wadah memanas:
- Saya juga menyarankan Anda membaca cek baru startupProbe, muncul di versi 1.16 (kami menulis tentang itu dalam bahasa Rusia di sini - kira-kira. terjemahkan).

Peringatan

Jangan bergantung pada ketergantungan eksternal (seperti gudang data) saat menjalankan uji kesiapan/keaktifan - hal ini dapat menyebabkan kegagalan berjenjang:
- Sebagai contoh, mari kita ambil layanan REST stateful dengan 10 pod yang bergantung pada satu database Postgres: ketika pemeriksaan bergantung pada koneksi yang berfungsi ke DB, semua 10 pod mungkin gagal jika ada penundaan di sisi jaringan/DB - biasanya hal itu terjadi. semuanya berakhir lebih buruk dari yang seharusnya;
- Harap dicatat bahwa Spring Data memeriksa koneksi database secara default*;
  * Ini adalah perilaku default Spring Data Redis (setidaknya ini terakhir kali saya memeriksanya), yang menyebabkan kegagalan "bencana": ketika Redis tidak tersedia untuk waktu yang singkat, semua pod "rusak".
- “eksternal” dalam pengertian ini juga bisa berarti pod lain dari aplikasi yang sama, yaitu, idealnya pemeriksaan tidak bergantung pada status pod lain dari cluster yang sama untuk mencegah crash berjenjang:
  - hasilnya mungkin berbeda untuk aplikasi dengan status terdistribusi (misalnya, cache dalam memori di pod).
Jangan gunakan probe keaktifan untuk pod (pengecualian adalah ketika pod benar-benar diperlukan dan Anda sepenuhnya mengetahui secara spesifik serta konsekuensi penggunaannya):
- Probe keaktifan dapat membantu memulihkan container yang digantung, namun karena Anda memiliki kendali penuh atas aplikasi Anda, hal-hal seperti proses yang terhenti dan kebuntuan idealnya tidak terjadi: alternatif terbaik adalah dengan sengaja menghentikan aplikasi dan mengembalikannya ke kondisi stabil sebelumnya;
- pemeriksaan keaktifan yang gagal akan menyebabkan penampung dimulai ulang, sehingga berpotensi memperburuk efek kesalahan terkait boot: memulai ulang penampung akan mengakibatkan waktu henti (setidaknya selama durasi permulaan aplikasi, misalnya 30+ detik), menyebabkan kesalahan baru, meningkatkan beban pada kontainer lain dan meningkatkan kemungkinan kegagalannya, dll.;
- pemeriksaan keaktifan dikombinasikan dengan ketergantungan eksternal adalah kombinasi terburuk yang mungkin terjadi, mengancam kegagalan berjenjang: sedikit penundaan di sisi database akan menyebabkan semua container Anda dimulai ulang!
Parameter pemeriksaan keaktifan dan kesiapan harus berbeda:
- Anda dapat menggunakan pemeriksaan keaktifan dengan health check yang sama, namun ambang respons yang lebih tinggi (failureThreshold), misalnya, menetapkan status belum siap setelah 3 kali percobaan dan menganggap bahwa pemeriksaan keaktifan telah gagal setelah 10 kali percobaan;
Jangan gunakan pemeriksaan exec, karena terkait dengan masalah umum yang menyebabkan munculnya proses zombie:
- detailnya: lihat presentasi oleh spesialis Datadog.

Ringkasan

Gunakan pemeriksaan kesiapan untuk menentukan kapan pod siap menerima lalu lintas.
Gunakan probe keaktifan hanya jika benar-benar diperlukan.
Penggunaan probe kesiapan/keaktifan yang tidak tepat dapat menyebabkan berkurangnya ketersediaan dan kegagalan berjenjang.

Materi tambahan tentang topik

Dokumen Kubernetes: Konfigurasikan Probe Keaktifan dan Kesiapan;
Pemeriksaan Keaktifan dan Kesiapan Kubernetes Ditinjau Kembali: Cara Menghindari Menembak Diri Sendiri;
Post-Mortem Pemadaman Lab NRE (dia juga berbicara tentang livenessProbe).

Pembaruan No. 1 dari 2019-09-29

Tentang kontainer init untuk migrasi database: Catatan kaki ditambahkan.

EJ mengingatkanku tentang PDB: salah satu masalah dalam pemeriksaan keaktifan adalah kurangnya koordinasi antar pod. Kubernetes punya Anggaran Gangguan Pod (PDB) untuk membatasi jumlah kegagalan bersamaan yang dapat dialami aplikasi, namun pemeriksaan tersebut tidak memperhitungkan PDB. Idealnya, kita dapat memerintahkan K8 untuk "Memulai ulang satu pod jika pengujiannya gagal, namun jangan memulai ulang semuanya untuk menghindari hal yang lebih buruk."

Bryan mengatakannya dengan sempurna: “Gunakan penyelidikan keaktifan jika Anda tahu persis apa itu hal terbaik yang harus dilakukan adalah mematikan aplikasi tersebut(sekali lagi, jangan terbawa suasana).

Pembaruan No. 2 dari 2019-09-29

Mengenai membaca dokumentasi sebelum digunakan: Saya membuat permintaan yang sesuai (permintaan fitur) untuk menambahkan dokumentasi tentang pemeriksaan keaktifan.

Pemeriksaan keaktifan di Kubernetes bisa berbahaya