Petunjuk dan cakupan
Klaster multi-tenant memiliki memori GPU dan bandwidth virtual-NIC yang tidak dapat dialokasikan hanya sebagai perangkat utuh. Platform menginginkan beberapa Pod berbagi satu perangkat, sementara setiap permintaan memiliki batas minimum, kelipatan (step), batas atas, dan identitas alokasi yang dapat dilacak. Desain model sumber daya dan alur menyeluruh (end-to-end) menggunakan consumable capacity pada Kubernetes DRA.
Asumsikan Kubernetes 1.34 dan driver yang dapat menegakkan batas kapasitas. Penjadwal (scheduler) tidak boleh melakukan oversubscribe pada perangkat. Kubernetes 1.34 menjadikan API DRA inti berstatus Generally Available (GA), sementara consumable capacity adalah kemampuan tahap alfa; jawaban yang kuat harus menandai batasan antara API stabil, feature gate, dan jaminan spesifik dari driver.
Apa yang dievaluasi oleh pewawancara
Jawaban harus menetapkan tanggung jawab yang jelas untuk DeviceClass, ResourceSlice, ResourceClaim, DeviceRequest, scheduler, dan driver. Jawaban harus menyatakan invarian bahwa kapasitas yang dialokasikan untuk satu perangkat tidak pernah melebihi kapasitas total, serta menjelaskan allowMultipleAllocations, RequestPolicy, ShareID, dan DistinctAttribute.
Pewawancara juga memeriksa apakah Anda menyamakan keputusan penjadwalan yang berhasil dengan pembatasan (throttling) tingkat aplikasi. Desain tingkat produksi membutuhkan penegakan driver, pelaporan status, otorisasi namespace, pemulihan kegagalan node, dan peluncuran bertahap yang dapat dibatalkan (reversible).
Pertanyaan klarifikasi
Apakah sumber daya dapat diisolasi?
Konfirmasikan apakah perangkat keras atau driver dapat menegakkan isolasi. Jika tidak dapat, platform dapat menawarkan kuota lunak atau alokasi perangkat utuh, tetapi tidak dapat menjanjikan QoS hanya dari kolom API.
Apa batas-batas pembagian dan otorisasi?
Tanyakan apakah beberapa namespace boleh berbagi satu perangkat, apakah akses admin diizinkan, dan atribut atau kapasitas perangkat apa yang dapat dibaca oleh tenant. Jawabannya akan mengubah selektor, pemeriksaan admisi, dan cakupan audit.
Apa yang harus bertahan dari kegagalan?
Klarifikasi apa yang terjadi setelah kegagalan penjadwalan, kegagalan alokasi driver, hilangnya node, atau pembuatan ulang Pod: pelepasan, retensi lease, atau antrean ulang (requeue). Percobaan ulang sementara dan kegagalan perangkat keras permanen memerlukan status yang berbeda.
Kerangka jawaban 30 detik
"Saya mendefinisikan invarian kapasitas dan batas tenant terlebih dahulu. DeviceClass mendeskripsikan perangkat yang memenuhi syarat, ResourceSlice memublikasikan kapasitas dan kebijakan permintaan, dan ResourceClaim mengekspresikan kebutuhan Pod. Scheduler memilih perangkat tanpa melebihi kapasitas; driver menggunakan ShareID untuk menegakkan batas memori atau bandwidth sebenarnya dan melaporkan status. Berbagi lintas-namespace membutuhkan otorisasi dan audit. Setiap pelepasan bersifat idempoten. Saya meluncurkan satu kelas perangkat pada satu waktu dan membandingkan kapasitas yang dialokasikan, batas sebenarnya, latensi penjadwalan, tingkat penolakan, dan waktu pemulihan."
Pembahasan mendalam langkah demi langkah
Langkah satu: mendefinisikan model sumber daya
DeviceClass mendeskripsikan tipe perangkat dan selektor CEL. ResourceSlice memublikasikan setiap perangkat, atributnya, kapasitas, dan apakah beberapa alokasi diizinkan. ResourceClaim menggunakan DeviceRequest untuk menyatakan kelas dan kapasitas. Pisahkan kapasitas total perangkat dari kapasitas permintaan; jumlah perangkat bernilai satu bukanlah nilai kapasitas.
Langkah dua: menyatakan invarian kapasitas
Untuk setiap perangkat, lacak kapasitas yang dialokasikan, unit, dan kebijakan permintaan. Jika suatu perangkat memiliki 40 GiB dan permintaan harus minimal 5 GiB dengan kelipatan 5 GiB, setiap permintaan harus memenuhi batas tersebut dan seluruh ShareID yang aktif jika dijumlahkan maksimal bernilai 40 GiB. Operasi pelepasan dan percobaan ulang menggunakan versi alokasi sehingga panggilan balik (callback) duplikat tidak mengurangi kapasitas dua kali.
Langkah tiga: mendeskripsikan alur data penjadwalan dan driver
Scheduler membaca ResourceSlice, memfilter selektor, rentang kapasitas, dan allowMultipleAllocations, mereservasi kandidat, dan mengikat (bind) ResourceClaim. Driver menerima alokasi, membuat batas independen yang diidentifikasi oleh ShareID, menerapkannya ke perangkat, dan melaporkan data dinamis dalam status ResourceClaim. Jika penjadwalan berhasil tetapi driver menolak alokasi, controller menampilkan status yang dapat dicoba ulang atau terminal; controller tidak boleh membuat Pod tampak Ready.
Langkah empat: menangani namespace dan perangkat duplikat
Perangkat bersama tidak menghapus batas namespace ResourceClaim. Admisi harus membatasi penggunaan DeviceClass, akses admin, dan konfigurasi driver. DistinctAttribute mencegah satu claim memilih perangkat dasar yang sama dua kali, seperti saat dua antarmuka jaringan harus mengakses subnet yang berbeda. Lakukan audit pada tenant, claim, ShareID, kapasitas, dan versi kebijakan, bukan hanya nama perangkat akhir.
Langkah lima: mendesain penanganan kegagalan dan reklamasi
Setelah driver dimulai ulang, pulihkan ShareID dan batas sebenarnya dari penyimpanan persisten. Setelah node hilang, tandai alokasi sebagai unknown dan jangan langsung memberikan kapasitas tersebut ke Pod lain sampai lease, isolasi perangkat (fencing), atau konfirmasi driver membuktikan alokasi lama telah hilang. Penghapusan Pod, kedaluwarsa claim, dan pembatalan (rollback) penjadwalan harus dapat diulang. Alokasi yang ada tetap mempertahankan snapshot kebijakannya; claim baru menggunakan kebijakan yang diperbarui.
Langkah enam: peluncuran, SLO, dan perhitungan kapasitas
Asumsikan 100 perangkat dengan masing-masing 40 GiB dan target pemanfaatan rata-rata 70 persen. Kapasitas logis yang dapat dijadwalkan adalah sekitar 2.800 GiB, bukan janji throughput; sediakan cadangan untuk overhead driver, fragmentasi, dan toleransi kegagalan. Tetapkan SLO untuk p99 penjadwalan, p99 konfigurasi driver, tingkat penolakan kapasitas, dan konvergensi status. Aktifkan feature gate per kelas perangkat. Bandingkan throughput, tail latency, fragmentasi, dan pemulihan dengan alokasi perangkat utuh.
Langkah tujuh: membandingkan alternatif
Jika perangkat keras hanya mendukung pembagian tetap, MIG atau DeviceClass yang dipartisi sebelumnya lebih sederhana dan lebih mudah divalidasi, dengan konsekuensi fragmentasi dan elastisitas yang lebih rendah. Jika driver tidak dapat menegakkan batas terperinci, kembalilah ke alokasi perangkat utuh atau ekspansi kapasitas; jangan berasumsi bahwa kolom kapasitas otomatis memberikan isolasi.
Contoh jawaban berkualitas tinggi
Saya pertama-tama memverifikasi apakah perangkat dapat menegakkan isolasi kapasitas. Jika tidak bisa, desain tersebut hanya berupa pemilihan deklaratif dan tidak memiliki jaminan QoS. Jika bisa, DeviceClass mendeskripsikan perangkat yang memenuhi syarat, ResourceSlice memublikasikan kapasitas dan kebijakan permintaan, dan ResourceClaim membawa permintaan tenant. Scheduler mengikat hanya ketika selektor cocok dan jumlah kapasitas tetap berada di bawah batas perangkat; driver kemudian membuat batas dalam cakupan ShareID dan melaporkan status.
Saya menjadikan jumlah kapasitas, versi kebijakan, dan pelepasan idempoten sebagai invarian eksplisit. Berbagi lintas-namespace menggunakan admisi, otorisasi admin, dan audit; DistinctAttribute mencegah pemilihan perangkat dasar yang duplikat dalam satu claim. Pada kegagalan driver atau node, saya mempertahankan alokasi dalam status unknown hingga ada fencing atau konfirmasi sebelum mereklamasinya. Peluncuran dimulai dengan satu kelas dan mengukur p99 penjadwalan, p99 driver, penolakan, penegakan batas sebenarnya, dan pemulihan. Perangkat keras dengan irisan tetap menggunakan desain partisi awal.
Kesalahan umum
- Gejala → menempatkan nilai kapasitas hanya di ResourceClaim → Alasan gagal → driver mungkin tidak menegakkan batas nyata → Solusi → buktikan jalur penegakan batas dan pelaporan status.
- Gejala → menggunakan jumlah perangkat sebagai total kapasitas → Alasan gagal → permintaan konkuren menyebabkan oversubscribe atau membuang fragmen → Solusi → lacak kapasitas yang dialokasikan per perangkat dan versi.
- Gejala → memperlakukan perangkat bersama sebagai pembagian lintas-tenant tanpa syarat → Alasan gagal → batas namespace dan otorisasi menghilang → Solusi → tambahkan admisi, kontrol akses admin, dan audit.
- Gejala → langsung melepaskan kapasitas setelah node hilang → Alasan gagal → driver lama mungkin masih menegakkan alokasi tersebut, menyebabkan alokasi ganda → Solusi → lakukan fencing, konfirmasi lease, atau pertahankan status unknown secara eksplisit.
- Gejala → menjanjikan SLO stabil untuk feature gate alfa → Alasan gagal → perilaku API, driver, dan pemutakhiran bervariasi → Solusi → tandai batasan versi dan validasi melalui canary.
Pertanyaan lanjutan dan respons yang kuat
Pertanyaan lanjutan 1: Dua namespace meminta sisa 10 GiB terakhir secara bersamaan. Bagaimana Anda menghindari race condition?
Gunakan versi ResourceSlice atau pemeriksaan konkurensi optimistik yang setara saat mereservasi kapasitas. Jika pengikatan gagal, baca kembali status saat ini dan coba lagi. Panggilan balik driver tidak dapat mengabaikan invarian scheduler; control plane yang mengonfirmasi alokasi akhir.
Pertanyaan lanjutan 2: Driver melaporkan ShareID, tetapi Pod tidak pernah mulai. Apa yang terjadi?
Pisahkan status alokasi dari kesiapan (readiness) Pod. Setelah waktu tunggu habis (timeout), controller melakukan pelepasan idempoten atau masuk ke status yang terlihat oleh operator sambil tetap mempertahankan ShareID, versi claim, dan alasannya. Jangan membuang kapasitas atau data audit hanya karena Pod tidak berstatus Running.
Pertanyaan lanjutan 3: Kebijakan berubah dari minimum 5 GiB menjadi 10 GiB. Apakah claim yang ada ikut berubah?
Alokasi yang telah selesai mempertahankan snapshot kebijakan saat alokasi tersebut diberikan; claim baru akan menggunakan kebijakan baru. Penyeimbangan ulang (rebalancing) memerlukan alur migrasi eksplisit, dukungan driver untuk perubahan ukuran, dan urutan pelepasan serta pengalokasian ulang yang dapat dibatalkan.
Pertanyaan lanjutan 4: Bagaimana Anda membuktikan bahwa bandwidth bersama benar-benar ditegakkan batasnya?
Jalankan pengujian dasar penyewa tunggal (single-tenant baseline) dan pengujian beban multi-ShareID dengan lalu lintas, node, dan versi driver yang tetap. Bandingkan throughput per tenant, p99, paket drop, dan batas atas penegakan. Status ResourceClaim saja tidak membuktikan QoS perangkat keras.