Temuduga backend: mereka bentuk penutupan anggun (graceful shutdown) dan penyaliran sambungan (connection draining) Kubernetes

Gesaan dan skop

Perkhidmatan HTTP berjalan dalam Deployment. Selepas Pod dipadamkan, sesetengah permintaan masih sampai ke contoh lama, manakala pengundian panjang (long polling) dan kerja latar belakang terganggu. Terangkan garis masa penamatan merentasi Kubernetes, Service, pengimbang beban (load balancers), dan proses, kemudian reka bentuk draining, pembatalan, percubaan semula (retries), dan pengesahan. Kemahiran teras ialah mengehadkan sambungan dan kesan sampingan semasa penutupan, jadi ini tergolong dalam backend.

Perkara yang dinilai oleh penemuduga

Jawapan yang kukuh memisahkan pemadaman Pod, kemas kini EndpointSlice, perambatan pengimbang beban, preStop, SIGTERM, dan SIGKILL. Menerima SIGTERM tidak bermakna trafik telah berhenti. Rangkumi sambungan jangka panjang, kerja giliran (queue jobs), percubaan semula idempoten, kehilangan kuasa nod yang tidak dijangka, dan tempoh tangguh yang tidak mencukupi.

Soalan untuk dijelaskan terlebih dahulu

• Adakah perkhidmatan ini jenis permintaan pendek, SSE, WebSocket, atau long polling? Bolehkah sambungan berhijrah?
• Apakah yang diperiksa oleh probe readiness, liveness, dan startup, dan adakah aplikasi mendedahkan status drain?
• Adakah preStop suatu sleep, cangkuk HTTP, atau titik akhir drain aplikasi? Siapa yang melakukan keluar akhir?
• Adakah Pod menjalankan pekerja (workers), dan bagaimanakah pajakan (leases) dan penghantaran pendua dikendalikan?
• Apakah kelewatan perambatan bagi pengimbang beban ingress, service mesh, dan LB awan?

Rangka kerja jawapan 30 saat

“Mula-mula tandakan aplikasi sebagai not-ready dan berhenti menerima kerja baharu, kemudian tunggu perambatan titik akhir dan pengimbang beban. Masuk ke fasa draining: selesaikan permintaan pendek, tutup atau hijrahkan sambungan jangka panjang, dan hentikan pekerja daripada menuntut kerja baharu sambil melepaskan pajakan yang tidak dapat mereka selesaikan. preStop hanyalah tetingkap penyelarasan; SIGTERM melakukan pembersihan. Tempoh tangguh mesti meliputi perambatan p99, draining, dan pembersihan, dengan SIGKILL hanya selepas ia tamat tempoh. Uji pelepasan dengan metrik sambungan dan kerja untuk membuktikan tiada permintaan yang hilang atau kesan pendua.”

Penyelesaian langkah demi langkah

Lukis garis masa: pengawal memadamkan Pod, kubelet memulakan penamatan, EndpointSlice dan pengimbang beban mengalih keluar titik akhir secara tak segerak (asynchronous), dan bekas boleh menjalankan preStop sebelum SIGTERM. Oleh kerana perambatan adalah tak segerak, aplikasi mesti menolak kerja baharu sebaik sahaja ia mengetahui ia sedang draining, walaupun trafik masih tiba di alamat lama.

Kekalkan keadaan ready dan draining yang berasingan. Laluan penutupan menetapkan draining, menggagalkan readiness, dan berhenti menerima sambungan baharu atau mengembalikan respons yang boleh dicuba semula. Permintaan pendek sedia ada diselesaikan. SSE, WebSocket, dan long polling harus menerima isyarat tutup, kursor, atau token sambung semula supaya klien boleh menyambung semula dengan selamat.

preStop sleep tidak boleh menggantikan logik aplikasi. Ia hanya membeli masa perambatan dan menggunakan tempoh tangguh. Utamakan titik akhir drain aplikasi yang merekodkan masa mula dan baki belanjawan; pengendali SIGTERM menghentikan kerja baharu, menutup pendengar, menunggu permintaan aktif, dan melepaskan kolam sambungan.

Reka bentuk penyaliran pekerja secara berasingan daripada penyaliran HTTP. Berhenti menuntut mesej baharu. Lindungi kerja aktif dengan pajakan atau tamat masa keterlihatan (visibility timeout), dan lepaskannya apabila baki belanjawan tidak mencukupi supaya pekerja lain boleh mencuba semula. Penulisan kerja dan kesan luaran memerlukan kunci keidempotennan; Pod yang dimatikan tidak boleh mengenakan bayaran atau menghantar dua kali.

Pilih terminationGracePeriodSeconds daripada nilai p99 yang diukur: perambatan ingress, permintaan paling lama dibenarkan, penutupan sambungan, pembersihan pekerja, dan pembilasan log (log flushing), ditambah margin jitter. Sebaik sahaja tarikh akhir tamat tempoh, kubelet boleh memaksa penamatan; permintaan yang belum selesai dan keadaan dalam proses tidak boleh bergantung pada pelaksanaan finally.

Penyelenggaraan nod berbeza daripada pemadaman Pod. Penutupan nod secara anggun (graceful node shutdown) Kubernetes memberikan kubelet dan Pod tetingkap yang dirancang, tetapi kehilangan kuasa, panik kernel, dan permulaan semula hos secara paksa tidak memberikannya. Kerja-kerja kritikal memerlukan titik pemeriksaan tahan lama, berbilang replika, dan pemulihan berasaskan giliran.

Sahkan pelepasan bergolek, pemadaman manual, pembuangan nod (node drain), perambatan LB yang perlahan, sambungan lama, dan tamat masa selepas SIGTERM. Periksa 5xx, pemutusan sambungan, kadar penyiapan, penolakan draining, percubaan semula kerja, kesan pendua, kelewatan penyingkiran titik akhir, dan pembunuhan Pod secara paksa, semuanya dikaitkan dengan versi pelepasan.

Model jawapan berkualiti tinggi

“Saya tidak akan menganggap preStop: sleep 30 sebagai penutupan anggun. Apabila menerima isyarat penutupan, aplikasi menandakan dirinya sebagai draining, menggagalkan readiness, dan berhenti menerima kerja baharu. Kemas kini titik akhir dan LB merambat secara tak segerak, jadi contoh lama masih menolak permintaan baharu. Permintaan pendek selesai; sambungan SSE dan WebSocket menerima token penutupan atau penyambungan semula; pekerja berhenti menuntut kerja dan melepaskan pajakan yang tidak dapat mereka selesaikan.

preStop hanya membeli masa perambatan. Pengendali SIGTERM menutup pendengar, menunggu permintaan aktif, melepaskan kolam, dan keluar sebelum satu tarikh akhir. Saya menentukan saiz tempoh tangguh daripada perambatan p99 yang diukur, permintaan paling lama, pembersihan pekerja, dan pembilasan log. Ujian meliputi pelepasan bergolek, pembuangan nod, sambungan lama, ranap, dan pembunuhan paksa, memastikan tiada permintaan yang hilang, kesan pendua, atau kerja yang tidak dipulihkan.”

Kesilapan biasa

• Hanya menunggu SIGTERM → trafik yang dirambatkan masih sampai ke Pod lama → gagalkan readiness dan masuki draining terlebih dahulu.
• Menggunakan sleep tetap dan bukannya draining → perubahan perambatan atau tempoh permintaan merosakkannya → pacu logik daripada baki tarikh akhir.
• Hentikan Pod tetapi terus menuntut kerja giliran → pembunuhan paksa menduplikasi kerja → berhenti menuntut dan lepaskan pajakan.
• Anggap sambungan lama seperti permintaan biasa → klien tidak boleh menyambung semula → hantar isyarat tutup dan kursor.
• Tentukan saiz tempoh tangguh daripada kependaman purata → permintaan p99 menerima SIGKILL → ukur kependaman ekor (tail latency) dan perambatan.
• Andaikan finally sentiasa berjalan → pembunuhan paksa dan kehilangan kuasa melangkau pembersihan → kekalkan keadaan kritikal secara tahan lama.
• Perhatikan status Pod sahaja → terlepas perambatan LB yang perlahan dan pemutusan sambungan → hubung kaitkan titik akhir, permintaan, dan metrik pelepasan.
• Gagalkan liveness semasa draining → cetuskan ribut permulaan semula (restart storms) → readiness bermakna kelayakan trafik; liveness bermakna kesihatan proses.

Soalan susulan dan respons

Soalan susulan 1: Mengapa permintaan boleh tiba selepas readiness gagal?

Kemas kini titik akhir, service mesh, dan pengimbang beban awan merambat dengan kelewatan, dan sambungan sedia ada tidak dipindahkan secara automatik. Aplikasi yang sedang draining mesti menolak kerja baharu dan menutup sambungan sedia ada dengan selamat.

Soalan susulan 2: Berapa lamakah preStop perlu sleep?

Jangan teka. Ukur perambatan p99 titik akhir dan LB, gabungkan dengan belanjawan pembersihan permintaan dan pekerja, dan layan sleep sebagai tetingkap penyelarasan yang terikat.

Soalan susulan 3: Bagaimanakah anda menutup WebSocket secara anggun?

Berhenti menerima sambungan baharu dan hantar kod tutup dengan panduan sambung semula. Benarkan klien menyambung semula dengan sesi atau kursor, dan kekalkan keadaan yang mencukupi untuk mengelakkan memainkan semula kesan sampingan.

Soalan susulan 4: Bagaimana jika Pod mati di pertengahan kerja?

Kekalkan keadaan kerja dan pajakan. Pekerja baharu menuntutnya selepas tamat masa keterlihatan; kunci keidempotennan atau pertanyaan status melindungi kesan luaran. Jangan bergantung pada finally dalam proses.

Soalan susulan 5: Bolehkah kehilangan kuasa nod berlaku secara anggun?

Tidak secara boleh dipercayai. Pengendalian penutupan nod yang dirancang merangkumi aliran penyelenggaraan yang boleh diperhatikan; kehilangan kuasa dan ranap kernel memerlukan replika, titik pemeriksaan tahan lama, dan kerja yang boleh dicuba semula.

Soalan susulan 6: Bagaimanakah anda memilih tempoh tangguh?

Tambahkan perambatan titik akhir, permintaan maksimum, penutupan sambungan lama, pelepasan pajakan, pembersihan sambungan, dan pembilasan log, kemudian sahkan dengan p99 yang diukur dan margin dan bukannya purata.

Soalan susulan 7: Bagaimanakah anda mengelakkan ribut permulaan semula semasa draining?

Gagalkan readiness sambil mengekalkan liveness sihat. Asingkan tanggungjawab probe supaya “tidak menerima trafik buat sementara waktu” tidak disalah anggap sebagai proses yang ranap.