Perintah dan konteks
Anda mengoperasikan platform GPU Kubernetes. Pekerjaan pelatihan (training) dan batch-inference harus menunggu kuota, sumber daya node, maintenance windows, dan kebijakan keamanan sebelum Pods dibuat. Desain admisi dengan Kueue Workloads, ClusterQueues, ResourceFlavors, dan AdmissionChecks, sekaligus mencegah starvation dan pelepasan yang tidak aman.
Apa yang sedang diuji oleh pewawancara
Memisahkan antrean dari admisi: Workload yang masuk ke dalam antrean tidak berarti Pods boleh dibuat. ClusterQueue memilih flavor dari grup sumber daya dan kuota nominal, sementara AdmissionChecks memungkinkan pengontrol internal atau eksternal memengaruhi pelepasan. Cakup konsistensi status, pencabutan (revocation), admisi parsial, keadilan tenant, backoff, dan auditabilitas.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Sumber daya dan prioritas
Klarifikasi model GPU, memori, CPU, topologi, preemption, prioritas tenant, keadilan antrean, dan batas waktu tunggu maksimum. Hanya menghitung GPU dapat menciptakan kapasitas palsu jika memori atau topologi tidak sesuai.
Dependensi admisi eksternal
Identifikasi pengontrol untuk maintenance windows, pemindaian image, persetujuan anggaran, dan akses data. Tentukan apakah hasilnya dapat diputar ulang (replayable) dan apakah batas waktu (timeout) berarti menolak atau menunggu. Setiap pemeriksaan eksternal memerlukan pemilik dan TTL.
Kebijakan kegagalan dan pencabutan
Definisikan apa yang terjadi ketika node berubah, kuota diambil kembali, atau kebijakan dicabut setelah admisi. Catatan admisi, pembuatan Pod, dan pemeriksaan eksternal memerlukan korelasi idempoten untuk mencegah pelepasan ganda.
Kerangka jawaban 30 detik
“Sebuah Workload masuk ke LocalQueue, dan ClusterQueue-nya mengevaluasi grup sumber daya, flavor, dan kuota kohor. Semua AdmissionCheckStates yang diperlukan harus berstatus Ready sebelum admisi; Pending tetap berada dalam antrean, sementara Rejected atau timeout mengikuti kebijakan percobaan ulang terbatas atau penghentian. Pertahankan status workload yang dapat dilacak, periksa kembali sumber daya dan kebijakan sebelum membuat Pods, serta ukur penggunaan kuota, waktu tunggu, latensi pemeriksaan, penolakan, dan pencabutan untuk memvalidasi keamanan dan keadilan.”
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan batasan Workload dan antrean
Ubah Job pengguna menjadi Workload yang dapat dijadwalkan dengan PodSets, permintaan sumber daya, prioritas, dan antrean tenant. LocalQueue mengurutkan dan menunggu; ia tidak boleh membuat Pods atau melewati batasan sumber daya ClusterQueue.
Langkah 2: Pilih ResourceFlavors melalui ClusterQueue
Jelaskan sumber daya CPU, memori, dan GPU dengan ResourceGroups, lalu pilih kombinasi flavor dengan kuota nominal yang tersedia. Masukkan model GPU, wilayah (region), label node, dan topologi ke dalam batasan flavor sehingga "GPU yang cukup" tidak menjadi admisi palsu.
Langkah 3: Orkestrasi state machine AdmissionCheck
Tampilkan status Pending, Ready, Rejected, dan status terminal yang dapat diobservasi. Pengontrol keamanan, pemeliharaan, dan anggaran memperbarui status secara idempoten menggunakan UID Workload. Kueue hanya menerima (admit) jika setiap pemeriksaan yang diperlukan berstatus Ready; Pending tidak boleh salah dilabeli sebagai kegagalan, dan Rejected tidak boleh diabaikan begitu saja.
Langkah 4: Tangani admisi parsial dan perubahan sumber daya
Jika admisi parsial diizinkan, tentukan paralelisme PodSet yang dapat dikurangi, ukuran minimum, dan aturan ekspansi di kemudian hari. Evaluasi ulang flavor dan pemeriksaan setelah pelepasan kuota atau kegagalan node; jangan pernah menggunakan kembali snapshot admisi yang sudah kedaluwarsa. Permintaan yang secara permanen tidak memungkinkan memerlukan penolakan yang disertai penjelasan, bukan percobaan ulang tanpa batas.
Langkah 5: Jaga keadilan dan cegah starvation
Definisikan batas pembagian kohor (cohort sharing) dan peminjaman (borrowing) lintas tenant, antrean, dan prioritas. Cegah pekerjaan berprioritas tinggi dari memonopoli GPU langka tanpa batas; tambahkan aturan tunggu atau penuaan (aging) untuk prioritas yang lebih rendah. Amati alokasi kuota, waktu tunggu pemeriksaan, dan startup Pod yang sebenarnya secara terpisah agar admisi cepat dengan startup lambat dapat terlihat.
Langkah 6: Desain pencabutan, percobaan ulang, dan audit
Gunakan jittered backoff dan batas percobaan ulang untuk timeout atau kegagalan pengontrol. Pencabutan harus merambat secara aman ke Workload dan PodSets, bukan hanya mengubah satu field saja. Catat pelaku, waktu, alasan, flavor, versi kuota, dan versi pemeriksaan eksternal agar keputusan dapat diputar ulang.
Langkah 7: Validasi observabilitas dan simulasi kegagalan
Pantau waktu tunggu antrean, latensi admisi, durasi Pending dari setiap pemeriksaan, penolakan, pencabutan, pemanfaatan kuota, pemilihan flavor, GPU yang menganggur, dan startup Pod. Lakukan simulasi pemadaman pengontrol, callback duplikat, reklamasi kuota, kegagalan node, dan partisi jaringan untuk membuktikan bahwa sistem tidak melepas sumber daya secara tidak aman maupun macet selamanya.
Contoh jawaban berkualitas tinggi
Saya akan menempatkan Workload di LocalQueue, membiarkan ClusterQueue memilih kombinasi sumber daya yang layak dari flavor dan kuota kohor, serta menggunakan AdmissionChecks untuk kondisi keamanan, pemeliharaan, dan anggaran. Penerimaan hanya dilakukan ketika setiap pemeriksaan yang diperlukan bernilai Ready dan snapshot sumber daya masih valid; status Pending tetap berada di antrean serta Rejected atau timeout menggunakan backoff terbatas. Model GPU, topologi, dan region ditentukan dalam flavor. Kuota tenant dan aging melindungi keadilan, sementara callback idempoten dan pencabutan merambat dengan aman ke Workload dan PodSets.
Kesalahan umum
- Kesalahan: Menganggap masuknya beban kerja ke antrean sebagai izin untuk membuat Pods. → Mengapa gagal: Mengantre dan admisi adalah status yang terpisah. → Solusi: Wajibkan alokasi ClusterQueue dan semua pemeriksaan berstatus Ready.
- Kesalahan: Memilih sumber daya hanya berdasarkan jumlah GPU. → Mengapa gagal: Model, memori, topologi, atau region mungkin tidak sesuai. → Solusi: Nyatakan batasan perangkat keras dengan ResourceFlavors.
- Kesalahan: Mengulang pemeriksaan Pending tanpa batas. → Mengapa gagal: Ketidaklayakan permanen atau kegagalan pengontrol tetap tersembunyi. → Solusi: Bedakan Pending, Rejected, dan alasan dengan batasan serta backoff.
- Kesalahan: Hanya mencabut satu field Workload. → Mengapa gagal: Pods yang sudah ada mungkin terus mengonsumsi sumber daya. → Solusi: Definisikan tindakan PodSet, audit, dan perilaku rollback.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Apa perbedaan antara AdmissionCheck dan Kubernetes Admission Webhook?
AdmissionCheck adalah status bisnis Kueue untuk menentukan apakah suatu Workload boleh dimulai. Webhook memperluas jalur permintaan API. Keduanya dapat bekerja sama, namun kelolosan webhook tidak berarti sumber daya telah dialokasikan.
Pertanyaan lanjutan 2: Mengapa ResourceFlavors diperlukan?
Jumlah GPU yang sama dapat mewakili model, wilayah, atau topologi yang berbeda. Flavor mengikat atribut yang dapat dijadwalkan tersebut ke kuota resource-group, membuat pemilihan dapat dijelaskan dan aman.
Pertanyaan lanjutan 3: Bagaimana Anda mencegah callback duplikat mengembalikan status ke belakang?
Gunakan UID Workload, nama pemeriksaan, dan versi sebagai kunci idempotensi. Tolak versi usang dan pastikan pembaruan Ready yang berulang tidak dapat memicu pembuatan Pod kedua.
Pertanyaan lanjutan 4: Kapan permintaan harus ditolak alih-alih dipertahankan dalam status Pending?
Tolak ketika resource flavor, kebijakan, atau anggarannya tidak akan pernah bisa dipenuhi, dan sertakan alasannya. Kekurangan node sementara, maintenance window, atau percobaan ulang pengontrol dapat tetap berstatus Pending, namun membutuhkan batas waktu tunggu maksimum dan peringatan (alert).