Petunjuk dan ruang lingkup
Komponen penjadwalan eksternal merekomendasikan sebuah node untuk Pod yang berstatus Pending guna mengurangi pemfilteran berulang setelah preemption. Berdasarkan Kubernetes nominatedNodeName, rancang protokol kerja sama dan jelaskan mengapa komponen ini tidak dapat menggantikan nodeName, bagaimana penimpaan (overwrite) scheduler dan perubahan sumber daya ditangani, serta bagaimana Anda melakukan rollback.
Kubernetes v1.35 menandai nominatedNodeName sebagai beta. Ini adalah field status yang dapat digunakan oleh komponen eksternal untuk menominasikan sebuah node bagi Pod yang berstatus pending. Nominasi ini bersifat best effort, scheduler dapat menimpanya, dan node yang dinominasikan masih bisa gagal dalam pemeriksaan penjadwalan. Wawancara ini menguji apakah Anda memisahkan petunjuk intensi (intent hint) dari binding akhir.
Hal yang diuji oleh pewawancara
Mencakup izin dan kepemilikan (ownership) penulisan status, penentuan waktu nominasi dan pemfilteran, penghentian anggun (graceful termination) dari korban preemption, perbedaan semantik antara nodeName dan nominatedNodeName, keputusan eksternal yang idempoten dan memiliki masa kedaluwarsa, metrik, serta peluncuran dan rollback feature-gate.
Jawaban 30 detik
"Saya memperlakukan nominatedNodeName sebagai petunjuk yang dapat dibatalkan, bukan sebuah janji. Komponen eksternal memperbarui status hanya dengan izin eksplisit dan mencatat versi serta alasannya; scheduler memvalidasi node yang dinominasikan pada setiap siklus dan melakukan fallback ke semua kandidat jika gagal. Pod dengan prioritas lebih tinggi dapat mengambil node tersebut, dan scheduler dapat menulis ulang atau mengosongkan field tersebut. Saya menggunakan nodeName akhir dan binding event sebagai hasilnya, mengukur tingkat keberhasilan (hit rate), tingkat fallback, latensi penjadwalan, dan waktu terminasi korban, serta menonaktifkan feature gate atau penulis eksternal jika sinyal-sinyal tersebut mengalami regresi."
Solusi langkah demi langkah
Langkah 1: Pisahkan semantik field
nodeName adalah penetapan mutlak (hard assignment) pada Pod spec. Ini melewati scheduler, dan node yang hilang atau berukuran terlalu kecil dapat menyebabkan Pod gagal secara langsung. nominatedNodeName berada di status dan menyatakan kandidat untuk Pod yang berstatus pending; baik nominator eksternal maupun preemption scheduler dapat menulisnya, sehingga status ini bersifat fleksibel (soft state).
Langkah 2: Tentukan izin eksternal
Berikan RBAC minimal kepada komponen eksternal untuk hanya memperbarui status Pod target, dan catat alasan nominasi, versi algoritma, serta stempel waktu dalam anotasi atau event. Komponen ini tidak boleh menulis spec.nodeName atau menganggap pembaruan status akan membuat kubelet langsung melakukan binding pada Pod.
apiVersion: v1
kind: Pod
metadata:
name: batch-worker
status:
nominatedNodeName: worker-07Langkah 3: Hormati kepemilikan scheduler
Scheduler dapat menulis field tersebut setelah preemption atau saat memasuki WaitOnPermit atau PreBind. Komponen eksternal harus menerima penimpaan dan menghindari perang penulisan (write war). Bandingkan resourceVersion sebelum setiap pembaruan; jika terjadi konflik, baca ulang dan hitung kembali.
Langkah 4: Rancang pemfilteran dan fallback
Scheduler pertama-tama memeriksa apakah node yang dinominasikan masih lolos filter sumber daya, afinitas, taint, dan topologi. Jika tidak, alur kandidat normal akan berlanjut. Komponen eksternal harus melakukan pemeriksaan awal yang cepat sebelum menominasikan, tetapi hasilnya tidak pernah menjadi keputusan akhir scheduler.
Langkah 5: Tangani jendela preemption
Preemption memberi korban periode penghentian anggun, sehingga node yang dinominasikan mungkin tetap tidak layak selama proses penghentian tersebut berlangsung. Scheduler dapat mengosongkan field atau menyerahkan node kepada Pod dengan prioritas lebih tinggi. Lalu lintas bisnis harus menunggu binding event alih-alih memperlakukan status nominasi sebagai kesiapan.
Langkah 6: Buat keputusan yang idempoten dan dapat kedaluwarsa
Lampirkan ID keputusan yang dapat dilacak dan TTL singkat ke setiap nominasi. Perubahan sumber daya node, pembaruan Pod spec, perubahan prioritas, atau penataan ulang antrean membuat nominasi lama menjadi basi. Rekonsiliasi berulang harus menulis nilai yang sama hanya selama keputusan tersebut masih valid.
Langkah 7: Tentukan observabilitas
Ukur keberhasilan penulisan nominasi, konflik status, kegagalan filter pada node yang dinominasikan, latensi penjadwalan fallback, waktu dari Pending hingga binding, waktu terminasi korban, dan jumlah pengosongan field. Uraikan berdasarkan kluster, prioritas, scheduler, dan versi algoritma eksternal untuk menemukan regresi.
Langkah 8: Peluncuran dan rollback
Aktifkan jalur ini terlebih dahulu di beberapa namespace dan PriorityClass berisiko rendah, dengan membandingkan latensi penjadwalan dan hasil preemption. Jika waktu pemfilteran, binding yang salah, atau status churn meningkat, hentikan penulisan status eksternal dan nonaktifkan scheduler feature gate. Biarkan penjadwalan biasa tetap tersedia; jangan memaksakan fallback dengan menulis nodeName.
Pertukaran (trade-offs) dan batasan
nominatedNodeName atau nodeName
nominatedNodeName menjaga pemfilteran, preemption, dan binding tetap berada di bawah kendali scheduler, sehingga cocok untuk rekomendasi eksternal. nodeName melewati scheduler dan dicadangkan untuk kasus tingkat lanjut di mana pemanggil menerima tanggung jawab atas sumber daya dan kegagalan; ini bukan mekanisme akselerasi umum.
Petunjuk terlebih dahulu atau memindai setiap node
Mencoba petunjuk terlebih dahulu dapat mengurangi pemfilteran berulang di kluster besar setelah preemption, tetapi kondisi node mungkin telah berubah. Pemindaian fallback penuh adalah standar kebenaran dasar dan tidak dapat dihilangkan demi optimasi performa.
Visibilitas atau kendali
Status membuat intensi penjadwalan terlihat tanpa memberikan kendali akhir. Peringatan (alerts), controller, dan otomatisasi bisnis harus memantau binding, FailedScheduling, dan events daripada hanya mengandalkan nominatedNodeName.
Latihan kegagalan dan evolusi
Node yang dinominasikan kehilangan kapasitas
Jalankan Pod dengan prioritas lebih tinggi setelah nominasi dan verifikasi bahwa scheduler menimpa atau mengosongkan field tersebut, serta Pod asli melakukan fallback alih-alih berstatus Pending secara permanen.
Pembaruan status mengalami konflik
Perbarui status Pod yang sama secara bersamaan dan verifikasi bahwa komponen eksternal membaca ulang setelah konflik resourceVersion alih-alih menimpa scheduler dengan objek yang sudah usang.
Terminasi korban berjalan lambat
Berikan grace period penghentian yang panjang kepada korban preemption. Pastikan bahwa node yang dinominasikan tidak dilaporkan tersedia terlalu cepat dan pantau ekor (tail) latensi dari Pending ke binding.
Kesalahan umum dan tindak lanjut
Kesalahan 1: Memperlakukan nominatedNodeName sebagai hasil binding
Tindak lanjut: Apakah Pod dijamin berjalan di sana setelah field tersebut ada? Tidak. Scheduler akan memfilter ulang; nodeName akhir dan binding event adalah hasilnya.
Kesalahan 2: Mengganti nominasi dengan nodeName
Tindak lanjut: Mengapa tidak menulis nodeName secara langsung? Ini melewati perlindungan sumber daya, taint, afinitas, dan preemption, serta dapat gagal pada node yang tidak cocok.
Kesalahan 3: Menimpa status secara berulang-ulang
Tindak lanjut: Bagaimana jika scheduler mengubah field tersebut? Terima persaingan kepemilikan, gunakan resourceVersion, TTL keputusan, dan rekonsiliasi idempoten daripada bersaing melawan scheduler.
Tindak lanjut lebih mendalam dan contoh jawaban
Mengapa node yang dinominasikan mungkin bukan hasil akhir?
Selama terminasi korban, node lain mungkin melepaskan kapasitas atau Pod dengan prioritas lebih tinggi mungkin mengambil node yang dinominasikan. Scheduler terus mencoba dan dapat mengosongkan atau menimpa nominasi tersebut.
Bagaimana Anda membuktikan optimasi ini berhasil?
Bandingkan waktu pemfilteran, latensi dari Pending ke binding, hit rate nominasi, tingkat fallback, dan waktu terminasi korban sebelum dan sesudah peluncuran. Jumlah penulisan saja tidak membuktikan penjadwalan yang lebih cepat.
Apa batas keamanan minimum untuk komponen eksternal?
Perbarui status hanya pada Pod yang diizinkan, jangan pernah menulis nodeName atau prioritas dan spec sumber daya, serta konfirmasi hasilnya melalui binding event. Setiap keputusan harus memiliki masa kedaluwarsa, dapat diaudit, dan dapat di-rollback.