Masalah dan konteks
Kubernetes v1.35 memperkenalkan restartPolicyRules untuk kontena apabila tindakan RestartAllContainers didayakan. Peraturan ini boleh memetakan kod keluar (exit code) kepada tindakan mula semula, manakala Pod masih mempunyai kontrak kitaran hayat dan readiness. Anggap ciri ini sebagai klasifikasi kegagalan, bukan sebagai pengganti probe atau amaran.
Andaikan Pod worker mempunyai tiga kontena dengan domain kegagalan yang berbeza. fetcher mungkin pulih daripada kegagalan penyegaran kelayakan yang bersifat sementara; ralat konfigurasi proxy sepatutnya memanggil (page) pengendali; reporter mungkin memerlukan keseluruhan Pod dimulakan semula apabila keadaan setempatnya rosak.
Perkara yang dinilai oleh penemu duga
Penemu duga mencari taksonomi kegagalan yang tepat, kesedaran tentang prasyarat feature-gate dan versi, serta rancangan yang menghalang gelung mula semula (restart loops) daripada menutup insiden. Jawapan yang mantap menghubungkan kod keluar dengan pemilikan (ownership), readiness, backoff, metrik, dan keselamatan pelancaran.
Jawapan biasa hanya menambah restartPolicyRules pada setiap kontena. Jawapan yang mantap menerangkan kod mana yang merupakan semantik API yang stabil, mana yang merupakan perincian proses sampingan, dan cara membuktikan bahawa mula semula adalah selamat untuk keadaan setiap kontena.
Soalan untuk dijelaskan terlebih dahulu
- Versi Kubernetes dan feature gate yang manakah dijamin dalam setiap kluster?
- Adakah kod keluar dikawal oleh kontrak aplikasi atau dikeluarkan oleh runtime dan pembungkus shell (shell wrapper)?
- Adakah keadaan kontena boleh guna buang (disposable), mempunyai titik semak (checkpointed), atau digandingkan dengan kontena lain dalam Pod?
- Apakah yang sepatutnya berlaku apabila kod yang sama berulang: backoff, penggantian Pod, atau eskalasi?
- Isyarat manakah yang mentakrifkan readiness pengguna semasa satu kontena sedang dimulakan semula?
Jika kod bukan sebahagian daripada kontrak aplikasi yang telah diuji, utamakan dasar mula semula yang seragam dan perbaiki kontrak proses terlebih dahulu. Jika keadaan digandingkan, memulakan semula satu kontena boleh mewujudkan interaksi split-brain dengan rakan sekerjanya.
Jawapan 30 saat
"Saya akan mengesahkan versi Kubernetes dan feature gate terlebih dahulu, kemudian mentakrifkan semantik kod keluar dalam kontrak setiap kontena. Saya hanya akan memulakan semula kegagalan sementara tanpa keadaan (stateless); membiarkan kegagalan konfigurasi kekal kelihatan; dan menggunakan penggantian Pod untuk keadaan kongsi yang rosak. Saya akan memasang instrumen pada padanan peraturan, kiraan mula semula, backoff, readiness, dan amaran kod berulang, menguji dasar secara canary, dan mengembalikannya (rollback) jika kadar ralat atau gelung mula semula meningkat."
Reka bentuk langkah demi langkah
- Semak prasyarat. Sahkan tingkah laku v1.35,
RestartAllContainers, dasar kemasukan (admission policy), dan sama ada pengawal serta tindanan kebolehcerapan kluster memahami medan baharu tersebut. - Takrifkan pemilikan kod keluar. Peruntukkan set kecil yang didokumenkan seperti penyegaran sementara, konfigurasi kekal, dan keadaan yang tidak boleh dipulihkan. Uji pembungkus supaya isyarat tidak dipetakan semula secara tidak sengaja.
- Petakan tindakan selamat terkecil. Mulakan semula fetcher tanpa keadaan untuk kod sementara. Jangan mulakan semula proxy untuk konfigurasi yang salah; paparkannya sebagai NotReady dan berikan amaran. Gantikan Pod apabila keadaan kongsi tidak sah.
- Lindungi kebergantungan. Kawal readiness berdasarkan kontrak kebergantungan, selaraskan cangkuk penutupan (shutdown hooks), dan elakkan daripada menerima trafik semasa kontena yang dimulakan semula belum mempunyai keadaan yang sedia (warmed state).
- Kawal pengulangan. Gabungkan kiraan mula semula, backoff eksponen, dan amaran kod berulang. Peraturan yang terus memulakan semula akhirnya mesti menjadi kegagalan yang dapat dilihat oleh pengendali.
- Lancar secara beransur-ansur. Lakukan canary pada satu beban kerja, bandingkan kadar gelung mula semula, masa pemulihan, kadar ralat, dan pergolakan (churn) Pod dengan dasar sebelumnya, kemudian kembangkan hanya apabila kawalan keselamatan kekal kukuh.
Alternatif termasuk penyelia di dalam satu kontena, Deployment berasingan untuk domain kegagalan bebas, atau pengawal yang menggantikan Pod. Pilih sempadan paling mudah yang memelihara keadaan dan menjadikan kegagalan kelihatan.
Contoh jawapan
"Bagi fetcher, kod keluar 42 bermaksud kegagalan penyegaran kelayakan jangka pendek dan selamat untuk dimulakan semula kerana ia tidak mempunyai keadaan setempat yang kekal. Ralat konfigurasi kekal sebagai NotReady dan memberi amaran kepada pemilik; memulakannya semula hanya akan mengulangi kegagalan yang sama. Jika reporter mengesan titik semak setempat yang rosak, saya akan menamatkan Pod supaya volum yang bersih atau penggantian boleh pulih secara konsisten. Saya akan menghantar peraturan di sebalik feature gate ke satu canary, memberi amaran tentang padanan berulang dan gelung mula semula, serta membuang dasar tersebut jika masa pemulihan atau kadar ralat merosot."
Kesilapan lazim
- Kesilapan: Menganggap setiap keluar bukan sifar sebagai sementara → Sebab ia gagal: kerosakan kekal menjadi gelung mula semula yang senyap → Penyelesaian: takrifkan semantik kod keluar yang diuji.
- Kesilapan: Mengabaikan feature-gate dan perbezaan versi kluster (skew) → Sebab ia gagal: manifes berkelakuan berbeza merentasi persekitaran → Penyelesaian: tambah semakan kemasukan dan pelancaran.
- Kesilapan: Memulakan semula satu kontena dengan keadaan berganding → Sebab ia gagal: kontena rakan mengekalkan keadaan yang tidak serasi → Penyelesaian: gantikan Pod atau selaraskan pemulihan.
- Kesilapan: Hanya memantau mula semula kontena → Sebab ia gagal: pengguna mungkin masih melihat ralat semasa mula semula kelihatan sihat → Penyelesaian: gandingkan metrik mula semula dengan readiness dan SLO perkhidmatan.
Soalan susulan dan respons
Bagaimana jika kod keluar 42 dikeluarkan oleh pembungkus shell dan berubah selepas kemas kini imej?
Anggap kod tersebut sebagai API. Tetapkan versi (pin) dan uji pembungkus, dokumentasikan pemilikan, dan gagalkan pelancaran apabila kontrak berubah. Jangan mewarisi kod khusus runtime secara senyap.
Bagaimanakah anda menghalang gelung mula semula daripada menyembunyikan gangguan?
Beri amaran tentang padanan peraturan berulang, kadar mula semula, ketepuan backoff, dan kehilangan readiness. Selepas bilangan percubaan yang terhad, eskalasikan kepada penggantian Pod atau kegagalan yang dapat dilihat oleh pengendali.
Bilakah memulakan semula keseluruhan Pod lebih selamat?
Gunakan penggantian Pod apabila keadaan dikongsi, susunan permulaan penting, atau kerosakan satu kontena boleh membatalkan rakan sekerjanya. Mula semula yang lebih meluas adalah lebih baik daripada pemulihan separa yang tidak konsisten.
Bagaimanakah anda akan mengembalikan (rollback) ciri tersebut?
Nyahdayakan dasar pada templat beban kerja, pulihkan tingkah laku mula semula sebelumnya, dan sahkan bahawa replika lama menumpu (converge). Kekalkan kontrak kod keluar dan papan pemuka supaya tindakan rollback kekal boleh dicerap.