Temu duga reka bentuk sistem: Bagaimanakah anda menggunakan kesihatan peranti Kubernetes untuk mentadbir kegagalan GPU?

Gesaan dan konteks

Platform inferens GPU berbilang penyewa menggunakan Kubernetes Device Plugins dan Dynamic Resource Allocation (DRA). Apabila pemacu mengesan kad yang terputus, sistem lama hanya mendedahkan ralat dalam log nod; Pod dimulakan semula dan berulang kali menuntut peranti yang sama. Reka bentuk tadbir urus kegagalan di sekitar allocatedResourcesStatus dalam Pod .status: pengendali dan pengawal harus melihat kesihatan peranti, mengkuarantin kad yang rosak, mengendalikan Unknown dengan selamat, dan mengelakkan pemadaman besar-besaran daripada isyarat sementara.

Kubernetes v1.36 menaikkan status kesihatan sumber kepada Beta. Nota keluaran rasmi menyatakan bahawa status Pod melaporkan kesihatan peranti yang diperuntukkan dan bahawa kubectl describe pod boleh mendedahkan Unhealthy atau Unknown; mekanisme ini merangkumi kedua-dua laluan Device Plugins tradisional dan DRA.

Perkara yang diuji oleh penemu duga

• Bolehkah anda membezakan kejayaan peruntukan, kesihatan peranti, kesediaan kontena (container readiness), dan SLO perniagaan?
• Bolehkah anda melakar aliran data antara pemacu, kubelet, status Pod, pengawal, penjadual, dan sistem amaran?
• Bolehkah anda mengendalikan Unhealthy dan Unknown secara berbeza dan bukannya mengubah pemerhatian yang hilang menjadi kegagalan mutlak?
• Bolehkah anda mereka bentuk kuarantin idempoten, pajakan (leases), percubaan semula, had kadar, dan kemasukan semula selepas pemulihan?
• Bolehkah anda menerangkan bahawa status ialah isyarat diagnostik, bukan pengganti automatik untuk dasar penjadualan atau prob perniagaan?

Soalan untuk dijelaskan terlebih dahulu

• Pemacu manakah yang menghasilkan kesihatan, dan apakah kelewatan kemas kini serta tempoh degupan jantung (heartbeat) mereka?
• Sebuah Pod mungkin memegang beberapa kad; jika satu gagal, bolehkah kerja itu mengalami penurunan prestasi separa (degrade) atau mesti berhijrah sebagai satu unit?
• Adakah Unknown bermaksud pemutusan sementara, gangguan nod, atau tingkah laku pemacu yang tidak disokong? Apakah tetingkap toleransinya?
• Adakah kuarantin bagi setiap peranti, nod, ResourceClaim, atau beban kerja penyewa, dan siapa yang boleh melepaskannya?
• Adakah kerja mempunyai titik semak (checkpoints), komit idempoten, dan bajet percubaan semula? Berapa banyak churn GPU yang boleh disebabkan oleh penghijrahan?

Jawapan 30 saat

"Saya akan menganggap kesihatan peranti sebagai input keadaan, bukan sebagai arahan memadam Pod. Selepas pemacu dan kubelet mengemas kini allocatedResourcesStatus, pengawal mengagregat mengikut ID peranti: Unhealthy memasuki kuarantin dan amaran, manakala Unknown terlebih dahulu mendapat tetingkap toleransi degupan jantung. Kunci keidempotenan dan pajakan menyekat peruntukan baharu, dan kerja yang mempunyai titik semak berhijrah dengan had kadar setiap nod. Pemulihan menjalankan prob dan kenari kecil sebelum dilepaskan. Saya akan mengesahkan usia keadaan, kuarantin palsu, kejayaan penghijrahan, dan SLO perniagaan."

Langkah demi langkah secara mendalam

1. Tentukan model keadaan. Rekod identiti peranti, Pod, kontena, ResourceClaim, nod, nilai kesihatan, mesej, masa pemerhatian, dan versi status. Asingkan Unhealthy (kegagalan yang disahkan) daripada Unknown (tidak disahkan) supaya satu Boolean tidak memacu setiap automasi.

1. Bina aliran data. DRA atau Device Plugin memperuntukkan peranti kepada Pod; kubelet menulis kesihatan yang dilaporkan pemacu ke dalam status Pod. Pemerhati status memantau perubahan Pod, menyahduplikasi mengikut kunci peranti, dan menulis direktori peranti yang boleh dimainkan semula (replayable). Amaran dan pengawal membaca direktori tersebut dan bukannya mengimbas API secara berasingan.

1. Kuarantin peruntukan baharu. Bagi peranti tidak sihat yang disahkan, cipta rekod kuarantin dalaman dan kecualikannya daripada sambungan penjadual, pemilihan ResourceClaim, atau paparan kapasiti nod. Jangan edit status Pod atau serta-merta mengubah peristiwa sekali sahaja kepada Node NotReady. Tindakan kuarantin memerlukan sebab, pelaku, dan tarikh luput.

1. Kendalikan kerja yang sedang berjalan. Pengawal memeriksa titik semak dan komit idempoten sebelum memperoleh pajakan penghijrahan. Kerja yang boleh dipulihkan menghentikan permintaan baharu, menyimpan titik semak, melepaskan peranti, dan membina semula pada peranti yang sihat. Kerja yang tidak boleh dipulihkan memelihara bukti dan memberitahu penyewa. Hanya satu aliran penghijrahan boleh memiliki peranti dan kerja.

1. Kawal Unknown. Unknown mungkin datang daripada kubelet, pemacu, atau gangguan rangkaian nod. Gunakan tetingkap toleransi berasaskan degupan jantung dan backoff eksponen; berikan amaran semasa tetingkap tersebut dan sekat peruntukan hanya selepas ia tamat tempoh. Untuk gangguan keseluruhan nod, gunakan pajakan nod dan pengesanan kegagalan sedia ada dan bukannya membuat kesimpulan bahawa setiap peranti rosak daripada satu status Pod.

1. Pulihkan dan sahkan. Apabila peranti melaporkan sihat semula, jalankan prob pemacu, kerja kecil, dan tetingkap kestabilan sebelum melepaskan kuarantin. Jejaki usia status, tempoh Unknown, kadar kuarantin palsu, kejayaan penghijrahan, masa GPU terbiar, dan ralat perniagaan. Mainkan semula peristiwa pendua dan tidak teratur serta mulakan semula pengawal 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

Jawapan model

Saya akan mencipta direktori status peringkat peranti yang memautkan pemacu, kubelet, Pod, ResourceClaim, dan kerja. Unhealthy ialah kegagalan yang disahkan, jadi saya mencipta kuarantin bersandarkan pajakan dengan tarikh luput, menyekat peruntukan baharu, dan memberi amaran. Unknown terlebih dahulu memasuki tetingkap toleransi degupan jantung dan hanya menyekat peruntukan selepas tetingkap itu tamat tempoh. Pemerhati menyahduplikasi mengikut ID peranti, dan pengawal yang dimulakan semula membina semula daripada peristiwa dan rekod yang dikekalkan dan bukannya bendera dalam ingatan.

Penghijrahan bergantung pada titik semak, komit idempoten, dan keutamaan penyewa. Kerja yang boleh dipulihkan melakukan titik semak, melepaskan peranti, dan membina semula pada peranti yang sihat; kerja yang tidak boleh dipulihkan mengekalkan bukti. Pemulihan bermula dengan prob pemacu dan kenari kecil. Sambungan penjadual, pemilihan DRA, dan paparan kapasiti menggunakan rekod kuarantin, manakala status kekal sebagai input diagnostik dan bukannya kesediaan atau SLO perniagaan. Saya akan membuktikan reka bentuk ini dengan metrik usia keadaan, positif palsu, kejayaan penghijrahan, dan ralat perniagaan.

Kesilapan lazim

• Gejala: Padam setiap Pod apabila status ialah Unknown → Sebab ia gagal: Jurang pemerhatian sementara menjadi churn kluster → Penyelesaian: Gunakan pajakan, tetingkap degupan jantung, dan had kadar.
• Gejala: Kuarantin nod sahaja dan tinggalkan identiti peranti → Sebab ia gagal: Satu kad yang rosak menjejaskan peranti yang sihat bersamanya → Penyelesaian: Kuncikan rekod mengikut peranti dan ResourceClaim, eskalasikan ke nod hanya apabila wajar.
• Gejala: Edit status Pod untuk menjadikan peranti kelihatan sihat → Sebab ia gagal: Punca kebenaran (source of truth) dirosakkan dan pemulihan mungkin salah → Penyelesaian: Kekalkan status kubelet dan cipta keadaan kuarantin yang boleh diaudit secara berasingan.
• Gejala: Kembalikan peranti yang dipulihkan kepada beban penuh serta-merta → Sebab ia gagal: Pemulihan sementara atau pemacu yang tidak stabil boleh gagal lagi → Penyelesaian: Uji dengan prob, kenari, kemudian naikkan beban secara beransur-ansur.

Soalan susulan dan respons

Satu GPU gagal tetapi Pod memiliki GPU yang lain. Patutkah hanya sebahagian daripada kerja itu berhijrah?

Mula-mula sahkan sama ada rangka kerja menyokong pengecutan dinamik (dynamic shrink) dan pengikatan semula. Jika model memerlukan topologi peranti yang tetap, hijrahkan keseluruhan kerja. Jika ia boleh dibahagikan (shard), alihkan hanya shard yang terjejas sambil mengekalkan semantik ResourceClaim dan titik semak bagi peranti yang selebihnya.

Nilainya adalah Healthy tetapi mesej status sudah lama. Apakah yang anda lakukan?

Asingkan nilai kesihatan daripada usia status. Selepas had degupan jantung melebihi, lakukan peralihan kepada Unknown daripada menganggap Healthy yang lapuk sebagai bukti semasa; amaran dan sekatan penjadualan menggunakan usia tersebut.

Bagaimanakah anda menghalang berbilang pengawal daripada menghijrahkan kerja yang sama?

Gunakan kunci keidempotenan yang dibina daripada ID peranti, ID kerja, dan versi status, dengan pajakan yang akan tamat tempoh atau kemas kini versi optimistik. Pengawal yang kehilangan pajakan akan berhenti, dan pengawal pengganti menyambung semula daripada rekod yang dikekalkan.

Bilakah peranti boleh kembali ke kolam kapasiti?

Laporan pemacu yang sihat adalah perlu tetapi tidak mencukupi. Wajibkan prob peranti, kerja kecil, tetingkap kestabilan, dan sebab kuarantin yang ditutup; sebarang kegagalan akan melanjutkan kuarantin dan menyekat pelepasan paksa manual.

Rujukan

• 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

Senarai semak temu duga

Lakar aliran pemacu-ke-status-Pod, pemerhati, kuarantin, dan penapis penjadualan. Asingkan Unhealthy daripada Unknown, kemudian tambahkan pajakan, titik semak, had kadar, kenari pemulihan, dan metrik.

Rumusan satu ayat

Kesihatan peranti menjadikan kegagalan perkakasan boleh diperhatikan dalam Kubernetes, tetapi pemulihan yang selamat masih memerlukan kuarantin peringkat peranti, sekatan Unknown, penghijrahan idempoten, dan penggunaan semula secara berperingkat.