Wawancara Kubernetes: Bagaimana cara membuat panggilan API kube-scheduler menjadi non-blocking?

Petunjuk dan ruang lingkup

Sebuah kluster mengaktifkan plugin penjadwalan yang memanggil server API. Ketika latensi API meningkat, panggilan sinkron menghabiskan siklus penjadwalan dan Pod yang belum terjadwal menumpuk. Rancang pendekatan asinkron yang dijelaskan oleh KEP-5229, yang mencakup antrean prioritas, request coalescing, percobaan ulang, pembatalan, keadilan (fairness), dan rollback.

Apa yang sedang diuji oleh pewawancara

• Apakah Anda memisahkan semantik siklus penjadwalan serial dari efek samping API asinkron.
• Apakah antrean prioritas terbatas (bounded) dan coalescing mencegah starvation dan penulisan ganda.
• Apakah Anda mendefinisikan kunci idempotensi, tenggat waktu (deadlines), pembatalan, hasil basi (stale), dan kesalahan permanen.
• Apakah Anda mencakup keadilan prioritas, backpressure, metrik, dan peluncuran berbasis feature-gate.

Pertanyaan klarifikasi yang perlu diajukan

1. Apakah panggilan tersebut berupa operasi baca, tulis idempoten, atau pembuatan sumber daya eksternal? Efek samping menentukan batas percobaan ulang.
2. Bisakah plugin menerima status eksternal yang eventual, atau harus mengonfirmasi status sebelum binding?
3. Apakah kegagalan memasukkan kembali Pod ke antrean sebagai unschedulable, atau hanya mencoba ulang operasi API? Jaga agar loop tersebut tetap terpisah.
4. Berapa QPS API kluster, tingkat penjadwalan konkuren, dan anggaran antrean?

Kerangka jawaban 30 detik

Pindahkan operasi API yang lambat dari thread penjadwalan ke antrean prioritas terbatas. Scheduler mengirimkan tugas dengan kunci idempotensi dan melanjutkan pemrosesan Pod lainnya. Layani berdasarkan prioritas Pod dan waktu tunggu, dengan menggabungkan (coalescing) kunci yang identik. Penyelesaian tugas hanya memicu evaluasi ulang yang aman; hasil yang basi tidak boleh melakukan binding pada Pod. Klasifikasikan kesalahan menjadi dapat dicoba ulang dan permanen, dengan tenggat waktu, pembatalan, backoff, dan batas konkurensi. Luncurkan di balik feature gate menggunakan kedalaman antrean, waktu tunggu, tingkat keberhasilan, dan latensi penjadwalan; nonaktifkan jalur asinkron dan lakukan fallback ketika ambang batas terlampaui.

Pembahasan mendalam langkah demi langkah

1. Tentukan batas sinkron

Siklus penjadwalan memilih sebuah node dan memiliki konteks penjadwalan; tugas asinkron melakukan pekerjaan yang dapat ditunda. Jika hasilnya adalah prasyarat binding mutlak, modelkan sebagai pending dan cegah binding sampai ada konfirmasi. Hanya pekerjaan yang tidak membahayakan siklus saat ini yang boleh dibuat asinkron.

2. Bangun antrean prioritas terbatas

Setiap tugas membawa UID Pod, jenis operasi, kunci idempotensi, tenggat waktu, dan konteks pembatalan. Antrean memiliki batas kapasitas. Saat penuh, kembalikan sinyal backpressure eksplisit alih-alih menumpuk memori tanpa batas. Layani pekerjaan berprioritas tinggi terlebih dahulu, sementara penuaan (aging) atau kuota mencegah terjadinya starvation permanen.

submit(key, priority, deadline, operation)
if same key is pending: coalesce(operation)
else if queue is full: return Backpressure
else enqueue(operation)

3. Coalescing dan idempotensi

Coalescing menggabungkan permintaan konkuren untuk satu operasi logis; ini tidak menyediakan idempotensi pada API server. Operasi tulis memerlukan kunci sumber daya yang stabil, pembaruan kondisional, atau idempotensi sisi server. Periksa hasil sebelumnya sebelum mencoba ulang agar sumber daya eksternal tidak dibuat dua kali. Permintaan untuk versi atau target yang berbeda tidak boleh digabungkan hanya karena string mereka terlihat serupa.

4. Penyelesaian, pembatalan, dan hasil basi

Publikasikan peristiwa penyelesaian yang meminta Pod terkait untuk mengevaluasi ulang; jangan berasumsi bahwa status penjadwalan masih valid. Batalkan tugas ketika Pod dihapus, di-preempt, atau memasuki konteks penjadwalan baru. Buang hasil yang melewati tenggat waktunya dan catat alasannya. Panggilan API yang berhasil dari konteks yang kedaluwarsa tidak boleh melakukan binding lama.

5. Percobaan ulang, backpressure, dan keadilan

Coba ulang batas waktu (timeouts), kesalahan jaringan sementara, dan respons 429 dengan exponential backoff. Kegagalan autentikasi, parameter tidak valid, dan konflik memerlukan penanganan kegagalan permanen atau kalkulasi ulang baru. Batasi jumlah worker, kuota per-plugin, dan QPS API. Hitung percobaan ulang penjadwalan Pod secara terpisah dari percobaan ulang tugas API, jika tidak, satu operasi lambat dapat melipatgandakan antrean.

6. Kompatibilitas, peluncuran, dan rollback

Pertahankan API plugin dan semantik penjadwalan sambil menempatkan jalur asinkron di balik feature gate. Mulailah dengan plugin berisiko rendah dan kluster konkurensi rendah. Bandingkan P99 penjadwalan, waktu tunggu antrean, latensi API, kegagalan tugas, permintaan duplikat, dan percobaan ulang unschedulable. Jika backlog, kesalahan binding, atau tekanan API melebihi batas dasar (baseline), hentikan pengiriman baru, kuras atau batalkan tugas, dan kembali ke jalur sinkron.

Contoh jawaban berkualitas tinggi

Pertama, klasifikasikan panggilan mana yang dapat ditunda dan mana yang merupakan prasyarat binding. Tempatkan yang pertama dalam antrean prioritas terbatas dan representasikan yang terakhir sebagai status pending eksplisit. Sertakan UID Pod, jenis operasi, kunci idempotensi, tenggat waktu, dan konteks pembatalan; gabungkan kunci yang sama dan terapkan backpressure saat penuh. Worker hanya mengeksekusi operasi yang idempoten atau dapat dicoba ulang dengan aman, melakukan backoff pada kesalahan sementara dan menyerahkan kesalahan permanen ke penanganan kegagalan plugin. Penyelesaian memicu evaluasi ulang, bukan binding tanpa syarat. Luncurkan di balik feature gate dan ukur P99 penjadwalan, kedalaman antrean, QPS API, tingkat duplikat, tingkat kegagalan, dan kebenaran binding. Jika terjadi pelanggaran ambang batas, hentikan pengiriman, bersihkan tugas, dan lakukan fallback.

Kesalahan umum

• Mengirim setiap panggilan ke latar belakang → prasyarat binding dapat terlewati → gambarkan state machine penjadwalan terlebih dahulu.
• Menggunakan satu FIFO global → Pod prioritas tinggi menunggu di belakang pekerjaan prioritas rendah → tambahkan prioritas, aging, dan kuota.
• Melakukan deduplikasi berdasarkan teks permintaan → versi atau efek samping dapat digabungkan secara salah → gunakan kunci sumber daya dan idempotensi eksplisit.
• Mencoba ulang tanpa batas → pemadaman API menjadi badai antrean → gunakan tenggat waktu, backoff, batas percobaan, dan circuit breaker.
• Hanya mengukur throughput → regresi latensi dan kebenaran tetap tersembunyi → amati antrean, API, percobaan ulang, dan binding.

Pertanyaan lanjutan dan tanggapan

Bisakah operasi baca dan tulis untuk Pod yang sama digabungkan (coalesced)?

Tidak hanya berdasarkan UID Pod saja. Operasi baca dapat digabungkan berdasarkan versi sumber daya; operasi tulis memerlukan jenis operasi, target, dan kunci idempotensi, sambil tetap mempertahankan urutan yang diperlukan.

Tugas mana yang harus dibuang ketika antrean penuh?

Gunakan tenggat waktu, prioritas, dan kemampuan untuk direkonstruksi. Prasyarat binding yang tidak dapat dibuang harus menghasilkan backpressure. Setiap tugas yang dibuang harus mengarah ke status percobaan ulang atau kegagalan yang dapat dijelaskan, bukan penghapusan secara diam-diam.

Bagaimana jika panggilan API berhasil setelah Pod di-preempt?

Gunakan pembatalan dan pemeriksaan versi objek untuk mencegah konteks lama menulis lebih lanjut. Simpan keberhasilan tersebut untuk audit, lalu biarkan konteks penjadwalan baru menghitung ulang alih-alih menggunakan kembali niat binding yang sudah basi.