Masalah dan konteks
Kubernetes v1.35 memperkenalkan restartPolicyRules untuk kontainer ketika aksi RestartAllContainers diaktifkan. Aturan ini dapat memetakan exit code ke aksi restart, sementara Pod tetap memiliki kontrak siklus hidup dan readiness. Perlakukan fitur ini sebagai klasifikasi kegagalan, bukan sebagai pengganti probe atau alerting.
Asumsikan sebuah Pod worker memiliki tiga kontainer dengan domain kegagalan yang berbeda. fetcher dapat pulih dari kegagalan refresh kredensial yang bersifat sementara; kesalahan konfigurasi proxy harus mengirimkan panggilan (page) ke operator; reporter mungkin memerlukan seluruh Pod di-restart ketika state lokalnya rusak.
Apa yang dievaluasi oleh pewawancara
Pewawancara mencari taksonomi kegagalan yang presisi, pemahaman tentang prasyarat feature-gate dan versi, serta rencana yang mencegah restart loop menutupi insiden. Jawaban yang kuat menghubungkan exit code dengan kepemilikan (ownership), readiness, backoff, metrik, dan keamanan rollout.
Jawaban biasa menambahkan restartPolicyRules ke setiap kontainer. Jawaban yang kuat menjelaskan kode mana yang merupakan semantik API yang stabil, mana yang merupakan detail proses yang tidak disengaja, dan bagaimana membuktikan bahwa restart aman untuk state masing-masing kontainer.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Versi Kubernetes dan feature gate mana yang dijamin di setiap kluster?
- Apakah exit code dikendalikan oleh kontrak aplikasi atau dihasilkan oleh runtime dan shell wrapper?
- Apakah state kontainer bersifat sekali pakai (disposable), memiliki checkpoint, atau terikat dengan kontainer lain di dalam Pod?
- Apa yang harus terjadi jika kode yang sama berulang: backoff, penggantian Pod, atau eskalasi?
- Sinyal mana yang mendefinisikan kesiapan (readiness) pengguna saat salah satu kontainer sedang me-restart?
Jika kode bukan bagian dari kontrak aplikasi yang telah diuji, prioritaskan kebijakan restart yang seragam dan perbaiki kontrak proses terlebih dahulu. Jika state terikat, me-restart satu kontainer dapat menciptakan interaksi split-brain dengan kontainer lainnya.
Jawaban 30 detik
“Pertama-tama saya akan memverifikasi versi Kubernetes dan feature gate, lalu mendefinisikan semantik exit-code dalam kontrak setiap kontainer. Saya hanya akan me-restart kegagalan stateless yang bersifat sementara; membiarkan kegagalan konfigurasi permanen terlihat; dan menggunakan penggantian Pod untuk state bersama yang rusak. Saya akan menginstrumentasi kecocokan aturan, jumlah restart, backoff, readiness, serta peringatan kode berulang, melakukan canary pada kebijakan tersebut, dan melakukan rollback jika tingkat kesalahan atau restart loop meningkat.”
Desain langkah demi langkah
- Periksa prasyarat. Konfirmasikan perilaku v1.35,
RestartAllContainers, kebijakan admisi, dan apakah pengontrol serta tumpukan observabilitas kluster memahami field-field baru. - Definisikan kepemilikan exit-code. Cadangkan sebagian kecil set yang terdokumentasi seperti refresh sementara, konfigurasi permanen, dan state yang tidak dapat dipulihkan. Uji wrapper agar sinyal tidak dipetakan ulang secara tidak sengaja.
- Petakan aksi aman terkecil. Restart fetcher yang stateless untuk kode sementara. Jangan me-restart proxy untuk konfigurasi yang buruk; tampilkan sebagai NotReady dan beri peringatan. Ganti Pod ketika state bersama tidak valid.
- Lindungi dependensi. Kendalikan readiness berdasarkan kontrak dependensi, koordinasikan shutdown hook, dan hindari menerima lalu lintas saat kontainer yang di-restart belum memiliki state yang siap (warmed state).
- Kendalikan pengulangan. Gabungkan jumlah restart, exponential backoff, dan peringatan kode berulang. Aturan yang terus-menerus me-restart pada akhirnya harus menjadi kegagalan yang terlihat oleh operator.
- Lakukan rollout secara bertahap. Uji canary pada satu workload, bandingkan tingkat restart-loop, waktu pemulihan, tingkat kesalahan, dan perputaran (churn) Pod dengan kebijakan sebelumnya, lalu perluas hanya jika guardrail tetap terjaga.
Alternatifnya mencakup supervisor di dalam satu kontainer, Deployment terpisah untuk domain kegagalan independen, atau controller yang menggantikan Pod. Pilih batas paling sederhana yang menjaga state dan membuat kegagalan terlihat.
Contoh jawaban
“Untuk fetcher, exit code 42 berarti kegagalan refresh kredensial yang berumur pendek dan aman untuk di-restart karena tidak memiliki state lokal yang persisten. Kesalahan konfigurasi tetap berada dalam status NotReady dan memberi peringatan kepada pemiliknya; me-restart-nya hanya akan mengulangi kegagalan yang sama. Jika reporter mendeteksi checkpoint lokal yang rusak, saya akan menghentikan Pod agar volume yang bersih atau penggantian dapat pulih secara konsisten. Saya akan merilis aturan di balik feature gate ke satu canary, memberi peringatan pada pencocokan berulang dan restart loop, serta menghapus kebijakan jika waktu pemulihan atau tingkat kesalahan mengalami kemunduran.”
Kesalahan umum
- Kesalahan: Memperlakukan setiap exit non-nol sebagai sementara → Alasan gagal: kesalahan permanen menjadi restart loop yang hening → Solusi: definisikan semantik exit-code yang teruji.
- Kesalahan: Mengabaikan feature-gate dan perbedaan versi (skew) kluster → Alasan gagal: manifes berperilaku berbeda di berbagai lingkungan → Solusi: tambahkan pemeriksaan admisi dan rollout.
- Kesalahan: Me-restart satu kontainer yang memiliki state terikat → Alasan gagal: kontainer lain mempertahankan state yang tidak kompatibel → Solusi: ganti Pod atau koordinasikan pemulihan.
- Kesalahan: Hanya memantau restart kontainer → Alasan gagal: pengguna mungkin masih melihat kesalahan sementara restart terlihat normal → Solusi: pasangkan metrik restart dengan readiness dan SLO layanan.
Pertanyaan lanjutan dan respons
Bagaimana jika exit code 42 dihasilkan oleh shell wrapper dan berubah setelah pembaruan image?
Perlakukan kode tersebut sebagai API. Kunci versi (pin) dan uji wrapper, dokumentasikan kepemilikan, dan gagalkan rollout ketika kontrak berubah. Jangan mewarisi kode spesifik runtime secara diam-diam.
Bagaimana Anda mencegah restart loop menyembunyikan pemadaman?
Beri peringatan pada kecocokan aturan yang berulang, tingkat restart, saturasi backoff, dan hilangnya readiness. Setelah sejumlah upaya yang dibatasi, eskalasikan ke penggantian Pod atau kegagalan yang terlihat oleh operator.
Kapan me-restart seluruh Pod lebih aman?
Gunakan penggantian Pod ketika state digunakan bersama, urutan inisialisasi penting, atau kerusakan pada satu kontainer dapat membatalkan kontainer lainnya. Restart yang lebih menyeluruh lebih disukai daripada pemulihan parsial yang tidak konsisten.
Bagaimana Anda melakukan rollback fitur ini?
Nonaktifkan kebijakan pada template workload, pulihkan perilaku restart sebelumnya, dan verifikasi bahwa replika lama telah konvergen. Pertahankan kontrak exit-code dan dasbor agar rollback tetap dapat diobservasi.