Wawancara system design: Bagaimana Anda menggunakan kesehatan perangkat Kubernetes untuk mengatur kegagalan GPU?

Perintah dan konteks

Sebuah platform inferensi GPU multi-tenant menggunakan Kubernetes Device Plugins dan Dynamic Resource Allocation (DRA). Ketika driver mendeteksi kartu yang terputus, sistem lama hanya mengekspos kesalahan di log node; Pod restart dan berulang kali mengklaim perangkat yang sama. Rancang tata kelola kegagalan di sekitar allocatedResourcesStatus pada Pod .status: operator dan pengontrol harus dapat melihat kesehatan perangkat, mengkarantina kartu yang rusak, menangani Unknown dengan aman, dan menghindari penghapusan massal akibat sinyal sementara.

Kubernetes v1.36 mempromosikan status kesehatan sumber daya ke Beta. Catatan rilis resmi menyatakan bahwa status Pod melaporkan kesehatan perangkat yang dialokasikan dan bahwa kubectl describe pod dapat mengekspos Unhealthy atau Unknown; mekanisme ini mencakup jalur Device Plugins tradisional maupun DRA.

Apa yang sedang diuji oleh pewawancara

• Bisakah Anda membedakan keberhasilan alokasi, kesehatan perangkat, kesiapan kontainer (readiness), dan SLO bisnis?
• Bisakah Anda menggambarkan alur data antara driver, kubelet, status Pod, pengontrol, penjadwal (scheduler), dan peringatan?
• Bisakah Anda memperlakukan Unhealthy dan Unknown secara berbeda daripada mengubah observasi yang hilang menjadi kegagalan mutlak?
• Bisakah Anda merancang karantina idempoten, lease, percobaan ulang (retry), batas laju (rate limits), dan entri ulang setelah pemulihan?
• Bisakah Anda menjelaskan bahwa status adalah sinyal diagnostik, bukan pengganti otomatis untuk kebijakan penjadwalan atau probe bisnis?

Pertanyaan untuk diklarifikasi terlebih dahulu

• Driver mana yang menghasilkan kesehatan, dan berapa delay pembaruan serta periode heartbeat-nya?
• Sebuah Pod dapat memiliki beberapa kartu; jika satu kartu gagal, apakah pekerjaan dapat mengalami penurunan kinerja sebagian (degrade) atau harus dimigrasikan sebagai satu kesatuan?
• Apakah Unknown berarti diskoneksi sementara, pemadaman node, atau perilaku driver yang tidak didukung? Berapa jendela toleransinya?
• Apakah karantina dilakukan per perangkat, node, ResourceClaim, atau beban kerja tenant, dan siapa yang dapat melepaskannya?
• Apakah pekerjaan memiliki checkpoint, commit idempoten, dan anggaran percobaan ulang? Berapa banyak churn GPU yang dapat disebabkan oleh migrasi?

Jawaban 30 detik

"Saya akan memperlakukan kesehatan perangkat sebagai input status, bukan sebagai perintah penghapusan Pod. Setelah driver dan kubelet memperbarui allocatedResourcesStatus, sebuah pengontrol mengagregasi berdasarkan ID perangkat: Unhealthy masuk ke karantina dan peringatan, sementara Unknown terlebih dahulu mendapatkan jendela toleransi heartbeat. Kunci idempotensi dan lease memblokir alokasi baru, dan pekerjaan yang memiliki checkpoint dimigrasikan dengan batas laju per-node. Pemulihan menjalankan probe dan canary kecil sebelum pelepasan. Saya akan memvalidasi usia status, karantina palsu, keberhasilan migrasi, dan SLO bisnis."

Pembahasan mendalam langkah demi langkah

1. Definisikan model status. Catat identitas perangkat, Pod, kontainer, ResourceClaim, node, nilai kesehatan, pesan, waktu observasi, dan versi status. Pisahkan Unhealthy (kegagalan terkonfirmasi) dari Unknown (belum terkonfirmasi) agar satu nilai Boolean tidak mendorong setiap otomatisasi.

1. Bangun alur data. DRA atau Device Plugin mengalokasikan perangkat ke Pod; kubelet menulis kesehatan yang dilaporkan driver ke dalam status Pod. Pengamat status (status observer) memantau perubahan Pod, melakukan deduplikasi berdasarkan kunci perangkat, dan menulis direktori perangkat yang dapat diputar ulang (replayable). Peringatan dan pengontrol membaca direktori tersebut alih-alih memindai API secara independen.

1. Karantina alokasi baru. Untuk perangkat yang terkonfirmasi tidak sehat, buat catatan karantina internal dan kecualikan dari ekstensi penjadwal, pemilihan ResourceClaim, atau tampilan kapasitas node. Jangan mengedit status Pod atau langsung mengubah peristiwa tunggal menjadi Node NotReady. Tindakan karantina memerlukan alasan, pelaku, dan masa berlaku.

1. Tangani pekerjaan yang sedang berjalan. Pengontrol memeriksa checkpoint dan commit idempoten sebelum memperoleh lease migrasi. Pekerjaan yang dapat dipulihkan menghentikan permintaan baru, menyimpan checkpoint, melepaskan perangkat, dan membangun kembali pada perangkat yang sehat. Pekerjaan yang tidak dapat dipulihkan menyimpan bukti dan memberi tahu tenant. Hanya satu alur migrasi yang boleh memiliki perangkat dan pekerjaan.

1. Lindungi Unknown. Unknown dapat berasal dari kubelet, driver, atau gangguan jaringan node. Terapkan jendela toleransi berbasis heartbeat dan exponential backoff; berikan peringatan selama jendela berlangsung dan batasi alokasi hanya setelah jendela berakhir. Untuk pemadaman seluruh node, gunakan lease node dan deteksi kegagalan yang ada daripada menyimpulkan bahwa setiap perangkat rusak dari satu status Pod.

1. Pulihkan dan verifikasi. Ketika perangkat kembali melaporkan sehat, jalankan probe driver, pekerjaan kecil, dan jendela stabilitas sebelum melepaskan karantina. Lacak usia status, durasi Unknown, tingkat karantina palsu, keberhasilan migrasi, waktu GPU menganggur, dan kesalahan bisnis. Putar ulang peristiwa duplikat dan di luar urutan, lalu restart pengontrol untuk menguji pemulihan.

Device health event
  -> Pod status observer
  -> deduplicate by (node, deviceID, statusVersion)
  -> device quarantine record with lease and expiry
  -> scheduler/claim filter excludes unhealthy device
  -> checkpointed workload migration
  -> probe + canary
  -> release quarantine

Jawaban model

Saya akan membuat direktori status tingkat perangkat yang menghubungkan driver, kubelet, Pod, ResourceClaim, dan pekerjaan. Unhealthy adalah kegagalan yang terkonfirmasi, jadi saya membuat karantina yang didukung lease dengan masa kedaluwarsa, memblokir alokasi baru, dan memberikan peringatan. Unknown terlebih dahulu memasuki jendela toleransi heartbeat dan hanya membatasi alokasi setelah jendela tersebut kedaluwarsa. Pengamat melakukan deduplikasi berdasarkan ID perangkat, dan pengontrol yang di-restart membangun kembali dari peristiwa dan catatan yang dipertahankan, bukan dari flag di memori.

Migrasi bergantung pada checkpoint, commit idempoten, dan prioritas tenant. Pekerjaan yang dapat dipulihkan melakukan checkpoint, melepaskan perangkat, dan membangun kembali pada perangkat yang sehat; pekerjaan yang tidak dapat dipulihkan menyimpan bukti. Pemulihan dimulai dengan probe driver dan canary kecil. Ekstensi penjadwal, pemilihan DRA, dan tampilan kapasitas menggunakan catatan karantina, sementara status tetap menjadi input diagnostik dan bukan kesiapan (readiness) atau SLO bisnis. Saya akan membuktikan desain tersebut dengan usia status, positif palsu, keberhasilan migrasi, dan metrik kesalahan bisnis.

Kesalahan umum

• Gejala: Menghapus setiap Pod ketika statusnya adalah Unknown → Mengapa gagal: Kesenjangan observasi sementara menjadi churn kluster → Solusi: Gunakan lease, jendela heartbeat, dan batas laju.
• Gejala: Hanya mengkarantina node dan mengabaikan identitas perangkat → Mengapa gagal: Satu kartu yang rusak ikut membawa perangkat yang sehat → Solusi: Beri kunci pada catatan berdasarkan perangkat dan ResourceClaim, eskalasikan ke node hanya jika ada justifikasi.
• Gejala: Mengedit status Pod agar perangkat terlihat sehat → Mengapa gagal: Sumber kebenaran menjadi rusak dan pemulihan bisa salah → Solusi: Pertahankan status kubelet dan buat status karantina yang dapat diaudit secara terpisah.
• Gejala: Mengembalikan perangkat yang pulih ke beban penuh secara langsung → Mengapa gagal: Pemulihan sementara atau driver yang tidak stabil dapat gagal lagi → Solusi: Jalankan probe, canary, lalu tingkatkan secara bertahap.

Pertanyaan lanjutan dan tanggapan

Satu GPU gagal tetapi Pod memiliki GPU lainnya. Haruskah hanya sebagian pekerjaan yang dimigrasikan?

Pertama, verifikasi apakah framework mendukung penyusutan dinamis (dynamic shrink) dan pengikatan ulang (rebinding). Jika model memerlukan topologi perangkat yang tetap, migrasikan seluruh pekerjaan. Jika dapat di-shard, pindahkan hanya shard yang terpengaruh sambil mempertahankan semantik ResourceClaim dan checkpoint untuk perangkat yang tersisa.

Nilainya adalah Healthy tetapi pesan statusnya sudah lama. Apa yang Anda lakukan?

Pisahkan nilai kesehatan dari usia status. Setelah batas heartbeat terlampaui, alihkan ke Unknown daripada memperlakukan Healthy yang usang sebagai bukti terkini; peringatan dan pembatas penjadwalan menggunakan usia tersebut.

Bagaimana Anda menghentikan beberapa pengontrol agar tidak memigrasikan pekerjaan yang sama?

Gunakan kunci idempotensi yang dibangun dari ID perangkat, ID pekerjaan, dan versi status, dengan lease yang memiliki masa kedaluwarsa atau pembaruan versi optimis. Pengontrol yang kehilangan lease akan berhenti, dan pengontrol pengganti melanjutkan dari catatan yang dipertahankan.

Kapan perangkat dapat kembali ke pool kapasitas?

Laporan driver yang sehat memang diperlukan tetapi tidak cukup. Diperlukan probe perangkat, pekerjaan kecil, jendela stabilitas, dan alasan karantina yang ditutup; setiap kegagalan akan memperpanjang karantina dan memblokir pelepasan paksa secara manual.

Referensi

• Kubernetes v1.36: Haru
• Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA
• Kubernetes v1.34: Pods Report DRA Resource Health
• Dokumentasi Dynamic Resource Allocation

Daftar periksa wawancara

Gambarkan alur dari driver ke status Pod, pengamat, karantina, dan filter penjadwalan. Pisahkan Unhealthy dari Unknown, lalu tambahkan lease, checkpoint, batas laju, canary pemulihan, dan metrik.

Kesimpulan satu kalimat

Kesehatan perangkat membuat kegagalan perangkat keras dapat diamati di Kubernetes, namun pemulihan yang aman tetap memerlukan karantina tingkat perangkat, pembatas Unknown, migrasi idempoten, dan penggunaan kembali secara bertahap.