Wawancara system design: Bagaimana seharusnya Kubernetes memperbarui kapasitas volume node CSI secara dinamis?

Petunjuk dan konteks

Kapasitas lampiran volume driver CSI berubah seiring kuota cloud dan kesehatan sistem. Rancang pelaporan kapasitas, konsistensi penjadwal, perlindungan kegagalan, dan peningkatan untuk Mutable CSINode Allocatable Kubernetes. Jelaskan batas tanggung jawab antara driver CSI, objek node, penjadwal, dan kegagalan lampiran (attach).

Hal yang dievaluasi pewawancara

• Pemahaman bahwa CSINode.spec.drivers[].allocatable.count adalah petunjuk penjadwalan (scheduling hint), bukan kunci waktu nyata (real-time lock).
• Menjelaskan bagaimana driver CSI memperbarui kapasitas secara berkala atau setelah terjadi kesalahan.
• Menangani nilai usang (stale), pembaruan bersamaan (concurrent updates), cache penjadwal, dan kegagalan lampiran.
• Merancang peringatan, backoff, peningkatan kompatibilitas, dan pemulihan kapasitas.

Pertanyaan klarifikasi yang perlu diajukan

1. Apakah kapasitas berubah karena kuota cloud, kesehatan driver, atau sumber daya node lokal?
2. Berapa keterlambatan pembaruan dan tingkat kesalahan yang dapat diterima, dan apakah perilaku Pending yang konservatif diperbolehkan?
3. Apakah versi kluster dan driver CSI mendukung nilai allocatable yang dapat diubah (mutable)?
4. Setelah kegagalan lampiran, apakah sistem harus mencoba lagi, memindahkan Pod, atau membekukan node terlebih dahulu?

Kerangka jawaban 30 detik

Mulailah dengan objeknya: driver CSI menulis kapasitas volume yang dapat digunakan ke dalam CSINode, dan penjadwal menyaring dengannya; karena nilainya bisa tertinggal (lag), proses attach tetap melakukan pemeriksaan akhir. Driver memperbarui secara berkala atau saat terjadi kesalahan kapasitas yang jelas, sementara pengontrol dan penjadwal bertemu melalui watch. Batasi laju pembaruan (rate-limit), lindungi urutan, dan kurangi kapasitas secara konservatif selama ketidakpastian agar nilai tinggi yang salah tidak menyebar ke seluruh kluster.

Pembahasan mendalam langkah demi langkah

1. Rantai tanggung jawab dan model data

Setiap pasangan node-dan-driver memiliki CSINode.spec.drivers[].allocatable.count. Driver CSI mengetahui batas lampiran backend penyimpanan dan melaporkan kapasitas yang dapat digunakan; penjadwal memperlakukannya sebagai informasi pra-penyaringan. Field ini bukan kunci terdistribusi dan tidak dapat mencegah race condition antar keputusan penjadwalan. Driver dan pengontrol harus memvalidasi kapasitas lagi ketika volume benar-benar dibuat atau dilampirkan.

2. Pemicu pembaruan dan konsistensi

Driver dapat menyegarkan pada periode yang dikonfigurasi melalui CSIDriver, atau segera setelah kesalahan kehabisan kapasitas yang jelas. Gunakan prasyarat versi sumber daya (resource-version preconditions) agar driver yang lebih lama tidak dapat menimpa nilai yang lebih baru. Tambahkan interval minimum dan jitter untuk menghindari perubahan derau API cloud menjadi amplifikasi penulisan control-plane. Penjadwal menyegarkan cache-nya melalui watch dan harus membuat keputusan konservatif selama jendela inkonsistensi yang singkat.

3. Perlindungan kegagalan dan pemulihan

Ketika driver tidak dapat memperoleh kuota atau kesehatan, driver tidak boleh melaporkan kapasitas tak terbatas. Driver dapat mempertahankan nilai baik terakhir yang diketahui dengan masa kedaluwarsa atau mengurangi kapasitas menjadi nol sehingga Pod baru tetap dalam status Pending. Klasifikasikan kegagalan lampiran sebagai kesalahan kapasitas, izin, topologi, atau jaringan sementara; hanya kesalahan kapasitas yang boleh memperbarui allocatable. Tingkatkan kapasitas secara bertahap setelah pemulihan sambil memantau keberhasilan lampiran.

4. Peningkatan, observasi, dan validasi

Kubernetes v1.36 membuat Mutable CSINode Allocatable menjadi stabil. Sebelum meningkatkan, validasi matriks versi API Server, penjadwal, kubelet, dan driver CSI, lalu aktifkan pembaruan berkala pada sejumlah kecil node kenari (canary). Pantau keterlambatan pembaruan objek, frekuensi perubahan kapasitas, alasan Pending, kelas kegagalan lampiran, QPS penulisan control-plane, dan penggunaan node sebenarnya. Jika sinyal memburuk, jeda pembaruan, pulihkan pengaturan yang kompatibel, dan pertahankan kapasitas tepercaya terakhir.

Jawaban model

Saya akan memperlakukan allocatable yang dapat diubah sebagai petunjuk penjadwalan, bukan kunci waktu nyata. Driver CSI melaporkan kapasitas lampiran node-dan-driver di CSINode.spec.drivers[].allocatable.count, menyegarkan secara berkala atau setelah kesalahan kehabisan kapasitas yang jelas. Penjadwal mengamati objek melalui watch, tetapi driver tetap melakukan pemeriksaan lampiran akhir.

Pembaruan memerlukan pembatasan laju (rate limits), ketentuan versi sumber daya, dan jitter. Jika kuota tidak dapat diandalkan, kurangi kapasitas secara konservatif daripada menulis nilai tinggi yang sembarangan. Klasifikasikan kegagalan lampiran berdasarkan kapasitas, izin, topologi, dan jaringan; hanya kegagalan kapasitas yang memicu pembaruan. Setelah v1.36 menstabilkan fitur ini, gunakan node canary dan pantau lag pembaruan, alasan Pending, kegagalan lampiran, QPS penulisan, dan penggunaan sebenarnya. Jeda pembaruan dan pulihkan nilai tepercaya terakhir ketika sinyal memburuk.

Kesalahan umum

• Memperlakukan allocatable sebagai kunci waktu nyata yang bebas pertikaian (contention-free).
• Mengurangi kapasitas menjadi nol untuk setiap kegagalan lampiran dan menyebabkan Pod Pending kolateral.
• Membiarkan driver menulis CSINode dengan frekuensi tinggi dan memperbesar beban control-plane.
• Melaporkan kapasitas tinggi ketika pencarian kuota gagal.
• Hanya meningkatkan versi API sambil mengabaikan kompatibilitas driver CSI, penjadwal, dan kubelet.

Pertanyaan lanjutan dan tanggapan

Lanjutan 1: Mengapa lampiran bisa gagal setelah penjadwal melihat kapasitas yang cukup?

Field tersebut memiliki keterlambatan penyebaran (propagation delay) dan konsumen bersamaan dapat menghabiskan kuota yang sama. Filter penjadwalan menurunkan probabilitas kegagalan; driver CSI harus memvalidasi lagi saat lampiran dan mengembalikan kesalahan yang terklasifikasi.

Lanjutan 2: Seberapa sering kapasitas harus disegarkan?

Itu tergantung pada frekuensi perubahan kuota, anggaran penulisan control-plane, dan toleransi bisnis terhadap Pod Pending. Mulailah secara konservatif, sesuaikan berdasarkan lag pembaruan, tingkat kegagalan, dan QPS penulisan, serta gunakan pembaruan yang dipicu oleh backoff setelah kesalahan.

Lanjutan 3: Bagaimana cara mencegah driver lama menimpa kapasitas baru?

Gunakan pembaruan bersyarat versi sumber daya dan gerbang versi driver, membatasi penulisan dari driver lama selama peningkatan. Pantau identitas penulis, stempel waktu, dan regresi; jeda ekspansi otomatis ketika rollback terdeteksi.