Petunjuk dan cakupan
Sebuah platform machine-learning multi-tenant menggunakan GPU, FPGA, dan NIC berkecepatan tinggi. Desainnya saat ini mengalokasikan seluruh perangkat melalui label node, extended resources, dan device plugins, yang membuat atribut perangkat, pembagian (sharing), dan isolasi tenant sulit untuk diekspresikan. Tim ingin mengadopsi Dynamic Resource Allocation (DRA), yang API inti resource.k8s.io/v1-nya telah menjadi stabil di Kubernetes 1.34.
Rancang migrasi tersebut dan jelaskan tanggung jawab dari ResourceClaim, DeviceClass, ResourceClaimTemplate, ResourceSlice, driver, dan scheduler. Kluster harus bermigrasi secara bertahap tanpa me-restart setiap beban kerja sekaligus.
Hal yang dievaluasi pewawancara
Pewawancara ingin melihat pemisahan yang jelas antara mendeklarasikan kebutuhan perangkat dan mengalokasikan perangkat konkret. Jelaskan aliran data antara API control-plane, scheduler, driver node, dan kubelet, serta bedakan API DRA yang stabil dari kemampuan yang masih bersifat eksperimental atau spesifik untuk driver.
Jawaban yang kuat mencakup pembagian kapasitas, referensi lintas namespace, kegagalan driver, penggantian Pod, koeksistensi dengan beban kerja lama, prinsip least privilege, dan sinyal rollback, bukan sekadar mencantumkan jenis-jenis resource.
Pertanyaan klarifikasi sebelum menjawab
- Apakah permintaannya untuk seluruh perangkat utuh, kapasitas yang dapat diiris (sliceable), atau perangkat apa pun yang cocok dengan atribut tertentu?
- Apakah driver mendukung DRA, dan bisakah device plugin lama tetap berjalan selama migrasi?
- Haruskah beban kerja membuat Claims secara langsung, atau haruskah template platform yang membuatnya?
- Bolehkah tenant menggunakan kembali Claims di seluruh namespace, dan objek apa saja yang boleh ditulis oleh pengontrol platform?
- Selama migrasi, apakah prioritasnya adalah kontinuitas pekerjaan, throughput penjadwalan, atau utilisasi?
Kerangka jawaban 30 detik
“Saya akan memodelkan kebutuhan perangkat sebagai Claims, membiarkan driver menemukan, mengalokasikan, dan mengonfigurasi perangkat, serta membiarkan scheduler membuat keputusan kelayakan dari Claims dan ResourceSlices. Saya akan melakukan canary pada device class kecil di namespace yang terisolasi. Plugin lama dan DRA dapat hidup berdampingan berdasarkan pool, tetapi keduanya tidak boleh memiliki perangkat yang sama. Setiap fase mengukur status Claim, pengikatan Pod, visibilitas node, kesalahan driver, latensi alokasi, dan batas tenant. Jika alokasi gagal, saya menghentikan Claims baru, mempertahankan pekerjaan yang sedang berjalan, dan mengarahkan beban kerja baru kembali ke jalur lama.”
Jawaban mendalam langkah demi langkah
Gambarkan alur data DRA terlebih dahulu
Beban kerja mereferensikan Claim melalui kolom resourceClaims pada Pod. Claim dapat dibuat secara langsung atau dibuat untuk suatu Job oleh ResourceClaimTemplate. DeviceClass mendeskripsikan kelas perangkat yang dapat dipilih, sementara driver memublikasikan perangkat node dan atributnya melalui ResourceSlice. Scheduler menggabungkan Pod, Claim, DeviceClass, dan ResourceSlice untuk memilih sebuah node; driver node kemudian melakukan alokasi dan konfigurasi konkret.
Hal ini memisahkan pemilihan perangkat dari YAML aplikasi dan menghindari pengkodean topologi perangkat keras ke dalam konvensi label.
Rancang template Claim dan batasan tenant
Hanya ekspos parameter yang ditujukan untuk tenant seperti tier memori, tipe interkoneksi, atau bandwidth jaringan. Jangan mengekspos pengidentifikasi internal driver. Pengontrol platform menerapkan kebijakan penerimaan (admission policy) namespace, kuota, dan pembersihan siklus proses. Penggunaan Claim lintas namespace memerlukan izin referensi eksplisit dan peristiwa audit. Selama penghapusan tenant, hentikan Claims baru, tunggu Pod melepaskan perangkat, lalu klaim kembali status perangkat.
Tangani perangkat utuh dan kapasitas yang dapat dibagikan
Alokasi seluruh perangkat dapat memetakan satu DeviceRequest ke satu perangkat. Berbagi memori, bandwidth, atau irisan waktu (time slices) mengharuskan driver untuk memublikasikan kapasitas dan mendukung perilaku kapasitas habis pakai (consumable-capacity) DRA yang relevan. Jangan menyimulasikan pembagian dengan label scheduler; penjadwalan dapat berhasil sementara node melakukan penjualan berlebih (overselling) dari kapasitas nyata. Tentukan unit, batas konkurensi, waktu pelepasan, dan kebijakan fragmentasi.
Berdampingan dengan device plugins
Partisi migrasi berdasarkan kelas perangkat atau pool node sehingga plugin lama dan DRA tidak pernah mengiklankan kepemilikan atas perangkat keras yang sama. Beban kerja yang ada mempertahankan extended resources; beban kerja baru mereferensikan DRA Claims. Label pool adalah batas migrasi, bukan sumber akhir dari atribut perangkat. Setiap pool memerlukan kepemilikan eksplisit dan sakelar penonaktifan untuk mencegah inisialisasi driver ganda.
Tangani penjadwalan, preemption, dan kegagalan
Ketika Claim menunggu atau gagal, Pod harus mengekspos alasan Pending yang dapat dijelaskan. Memilih node bukan berarti perangkat telah dikonfigurasi; driver dapat gagal selama penyiapan node. Pengontrol harus mengklasifikasikan kegagalan sebagai dapat dicoba lagi, tidak dapat dicoba lagi, atau memerlukan pembersihan, dan mengirimkan setiap kelas ke peringatan yang tepat. Preemption harus mempertimbangkan prioritas Pod, kapasitas Claim yang ditempati, dan latensi pelepasan, bukan hanya CPU atau memori.
Observasi dan rencanakan kapasitas
Ukur pembuatan Claim hingga pengikatan (binding), pengikatan hingga alokasi node, dan alokasi hingga Pod Ready sebagai tahap terpisah. Lacak kapasitas yang menganggur, teralokasi, tidak tersedia, terfragmentasi, dan kesalahan driver. Rekonsiliasikan kapasitas yang diiklankan oleh ResourceSlices dengan apa yang sebenarnya diekspos oleh node; hentikan ekspansi canary saat keduanya menyimpang. Platform pelatihan juga harus mencatat percobaan ulang, pemulihan checkpoint, dan peristiwa kesehatan perangkat.
Canary, rollback, dan konsistensi
Mulai dengan satu driver dan satu pool node menggunakan pekerjaan yang dapat dicoba lagi. Selanjutnya kembangkan ke beberapa tenant dan template; migrasikan pekerjaan yang berjalan lama dan tidak dapat diinterupsi pada urutan terakhir. Rollback tidak berarti menghapus Claims yang sudah terikat. Hentikan pembuatan Claim baru, biarkan Pod yang sedang berjalan selesai atau bermigrasi, bekukan perubahan driver, dan arahkan pekerjaan baru ke plugin lama. Pertahankan peristiwa Claim, Pod, dan driver agar insiden tetap dapat didiagnosis.
Validasi API dan batasan keamanan
Sebelum penerapan, jalankan pengujian kontrak terhadap API resource.k8s.io/v1 untuk versi Claim, Template, DeviceClass, dan ResourceSlice, transisi status, serta urutan penghapusan. Lakukan injeksi restart driver, kehilangan node, alokasi ganda, kebocoran Claim, dan akses lintas namespace. Periksa penerimaan, RBAC, audit, dan izin node-agent. Perluas pool perangkat hanya setelah metrik fungsionalitas, isolasi, dan pemulihan terpenuhi.
Jawaban model berkualitas tinggi
“Saya akan membagi migrasi menjadi lapisan model resource, driver, penjadwalan, dan runtime. Beban kerja mendeklarasikan Claims; Templates membuatnya; DeviceClass mengekspresikan pemilihan; driver memublikasikan ResourceSlices dan mengalokasikan pada node; scheduler menangani kelayakan dan pemilihan node. Plugin lama dan DRA hidup berdampingan berdasarkan pool atau kelas perangkat, tidak pernah dengan kepemilikan ganda. Untuk pembagian, saya memerlukan model kapasitas driver dan semantik pelepasan alih-alih overselling berbasis label. Saya mulai dengan pekerjaan yang dapat dicoba ulang, mengukur latensi Claim-ke-Ready, kegagalan alokasi, fragmentasi, kesehatan driver, dan pelanggaran tenant, kemudian menghentikan Claims baru dan mempertahankan status sebelum mengarahkan pekerjaan baru kembali selama rollback.”
Kesalahan umum
- Memperlakukan DRA sebagai label perangkat baru → penjadwalan berhasil tanpa pemenuhan di tingkat node → buat driver memublikasikan perangkat terstruktur dan kapasitas.
- Membiarkan plugin dan DRA memiliki satu perangkat yang sama → inisialisasi ganda atau alokasi ganda → partisi kepemilikan berdasarkan pool atau kelas perangkat.
- Merancang Claims tanpa reklamasi → kebocoran perangkat dan kuota menumpuk → tentukan pelepasan, batas waktu, penghapusan, dan rekonsiliasi.
- Menyimulasikan pembagian dengan label → scheduler tidak dapat melihat kapasitas tersisa yang sebenarnya → buat driver memublikasikan kapasitas dan konkurensi.
- Menyamakan pemilihan node dengan keberhasilan alokasi → kesalahan driver membuat Pod berstatus Pending tanpa batas → pisahkan metrik penjadwalan, alokasi node, dan Ready.
- Menghapus setiap Claim selama rollback → pekerjaan yang berjalan dan bukti diagnostik menghilang → bekukan alokasi baru dan pertahankan status.
Pertanyaan lanjutan dan tanggapan
Lanjutan 1: Mengapa tidak tetap mendaftarkan GPU sebagai extended resources?
Extended resources cocok untuk permintaan kuantitas sederhana tetapi tidak mengekspresikan atribut perangkat, alternatif, kapasitas bersama, atau konfigurasi kompleks dengan baik. Jika persyaratannya hanya penghitungan seluruh perangkat dan driver sudah matang, jalur lama dapat dipertahankan. DRA harus diperkenalkan ketika kompleksitas pemilihan perangkat dan siklus proses membenarkannya.
Lanjutan 2: Bagaimana Anda mencegah overselling ketika beberapa Pod mereferensikan satu Claim?
Semantik penggunaan kembali harus eksplisit dalam kebijakan driver dan platform, bukan diasumsikan dari YAML. Untuk kapasitas bersama, driver mencatat kapasitas yang dialokasikan, batas konkurensi, dan status pelepasan; penerimaan (admission) membatasi referensi yang melanggar kebijakan tenant.
Lanjutan 3: Haruskah scheduler mencoba ulang kegagalan driver selama penyiapan node?
Klasifikasikan kegagalan node sementara, kegagalan kesehatan perangkat, dan parameter Claim yang tidak valid terlebih dahulu. Coba ulang kegagalan sementara dengan backoff; tandai parameter yang tidak valid sebagai tidak dapat dicoba lagi; isolasi node yang tidak sehat sehingga scheduler tidak berulang kali mengirimkan beban kerja ke domain kegagalan yang sama.
Lanjutan 4: Bagaimana Anda membuktikan bahwa migrasi tidak mengurangi utilisasi?
Bandingkan keberhasilan alokasi, waktu tunggu, fragmentasi, waktu komputasi yang berguna, dan tingkat percobaan ulang pekerjaan untuk beban kerja serupa di pool perangkat yang sama. Pisahkan DRA dan plugin lama berdasarkan kelas perangkat; rata-rata utilisasi GPU di seluruh kluster saja tidak mencukupi.