Gesaan dan skop
Kluster berbilang penyewa mempunyai memori GPU dan lebar jalur NIC maya yang tidak boleh diperuntukkan hanya sebagai peranti penuh. Platform mahu beberapa Pod berkongsi satu peranti, manakala setiap permintaan mempunyai nilai minimum, langkah (step), had atas dan identiti peruntukan yang boleh dikesan. Reka bentuk model sumber dan aliran hujung ke hujung dengan consumable capacity Kubernetes DRA.
Andaikan Kubernetes 1.34 dan pemacu yang boleh menguatkuasakan had kapasiti. Penjadual (scheduler) tidak boleh terlebih langgan (oversubscribe) sesuatu peranti. Kubernetes 1.34 menjadikan API DRA teras tersedia secara umum (GA) manakala consumable capacity ialah keupayaan alfa; jawapan yang mantap menandakan sempadan antara API stabil, feature gate dan jaminan khusus pemacu.
Perkara yang dinilai oleh penemu duga
Jawapan harus menetapkan tanggungjawab yang jelas kepada DeviceClass, ResourceSlice, ResourceClaim, DeviceRequest, scheduler dan pemacu. Ia harus menyatakan invarian bahawa kapasiti yang diperuntukkan untuk satu peranti tidak pernah melebihi jumlah kapasiti, dan menerangkan allowMultipleAllocations, RequestPolicy, ShareID dan DistinctAttribute.
Penemu duga juga menyemak sama ada anda mengelirukan keputusan penjadualan yang berjaya dengan pendikit (throttling) peringkat aplikasi. Reka bentuk pengeluaran memerlukan penguatkuasaan pemacu, pelaporan status, kebenaran ruang nama, pemulihan kegagalan nod dan pelancaran yang boleh diundur semula (reversible).
Soalan penjelasan
Bolehkah sumber itu diasingkan?
Sahkan sama ada perkakasan atau pemacu boleh menguatkuasakan pengasingan. Jika tidak boleh, platform boleh menawarkan kuota lembut atau peruntukan seluruh peranti, tetapi ia tidak boleh menjanjikan QoS daripada medan API semata-mata.
Apakah sempadan perkongsian dan kebenaran?
Tanya sama ada ruang nama boleh berkongsi peranti, sama ada akses pentadbir dibenarkan, dan atribut atau kapasiti peranti yang boleh dibaca oleh penyewa. Jawapan ini mengubah pemilih, semakan kemasukan (admission) dan skop audit.
Apakah yang mesti bertahan daripada kegagalan?
Jelaskan perkara yang berlaku selepas kegagalan penjadualan, kegagalan peruntukan pemacu, kehilangan nod atau penciptaan semula Pod: pelepasan, pengekalan pajakan (lease) atau baris gilir semula (requeue). Percubaan semula sementara dan kegagalan perkakasan kekal memerlukan keadaan yang berbeza.
Rangka kerja jawapan 30 saat
"Saya mentakrifkan invarian kapasiti dan sempadan penyewa terlebih dahulu. DeviceClass menerangkan peranti yang layak, ResourceSlice menerbitkan kapasiti dan dasar permintaan, dan ResourceClaim menyatakan keperluan Pod. Scheduler memilih peranti tanpa melebihi kapasiti; pemacu menggunakan ShareID untuk menguatkuasakan had memori atau lebar jalur sebenar dan melaporkan status. Perkongsian merentas ruang nama memerlukan kebenaran dan audit. Setiap pelepasan adalah idempoten. Saya melancarkan satu kelas peranti pada satu masa dan membandingkan kapasiti yang diperuntukkan, had sebenar, kependaman penjadualan, kadar penolakan dan masa pemulihan."
Perincian langkah demi langkah
Langkah satu: tentukan model sumber
DeviceClass menerangkan jenis peranti dan pemilih CEL. ResourceSlice menerbitkan setiap peranti, atributnya, kapasiti dan sama ada pelbagai peruntukan dibenarkan. ResourceClaim menggunakan DeviceRequest untuk menyatakan kelas dan kapasiti. Asingkan jumlah kapasiti peranti daripada kapasiti permintaan; kiraan peranti bernilai satu bukanlah nilai kapasiti.
Langkah dua: nyatakan invarian kapasiti
Bagi setiap peranti, jejak kapasiti yang diperuntukkan, unit dan dasar permintaan. Jika peranti mempunyai 40 GiB dan permintaan mestilah sekurang-kurangnya 5 GiB dalam gandaan 5 GiB, setiap permintaan mesti memenuhi batas tersebut dan semua ShareID aktif mesti berjumlah paling banyak 40 GiB. Operasi pelepasan dan percubaan semula menggunakan versi peruntukan supaya panggilan balik (callback) pendua tidak menolak dua kali.
Langkah tiga: terangkan aliran data penjadualan dan pemacu
Scheduler membaca ResourceSlice, menapis pemilih, julat kapasiti dan allowMultipleAllocations, menempah calon dan mengikat ResourceClaim. Pemacu menerima peruntukan, mencipta had bebas yang ditentukan oleh ShareID, mengaplikasikannya pada peranti dan melaporkan data dinamik dalam status ResourceClaim. Jika penjadualan berjaya tetapi pemacu menolak peruntukan, pengawal (controller) mendedahkan keadaan yang boleh dicuba semula atau terminal; ia tidak boleh menjadikan Pod kelihatan Ready.
Langkah empat: kendalikan ruang nama dan peranti pendua
Peranti yang dikongsi tidak memadamkan sempadan ruang nama ResourceClaim. Kemasukan (admission) harus mengehadkan penggunaan DeviceClass, akses pentadbir dan konfigurasi pemacu. DistinctAttribute menghalang satu claim daripada memilih peranti asas yang sama dua kali, seperti apabila dua antara muka rangkaian mesti mencapai subnet yang berbeza. Audit penyewa, claim, ShareID, kapasiti dan versi dasar dan bukannya hanya nama peranti akhir.
Langkah lima: reka bentuk kegagalan dan penambusgunaan (reclamation)
Selepas pemacu dimulakan semula, pulihkan ShareID dan had sebenar daripada keadaan tahan lama (durable state). Selepas kehilangan nod, tandakan peruntukan sebagai unknown dan jangan berikan kapasiti itu serta-merta kepada Pod lain sehingga pajakan (lease), pemagaran peranti (device fence) atau pengesahan pemacu membuktikan peruntukan lama telah tiada. Pemadaman Pod, tamat tempoh claim dan pengunduran (rollback) penjadualan mesti boleh diulang. Peruntukan sedia ada mengekalkan snapshot dasar mereka; claim baharu menggunakan dasar yang telah diubah.
Langkah enam: pelancaran, SLO dan pengiraan kapasiti
Andaikan 100 peranti dengan 40 GiB setiap satu dan sasaran purata penggunaan sebanyak 70 peratus. Kapasiti boleh dijadualkan secara logik adalah kira-kira 2,800 GiB, bukan janji daya pemprosesan (throughput); simpan ruang atas untuk overhed pemacu, pemecahan (fragmentation) dan toleransi kegagalan. Tetapkan SLO untuk p99 penjadualan, p99 konfigurasi pemacu, kadar penolakan kapasiti dan penumpuan status. Dayakan feature gate bagi setiap kelas peranti. Bandingkan daya pemprosesan, kependaman ekor, pemecahan dan pemulihan dengan peruntukan seluruh peranti.
Langkah tujuh: bandingkan alternatif
Jika perkakasan hanya menyokong hirisan tetap, MIG atau DeviceClasses yang diprapemotongan adalah lebih mudah dan lebih senang untuk dibuktikan, dengan kos pemecahan dan kurang keanjalan. Jika pemacu tidak dapat menguatkuasakan had terperinci, kembali kepada peruntukan seluruh peranti atau pengembangan kapasiti; jangan menganggap bahawa medan kapasiti secara automatik menyediakan pengasingan.
Contoh jawapan berkualiti tinggi
Saya terlebih dahulu mengesahkan sama ada peranti boleh menguatkuasakan pengasingan kapasiti. Jika tidak boleh, reka bentuk tersebut hanyalah pemilihan deklaratif dan tidak mempunyai jaminan QoS. Jika boleh, DeviceClass menerangkan peranti yang layak, ResourceSlice menerbitkan kapasiti dan dasar permintaan, dan ResourceClaim membawa permintaan penyewa. Scheduler mengikat hanya apabila pemilih sepadan dan jumlah kapasiti kekal di bawah had peranti; pemacu kemudiannya mencipta had berskop ShareID dan melaporkan status.
Saya menjadikan jumlah kapasiti, versi dasar dan pelepasan idempoten sebagai invarian eksplisit. Perkongsian merentas ruang nama menggunakan kemasukan, kebenaran pentadbir dan audit; DistinctAttribute menghalang pilihan peranti asas yang berulang dalam satu claim. Apabila berlaku kegagalan pemacu atau nod, saya mengekalkan peruntukan unknown sehingga pemagaran (fencing) atau pengesahan diperoleh sebelum menuntutnya semula. Pelancaran bermula dengan satu kelas dan mengukur p99 penjadualan, p99 pemacu, penolakan, penguatkuasaan sebenar dan pemulihan. Perkakasan hirisan tetap menggunakan reka bentuk prapemotongan.
Kesilapan biasa
- Gejala → meletakkan nilai kapasiti hanya dalam ResourceClaim → Sebab ia gagal → pemacu mungkin tidak menguatkuasakan had sebenar → Pembetulan → buktikan laluan penguatkuasaan dan status.
- Gejala → menggunakan kiraan peranti sebagai jumlah kapasiti → Sebab ia gagal → permintaan serentak terlebih langgan atau membazirkan serpihan → Pembetulan → jejak kapasiti yang diperuntukkan bagi setiap peranti dan versi.
- Gejala → menganggap peranti kongsi sebagai perkongsian merentas penyewa tanpa syarat → Sebab ia gagal → sempadan ruang nama dan kebenaran hilang → Pembetulan → tambah kemasukan, kawalan akses pentadbir dan audit.
- Gejala → melepaskan kapasiti serta-merta selepas kehilangan nod → Sebab ia gagal → pemacu lama mungkin masih menguatkuasakan peruntukan, mewujudkan tugasan berganda → Pembetulan → laksanakan pagar (fence), sahkan pajakan atau kekalkan keadaan unknown yang jelas.
- Gejala → menjanjikan SLO yang stabil untuk feature gate alfa → Sebab ia gagal → tingkah laku API, pemacu dan peningkatan adalah berbeza-beza → Pembetulan → tandakan sempadan versi dan sahkan melalui canary.
Soalan susulan dan respons yang mantap
Soalan susulan satu: Dua ruang nama meminta 10 GiB terakhir secara serentak. Bagaimanakah anda mengelakkan race condition?
Gunakan versi ResourceSlice atau semakan kebersamaan optimistik yang setara semasa menempah kapasiti. Jika pengikatan gagal, baca semula keadaan semasa dan cuba lagi. Panggilan balik pemacu tidak boleh memintas invarian scheduler; satah kawalan (control plane) mengesahkan peruntukan akhir.
Soalan susulan dua: Pemacu melaporkan ShareID, tetapi Pod tidak pernah bermula. Apakah yang berlaku?
Asingkan keadaan peruntukan daripada kesediaan (readiness) Pod. Selepas tamat masa (timeout), pengawal melakukan pelepasan idempoten atau memasuki keadaan yang boleh dilihat oleh pengendali sambil mengekalkan ShareID, versi claim dan sebab. Jangan buang kapasiti atau data audit semata-mata kerana Pod tidak berada dalam keadaan Running.
Soalan susulan tiga: Dasar berubah daripada minimum 5 GiB kepada 10 GiB. Adakah claim sedia ada berubah?
Peruntukan yang telah selesai mengekalkan snapshot dasar tempat ia diberikan; claim baharu menggunakan dasar baharu. Pengimbangan semula memerlukan aliran penghijrahan yang jelas, sokongan pemacu untuk saiz semula dan jujukan pelepasan-dan-peruntukan-semula yang boleh diterbalikkan.
Soalan susulan empat: Bagaimanakah anda membuktikan bahawa lebar jalur yang dikongsi benar-benar dikuatkuasakan?
Jalankan garis dasar penyewa tunggal dan ujian beban berbilang ShareID dengan trafik, nod dan versi pemacu yang tetap. Bandingkan daya pemprosesan bagi setiap penyewa, p99, keguguran paket dan siling penguatkuasaan. Status ResourceClaim sahaja tidak membuktikan QoS perkakasan.