Wawancara Desain Sistem: Bagaimana Anda Mendesain Node Readiness Controller Kubernetes?

Konteks dan cakupan

Setelah sebuah node melakukan boot, kubelet mungkin melaporkan Ready meskipun driver GPU, CNI, plugin penyimpanan, atau agen lokal belum dapat digunakan. Jika scheduler menempatkan Pod terlalu cepat, beban kerja akan gagal berulang kali atau mengalami penurunan performa secara hening. Rancang Node Readiness Controller yang mendeklarasikan prasyarat tambahan, memblokir penjadwalan hingga prasyarat terpenuhi, dan menangani dependensi yang gagal di kemudian hari dalam siklus hidup node.

Topik ini cocok untuk wawancara platform engineering, SRE, dan Kubernetes controller. Materi wawancara Kubernetes publik mencakup node NotReady, taint dan toleration, serta pemecahan masalah Pod yang berstatus Pending. Proyek resmi Node Readiness Controller menjelaskan NodeReadinessRule API, manajemen taint otomatis, mode bootstrap-only dan continuous, serta dry run. Desain di bawah ini adalah jawaban wawancara yang beralasan, bukan klaim pertanyaan dari perusahaan tertentu.

Apa yang dievaluasi oleh pewawancara

Pewawancara ingin Anda memisahkan antara "node berstatus Ready" dan "node cocok untuk kelas beban kerja ini." Jawaban yang kuat mendefinisikan sumber kondisi, cakupan aturan, idempotensi taint, pemulihan setelah restart, status yang dapat diobservasi, dan perlindungan terhadap pemblokiran armada secara tidak sengaja.

Jawaban yang lemah akan menulis DaemonSet yang memeriksa segalanya. Jawaban yang kuat menjelaskan mengapa pelaporan kondisi dipisahkan dari penegakan kebijakan, bagaimana bootstrap-only berbeda dari penegakan continuous, bagaimana dry run memperkirakan radius dampak (blast radius), dan bagaimana menangani kondisi usang (stale), partisi kontroler, serta aturan yang bertentangan.

Pertanyaan klarifikasi sebelum menjawab

• Apakah kontroler harus melindungi bootstrap node saja, atau juga menghentikan penjadwalan baru ketika driver gagal di kemudian hari? Ini menentukan mode penegakan dan tindakan pemulihan.
• Siapa yang menghasilkan kondisi: Node Problem Detector, device plugin, agen CNI, atau DaemonSet kustom? Sumber yang tidak tepercaya memerlukan pemeriksaan identitas dan kebaruan (freshness).
• Apakah semua kondisi harus bernilai True, atau boleh salah satu kondisi saja yang lolos? GPU, jaringan, dan penyimpanan biasanya membutuhkan node pool dan aturan yang berbeda.
• Apakah kondisi bernilai false akan memblokir Pod baru atau menggusur (evict) Pod yang sudah ada? Yang pertama bersifat reversibel; yang kedua membutuhkan bukti yang lebih kuat dan kebijakan penggusuran terpisah.

Kerangka jawaban 30 detik

"Saya akan memisahkan pelaporan kondisi, evaluasi aturan, dan eksekusi taint. NodeReadinessRule memilih node dan mencantumkan kondisi yang harus bernilai True; kontroler menambahkan atau menghapus taint NoSchedule sesuai dengan penegakan bootstrap-only atau continuous. Operasi penulisan harus idempoten, dapat diobservasi, dan mendukung dry-run. Aturan dan status kondisi disimpan di API server sehingga status dapat dibangun kembali setelah restart. Saya akan mencatat dampaknya terlebih dahulu, mengaktifkan satu node pool, dan jika terjadi kegagalan, menghentikan penulisan atau me-rollback aturan alih-alih membuat seluruh kluster tidak dapat dijadwalkan."

Jawaban langkah demi langkah

Mulailah dengan batas tanggung jawab. Kontroler tidak melakukan probe pada GPU atau jaringan; kontroler menggunakan Node Conditions. Node Problem Detector, device plugin, atau agen kustom melaporkan fakta. Ini menggunakan kembali ekosistem probe yang ada dan memisahkan "pemeriksaan gagal" dari "penjadwalan diizinkan." Suatu kondisi harus memuat type, status, waktu pembaruan, sumber, dan generasi observasi; kondisi yang usang tidak boleh terus mengizinkan beban kerja.

Model aturan berisi node selector, kumpulan kondisi, taint target, dan mode penegakan. Proyek resmi mewajibkan setiap kondisi yang tercantum harus terpenuhi sebelum menghapus taint dan mendukung pemilihan node heterogen berdasarkan label. bootstrap-only berhenti mengevaluasi aturan tersebut setelah inisialisasi berhasil. continuous menambahkan kembali taint ketika kondisi kritis menjadi False di kemudian hari. Mode pertama cocok untuk pre-pull image atau penyiapan perangkat keras; mode kedua cocok untuk dependensi yang harus tetap sehat.

Loop kontrol membaca aturan, node, dan kondisi, menghitung taint yang diinginkan, dan menerapkan pembaruan menggunakan resource version. Penulisan harus idempoten dan dicoba kembali jika terjadi konflik: kelola hanya taint yang dimiliki oleh kontroler ini, jangan pernah menghapus taint milik administrator atau kontroler lain. Jika dua aturan mengklaim kunci taint yang sama dengan arti berbeda, validasi admisi harus menolak konflik tersebut; jika tidak, satu aturan dapat secara tidak sengaja menghapus perlindungan aturan lainnya.

Perjelas alur kegagalan. Ketika pelapor berhenti memperbarui, fail-closed atau fail-open adalah pilihan produk: dependensi keamanan kritis dapat menggunakan fail-closed, sedangkan bootstrap berisiko rendah dapat menggunakan fail-open dengan TTL pendek. Kontroler yang terputus tidak boleh menghapus taint yang ada; kontroler melakukan rekonsiliasi setelah pulih. Jika sebuah node dihapus atau labelnya berubah, tandai aturan sebagai tidak berlaku sehingga status usang tidak memblokir node pengganti.

Observabilitas harus mencakup node yang cocok per aturan, kondisi yang hilang atau usang, deviasi taint yang diinginkan versus aktual, latensi dari kondisi menjadi True hingga dapat dijadwalkan, dan jumlah Pod yang tertahan (gated-Pod). Status harus menampilkan kondisi yang gagal dan waktu evaluasi terakhir tanpa mencatat kredensial atau data perangkat sensitif. Untuk melindungi control plane, antrekan berdasarkan node dan aturan, gabungkan perubahan kondisi yang cepat (coalesce), dan hindari penulisan ke API-server untuk setiap heartbeat.

Luncurkan dengan dry run. Dry run proyek resmi mencatat tindakan yang dimaksudkan dan memperbarui status aturan tanpa menerapkan taint. Amati node yang terpengaruh dan Pod yang Pending, lalu aktifkan satu node pool. Rollback menjeda evaluasi aturan baru, mempertahankan taint perlindungan yang ada, memperbaiki sumber kondisi, dan melakukan rekonsiliasi ulang; ini tidak menghapus setiap taint NoSchedule dengan satu perintah.

Alternatifnya meliputi penambahan nodeSelector ke setiap beban kerja, menggunakan Pod schedulingGates, atau menambahkan taint dari skrip bootstrap. Penyeleksi beban kerja cocok untuk kelompok konsumen kecil yang diketahui tetapi mengabaikan Pod di masa mendatang. Pod gate melindungi Pod, sedangkan masalah ini melindungi node. Skrip tidak memiliki status bersama dan mekanisme pemulihan. Kontroler cocok untuk node heterogen dan kluster bersama, dengan konsekuensi biaya berupa CRD, loop kontrol, dan domain kegagalan tambahan.

Contoh jawaban berkualitas tinggi

Saya akan membangun kontroler deklaratif yang hanya bertanggung jawab atas "apakah Pod baru boleh dijadwalkan di sini?" Node Problem Detector, device plugin, atau agen CNI menulis kondisi; kontroler tidak menduplikasi probe mereka. Aturan memilih node, mencantumkan kondisi yang harus True, menentukan taint NoSchedule, dan memilih mode. Pekerjaan bootstrap menggunakan bootstrap-only: setelah driver GPU dan agen jaringan siap, taint dihapus. Dependensi continuous menggunakan continuous: kegagalan di kemudian hari akan menambahkan taint lagi, tetapi tidak menggusur Pod yang ada secara otomatis.

Kontroler hanya memiliki dan merekonsiliasi taint yang membawa penanda kepemilikannya, menggunakan resource version dan percobaan ulang konflik untuk idempotensi. Klaim yang saling bertentangan untuk kunci taint yang sama akan ditolak. Status aturan melaporkan node yang cocok, kondisi yang hilang atau usang, deviasi taint, dan waktu evaluasi. Saya akan menerapkan dry run terlebih dahulu, membandingkan proyeksi dampak dengan Pod Pending, dan melakukan canary pada satu node pool. Selama kontroler terputus, pertahankan perlindungan yang ada; setelah pemulihan, lakukan rekonsiliasi. Rollback menjeda evaluasi dan memperbaiki sumber kondisi daripada menghapus setiap taint kluster.

Kesalahan umum

• Kesalahan → Membuat kontroler melakukan SSH ke setiap node; kegagalan → melewati sumber kondisi Kubernetes dan memperluas batasan izin; perbaikan → biarkan agen khusus melaporkan kondisi dan pertahankan evaluasi kebijakan di dalam kontroler.
• Kesalahan → Menggunakan continuous untuk bootstrap satu kali; kegagalan → node yang telah selesai terus mengalami fluktuasi (flapping) dan tetap tidak dapat dijadwalkan; perbaikan → gunakan bootstrap-only dan catat penyelesaiannya.
• Kesalahan → Menghapus taint apa pun yang memiliki kunci sama; kegagalan → perlindungan keamanan dari administrator atau kontroler lain bisa hilang; perbaikan → gunakan penanda kepemilikan, validasi konflik, dan pembaruan tingkat bidang (field-level).
• Kesalahan → Menghapus semua taint setelah kontroler restart; kegagalan → beban kerja mendarat di node yang belum siap selama jendela pemulihan; perbaikan → pertahankan status dan lakukan rekonsiliasi dengan pemeriksaan resource-version.

Pertanyaan lanjutan dan tanggapan

Bagaimana jika pelapor kondisi berhenti memperbarui: fail-open atau fail-closed?

Klasifikasikan dependensinya. Driver GPU, modul kripto, dan jaringan lintas zona dapat menggunakan fail-closed dengan waktu kedaluwarsa, menerima kehilangan kapasitas sementara. Bootstrap satu kali yang berisiko rendah dapat menggunakan fail-open dengan catatan sukses dan TTL pendek. Dalam kedua kasus, ukur "unknown" secara terpisah dari False agar telemetri yang hilang tidak disalahartikan sebagai kondisi sehat.

Dua aturan cocok dengan sebuah node dan mengklaim kunci taint yang sama. Apa yang Anda lakukan?

Tolak konflik semantik selama admisi atau kompilasi aturan, dengan mewajibkan kunci yang berbeda atau satu pemilik agregat yang eksplisit. Kontroler menyimpan status yang diinginkan untuk setiap aturan dan menghapus taint agregat hanya jika setiap pemilik memenuhi kondisi pelepasannya. Aturan terakhir yang merekonsiliasi tidak boleh menghapusnya sendirian.

Bagaimana Anda membuktikan dry run tidak akan menghabiskan kapasitas kluster?

Masukkan node yang cocok, kapasitas terjadwal yang tersedia, permintaan Pod, dan penyebaran topologi ke dalam satu laporan dampak. Simulasikan satu node pool, amati Pod yang tertahan, antrean autoscaler, dan latensi penjadwalan, lalu perluas. Jika beban kerja kritis kekurangan ruang (headroom), ubah node pool atau aturan sebelum penegakan.

Mengapa tidak menggusur Pod yang ada saat node gagal dalam kesiapan continuous?

"Tidak ada Pod baru" dan "Pod yang ada tidak aman" adalah keputusan yang terpisah. NoSchedule mempertahankan kontinuitas sambil memblokir penempatan baru; penggusuran membutuhkan PDB, penghentian anggun (graceful termination), dan kebijakan keamanan data tersendiri. Kontroler penggusuran terpisah hanya boleh bertindak ketika ada bukti bahwa beban kerja yang ada tidak aman.