Gesaan dan konteks
Anda memiliki kluster Kubernetes untuk tugas latihan dan inferens. Nod mengandungi H100, A100, dan pemecut yang lebih kecil. Beban kerja menginginkan H100 terlebih dahulu, kemudian A100, dan seterusnya peranti serasi lain apabila kapasiti tidak tersedia. Reka bentuk permintaan dan aliran penjadualan Dynamic Resource Allocation (DRA), meliputi determinisme, keadilan, kegagalan, kebolehperhatian, migrasi, dan rollback. Jawab sebagai jurutera kanan yang mampu membuat pertimbangan kompromi seni bina.
Perkara yang diuji oleh penemu duga
- Sama ada keutamaan ialah dasar yang boleh disahkan dan bukannya pengundian (polling) pihak klien atau penuntutan yang dikod keras.
- Pemahaman tentang kitaran hayat ResourceClaim, ResourceSlice, pemacu (driver), dan penjadual.
- Pemutus seri deterministik, perubahan kesihatan, percubaan semula, dan had masa tamat (timeouts).
- Peruntukan kapasiti yang adil, pengasingan penyewa (tenant), metrik, dan kebolehaupitan.
- Laluan migrasi yang boleh berpatah balik daripada pemalam peranti kepada DRA.
Soalan untuk penjelasan
- Adakah sebarang fallback yang tersedia boleh diterima, atau adakah memori, seni bina, dan keupayaan pemacu mesti kekal sebagai kekangan tegar (hard constraints)?
- Bolehkah satu Pod menerima model peranti yang berbeza? Adakah topologi, NUMA, dan lebar jalur rangkaian merupakan kekangan tegar?
- Adakah perniagaan memerlukan jaminan model yang ketat, atau bolehkah ia mengorbankan keutamaan model demi kadar kejayaan dan kos?
- Adakah penyewa mempunyai kuota, keutamaan, dan peraturan preemption? Bilakah peranti yang tidak sihat dikeluarkan daripada calon?
- Bolehkah beban kerja sedia ada mengguna pakai ResourceClaims, dan adakah pemalam peranti lama mesti wujud bersama semasa migrasi?
Jawapan 30 saat
Saya akan mengekodkan keutamaan peranti sebagai calon tersusun berserta kekangan tegar dalam permintaan DRA, membenarkan penjadual memadankan sumber semasa kitaran hayat tuntutan dan bukannya meminta klien mengundi nod. Penjadual menapis kekangan pemacu, seni bina, topologi, dan kuota penyewa terlebih dahulu, kemudian menilai H100, A100, dan peranti serasi lain mengikut urutan. Setiap peringkat menggunakan pemutus seri yang stabil, dan peristiwa serta metrik merekodkan calon, sebab penolakan, dan pilihan akhir. Perubahan kesihatan atau kegagalan pengikatan mencetuskan penilaian semula hanya semasa tuntutan boleh dicuba semula. Kuota baris gilir dan pemberat penyewa menyediakan keadilan. Migrasi menggunakan kanari dua trek, templat ResourceClaim berversi, dan suis kembali kepada pemalam lama.
Perincian langkah demi langkah
1. Tentukan model keutamaan
Anggap susunan model sebagai keutamaan lembut. Anggap versi pemacu, seni bina, aras memori minimum, topologi, dan pengasingan sebagai kekangan tegar. Permintaan boleh menyatakan "H100 dahulu, A100 kedua," tetapi fallback tidak boleh memintas memori atau kuota penyewa. Sertakan pengecam dasar berversi untuk audit dan rollback.
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
spec:
spec:
devices:
requests:
- name: accelerator
exactly:
deviceClassName: gpu
selectors:
- cel: "device.attributes['model'] == 'H100'"
- cel: "device.attributes['model'] == 'A100'"Calon yang disusun menyatakan keutamaan perniagaan; penggunaan masih mesti sepadan dengan versi API DRA dan keupayaan pemacu yang disokong oleh kluster.
2. Tuntutan sumber dan aliran penjadualan
Pod menggunakan ResourceClaimTemplate untuk membuat tuntutan. Pemacu DRA menerbitkan ResourceSlices yang mengandungi atribut peranti, kapasiti, dan kesihatan. Semasa pra-penapisan, penjadual membaca tuntutan dan hirisan, mengesahkan kekangan tegar, dan mencari calon mengikut urutan. Selepas pengikatan, pemacu mendedahkan peruntukan kepada bekas (container). Tuntutan mestilah idempoten supaya percubaan semula tidak mencipta peruntukan kedua yang tidak boleh ditebus guna.
3. Pilihan deterministik dan penjelasan
Apabila sesuatu peringkat mempunyai berbilang peranti, gunakan susunan stabil berdasarkan kolam sumber, nama ResourceSlice, dan pengecam peranti, atau kedudukan kapasiti dan topologi yang jelas. Jadikan peraturan tersebut sebahagian daripada kontrak antara muka. Rekodkan calon, penapis, sebab penolakan, peranti akhir, dan versi dasar. Memainkan semula input yang sama harus menghasilkan keputusan yang sama, dan pengendali boleh menerangkan sebab H100 dilangkau.
4. Tingkah laku kegagalan, kesihatan, dan percubaan semula
Tuntutan baharu harus melangkau peranti yang ditandakan tidak sihat; beban kerja yang telah terikat mengikut dasar masa jalanan dan pengawal untuk penamatan, migrasi, atau penciptaan semula. Bezakan konflik pengikatan, hirisan lapuk, dan kehilangan nod sebagai boleh dicuba semula atau terminal. Percubaan semula memerlukan backoff dan kunci keidempotenan untuk mengelakkan imbasan berulang yang membebankan penjadual. Berundur (fallback) ke A100 hanya sah apabila kekangan tegar masih dipenuhi, dan model sebenar mesti kelihatan dalam status Pod.
5. Keadilan, kapasiti, dan kebolehperhatian
Keutamaan tidak boleh menjadi pas yang menempah H100 selama-lamanya. Timbang tara peringkat baris gilir menggunakan kuota penyewa, pemberat, dan masa menunggu; pilihan peringkat peranti mengikut susunan calon. Jejaki volum permintaan mengikut model, kadar fallback, masa menunggu, kegagalan pengikatan, perubahan kesihatan, penggunaan penyewa, dan kadar ketepatan dasar. Kekalkan rantaian keputusan yang boleh dibaca dalam peristiwa sambil mengelakkan data sensitif penyewa dalam log.
6. Migrasi dan rollback
Mulakan dengan kelas DRA dan templat ResourceClaim untuk sebahagian kecil beban kerja sementara pemalam peranti lama memberi perkhidmatan kepada selebihnya. Bandingkan kadar kejayaan, kadar fallback, kependaman penjadualan, dan penggunaan GPU sebelum berkembang. Versikan templat dan dasar. Jika isu pemacu atau penjadualan muncul, hentikan penerbitan templat baharu dan tukar beban kerja kembali ke pemalam lama; kendalikan tugasan yang telah terikat di bawah dasar penamatan yang ditetapkan dan bukannya menukar tuntutan dan peruntukan peranti secara serentak.
Jawapan model
Saya akan mengasingkan keutamaan, kekangan, dan bukti peruntukan. Keutamaan ialah senarai calon yang tersusun. Kekangan meliputi keupayaan model, memori, pemacu, topologi, kuota penyewa, dan pengasingan. Selepas Pod mencipta ResourceClaim, pemacu DRA menerbitkan ResourceSlices dan penjadual menapis kekangan tegar sebelum memilih calon mengikut urutan. Susunan kolam sumber dan pengecam peranti yang stabil menyelesaikan seri, menjadikan main semula bersifat deterministik. Peristiwa merangkumi calon, sebab penolakan, versi dasar, dan model sebenar.
Laluan kegagalan membezakan peranti tidak sihat, konflik pengikatan, tuntutan lapuk, dan kehilangan nod. Hanya ralat yang boleh dicuba semula menggunakan backoff; fallback tidak pernah melanggar kekangan tegar, dan model akhir ditulis pada status. Kuota penyewa, pemberat baris gilir, dan masa menunggu melindungi keadilan supaya keutamaan H100 tidak membiarkan penyewa lain kelaparan sumber. Migrasi menjalankan pemalam lama dan DRA dalam bentuk kanari, dengan templat berversi dan suis rollback yang telah diuji.
Kesilapan biasa
- Hanya menyatakan "susun mengikut model" tanpa kekangan tegar atau pemutus seri dalam peringkat.
- Membenarkan klien mengimbas nod atau menuntut peranti secara langsung, memintas tuntutan dan penjadual.
- Menganggap perubahan kesihatan, konflik pengikatan, dan kekangan yang tidak dapat dipenuhi sebagai percubaan semula tanpa had.
- Mengoptimumkan kadar ketepatan H100 sahaja sambil mengabaikan keadilan penyewa, kuota, dan masa menunggu.
- Mengalih keluar pemalam peranti lama dalam satu langkah, tanpa meninggalkan laluan rollback yang pantas.
- Hanya merekodkan peranti akhir dan kehilangan bukti calon serta penolakan.
Soalan susulan dan jawapan
Jika kedua-dua H100 dan A100 memenuhi kekangan, mengapa tidak memilih secara rawak?
Pilihan rawak melemahkan kebolehulangan main semula dan diagnosis. Pengimbangan kapasiti boleh mengikut susunan yang stabil, tetapi peraturan itu mesti kekal boleh diterangkan dan boleh diperhatikan; benih rawak tidak boleh menjadi kontrak tersembunyi.
Bagaimana jika peranti menjadi tidak sihat selepas pra-penapisan tetapi sebelum pengikatan?
Semak semula versi dan kesihatan semasa pengikatan. Kembalikan ralat terperingkat dan cuba semula dengan backoff hanya apabila tuntutan kekal sah dan calon masih wujud; jika tidak, dedahkan sebab tidak dapat dipenuhi yang jelas pada Pod.
Bagaimanakah anda membuktikan fallback tidak menjejaskan keadilan?
Ukur masa menunggu, penggunaan, kadar fallback, dan bahagian baris gilir mengikut penyewa dan model, kemudian bandingkan kohort main semula dan kanari. Jika penyewa jarang mendapat pilihan pertamanya, laraskan kuota atau pemberat dan bukannya terus meningkatkan keutamaan permintaan.