Gesaan dan skop
Kluster menggunakan Dynamic Resource Allocation (DRA) untuk GPU atau peranti rangkaian. Sebuah kontena memerlukan atribut PCI, antara muka atau pemacu untuk peranti yang diperuntukkan kepadanya tetapi tidak boleh menerima akses API Kubernetes. Reka bentuk laluan metadata daripada pemacu ke kontena dan terangkan pemversian, pengasingan, kegagalan dan tingkah laku naik taraf.
Perkara yang diuji oleh penemu duga
- Sama ada anda memahami sempadan tanggungjawab antara pemacu DRA, ResourceClaim, kubelet dan kontena.
- Sama ada anda boleh menentukan laluan metadata, masa penjanaan, pelekapan (mounting) dan kitaran hayat pembersihan.
- Sama ada anda mengendalikan medan pemacu yang tidak dipercayai, kebocoran rentas nod, keserasian versi dan mula semula Pod.
- Sama ada anda menyemak status ciri dan versi yang disokong dan bukannya menganggap status alpha sebagai kontrak yang stabil.
Soalan penjelasan
- Adakah metadata tersebut merupakan data penemuan (discovery), konfigurasi rangkaian, atau bahan sensitif seperti kelayakan?
- Medan dan versi skema manakah yang diperlukan, dan bolehkah aplikasi bertolak ansur dengan data yang hilang atau lewat?
- Adakah kluster dan nod menyokong metadata peranti DRA, dan adakah pemacu menggunakan pustaka rasmi?
- Apakah yang membatalkan fail selepas peruntukan semula, mula semula Pod, naik taraf pemacu atau kegagalan nod?
Jawapan 30 saat
Saya akan menetapkan pemacu hanya mendedahkan metadata bukan sensitif untuk ResourceClaim semasa dan membiarkan kubelet menjana JSON berversi semasa penyediaan peranti, yang dilekapkan secara baca sahaja pada laluan yang didokumenkan. Aplikasi membaca fail, bukan API; penciptaan, pengemaskinian, nyahlekap dan pembersihan mengikut kitaran hayat Pod. Sahkan medan dan saiz, serta jadikan kegagalan pemacu boleh diperhatikan (observable) dan bukannya mendedahkan fail separa. Memandangkan keupayaan ini adalah alpha, kekalkan pengesanan versi dan sandaran (fallback) kepada pemboleh ubah persekitaran, prob, atau laluan pemacu yang lebih lama.
Reka bentuk langkah demi langkah
1. Tentukan data dan sempadan kepercayaan
DRA memperuntukkan peranti kepada ResourceClaim, pemacu mengetahui peranti fizikal dan aplikasi menggunakan hasilnya. Metadata hendaklah terhad kepada atribut peranti atau butiran antara muka, bukan kunci peribadi, token atau pengecam rentas penyewa. Ikat input pemacu pada tuntutan, permintaan dan nod supaya peranti lain tidak dapat dipancarkan ke dalam Pod.
2. Gunakan mekanisme penghantaran yang stabil
Dokumentasi mentakrifkan laluan yang diketahui umum di dalam kontena dan fail JSON untuk atribut peranti. Gunakan lekapan baca sahaja dan tahap direktori deterministik supaya aplikasi membaca fail dan bukannya menyoal API. Sertakan medan skema atau versi supaya aplikasi boleh menolak versi yang tidak diketahui dan memilih logik keserasian.
3. Kendalikan kitaran hayat dan kegagalan
Cipta fail hanya selepas peruntukan dan penyediaan berjaya; padamkannya semasa nyahsedia (unprepare), pemadaman Pod atau pelepasan tuntutan. Kegagalan penjanaan, penulisan atau pengesahan JSON tidak boleh mendedahkan fail separa. Laporkan ralat pemacu atau kubelet yang boleh diperhatikan dan halang aplikasi daripada menggunakan data yang tidak sah. Selepas mula semula, jana semula daripada tuntutan semasa dan bukannya menggunakan semula fail nod yang lapuk (stale).
4. Rancang peningkatan dan kebolehcerapan
Dokumenkan matriks versi untuk pustaka pemacu, kubelet, nod dan aplikasi. Pantau kependaman penjanaan, kadar kegagalan, penolakan skema, versi pemacu dan mula semula Pod; log pengecam tuntutan, permintaan dan nod tanpa kandungan metadata. Kawal naik taraf alpha dengan skema yang serasi, feature gates dan pengunduran (rollback) yang telah diuji.
Model jawapan berkualiti tinggi
Saya akan menjadikan metadata peranti sebagai unjuran baca sahaja bagi peruntukan DRA. Pemacu hanya menulis atribut bukan sensitif untuk ResourceClaim dan nod semasa; kubelet mengubahnya menjadi JSON berversi dan melekapkannya secara baca sahaja pada laluan yang diketahui umum selepas penyediaan peranti. Aplikasi tidak memerlukan sebarang kebenaran API Kubernetes. Sebelum menulis, sahkan tuntutan, permintaan, pengikatan nod, senarai izin (allowlist) dan saiz; selepas menulis, sahkan skema. Jika berlaku kegagalan, jangan lekapkan fail separa dan dedahkan ralat yang boleh diperhatikan. Bersihkan semasa pelepasan atau pemadaman Pod dan jana semula selepas mula semula. Memandangkan keupayaan ini adalah alpha, kesan sokongan, gunakan feature gate, kekalkan sandaran kepada laluan yang lebih lama atau persekitaran eksplisit, dan pantau kegagalan, kependaman serta versi pemacu dan bukannya menjanjikan kestabilan fail rentas versi.
Kesilapan biasa
- Memberikan kontena akses API Kubernetes atau RBAC yang terlalu luas.
- Mendedahkan setiap medan pemacu, termasuk kelayakan atau data peranti penyewa lain.
- Mengabaikan medan versi, senarai izin dan pengesahan skema JSON.
- Mengekalkan fail nod yang lapuk selepas mula semula Pod atau pelepasan tuntutan.
- Melekapkan fail kosong selepas kegagalan penjanaan sehingga aplikasi menganggap peranti boleh digunakan.
- Memperlakukan ciri alpha sebagai API yang stabil merentas semua versi.
Soalan susulan dan jawapan
Mengapa tidak menggunakan pemboleh ubah persekitaran secara langsung?
Pemboleh ubah persekitaran sesuai untuk beberapa nilai statik tetapi sukar untuk berbilang peranti, medan berstruktur dan perubahan kitaran hayat. Fail JSON baca sahaja membawa struktur dan semantik versi serta kegagalan yang eksplisit.
Bagaimanakah anda menghalang kebocoran rentas penyewa?
Gunakan tuntutan, permintaan dan nod sebagai sempadan kebenaran penulisan; benarkan pemacu menulis hanya peranti yang diperuntukkan, tapis medan sensitif, asingkan lekapan bagi setiap Pod dan uji bahawa tuntutan lain tidak boleh dibaca.
Bagaimanakah anda melancarkan keupayaan alpha?
Sahkan versi kluster, status ciri, pustaka pemacu dan keserasian kubelet; lakukan canary pada kumpulan nod kecil di sebalik feature gate, kekalkan sandaran aplikasi atau pemacu, dan sertakan perubahan skema dalam pengunduran dan amaran (alerting).