Wawancara system design: Bagaimana Anda menggunakan Kubernetes v1.36 DRA untuk resource Node Allocatable?

Pertanyaan dan ruang lingkup

Kluster inferensi multi-tenant mengalokasikan akselerator melalui Dynamic Resource Allocation (DRA). Driver mengonsumsi CPU, memori, atau hugepages per perangkat, dan beberapa perangkat memerlukan penyelarasan NUMA. Rancang rencana Node Allocatable Kubernetes v1.36 sehingga scheduler memperhitungkan alokasi DRA dan request Pod biasa secara bersamaan. Jelaskan pemetaan ResourceSlice, status Pod, peluncuran (rollout), pemantauan, dan batasan rollback.

Pembaruan resmi DRA v1.36 mendeskripsikan resource Node Allocatable sebagai iterasi pertama yang membawa CPU, memori, dan hugepages yang dikelola DRA ke dalam penghitungan standar node. Kemampuan ini masih berstatus alpha, sehingga perancangannya memerlukan pembatas pengaman (guardrails) untuk fitur eksperimental.

Konteks dan batasan

Pertanyaan ini berfokus pada penghitungan resource pra-penjadwalan (pre-scheduling), batasan topologi, dan keamanan rilis. Alokasi perangkat keras di dalam driver dan toleransi kesalahan tingkat bisnis adalah dependensi eksternal; jawaban harus menyatakan versi API, feature gate, kebijakan kesegaran data (freshness policy), konsistensi buku besar (ledger), dan kondisi rollback.

Hal yang diuji oleh pewawancara

• Apakah Anda dapat menghubungkan buku besar resource, scheduler, driver DRA, ResourceSlice, dan status Pod.
• Apakah Anda membedakan kapasitas perangkat dari resource node yang dikonsumsi oleh alokasi perangkat dan dari request Pod biasa.
• Apakah Anda menangani NUMA, hugepages, pembaruan yang tidak berurutan, restart driver, dan ResourceSlice yang usang (stale).
• Apakah Anda dapat meluncurkan feature gate alpha dengan canary, observabilitas, rollback, dan kompatibilitas driver lama.
• Apakah pembaruan status dibatasi pada subresource sintetis DRA dan izin dengan cakupan node (node-scoped).

Jawaban 30 detik

“Saya akan meminta driver DRA mendeklarasikan kontribusi CPU, memori, atau hugepage setiap perangkat di nodeAllocatableResourceMappings pada ResourceSlice. Scheduler menggabungkan alokasi dari claim yang terikat dengan request Pod biasa di dalam buku besar node, menghitung setiap claim tepat satu kali. Footprint tetap dapat menggunakan allocationMultiplier; footprint berbasis kapasitas dapat menggunakan capacityKey. Status Pod menampilkan hasilnya melalui nodeAllocatableResourceClaimStatuses. Saya hanya akan mengaktifkan DRANodeAllocatableResources pada node canary, menguji NUMA, pembaruan usang, dan perilaku pending, serta menghentikan claim baru jika buku besar atau pemetaan menjadi tidak aman.”

Solusi langkah demi langkah

1. Tentukan model resource. Simpan ID perangkat, ResourceClaim, node, zona NUMA, nama resource, unit, versi pemetaan, dan waktu observasi dalam buku besar yang dapat diputar ulang (replayable). Pisahkan kapasitas perangkat dari konsumsi CPU, memori, dan hugepage; sebuah claim harus masuk ke buku besar tepat satu kali.

1. Publikasikan pemetaan ResourceSlice. Driver DRA menulis nodeAllocatableResourceMappings di dalam ResourceSlice. Kunci pemetaan dapat merepresentasikan CPU, memori, ephemeral-storage, atau hugepages. Footprint tetap per perangkat dapat direpresentasikan dengan allocationMultiplier; konsumsi berbasis kapasitas dapat menggunakan capacityKey.

resourceSlice:
  nodeAllocatableResourceMappings:
    cpu:
      allocationMultiplier: 2
    memory:
      allocationMultiplier: 4Gi
    hugepages-2Mi:
      capacityKey: consumed

Ini hanya mengilustrasikan semantik pemetaan. Tipe kolom dan unit harus diperiksa terhadap skema API Kubernetes dan implementasi driver saat ini; ini bukan objek yang siap dikirimkan secara langsung.

1. Gabungkan buku besar penjadwalan. Scheduler membaca ResourceSlice dan ResourceClaim yang terikat, menghitung kontribusi DRA, dan menambahkan request Pod biasa. Gunakan kunci claim yang stabil untuk deduplikasi. Jika ResourceSlice usang atau pemetaannya hilang, pertahankan Pod baru dalam status pending dan beri peringatan alih-alih menjadwalkan terhadap kapasitas lama.

1. Tangani NUMA dan pengurutan. Catat afinitas dan versi NUMA. Lakukan komit alokasi, pelepasan, atau pembaruan ResourceSlice hanya jika pengurutan versi node bersifat monotonik. Selama driver di-restart, bangun kembali pemetaan sebelum menerima claim baru untuk menghindari alokasi ganda sementara.

1. Tampilkan status dan telemetri. status.nodeAllocatableResourceClaimStatuses pada Pod mencatat status resource node dari claim tersebut. Lacak kapasitas buku besar, penggunaan, usia pemetaan, alasan pending, jumlah penolakan duplikat, dan kegagalan penempatan NUMA. Hubungkan penulisan status dan keputusan penjadwalan dengan UID claim.

1. Canary dan rollback. Setelah kompatibilitas control-plane, scheduler, dan driver dikonfirmasi, aktifkan DRANodeAllocatableResources hanya untuk node canary. Uji ResourceSlice, Pod biasa yang dicampur dengan claim, restart node, upgrade driver, dan pelepasan. Jika terjadi kegagalan, hentikan claim baru, pertahankan binding yang ada, ekspor buku besar, perbaiki pemetaan, dan lanjutkan kembali berdasarkan versi. Jangan berasumsi bahwa setiap kluster dapat mengaktifkan kemampuan alpha dengan aman.

1. Batasan keamanan. Berikan izin subresource sintetis kepada driver DRA hanya sebatas yang diperlukan untuk pembaruan statusnya. Driver lokal node menggunakan verb yang memahami konteks node (node-aware) dan RBAC dengan hak akses paling rendah (least-privilege). Penulisan yang gagal harus memicu peringatan dan dicoba kembali; memperluas izin tidak akan memperbaiki inkonsistensi buku besar.

Jawaban model

Saya akan memperlakukan Node Allocatable sebagai buku besar resource yang memiliki versi. Driver mendeklarasikan kontribusi perangkat terhadap CPU, memori, atau hugepages di nodeAllocatableResourceMappings; kontribusi tetap menggunakan allocationMultiplier, dan kontribusi berbasis kapasitas menggunakan capacityKey. Scheduler membaca claim yang terikat, menggabungkan kontribusi setiap claim dengan request Pod biasa, dan melakukan deduplikasi berdasarkan UID claim sehingga penggunaan perangkat dan penggunaan resource node tidak dihitung dua kali.

Buku besar mencatat node, perangkat, NUMA, versi pemetaan, dan waktu observasi. Saat ResourceSlice usang, terjadi regresi versi, atau driver di-restart, Pod baru tetap berstatus pending daripada dijadwalkan dari kapasitas lama. nodeAllocatableResourceClaimStatuses pada Pod mendukung pembacaan kembali dan diagnosis, namun hal itu tidak menggantikan pemeriksaan konsistensi buku besar.

Karena v1.36 masih berstatus alpha, saya akan mengaktifkan DRANodeAllocatableResources pada node canary terlebih dahulu dan menguji campuran claim dan Pod, NUMA, restart node, pelepasan, dan upgrade driver. Rollback akan menghentikan claim baru, mempertahankan binding yang ada, dan mengekspor buku besar sebelum perbaikan pemetaan. RBAC dibatasi pada subresource sintetis DRA dan izin dengan cakupan node.

Kesalahan umum

• Kesalahan: Mengurangi CPU node sekali per perangkat dan sekali lagi setelah percobaan ulang claim → Alasan gagal: tidak ada kunci idempoten yang stabil → Solusi: deduplikasi berdasarkan UID claim, ID perangkat, dan versi pemetaan.
• Kesalahan: Mengirimkan YAML ilustratif sebagai objek API produksi → Alasan gagal: skema kolom dan unit memiliki versi → Solusi: verifikasi API ResourceSlice dan versi driver.
• Kesalahan: Tetap menggunakan kapasitas lama saat ResourceSlice tidak tersedia → Alasan gagal: data usang dapat menyebabkan overcommit → Solusi: gunakan jendela kesegaran data (freshness window) dan pertahankan claim baru tetap pending setelah masa berlaku berakhir.
• Kesalahan: Mengaktifkan gate alpha di semua tempat secara bersamaan → Alasan gagal: kompatibilitas dan rollback belum teruji → Solusi: gunakan canary, metrik, penghentian penerimaan claim, dan buku besar yang dapat dipulihkan.
• Kesalahan: Memperluas RBAC untuk memperbaiki kesalahan penulisan status → Alasan gagal: memperluas otoritas tanpa memperbaiki konsistensi data → Solusi: gunakan subresource sintetis, verb yang memahami konteks node, dan log audit.

Pertanyaan lanjutan dan jawaban

Kapan Anda harus menggunakan allocationMultiplier versus capacityKey?

Gunakan allocationMultiplier jika setiap alokasi mengonsumsi sejumlah CPU atau memori yang tetap. Gunakan capacityKey jika konsumsi bervariasi sesuai dengan kapasitas perangkat atau beban kerja, dengan semantik yang ditentukan driver dan dapat diaudit. Kunci unit dan pembuatan versi untuk kedua pilihan tersebut.

Bagaimana cara menghindari penghitungan ganda antara request Pod biasa dan pemetaan DRA?

Pertahankan satu buku besar: request biasa masuk ke aliran request, sementara kontribusi DRA masuk ke aliran alokasi yang diberi kunci berupa UID claim. Scheduler menerapkan setiap pemetaan satu kali dan mencatat sumber serta versinya. Kunci duplikat akan ditolak dan memicu peringatan.

Haruskah penjadwalan langsung dilanjutkan setelah driver di-restart?

Tidak. Bangun kembali ResourceSlice, validasi claim yang terikat, konfirmasikan versi dan kapasitas yang monotonik, lalu terima claim baru. Selama rekonstruksi, pertahankan binding yang ada dan biarkan Pod baru tetap pending.

Bagaimana Anda menunjukkan bahwa penempatan NUMA menjaga integritas pencatatan?

Putar ulang peristiwa lintas NUMA, NUMA yang sama, percobaan ulang pelepasan, dan restart node. Bandingkan total node, sub-buku besar NUMA, dan status Pod. Lacak kegagalan penempatan, divergensi buku besar, waktu pending, dan jumlah penolakan duplikat.

Kapan kemampuan alpha dapat dipromosikan?

Memerlukan cakupan driver yang kompatibel, latihan rollback, pemutaran ulang restart dan upgrade node, jendela observasi tanpa divergensi, serta SLO kapasitas dan pending yang eksplisit. Build yang sukses atau pengujian pada satu node tidak cukup untuk peluncuran penuh.

Referensi

• Pembaruan DRA Kubernetes v1.36 (Kubernetes Blog)
• Feature Gates (Dokumentasi Kubernetes)
• ResourceSlice API (Dokumentasi Kubernetes)
• Pod API (Dokumentasi Kubernetes)
• Panduan penguatan keamanan DRA (Dokumentasi Kubernetes)

Daftar periksa wawancara

Gambarkan alur dari driver ke ResourceSlice, claim, scheduler, buku besar Node Allocatable, dan status Pod. Kemudian tambahkan idempotensi, versi, NUMA, canary, dan hak akses paling rendah (least privilege).

Poin penting dalam satu kalimat

DRA Node Allocatable berhasil ketika satu buku besar yang memiliki versi dan aman dari rollback memperhitungkan kontribusi resource node nyata dari setiap claim.

Terus berlatih

Perluas pemetaan ke ResourceClaim multi-node dan jelaskan bagaimana topologi, kesegaran data (freshness), dan pemulihan mengubah keputusan penjadwalan.