Gesaan dan skop
Platform pembelajaran mesin berbilang penyewa menggunakan GPU, FPGA, dan NIC berkelajuan tinggi. Reka bentuk semasanya memperuntukkan keseluruhan peranti melalui label nod, extended resources, dan device plugins, menjadikan atribut peranti, perkongsian, dan pengasingan penyewa sukar untuk dinyatakan. Pasukan ingin menerima pakai Dynamic Resource Allocation (DRA), yang API teras resource.k8s.io/v1 telah menjadi stabil dalam Kubernetes 1.34.
Reka bentuk migrasi ini dan terangkan tanggungjawab ResourceClaim, DeviceClass, ResourceClaimTemplate, ResourceSlice, pemacu, dan penjadual (scheduler). Kluster mesti berhijrah secara beransur-ansur tanpa memulakan semula setiap beban kerja sekaligus.
Perkara yang dinilai oleh penemu duga
Penemu duga ingin melihat pemisahan antara pengisytiharan keperluan peranti dan peruntukan peranti yang konkrit. Terangkan aliran data antara API satah kawalan, penjadual, pemacu nod, dan kubelet, serta bezakan API DRA yang stabil daripada keupayaan yang masih bersifat eksperimen atau khusus untuk pemacu.
Jawapan yang mantap merangkumi perkongsian kapasiti, rujukan rentas ruang nama (cross-namespace), kegagalan pemacu, penggantian Pod, kewujudan bersama dengan beban kerja lama, prinsip keistimewaan paling sedikit (least privilege), dan isyarat pengunduran dan bukannya sekadar menyenaraikan jenis sumber.
Soalan penjelasan sebelum menjawab
- Adakah permintaan ini untuk keseluruhan peranti, kapasiti yang boleh dihiris (sliceable), atau sebarang peranti yang sepadan dengan atribut tertentu?
- Adakah pemacu menyokong DRA, dan bolehkah pemalam peranti lama beroperasi semasa migrasi?
- Patutkah beban kerja mencipta Claims secara langsung, atau patutkah templat platform yang menciptanya?
- Bolehkah penyewa menggunakan semula Claims merentasi ruang nama, dan objek manakah yang boleh ditulis oleh pengawal platform?
- Semasa migrasi, adakah keutamaannya ialah kesinambungan tugasan, daya pemprosesan (throughput) penjadualan, atau penggunaan (utilization)?
Rangka kerja jawapan 30 saat
“Saya akan memodelkan keperluan peranti sebagai Claims, membiarkan pemacu menemui, memperuntukkan, dan mengkonfigurasi peranti, serta membiarkan penjadual membuat keputusan kebolehlaksanaan daripada Claims dan ResourceSlices. Saya akan menjalankan ujian canary untuk kelas peranti kecil dalam ruang nama yang terpencil. Pemalam lama dan DRA boleh wujud bersama mengikut kolam (pool), tetapi mereka tidak boleh memiliki peranti yang sama. Setiap fasa mengukur keadaan Claim, pengikatan Pod, keterlihatan nod, ralat pemacu, pendaman peruntukan, dan sempadan penyewa. Jika peruntukan gagal, saya menghentikan Claims baharu, mengekalkan tugasan yang sedang berjalan, dan menghalakan beban kerja baharu kembali ke laluan lama.”
Jawapan mendalam langkah demi langkah
Lakarkan aliran data DRA terlebih dahulu
Beban kerja merujuk kepada Claim melalui medan resourceClaims pada Pod. Sesuatu Claim boleh dicipta secara langsung atau dijana untuk sesuatu Job oleh ResourceClaimTemplate. DeviceClass menerangkan kelas peranti yang boleh dipilih, manakala pemacu menerbitkan peranti nod dan atribut melalui ResourceSlice. Penjadual menggabungkan Pod, Claim, DeviceClass, dan ResourceSlice untuk memilih nod; pemacu nod kemudiannya melaksanakan peruntukan dan konfigurasi konkrit.
Ini memisahkan pemilihan peranti daripada YAML aplikasi dan mengelakkan pengekodan topologi perkakasan ke dalam konvensyen label.
Reka bentuk templat Claim dan sempadan penyewa
Dedahkan hanya parameter yang menghadap penyewa seperti peringkat memori, jenis sambungan, atau lebar jalur rangkaian. Jangan dedahkan pengecam dalaman pemacu. Pengawal platform menggunakan dasar kemasukan (admission policy) ruang nama, kuota, dan pembersihan kitaran hayat. Penggunaan Claim rentas ruang nama memerlukan kebenaran rujukan eksplisit dan peristiwa audit. Semasa pemadaman penyewa, hentikan Claims baharu, tunggu Pod melepaskan peranti, dan kemudian tuntut semula keadaan peranti.
Kendalikan peranti penuh dan kapasiti boleh kongsi
Peruntukan keseluruhan peranti boleh memetakan satu DeviceRequest kepada satu peranti. Berkongsi memori, lebar jalur, atau hirisan masa memerlukan pemacu menerbitkan kapasiti dan menyokong tingkah laku kapasiti boleh guna DRA yang berkaitan. Jangan simulasikan perkongsian dengan label penjadual; penjadualan boleh berjaya sedangkan nod menjual lebihan (overselling) kapasiti sebenar. Tentukan unit, had konkurensi, masa pelepasan, dan dasar pemecahan (fragmentation policy).
Wujud bersama dengan pemalam peranti
Bahagikan migrasi mengikut kelas peranti atau kolam nod supaya pemalam lama dan DRA tidak pernah mengiklankan pemilikan ke atas perkakasan yang sama. Beban kerja sedia ada mengekalkan extended resources; beban kerja baharu merujuk kepada DRA Claims. Label kolam ialah sempadan migrasi, bukan sumber akhir atribut peranti. Setiap kolam memerlukan pemilikan yang jelas dan suis penyahdayaan untuk mengelakkan permulaan pemacu berganda.
Kendalikan penjadualan, preemption, dan kegagalan
Apabila Claim menunggu atau gagal, Pod harus memaparkan sebab Pending yang boleh dijelaskan. Memilih nod tidak bermakna peranti telah dikonfigurasikan; pemacu mungkin gagal semasa persediaan nod. Pengawal harus mengklasifikasikan kegagalan sebagai boleh dicuba semula, tidak boleh dicuba semula, atau memerlukan pembersihan, dan menghantar setiap kelas ke amaran yang betul. Preemption mesti mempertimbangkan keutamaan Pod, kapasiti Claim yang diduduki, dan pendaman pelepasan, bukan sekadar CPU atau memori.
Perhatikan dan rancang kapasiti
Ukur penciptaan Claim kepada pengikatan (binding), pengikatan kepada peruntukan nod, dan peruntukan kepada Pod Ready sebagai peringkat yang berasingan. Jejaki kapasiti melahu, diperuntukkan, tidak tersedia, terpecah, dan ralat pemacu. Selaraskan kapasiti yang diiklankan oleh ResourceSlices dengan apa yang sebenarnya didedahkan oleh nod; hentikan pengembangan canary apabila ia menyimpang. Platform latihan juga harus merekodkan percubaan semula, pemulihan checkpoint, dan peristiwa kesihatan peranti.
Canary, pengunduran (rollback), dan ketekalan
Mulakan dengan satu pemacu dan satu kolam nod menggunakan tugasan yang boleh dicuba semula. Kembangkan ke beberapa penyewa dan templat seterusnya; migrasikan tugasan yang berjalan lama dan tidak boleh diganggu pada fasa terakhir. Pengunduran tidak bermakna memadamkan Claims yang terikat. Hentikan penciptaan Claim baharu, biarkan Pod yang sedang berjalan selesai atau berhijrah, bekukan perubahan pemacu, dan halakan tugasan baharu ke pemalam lama. Kekalkan peristiwa Claim, Pod, dan pemacu supaya insiden tersebut kekal boleh didiagnosis.
Sahkan API dan sempadan keselamatan
Sebelum pelaksanaan, jalankan ujian kontrak terhadap API resource.k8s.io/v1 untuk versi Claim, Template, DeviceClass, dan ResourceSlice, peralihan keadaan, dan susunan pemadaman. Suntik permulaan semula pemacu, kehilangan nod, peruntukan pendua, Claim yang bocor, dan akses rentas ruang nama. Periksa kemasukan, RBAC, audit, dan kebenaran ejen nod. Kembangkan kolam peranti hanya selepas metrik kefungsian, pengasingan, dan pemulihan lulus.
Jawapan model berkualiti tinggi
“Saya akan membahagikan migrasi kepada lapisan model sumber, pemacu, penjadualan, dan masa jalanan (runtime). Beban kerja mengisytiharkan Claims; Templates menjananya; DeviceClass menyatakan pemilihan; pemacu menerbitkan ResourceSlices dan memperuntukkan pada nod; penjadual mengendalikan kebolehlaksanaan dan pilihan nod. Pemalam lama dan DRA wujud bersama mengikut kolam atau kelas peranti, tidak pernah dengan pemilikan berganda. Untuk perkongsian, saya memerlukan model kapasiti pemacu dan semantik pelepasan dan bukannya penjualan lebihan berasaskan label. Saya bermula dengan tugasan yang boleh dicuba semula, mengukur pendaman Claim-ke-Ready, kegagalan peruntukan, pemecahan, kesihatan pemacu, dan pelanggaran penyewa, kemudian menghentikan Claims baharu dan mengekalkan keadaan sebelum menghalakan tugasan baharu kembali semasa pengunduran.”
Kesilapan lazim
- Menganggap DRA sebagai label peranti baharu → penjadualan berjaya tanpa pemenuhan pada peringkat nod → pastikan pemacu menerbitkan peranti berstruktur dan kapasiti.
- Membiarkan pemalam dan DRA memiliki satu peranti yang sama → permulaan pendua atau peruntukan bertindih → bahagikan pemilikan mengikut kolam atau kelas peranti.
- Mereka bentuk Claims tanpa penebusgunaan (reclamation) → kebocoran peranti dan kuota terkumpul → tentukan pelepasan, tamat masa, pemadaman, dan penyelarasan.
- Mensimulasikan perkongsian dengan label → penjadual tidak dapat melihat baki kapasiti sebenar → buat pemacu menerbitkan kapasiti dan konkurensi.
- Menyamakan pemilihan nod dengan kejayaan peruntukan → ralat pemacu menyebabkan Pod kekal Pending selama-lamanya → asingkan metrik penjadualan, peruntukan nod, dan Ready.
- Memadamkan setiap Claim semasa pengunduran → tugasan yang sedang berjalan dan bukti diagnostik hilang → bekukan peruntukan baharu dan kekalkan keadaan.
Soalan susulan dan respons
Susulan 1: Mengapa tidak terus mendaftarkan GPU sebagai extended resources?
Extended resources sesuai untuk permintaan kuantiti mudah tetapi tidak menyatakan atribut peranti, alternatif, kapasiti dikongsi, atau konfigurasi kompleks dengan baik. Jika keperluannya hanyalah pengiraan keseluruhan peranti dan pemacu sudah matang, laluan lama boleh dikekalkan. DRA harus diperkenalkan apabila pemilihan peranti dan kerumitan kitaran hayat mewajarkannya.
Susulan 2: Bagaimanakah anda mengelakkan penjualan berlebihan (overselling) apabila beberapa Pod merujuk satu Claim?
Semantik penggunaan semula mesti jelas dalam dasar pemacu dan platform, bukan diandaikan daripada YAML. Untuk kapasiti yang dikongsi, pemacu merekodkan kapasiti yang diperuntukkan, had konkurensi, dan keadaan pelepasan; kemasukan mengehadkan rujukan yang melanggar dasar penyewa.
Susulan 3: Patutkah penjadual mencuba semula kegagalan pemacu semasa persediaan nod?
Klasifikasikan kegagalan nod sementara, kegagalan kesihatan peranti, dan parameter Claim yang tidak sah terlebih dahulu. Cuba semula kegagalan sementara dengan backoff; tandakan parameter tidak sah sebagai tidak boleh dicuba semula; asingkan nod yang tidak sihat supaya penjadual tidak menghantar kerja secara berulang kali ke domain kegagalan yang sama.
Susulan 4: Bagaimanakah anda membuktikan migrasi tidak mengurangkan penggunaan (utilization)?
Bandingkan kejayaan peruntukan, masa menunggu, pemecahan, masa pengiraan yang berguna, dan kadar percubaan semula tugasan untuk beban kerja yang serupa dalam kolam peranti yang sama. Bahagikan DRA dan pemalam lama mengikut kelas peranti; purata penggunaan GPU di seluruh kluster sahaja tidak mencukupi.