Gesaan dan konteks
Anda mengendalikan platform GPU Kubernetes. Kerja latihan dan inferens kelompok mesti menunggu kuota, sumber nod, tetingkap penyelenggaraan, dan dasar keselamatan sebelum Pods dicipta. Reka bentuk kemasukan dengan Kueue Workloads, ClusterQueues, ResourceFlavors, dan AdmissionChecks, sambil menghalang kebuluran sumber (starvation) dan pelepasan yang tidak selamat.
Perkara yang diuji oleh penemu duga
Memisahkan pergiliran (queueing) daripada kemasukan (admission): Workload yang memasuki giliran tidak bermakna Pods boleh dicipta. ClusterQueue memilih perisa daripada kumpulan sumber dan kuota nominal, manakala AdmissionChecks membenarkan pengawal dalaman atau luaran mempengaruhi pelepasan. Rangkumi ketekalan keadaan, pembatalan (revocation), kemasukan separa, keadilan penyewa, penangguhan (backoff), dan kebolehpeksaan (auditability).
Soalan penjelasan untuk ditanya terlebih dahulu
Sumber dan keutamaan
Jelaskan model GPU, memori, CPU, topologi, preemption, keutamaan penyewa, keadilan giliran, dan masa menunggu maksimum. Mengira GPU sahaja boleh mewujudkan kapasiti palsu apabila memori atau topologi tidak sepadan.
Kebergantungan kemasukan luaran
Kenal pasti pengawal untuk tetingkap penyelenggaraan, pengimbasan imej, kelulusan belanjawan, dan akses data. Tentukan sama ada keputusan boleh dimainkan semula (replayable) dan sama ada tamat masa (timeout) bermaksud tolak atau tunggu. Setiap semakan luaran memerlukan pemilik dan TTL.
Dasar kegagalan dan pembatalan
Tentukan perkara yang berlaku apabila nod berubah, kuota dituntut semula, atau dasar dibatalkan selepas kemasukan. Rekod kemasukan, penciptaan Pod, dan semakan luaran memerlukan korelasi idempoten untuk mengelakkan pelepasan pendua.
Rangka kerja jawapan 30 saat
“Sesuatu Workload memasuki LocalQueue, dan ClusterQueue miliknya menilai kumpulan sumber, perisa, dan kuota kohort. Semua AdmissionCheckStates yang diperlukan mestilah Ready sebelum kemasukan; Pending kekal dalam giliran, manakala Rejected atau tamat masa mengikut dasar percubaan semula atau penamatan yang terikat. Kekalkan keadaan beban kerja yang boleh dikesan, semak semula sumber dan dasar sebelum mencipta Pods, dan ukur penggunaan kuota, masa menunggu, kependaman semakan, penolakan, dan pembatalan untuk mengesahkan keselamatan dan keadilan.”
Jawapan mendalam langkah demi langkah
Langkah 1: Tentukan sempadan Workload dan giliran
Tukarkan Job pengguna kepada Workload yang boleh dijadualkan dengan PodSets, permintaan sumber, keutamaan, dan giliran penyewa. LocalQueue menyusun dan menunggu; ia tidak boleh mencipta Pods atau memintas kekangan sumber ClusterQueue.
Langkah 2: Pilih ResourceFlavors melalui ClusterQueue
Huraikan sumber CPU, memori, dan GPU dengan ResourceGroups, kemudian pilih gabungan perisa dengan kuota nominal yang tersedia. Letakkan model GPU, rantau, label nod, dan topologi dalam kekangan perisa supaya "GPU yang mencukupi" tidak menjadi kemasukan palsu.
Langkah 3: Selaraskan mesin keadaan AdmissionCheck
Dedahkan keadaan Pending, Ready, Rejected, dan terminal yang boleh dicerap. Pengawal keselamatan, penyelenggaraan, dan belanjawan mengemas kini keadaan secara idempoten menggunakan UID Workload. Kueue hanya menerima apabila setiap semakan yang diperlukan adalah Ready; Pending tidak boleh tersilap dilabelkan sebagai kegagalan, dan Rejected tidak boleh diabaikan secara senyap.
Langkah 4: Kendalikan kemasukan separa dan perubahan sumber
Jika kemasukan separa dibenarkan, tentukan keselarian PodSet yang boleh dikurangkan, saiz minimum, dan peraturan peluasan kemudian. Nilaikan semula perisa dan semakan selepas pelepasan kuota atau kegagalan nod; jangan sekali-kali menggunakan semula snapshot kemasukan yang telah tamat tempoh. Permintaan yang mustahil secara kekal memerlukan penolakan dengan penjelasan dan bukannya percubaan semula tanpa had.
Langkah 5: Kekalkan keadilan dan halang kebuluran sumber
Tentukan sempadan perkongsian kohort dan peminjaman merentas penyewa, giliran, dan keutamaan. Halang kerja berkeutamaan tinggi daripada menduduki GPU yang terhad secara berterusan; tambah peraturan menunggu atau penuaan (aging) untuk keutamaan yang lebih rendah. Cerap peruntukan kuota, penantian semakan, dan permulaan Pod sebenar secara berasingan supaya kemasukan yang pantas dengan permulaan yang perlahan dapat dilihat.
Langkah 6: Reka bentuk pembatalan, percubaan semula, dan audit
Gunakan backoff berayun (jittered backoff) dan had percubaan semula untuk tamat masa atau kegagalan pengawal. Pembatalan mesti disebarkan dengan selamat kepada Workload dan PodSets, bukan sekadar menukar satu medan. Rekodkan pelaku, masa, sebab, perisa, versi kuota, dan versi semakan luaran supaya keputusan boleh dimainkan semula.
Langkah 7: Sahkan kebolehcerapan dan latih tubi kegagalan
Pantau masa menunggu giliran, kependaman kemasukan, tempoh Pending bagi setiap semakan, penolakan, pembatalan, penggunaan kuota, pemilihan perisa, GPU terbiar, dan permulaan Pod. Lakukan latih tubi bagi gangguan pengawal, panggilan balik pendua, penuntutan semula kuota, kegagalan nod, dan sekatan rangkaian untuk membuktikan sistem tidak melepaskan sumber secara tidak selamat mahupun tersekat selama-lamanya.
Contoh jawapan berkualiti tinggi
Saya akan meletakkan Workload dalam LocalQueue, membiarkan ClusterQueue memilih gabungan sumber yang berdaya maju daripada perisa dan kuota kohort, dan menggunakan AdmissionChecks untuk syarat keselamatan, penyelenggaraan, dan belanjawan. Benarkan kemasukan hanya apabila setiap semakan yang diperlukan adalah Ready dan snapshot sumber masih sah; Pending kekal dalam giliran dan Rejected atau tamat masa menggunakan backoff yang terikat. Model GPU, topologi, dan rantau tergolong dalam perisa. Kuota penyewa dan penuaan melindungi keadilan, manakala panggilan balik idempoten dan pembatalan tersebar dengan selamat kepada Workload dan PodSets.
Kesilapan lazim
- Kesilapan: Menganggap kemasukan ke dalam giliran sebagai kebenaran untuk mencipta Pods. → Sebab ia gagal: Beratur dan kemasukan adalah keadaan yang berasingan. → Pembetulan: Wajibkan peruntukan ClusterQueue dan semua semakan berstatus Ready.
- Kesilapan: Memilih sumber berdasarkan bilangan GPU sahaja. → Sebab ia gagal: Model, memori, topologi, atau rantau mungkin tidak sepadan. → Pembetulan: Nyatakan kekangan perkakasan dengan ResourceFlavors.
- Kesilapan: Mencuba semula semakan Pending selama-lamanya. → Sebab ia gagal: Ketidakbolehlaksanaan kekal atau kegagalan pengawal kekal tersembunyi. → Pembetulan: Bezakan Pending, Rejected, dan sebab-sebabnya dengan had dan backoff.
- Kesilapan: Membatalkan medan Workload sahaja. → Sebab ia gagal: Pods sedia ada mungkin terus menggunakan sumber. → Pembetulan: Tentukan tindakan PodSet, audit, dan tingkah laku pengunduran (rollback).
Soalan susulan dan jawapan
Soalan susulan 1: Bagaimanakah AdmissionCheck berbeza daripada Kubernetes Admission Webhook?
AdmissionCheck ialah keadaan perniagaan Kueue untuk menentukan sama ada Workload boleh dimulakan. Webhook memperluaskan laluan permintaan API. Kedua-duanya boleh bekerjasama, tetapi webhook yang diluluskan tidak bermakna sumber telah diperuntukkan.
Soalan susulan 2: Mengapakah ResourceFlavors diperlukan?
Bilangan GPU yang sama mungkin mewakili model, rantau, atau topologi yang berbeza. Perisa mengikat atribut yang boleh dijadualkan tersebut kepada kuota kumpulan sumber, menjadikan pemilihan boleh dijelaskan dan selamat.
Soalan susulan 3: Bagaimanakah anda menghalang panggilan balik pendua daripada menggerakkan keadaan ke belakang?
Gunakan UID Workload, nama semakan, dan versi sebagai kunci keidempotenan (idempotency key). Tolak versi lapuk dan pastikan kemas kini Ready yang berulang tidak dapat mencetuskan penciptaan Pod kali kedua.
Soalan susulan 4: Bilakah permintaan patut ditolak dan bukannya dikekalkan sebagai Pending?
Tolak apabila perisa sumber, dasar, atau belanjawannya tidak boleh dipenuhi sama sekali dan berikan sebabnya. Kekurangan nod sementara, tetingkap penyelenggaraan, atau percubaan semula pengawal boleh kekal sebagai Pending, tetapi memerlukan masa menunggu maksimum dan amaran.