Wawancara Linux: Bagaimana Cara Kerja Sinyal dan Graceful Shutdown?

Konteks dan Pertanyaan yang Berlaku

Layanan HTTP Linux berjalan di dalam container Kubernetes. Selama rolling update, layanan ini menerima SIGTERM dengan masa tenggang 30 detik saat 200 request sedang diproses (in flight), dua worker child sedang berjalan, dan consumer background-job sedang aktif. Rancang protokol shutdown dari pengiriman sinyal hingga proses keluar (exit). Jelaskan perilaku SIGTERM dan SIGKILL, keamanan signal-handler, pengosongan (draining) traffic, penanganan job dan child-process, batas waktu (deadline), serta verifikasinya.

30 detik dan 200 request tersebut adalah input skenario wawancara. Kubernetes umumnya menggunakan masa tenggang terminasi Pod default sebesar 30 detik, tetapi nilai produksi harus berasal dari durasi request yang terukur, waktu pembersihan (cleanup), semantik beban kerja, dan kebutuhan ketersediaan. Dalam skenario ini, gunakan deadline draining internal 25 detik dan sisakan lima detik untuk pembersihan akhir dan variansi penjadwalan. Pembagian tersebut merupakan pilihan rekayasa (engineering choice), bukan jaminan platform.

Masalah utamanya adalah protokol siklus hidup proses Linux. Kubernetes dan HTTP menyediakan konteks operasinya. Jawaban yang kuat mengikuti sinyal dari kernel ke proses yang dituju, mengubahnya menjadi transisi state yang aman, mengontrol penerimaan (admission) dan pekerjaan yang sedang berjalan, serta membuktikan bahwa penghentian tetap berada dalam batas waktu.

Hal yang Dievaluasi oleh Pewawancara

Pertama, pewawancara memeriksa semantik sinyal. Suatu proses dapat menangkap (catch), memblokir (block), atau mengabaikan (ignore) SIGTERM; tindakan default-nya adalah terminasi. Setelah aplikasi menangkapnya, aplikasi tersebut pada akhirnya harus menghentikan dirinya sendiri. SIGKILL tidak dapat ditangkap, diblokir, atau diabaikan, sehingga tidak memberikan kesempatan untuk pembersihan. Sinyal standar yang berulang bukanlah antrean yang persisten: beberapa instance yang tertunda dari sinyal standar yang sama dapat bergabung menjadi satu (coalesce).

Kedua, pewawancara memeriksa apakah sinyal mencapai layanan. Dalam container, entry point berbentuk shell dapat menyebabkan /bin/sh -c menjadi PID 1 dan mencegah file yang dieksekusi menerima SIGTERM yang diharapkan. Layanan biasanya harus berupa entry point berbentuk exec, atau wrapper harus diakhiri dengan exec. Layanan yang membuat child juga harus meneruskan terminasi dan membersihkannya (reap), atau berjalan dengan init kecil yang sesuai ketika tidak dapat menjalankan tugas-tugas PID 1 itu sendiri.

Ketiga, pewawancara mencari batasan async-signal-safe. Signal handler C mentah menginterupsi eksekusi normal pada instruksi arbitrer. Memanggil printf, mengalokasikan memori, mengambil mutex, menutup grafik objek aplikasi, atau melakukan flushing library klien dapat menyebabkan deadlock atau merusak state. Handler hanya boleh mempublikasikan notifikasi minimal menggunakan operasi yang aman dari sinyal (signal-safe); jalur kontrol normal yang memiliki tanggung jawab pembersihan.

Keempat, pewawancara mengevaluasi urutan shutdown. Layanan harus beralih menjadi unready dan berhenti menerima pekerjaan baru, kemudian mengosongkan atau membatalkan pekerjaan yang telah diterima di bawah batas waktu. Layanan harus menghentikan pengambilan job tanpa kehilangan kepemilikan lease, menjaga dependensi bersama tetap terbuka hingga penggunanya selesai, menghentikan dan me-reap child, melakukan flush telemetri yang terikat waktu, dan keluar sebelum orkestrator meningkatkannya ke SIGKILL.

Terakhir, pewawancara menginginkan bukti operasional. Pengujian unit handler saja tidak dapat membuktikan tata letak PID container, penghapusan endpoint, perilaku koneksi, pengiriman ulang job, reaping child, atau kepatuhan terhadap masa tenggang. Jawaban harus mencakup pengujian tingkat container dan tingkat rollout dengan kriteria kelulusan yang dapat diamati.

Pertanyaan yang Perlu Diklarifikasi Sebelum Menjawab

• Siapa yang mengirim sinyal, dan ke PID mana? Konfirmasikan container runtime, sinyal stop yang dikonfigurasi, entry point, wrapper, dan apakah aplikasi tersebut adalah PID 1.
• Apa yang menghabiskan 30 detik tersebut? Hook preStop Kubernetes berjalan dalam masa tenggang terminasi yang sama. Durasinya mengurangi sisa waktu untuk draining aplikasi.
• Apa arti "in flight"? Pisahkan request yang telah diterima, koneksi keep-alive tanpa request, streaming response, koneksi yang di-upgrade, dan pekerjaan aplikasi yang diantrekan. Semuanya membutuhkan kebijakan penyelesaian yang berbeda.
• Dapatkah layanan segera menolak pekerjaan baru? Identifikasi readiness probe, load balancer, listener, service mesh, dan pemanggil langsung apa pun. Propagasi readiness tidak terjadi secara instan.
• Bagaimana kontrak durasi request dan percobaan ulang (retry)? Operasi read idempoten yang singkat mungkin dapat selesai; upload yang panjang atau write yang memiliki efek samping mungkin memerlukan pembatalan, handoff, atau kunci idempotensi.
• Bagaimana kepemilikan background job diatur? Klarifikasi waktu acknowledgement, visibility timeout atau lease, perilaku heartbeat, pengiriman ulang, dan idempotensi. "Menghentikan worker" tidak aman tanpa adanya kontrak ini.
• Siapa yang memiliki worker child? Tentukan apakah parent dapat memberi sinyal ke process group, apakah child memiliki protokol shutdown sendiri, dan siapa yang memanggil waitpid.
• Runtime mana yang menangani sinyal? Thread sigwait khusus, callback event-loop, dan handler C mentah memiliki batas keamanan yang berbeda. Sebutkan perilaku runtime yang sebenarnya.
• Hasil apa yang menentukan keberhasilan? Tetapkan batasan untuk penerimaan baru, pekerjaan yang selesai dan dibatalkan, efek samping duplikat, proses zombie, waktu exit, dan tingkat terminasi paksa.

Kerangka Jawaban 30 Detik

"Saya memverifikasi bahwa entry point berbentuk exec mengirimkan SIGTERM ke aplikasi. Raw handler hanya membangunkan jalur kontrol normal. Jalur tersebut menggagalkan readiness, menghentikan penerimaan request dan job, serta mengosongkan pekerjaan yang diterima hingga batas waktu internal 25 detik. Jalur ini kemudian membatalkan sisa pekerjaan dengan aman, menghentikan dan me-reap kedua child, melakukan flush final yang terikat waktu, dan keluar sebelum masa tenggang 30 detik berakhir. SIGKILL tidak dapat menjalankan pembersihan. Saya menguji container yang telah di-build di bawah beban request dan job yang bersamaan, memeriksa batas akhir penerimaan, perilaku retry, reaping child, dan waktu keluar."

Kerangka kerja ini membentuk alur kontrol. Jawaban mendalam juga harus mencakup pengiriman sinyal multithreaded, system call yang terinterupsi, permintaan shutdown berulang, dan perbedaan antara penghapusan endpoint dan penerimaan listener.

Pembahasan Mendalam Langkah demi Langkah

Mulailah dengan jalur pengiriman. Gunakan bentuk eksekusi dari ENTRYPOINT atau CMD sehingga aplikasi menerima sinyal stop dari runtime secara langsung. Jika wrapper diperlukan untuk penyiapan, akhiri dengan exec "$@". Periksa container yang sedang berjalan alih-alih hanya mempercayai Dockerfile: verifikasi PID 1, command line-nya, hubungan parent-child, dan sinyal stop yang dikonfigurasi. Uji rollout yang mengirimkan SIGTERM ke container adalah pemeriksaan yang menentukan.

Inisialisasi mekanisme wake-up sebelum memasang handler, dan pasang handler sebelum mengiklankan readiness. Sketsa bergaya C dapat menggunakan nonblocking self-pipe:

static volatile sig_atomic_t stop_requested = 0;
static int wake_fd; /* initialized as nonblocking before sigaction */

static void on_term(int signo) {
  int saved_errno = errno;
  stop_requested = 1;
  const unsigned char byte = 1;
  (void)write(wake_fd, &byte, sizeof byte);
  errno = saved_errno;
}

write bersifat async-signal-safe. Deskriptor nonblocking mencegah handler menunggu jika notifikasi telah memenuhi pipe; flag menjaga state bahkan jika penulisan wake-up tidak dapat menambahkan byte lain. Handler tidak melakukan logging, alokasi, penguncian, menunggu child, atau memanggil klien aplikasi. Event loop biasa mengosongkan pipe dan memajukan state machine shutdown yang idempoten.

Alternatif untuk layanan multithreaded adalah memblokir sinyal terminasi sebelum membuat thread worker, lalu membiarkan satu thread khusus memanggil sigwait atau menggunakan signalfd di Linux. Disposisi sinyal berlaku untuk seluruh proses, sementara setiap thread memiliki signal mask-nya sendiri. Sinyal yang diarahkan ke proses dapat dikirim ke thread mana pun yang tidak memblokirnya. Penanganan sinyal sinkron yang terpusat menghilangkan handler asinkron dari kode aplikasi, asalkan signal mask ditetapkan secara konsisten sebelum thread dimulai.

Jangan hanya mengandalkan system call yang terinterupsi untuk membangunkan layanan. Bergantung pada antarmuka dan SA_RESTART, panggilan blocking dapat dilanjutkan secara otomatis atau mengembalikan EINTR. Self-pipe, event descriptor, runtime signal channel, atau thread sinyal khusus membuat jalur wake-up yang eksplisit. Setiap penungguan blocking dalam shutdown juga harus memiliki batas waktu (deadline).

Jalankan layanan melalui tahapan state yang eksplisit:

RUNNING
  --SIGTERM--> QUIESCING
  --admission closed--> DRAINING
  --work finished or 25 s reached--> FINALIZING
  --children reaped and bounded flush complete--> EXITED

Transisi dari RUNNING harus bersifat atomik dan idempoten. SIGTERM pertama mencatat waktu mulai dan deadline. SIGTERM kedua tidak boleh memulai grafik pembersihan lain atau menutup sumber daya yang sama dua kali. Tim dapat memilih apakah ini hanya mencatat pengulangan atau mempercepat proses pengosongan, tetapi perilakunya harus didokumentasikan dan diuji.

Pada QUIESCING, buat readiness gagal dan segera hentikan penerimaan aplikasi baru. Kubernetes menandai endpoint yang sedang dihentikan sebagai unready, tetapi propagasi control-plane dan proxy membutuhkan waktu. Tutup listening socket, nonaktifkan accept, atau minta layer penerimaan mengembalikan respons yang dapat dicoba lagi untuk request yang belum melewati batas pekerjaan yang diterima. Koneksi yang sudah diterima sebelumnya dapat tetap terbuka untuk pengosongan. Tangani HTTP keep-alive secara eksplisit sehingga koneksi lama yang menganggur tidak dapat mengirimkan request baru tanpa batas setelah shutdown dimulai.

Hentikan background consumer dari pengambilan job baru pada batas yang sama. Untuk job yang sudah di-lease, lanjutkan hanya jika dapat selesai dengan aman sebelum deadline. Jika tidak, hentikan heartbeat atau lepaskan/nack lease tersebut menggunakan kontrak antrean sehingga worker lain dapat mencoba lagi. Acknowledgement harus dilakukan setelah penyelesaian yang persisten (durable). Efek samping memerlukan kunci idempotensi atau transisi state transaksional karena terminasi paksa dapat terjadi setelah operasi penulisan eksternal dan sebelum acknowledgement.

Pada DRAINING, lacak pekerjaan yang diterima dengan penghitung atau registri. Izinkan request selesai sementara dependensinya tetap tersedia. Jangan menutup database pool, cache client, atau telemetry exporter saat request handler masih menggunakannya. Pada batas waktu internal 25 detik, batalkan pekerjaan yang tersisa sesuai dengan protokol: hentikan streaming, teruskan pembatalan, kembalikan respons yang ditentukan jika memungkinkan, dan pertahankan state yang konsisten untuk dicoba lagi. Sisakan lima detik sisanya untuk callback pembatalan, reaping child, penulisan state akhir, dan variansi penjadwalan runtime.

Untuk kedua worker child, hentikan inputnya terlebih dahulu, kirimkan sinyal terminasi yang telah disepakati, dan tunggu dengan batas waktu. Jika parent memiliki process group khusus, ia dapat memberi sinyal ke grup tersebut sambil menghindari proses yang tidak terkait. Reap setiap child yang telah keluar dengan waitpid sehingga tidak ada zombie yang tersisa. Init kecil dapat menyediakan penerusan sinyal dan reaping untuk container yang aplikasinya tidak dapat melakukannya, tetapi ini tidak menentukan semantik job atau request aplikasi.

Pada FINALIZING, kirimkan metrik shutdown akhir dan lakukan flush log atau trace dalam anggaran waktu yang ketat. Observabilitas membantu menjelaskan penghentian paksa, namun backend telemetri yang tidak tersedia tidak boleh menghabiskan seluruh masa tenggang. Tutup sumber daya yang tersisa berdasarkan urutan dependensi dan kembalikan status keluar nol untuk graceful shutdown yang selesai. Jika proses melebihi batas waktu platform, Kubernetes pada akhirnya meminta runtime untuk mengirim SIGKILL; tidak ada handler, deferred block, atau hook shutdown yang berjalan setelah titik tersebut.

Gunakan sinyal sebagai notifikasi kontrol, bukan pesan kerja. Sinyal standar dapat bergabung menjadi satu (coalesce), berisi payload yang sangat sedikit, dan dapat tiba di lokasi kode yang tidak terduga. Tempatkan pekerjaan, percobaan ulang (retry), dan kepemilikan yang persisten di dalam antrean atau penyimpanan state. Sinyal hanya memulai atau meningkatkan transisi siklus hidup lokal.

Verifikasi harus menguji batasan yang sama dengan yang digunakan dalam produksi:

1. Build image yang sebenarnya, periksa PID 1, mulai layanan, dan kirimkan SIGTERM ke container daripada memanggil endpoint shutdown internal.
2. Tahan 200 request dengan durasi campuran, termasuk pekerjaan yang selesai dalam 25 detik dan pekerjaan yang harus dibatalkan. Pastikan bahwa tidak ada request yang baru diterima setelah batas cut-off dan setiap request yang diterima memiliki hasil akhir yang tercatat.
3. Konfirmasikan readiness menjadi false dan Pod lama tidak menerima traffic rollout baru setelah propagasi endpoint. Uji juga koneksi langsung sehingga penerimaan listener diverifikasi secara independen.
4. Jalankan background job yang berstatus lease selama terminasi berlangsung. Verifikasi bahwa pekerjaan yang selesai diakui (acknowledged) satu kali, pekerjaan yang belum selesai memenuhi syarat untuk dicoba lagi, dan pengiriman duplikat tidak dapat menduplikasi efek bisnis.
5. Verifikasi bahwa kedua worker child menerima terminasi, keluar sesuai batas waktunya, dan di-reap. Periksa tabel proses untuk memastikan tidak ada zombie.
6. Kirimkan SIGTERM kedua dan buktikan bahwa pembersihan tetap idempoten. Secara terpisah kirimkan SIGKILL untuk membuktikan bahwa tidak ada asumsi pembersihan dan kontrak pemulihan tetap melindungi pekerjaan yang persisten.
7. Catat shutdown_started, state penerimaan, jumlah in-flight, pelanggaran deadline drain, status child, waktu exit, dan terminasi paksa. Gagalkan pengujian jika graceful exit mencapai 30 detik.

Contoh Jawaban Berkualitas Tinggi

"Saya akan mulai dari batas container. Saya akan menggunakan entry point berbentuk exec dan memeriksa image saat runtime untuk memverifikasi bahwa layanan HTTP adalah PID 1 atau berada di belakang init yang meneruskan sinyal. Shell wrapper akan diakhiri dengan exec, sehingga SIGTERM tidak berhenti di shell.

Sebelum readiness menjadi true, layanan akan memasang jalur sinyalnya. Dalam handler C mentah, saya hanya akan menyetel flag sig_atomic_t dan menulis ke nonblocking self-pipe. Logging, mutex, alokasi memori, panggilan database, dan penungguan child dijauhkan dari handler tersebut. Dalam implementasi multithreaded, saya lebih memilih memblokir sinyal terminasi sebelum membuat worker dan menerimanya dari satu thread sigwait. Kedua desain tersebut membangunkan loop kontrol normal secara eksplisit alih-alih bergantung pada EINTR.

SIGTERM pertama secara atomik memindahkan layanan dari kondisi running ke quiescing dan menetapkan batas waktu internal 25 detik kemudian. Layanan segera menggagalkan readiness, menutup atau menonaktifkan penerimaan baru, mencegah koneksi keep-alive memulai lebih banyak request, dan berhenti mengambil background job. Menghapus status readiness dan menutup penerimaan keduanya diperlukan karena propagasi endpoint bersifat asinkron.

200 request yang telah diterima dapat dilanjutkan sementara database dan cache client mereka tetap terbuka. Saya melacaknya secara langsung. Request yang selesai sebelum 25 detik kembali secara normal. Pada batas waktu internal, saya membatalkan sisanya melalui protokol aplikasi dan mempertahankan state yang dapat dicoba lagi. Untuk job consumer, saya hanya mengakui (acknowledge) penyelesaian yang persisten; pekerjaan berstatus lease yang belum selesai dilepaskan atau dibiarkan kedaluwarsa sesuai dengan kontrak antrean, dan efek sampingnya menggunakan kunci idempotensi.

Saya kemudian menghentikan kedua worker child melalui jalur sinyal yang ditentukan dan me-reap mereka dengan batas waktu tunggu. Hanya setelah request dan pengguna child selesai, saya menutup shared client. Log dan trace mendapatkan alokasi waktu flush yang kecil dan terbatas. Jalur yang berhasil akan keluar dengan status nol sebelum 30 detik. Jika batas waktu tersebut terlewati, SIGKILL dapat menghentikan proses dan tidak ada kode pembersihan yang akan berjalan, sehingga kebenaran yang persisten tidak dapat bergantung pada hook final.

Untuk verifikasi, saya menjalankan container yang telah di-build dengan 200 request bersamaan berdurasi campuran dan job berstatus lease yang aktif, lalu mengirimkannya SIGTERM. Saya memastikan proses sebenarnya menerima sinyal, readiness berubah, tidak ada pekerjaan baru yang melewati batas penerimaan, pekerjaan yang diterima selesai atau dibatalkan secara eksplisit sebelum 25 detik, job yang belum selesai dapat dicoba lagi tanpa efek duplikat, kedua child di-reap, dan proses keluar sebelum 30 detik. Saya juga menguji pengulangan SIGTERM untuk idempotensi dan SIGKILL untuk perilaku pemulihan. Dashboard rollout harus menampilkan durasi shutdown, pekerjaan in-flight, pelanggaran batas waktu, dan exit paksa."

Kesalahan Umum

• Melakukan pembersihan di dalam raw handler → Sinyal dapat menginterupsi kode saat lock library atau state allocator sedang aktif → Publikasikan notifikasi minimal yang aman dari sinyal dan lakukan pembersihan pada jalur kontrol normal.
• Mengasumsikan aplikasi menerima SIGTERM → Entry point berbentuk shell dapat mempertahankan shell sebagai PID 1 → Gunakan bentuk exec atau wrapper yang diakhiri dengan exec, lalu uji container yang telah di-build.
• Menganggap kegagalan readiness sebagai penutupan penerimaan → Pembaruan endpoint membutuhkan waktu dan koneksi langsung atau koneksi yang ada mungkin masih mengirimkan pekerjaan → Gagalkan readiness dan berlakukan penghentian listener/penerimaan aplikasi.
• Menutup shared client terlebih dahulu → Handler in-flight dapat gagal setelah penerimaan meskipun mereka punya waktu untuk selesai → Kosongkan (drain) pengguna sebelum menutup sumber daya yang mereka butuhkan.
• Menghentikan job consumer tanpa memeriksa lease → Pekerjaan dapat tetap tidak terlihat, diakui terlalu cepat, atau mengulang efek samping → Ikuti kontrak acknowledgement, lease, retry, dan idempotensi secara eksplisit.
• Menunggu selamanya untuk proses drain yang sempurna → Orkestrator pada akhirnya akan mengirim SIGKILL dan menghilangkan semua kesempatan pembersihan → Gunakan batas waktu internal dengan waktu yang disisihkan untuk finalisasi.
• Melupakan kepemilikan child → Child dapat hidup lebih lama dari parent secara singkat atau menjadi zombie saat tidak di-reap → Teruskan terminasi secara sengaja dan gunakan loop waitpid yang terikat batas waktu.
• Memulai pembersihan dua kali pada sinyal berulang → Operasi penutupan dan flush duplikat dapat saling beradu (race condition) atau mengalami crash → Jadikan transisi state bersifat atomik dan pembersihan bersifat idempoten.
• Menggunakan sinyal standar sebagai antrean perintah → Sinyal standar tertunda yang identik dapat bergabung menjadi satu (coalesce) dan tidak membawa kepemilikan yang persisten → Simpan pekerjaan dan percobaan ulang dalam antrean; gunakan sinyal hanya untuk kontrol siklus hidup.
• Hanya menguji metode shutdown internal → Tindakan ini mengabaikan tata letak PID, pengiriman sinyal runtime, dan perilaku orkestrasi → Kirimkan sinyal nyata ke image produksi di bawah beban kerja bersamaan yang realistis.

Pertanyaan Lanjutan dan Tanggapannya

Lanjutan 1: Mengapa signal handler tidak dapat memanggil fungsi shutdown normal?

Handler dapat menginterupsi program saat thread lain atau thread yang terinterupsi sedang memegang lock allocator, stdio, logging, atau aplikasi. Sebagian besar fungsi pembersihan aplikasi tidak bersifat async-signal-safe. Memanggilnya dapat menyebabkan deadlock atau merusak state internal. Handler harus menyetel flag dan menggunakan operasi wake-up yang aman dari sinyal; event loop atau thread sinyal khusus akan memanggil kode shutdown normal setelahnya.

Lanjutan 2: Bagaimana perilaku sinyal dalam proses multithreaded?

Disposisi sinyal digunakan bersama oleh proses, tetapi setiap thread memiliki signal mask-nya sendiri. Sinyal yang diarahkan ke proses dapat dikirim ke thread mana pun yang memenuhi syarat dan tidak memblokirnya. Salah satu pola yang kuat adalah memblokir sinyal terminasi sebelum worker dibuat dan membiarkan satu thread menerimanya secara sinkron dengan sigwait atau signalfd. Pola lainnya menggunakan handler minimal untuk seluruh proses yang hanya mengirimkan notifikasi aman. Mask yang bercampur dan tidak konsisten membuat perilaku proses lebih sulit untuk dipahami.

Lanjutan 3: Apa perbedaan praktis antara SIGTERM dan SIGKILL di sini?

SIGTERM meminta terminasi dan memberikan aplikasi kesempatan untuk menjalankan protokolnya karena sinyal ini dapat ditangkap. Tindakan default-nya tetap menghentikan proses. SIGKILL adalah terminasi yang dipaksakan oleh kernel: sinyal ini tidak dapat ditangkap, diblokir, atau diabaikan, dan tidak ada pembersihan yang berjalan. Masa tenggang hanya berharga jika jalur SIGTERM dapat dijangkau, aman, dan memiliki batas waktu yang jelas.

Lanjutan 4: Mengapa harus menggagalkan readiness dan juga menutup penerimaan?

Perubahan readiness memberi tahu Kubernetes dan proxynya untuk menghentikan perutean, tetapi pembaruan endpoint dan pengosongan koneksi bersifat asinkron. Koneksi keep-alive yang ada atau koneksi langsung mungkin masih dapat mencapai proses. Cut-off aplikasi menentukan titik pasti setelah pekerjaan baru tidak dapat masuk lagi, sementara readiness menghapus Pod dari perutean normal. Verifikasi harus mengamati kedua layer tersebut.

Lanjutan 5: Apa yang harus terjadi pada job yang baru selesai setengahnya?

Gunakan kontrak kepemilikan job tersebut. Lanjutkan hanya jika pekerjaan dapat selesai dengan aman sebelum batas waktu internal. Jika tidak, hentikan atau lepaskan lease-nya sehingga dapat dicoba lagi, dan hindari mengakuinya (acknowledge) sebelum penyelesaian yang persisten. Efek samping eksternal memerlukan kunci idempotensi atau transisi state transaksional karena terminasi dapat terjadi di antara efek samping dan acknowledgement.

Lanjutan 6: Apa yang berubah ketika hook preStop ada?

Hook tersebut menghabiskan masa tenggang terminasi Pod yang sama. Ukur durasi terburuknya dan kurangkan dari alokasi waktu aplikasi. Jaga agar hook tetap terikat batas waktu dan hindari menduplikasi pembersihan aplikasi dalam dua jalur yang saling bersaing. Aplikasi harus tetap menangani SIGTERM, karena hook dapat gagal dan proses dapat menerima sinyal di luar rollout normal.

Lanjutan 7: Bagaimana Anda akan menyelidiki terminasi paksa di lingkungan produksi?

Korelasikan alasan terminasi Pod dan timestamp-nya dengan waktu mulai shutdown aplikasi, jumlah in-flight, lease job, status child, dan state shutdown terakhir yang selesai. Bedakan antara pengiriman sinyal yang hilang dengan proses pengosongan yang lambat, child yang macet, atau flush akhir yang terblokir. Lacak durasi graceful shutdown dan tingkat penghentian paksa berdasarkan versi sehingga regresi dapat terdeteksi selama canary rollout.