Petunjuk dan cakupan
Kluster menggunakan Dynamic Resource Allocation (DRA) untuk GPU atau perangkat jaringan. Sebuah kontainer membutuhkan atribut PCI, antarmuka, atau driver untuk perangkat yang dialokasikan kepadanya, tetapi tidak boleh menerima akses API Kubernetes. Rancang jalur metadata dari driver ke kontainer dan jelaskan pembuatan versi, isolasi, kegagalan, dan perilaku peningkatan (upgrade).
Hal yang diuji oleh pewawancara
- Apakah Anda memahami batasan tanggung jawab antara driver DRA, ResourceClaim, kubelet, dan kontainer.
- Apakah Anda dapat menentukan jalur metadata, waktu pembuatan, pemasangan (mounting), dan siklus hidup pembersihan.
- Apakah Anda menangani field driver yang tidak tepercaya, kebocoran lintas node, kompatibilitas versi, dan restart Pod.
- Apakah Anda memeriksa status fitur dan versi yang didukung alih-alih memperlakukan status alpha sebagai kontrak yang stabil.
Pertanyaan klarifikasi
- Apakah metadata tersebut merupakan data penemuan (discovery), konfigurasi jaringan, atau materi sensitif seperti kredensial?
- Field dan versi skema mana yang diperlukan, dan bisakah aplikasi mentolerir data yang hilang atau terlambat?
- Apakah kluster dan node mendukung metadata perangkat DRA, dan apakah driver menggunakan pustaka resmi?
- Apa yang membatalkan file setelah alokasi ulang, restart Pod, upgrade driver, atau kegagalan node?
Jawaban 30 detik
Saya akan meminta driver mengekspos metadata non-sensitif hanya untuk ResourceClaim saat ini dan membiarkan kubelet menghasilkan JSON berversi selama persiapan perangkat, yang di-mount secara read-only pada jalur yang terdokumentasi. Aplikasi membaca file, bukan API; pembuatan, pembaruan, unmount, dan pembersihan mengikuti siklus hidup Pod. Validasi field dan ukuran, serta buat kegagalan driver dapat diamati (observable) alih-alih mengekspos file parsial. Karena kapabilitas ini berstatus alpha, pertahankan deteksi versi dan fallback ke variabel lingkungan, probe, atau jalur driver yang lebih lama.
Desain langkah demi langkah
1. Tentukan batasan data dan kepercayaan
DRA mengalokasikan perangkat ke ResourceClaim, driver mengetahui perangkat fisik, dan aplikasi menggunakan hasilnya. Metadata harus dibatasi pada atribut perangkat atau detail antarmuka, bukan kunci privat, token, atau pengidentifikasi lintas-tenant. Ikat input driver ke claim, request, dan node sehingga perangkat lain tidak dapat diproyeksikan ke dalam Pod.
2. Gunakan mekanisme pengiriman yang stabil
Dokumentasi mendefinisikan jalur umum (well-known path) di dalam kontainer dan file JSON untuk atribut perangkat. Gunakan read-only mount dan tingkat direktori yang deterministik sehingga aplikasi membaca file alih-alih menanyakan ke API. Sertakan field skema atau versi agar aplikasi dapat menolak versi yang tidak dikenal dan memilih logika kompatibilitas.
3. Tangani siklus hidup dan kegagalan
Buat file hanya setelah alokasi dan persiapan berhasil; hapus selama unprepare, penghapusan Pod, atau pelepasan claim. Kegagalan pembuatan, penulisan, atau validasi JSON tidak boleh mengekspos file parsial. Laporkan error driver atau kubelet yang dapat diamati dan cegah aplikasi menggunakan data yang tidak valid. Setelah restart, buat ulang dari claim saat ini daripada menggunakan kembali file node yang sudah usang (stale).
4. Rencanakan peningkatan dan observabilitas
Dokumentasikan matriks versi untuk pustaka driver, kubelet, node, dan aplikasi. Pantau latensi pembuatan, tingkat kegagalan, penolakan skema, versi driver, dan restart Pod; catat pengidentifikasi claim, request, dan node tanpa konten metadata. Batasi upgrade alpha dengan skema yang kompatibel, feature gate, dan rollback yang telah diuji.
Contoh jawaban berkualitas tinggi
Saya akan menjadikan metadata perangkat sebagai proyeksi read-only dari alokasi DRA. Driver hanya menulis atribut non-sensitif untuk ResourceClaim dan node saat ini; kubelet mengubahnya menjadi JSON berversi dan me-mount-nya secara read-only di jalur umum setelah persiapan perangkat. Aplikasi tidak memerlukan izin API Kubernetes. Sebelum menulis, validasi claim, request, pengikatan node, daftar izin (allowlist), dan ukuran; setelah menulis, validasi skema. Jika terjadi kegagalan, jangan mount file parsial dan ekspos error yang dapat diamati. Bersihkan saat pelepasan atau penghapusan Pod dan buat ulang setelah restart. Karena kapabilitas ini berstatus alpha, deteksi dukungan, gunakan feature gate, pertahankan fallback ke jalur yang lebih lama atau lingkungan eksplisit, dan pantau kegagalan, latensi, serta versi driver alih-alih menjanjikan stabilitas file lintas versi.
Kesalahan umum
- Memberikan akses API Kubernetes atau RBAC yang terlalu luas kepada kontainer.
- Mengekspos setiap field driver, termasuk kredensial atau data perangkat milik tenant lain.
- Mengabaikan field versi, allowlist, dan validasi skema JSON.
- Membiarkan file node yang usang setelah restart Pod atau pelepasan claim.
- Me-mount file kosong setelah kegagalan pembuatan sehingga aplikasi menganggap perangkat dapat digunakan.
- Memperlakukan fitur alpha sebagai API yang stabil di semua versi.
Pertanyaan lanjutan dan tanggapan
Mengapa tidak menggunakan variabel lingkungan secara langsung?
Variabel lingkungan cocok untuk beberapa nilai statis tetapi merepotkan untuk banyak perangkat, field terstruktur, dan perubahan siklus hidup. File JSON read-only membawa struktur serta semantik versi dan kegagalan yang eksplisit.
Bagaimana Anda mencegah kebocoran lintas tenant?
Gunakan claim, request, dan node sebagai batas otorisasi penulisan; izinkan driver untuk menulis hanya perangkat yang dialokasikan, filter field sensitif, isolasi mount per Pod, dan uji bahwa claim lain tidak dapat dibaca.
Bagaimana Anda meluncurkan kapabilitas alpha?
Konfirmasikan versi kluster, status fitur, pustaka driver, dan kompatibilitas kubelet; lakukan canary pada kumpulan node kecil di balik feature gate, pertahankan fallback aplikasi atau driver, dan sertakan perubahan skema dalam rollback serta peringatan (alerting).