Wawancara Desain Sistem: Preferensi Perangkat dan Fallback yang Dapat Dijelaskan dengan Kubernetes DRA

Petunjuk dan konteks

Anda mengelola kluster Kubernetes untuk tugas pelatihan dan inferensi. Node berisi H100, A100, dan akselerator yang lebih kecil. Sebuah beban kerja menginginkan H100 terlebih dahulu, kemudian A100, lalu perangkat kompatibel lainnya saat kapasitas tidak tersedia. Rancang alur permintaan dan penjadwalan Dynamic Resource Allocation (DRA), yang mencakup determinisme, keadilan, kegagalan, observabilitas, migrasi, dan rollback. Jawablah sebagai seorang insinyur senior yang dapat mengambil keputusan trade-off arsitektural.

Hal yang diuji oleh pewawancara

• Apakah preferensi merupakan kebijakan yang dapat diverifikasi alih-alih polling sisi klien atau klaim yang di-hardcode.
• Pemahaman tentang siklus hidup ResourceClaim, ResourceSlice, driver, dan scheduler.
• Pemecahan seri (tie-breaking) yang deterministik, perubahan kesehatan, percobaan ulang, dan batas waktu (timeout).
• Alokasi kapasitas yang adil, isolasi penyewa (tenant), metrik, dan auditabilitas.
• Jalur migrasi yang dapat dibatalkan (reversible) dari plugin perangkat ke DRA.

Pertanyaan untuk klarifikasi

1. Apakah sembarang fallback yang tersedia dapat diterima, atau apakah memori, arsitektur, dan kemampuan driver harus tetap menjadi batasan mutlak (hard constraint)?
2. Bisakah satu Pod menerima model perangkat yang berbeda? Apakah topologi, NUMA, dan bandwidth jaringan merupakan batasan mutlak?
3. Apakah bisnis memerlukan jaminan model yang ketat, atau dapatkah menukar preferensi model demi tingkat keberhasilan dan biaya?
4. Apakah penyewa memiliki kuota, prioritas, dan aturan preemption? Kapan perangkat yang tidak sehat dihapus dari daftar kandidat?
5. Bisakah beban kerja yang ada mengadopsi ResourceClaims, dan haruskah plugin perangkat lama hidup berdampingan selama migrasi?

Jawaban 30 detik

Saya akan mengenkode preferensi perangkat sebagai kandidat terurut ditambah batasan mutlak dalam permintaan DRA, membiarkan scheduler mencocokkan sumber daya selama siklus hidup klaim daripada meminta klien melakukan polling pada node. Scheduler memfilter batasan driver, arsitektur, topologi, dan kuota penyewa terlebih dahulu, kemudian mengevaluasi H100, A100, dan perangkat kompatibel lainnya secara berurutan. Setiap tingkatan menggunakan pemecah seri yang stabil, dan peristiwa serta metrik mencatat kandidat, alasan penolakan, dan pilihan akhir. Perubahan kesehatan atau kegagalan pengikatan (binding) memicu evaluasi ulang hanya saat klaim masih dapat dicoba ulang. Kuota antrean dan bobot penyewa memberikan keadilan. Migrasi menggunakan canary jalur ganda, templat ResourceClaim berversi, dan peralihan kembali ke plugin lama.

Pembahasan mendalam langkah demi langkah

1. Tentukan model preferensi

Perlakukan urutan model sebagai preferensi lunak (soft preference). Perlakukan versi driver, arsitektur, batas memori minimum, topologi, dan isolasi sebagai batasan mutlak. Permintaan dapat menyatakan “H100 pertama, A100 kedua,” tetapi fallback tidak boleh mengabaikan memori atau kuota penyewa. Sertakan pengidentifikasi kebijakan 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'"

Kandidat terurut mengekspresikan preferensi bisnis; penerapan harus tetap cocok dengan versi API DRA dan kemampuan driver yang didukung oleh kluster.

2. Alur klaim sumber daya dan penjadwalan

Pod menggunakan ResourceClaimTemplate untuk membuat klaim. Driver DRA menerbitkan ResourceSlices yang berisi atribut perangkat, kapasitas, dan kesehatan. Selama pra-pemfilteran, scheduler membaca klaim dan slice, memverifikasi batasan mutlak, dan mencari kandidat secara berurutan. Setelah pengikatan, driver mengekspos alokasi ke kontainer. Klaim harus idempoten sehingga percobaan ulang tidak dapat membuat alokasi kedua yang tidak dapat direklamasi.

3. Pilihan deterministik dan penjelasan

Ketika sebuah tingkatan memiliki banyak perangkat, gunakan urutan stabil berdasarkan pool sumber daya, nama ResourceSlice, dan pengidentifikasi perangkat, atau peringkat kapasitas dan topologi eksplisit. Jadikan aturan tersebut bagian dari kontrak antarmuka. Catat kandidat, filter, alasan penolakan, perangkat akhir, dan versi kebijakan. Memutar ulang masukan yang sama harus menghasilkan hasil yang sama, dan seorang operator dapat menjelaskan mengapa H100 dilewati.

4. Perilaku kegagalan, kesehatan, dan percobaan ulang

Klaim baru harus melewati perangkat yang ditandai tidak sehat; beban kerja yang sudah terikat mengikuti kebijakan runtime dan pengontrol untuk penghentian, migrasi, atau pembuatan ulang. Bedakan konflik pengikatan, slice kedaluwarsa, dan kehilangan node sebagai dapat dicoba ulang atau terminal. Percobaan ulang memerlukan backoff dan kunci idempotensi untuk menghindari pemindaian berulang yang memperbesar beban scheduler. Melakukan fallback ke A100 hanya valid ketika batasan mutlak masih terpenuhi, dan model sebenarnya harus terlihat di status Pod.

5. Keadilan, kapasitas, dan observabilitas

Preferensi tidak boleh menjadi izin yang memesan H100 tanpa batas waktu. Arbitrase tingkat antrean menggunakan kuota penyewa, bobot, dan waktu tunggu; pilihan tingkat perangkat mengikuti urutan kandidat. Lacak volume permintaan berdasarkan model, tingkat fallback, waktu tunggu, kegagalan pengikatan, perubahan kesehatan, penggunaan penyewa, dan tingkat keberhasilan kebijakan (hit rate). Simpan rantai keputusan yang dapat dibaca dalam peristiwa sambil menghindari data sensitif penyewa dalam log.

6. Migrasi dan rollback

Mulai dengan kelas DRA dan templat ResourceClaim untuk sebagian kecil beban kerja sementara plugin perangkat lama melayani sisanya. Bandingkan tingkat keberhasilan, tingkat fallback, latensi penjadwalan, dan utilisasi GPU sebelum melakukan ekspansi. Buat versi untuk templat dan kebijakan. Jika masalah driver atau penjadwalan muncul, hentikan penerbitan templat baru dan alihkan kembali beban kerja ke plugin lama; tangani pekerjaan yang sudah terikat di bawah kebijakan penghentian yang ditetapkan alih-alih mengubah klaim dan alokasi perangkat secara bersamaan.

Jawaban model

Saya akan memisahkan preferensi, batasan, dan bukti alokasi. Preferensi adalah daftar kandidat yang terurut. Batasan mencakup kemampuan model, memori, driver, topologi, kuota penyewa, dan isolasi. Setelah Pod membuat ResourceClaim, driver DRA menerbitkan ResourceSlices dan scheduler memfilter batasan mutlak sebelum memilih kandidat secara berurutan. Urutan pool sumber daya dan pengidentifikasi perangkat yang stabil menyelesaikan kondisi seri, membuat pemutaran ulang menjadi deterministik. Peristiwa mencakup kandidat, alasan penolakan, versi kebijakan, dan model sebenarnya.

Jalur kegagalan membedakan perangkat tidak sehat, konflik pengikatan, klaim kedaluwarsa, dan kehilangan node. Hanya kesalahan yang dapat dicoba ulang yang menggunakan backoff; fallback tidak pernah melanggar batasan mutlak, dan model akhir ditulis ke status. Kuota penyewa, bobot antrean, dan waktu tunggu melindungi keadilan sehingga preferensi H100 tidak membuat penyewa lain kelaparan sumber daya. Migrasi menjalankan plugin lama dan DRA dalam bentuk canary, dengan templat berversi dan sakelar rollback yang telah diuji.

Kesalahan umum

• Hanya mengatakan “urutkan berdasarkan model” tanpa batasan mutlak atau pemecah seri di dalam tingkatan.
• Membiarkan klien memindai node atau mengklaim perangkat secara langsung, melewati klaim dan scheduler.
• Memperlakukan perubahan kesehatan, konflik pengikatan, dan batasan yang tidak dapat dipenuhi sebagai percobaan ulang tanpa batas.
• Hanya mengoptimalkan tingkat keberhasilan H100 sambil mengabaikan keadilan penyewa, kuota, dan waktu tunggu.
• Menghapus plugin perangkat lama dalam satu langkah, sehingga tidak menyisakan rollback cepat.
• Hanya mencatat perangkat akhir dan kehilangan bukti kandidat serta penolakan.

Pertanyaan lanjutan dan tanggapan

Jika H100 dan A100 sama-sama memenuhi batasan, mengapa tidak memilih secara acak?

Pilihan acak melemahkan keterulangan (replayability) dan diagnosis. Penyeimbangan kapasitas dapat mengikuti urutan yang stabil, tetapi aturan tersebut harus tetap dapat dijelaskan dan diamati; seed acak tidak boleh menjadi kontrak tersembunyi.

Bagaimana jika suatu perangkat menjadi tidak sehat setelah pra-pemfilteran tetapi sebelum pengikatan?

Periksa kembali versi dan kesehatan saat pengikatan. Kembalikan kesalahan terklasifikasi dan coba lagi dengan backoff hanya jika klaim tetap valid dan kandidat masih ada; jika tidak, tampilkan alasan tidak terpenuhi yang jelas pada Pod.

Bagaimana Anda membuktikan bahwa fallback tidak merugikan keadilan?

Ukur waktu tunggu, penggunaan, tingkat fallback, dan pangsa antrean berdasarkan penyewa dan model, lalu bandingkan kohort pemutaran ulang dan canary. Jika seorang penyewa jarang mendapatkan pilihan pertamanya, sesuaikan kuota atau bobot alih-alih terus-menerus menaikkan prioritas permintaan.