Wawancara system design: Bagaimana Anda akan menggunakan Kubernetes PodGroup untuk gang scheduling?

Pertanyaan

Kubernetes v1.35 mendokumentasikan Scheduling Group sebagai kemampuan alpha. Rancang platform batch di mana worker yang saling bergantung hanya berjalan ketika setidaknya minCount Pod dapat ditempatkan bersama. Jelaskan bagaimana PodGroup, scheduler, controller, autoscaling, dan penanganan kegagalan saling bekerja sama. Nyatakan asumsi versi dan feature-gate.

Hal yang diuji oleh pewawancara

Poin pengujian utamanya adalah apakah Anda dapat meningkatkan kelayakan penjadwalan dari satu Pod ke tingkat grup sambil menjaga API, penjadwalan, dan runtime state tetap konsisten. Jawaban yang kuat membedakan basic dari gang, menangani ketiadaan PodGroup, kekurangan kapasitas, kegagalan anggota, preemption, dan observabilitas, serta menghindari penyajian alpha API sebagai sesuatu yang sepenuhnya siap untuk produksi.

Pertanyaan klarifikasi

1. Apakah setiap worker harus mulai bersamaan, atau apakah ambang batas konkurensi yang lebih rendah sudah cukup?
2. Apakah anggotanya berupa Job sekali jalan (one-shot) atau service yang berjalan terus-menerus (long-running)?
3. Apakah mereka membutuhkan GPU, batasan topologi, atau penempatan lintas klaster? Referensi yang terdokumentasi adalah PodGroup dalam namespace yang sama.
4. Berapa batas waktu tunggu (deadline), dan bolehkah job mengantre, meminjam kapasitas, atau menurunkan spesifikasi?

Kerangka kerja 30 detik

Mulailah dengan batasannya: Scheduling Group dan kebijakan PodGroup berstatus alpha di v1.35, dinonaktifkan secara default, dan memerlukan feature gate GenericWorkload. Kemudian jelaskan empat lapisan: kontrak API, penjadwalan grup, siklus hidup, dan operasi. Workload membuat PodGroup; Pod merujuknya; scheduler menerapkan kebijakan dan minCount; controller menangani timeout, percobaan ulang (retry), dan pembersihan; metrik serta rollback melindungi proses peluncuran (rollout).

Desain langkah demi langkah

1. Model dan invarian

Controller membuat satu PodGroup per eksekusi dengan anggota yang diinginkan, kebijakan, versi, dan tenant. Setiap Pod menyetel spec.schedulingGroup.podGroupName ke PodGroup di namespace yang sama. Field ini bersifat immutable, sehingga memindahkan Pod berarti membuat set baru. Untuk sebuah gang, tidak ada anggota yang di-bind hingga invarian minCount terpenuhi.

2. Memilih kebijakan

Gunakan basic jika anggota dapat berjalan secara independen dan pengelompokan terutama ditujukan untuk manajemen dan observabilitas. Gunakan gang untuk beban kerja pelatihan (training) atau batch yang saling terikat erat; grup hanya layak dijalankan jika setidaknya minCount anggota dapat dijadwalkan secara bersamaan. Menyetel minCount di bawah jumlah total memungkinkan elastisitas; menyetelnya sama dengan total mengharuskan semua anggota tersedia.

3. State machine pengiriman dan penantian

Buat PodGroup sebelum membuat Pod agar referensi dapat diselesaikan. Jika objek yang dirujuk tidak ada, Pod tetap dalam status Pending dan scheduler akan mencoba lagi setelah grup muncul. Lacak status seperti PendingGroup, WaitingCapacity, Feasible, Bound, Running, Failed, dan Cancelled, masing-masing dengan generasi, alasan, dan timestamp.

4. Koordinasi penjadwalan dan kapasitas

Scheduler pertama-tama mengevaluasi node kandidat menggunakan filter, topologi, perangkat, dan prioritas, lalu memeriksa kelayakan grup. Operasi bind harus dapat diulang (retryable) dan idempoten, serta hanya terjadi setelah jumlah kandidat mencapai minCount. Autoscaler harus memperhitungkan pola kebutuhan resource grup dan melakukan penskalaan untuk seluruh permintaan alih-alih hanya menambahkan kapasitas untuk Pod pertama saja.

5. Preemption, batas waktu, dan keadilan

Berikan grup prioritas dan bobot antrean yang konsisten agar preemption tidak menyisakan setengah grup yang tidak dapat digunakan. Pada saat mencapai deadline, batalkan grup dan lepaskan reservasi; percobaan ulang menggunakan generasi baru sehingga anggota yang basi tidak dapat bergabung kembali. Kuota tenant, ukuran grup maksimum, dan penuaan antrean mencegah gang besar memonopoli klaster.

6. Kegagalan anggota dan rollback

Setelah startup, anggota yang mengalami crash tidak boleh diperlakukan sebagai bukti bahwa grup saat ini dalam kondisi sehat. Bergantung pada semantik job, restart satu anggota atau hentikan seluruh grup; job pelatihan biasanya memulihkan checkpoint dan membuat generasi baru. Menghapus Workload harus membersihkan Pod dan PodGroup yang dimilikinya sambil tetap mempertahankan terminal event untuk audit.

7. Batas observabilitas dan keamanan

Ekspos latensi antrean grup, jumlah anggota yang layak, minCount, jumlah scale-up dan preemption, serta alasan kegagalan. Admission webhook memvalidasi namespace, kuota, ukuran grup, dan ketersediaan feature gate. Karena API ini masih berstatus alpha, gunakan switch peluncuran eksplisit, uji kompatibilitas, dan jalur rollback yang cepat.

Contoh jawaban yang kuat

"Saya akan meminta Workload controller membuat PodGroup di namespace yang sama dengan kebijakan gang dan minCount yang sama dengan jumlah minimum worker yang dibutuhkan untuk membuat progres. Pod merujuknya melalui field schedulingGroup yang immutable. Controller membuat grup terlebih dahulu; referensi yang belum terselesaikan tetap berstatus Pending. Scheduler mengevaluasi resource, topologi, dan prioritas untuk semua anggota dan hanya melakukan binding saat jumlah yang layak mencapai minCount. Autoscaler melakukan penskalaan berdasarkan pola kebutuhan resource grup. Deadline akan membatalkan seluruh grup dan melepaskan kapasitas; sesi pelatihan yang gagal mendapatkan generasi baru yang dipulihkan dari checkpoint. Manifes deployment secara eksplisit mencatat v1.35 alpha dan GenericWorkload, dan peluncuran dimulai di klaster yang terisolasi."

Pola kegagalan umum

• Menyebut basic sebagai all-or-nothing padahal anggotanya dapat dijadwalkan secara independen.
• Hanya menggunakan label tanpa menjelaskan referensi PodGroup pada namespace yang sama dan field yang bersifat immutable.
• Mengabaikan grup yang hilang, scale-up, deadline, preemption, atau generasi retry.
• Mengabaikan status alpha dan feature gate GenericWorkload.
• Membahas binding yang berhasil tanpa pembatalan di tingkat grup dan metrik.

Arah tindak lanjut

Bagaimana jika PodGroup dibuat setelah Pod?

Pod tetap berstatus Pending, dan scheduler akan mempertimbangkannya kembali setelah PodGroup dibuat. Controller sebaiknya tetap membuat grup terlebih dahulu untuk memperpendek jeda waktu tersebut.

Bagaimana Anda memilih minCount?

Gunakan konkurensi minimum yang berguna dari aplikasi, resource per Pod, dan waktu antrean yang dapat diterima, lalu terapkan kuota dan batas atas.

Bagaimana Anda menghindari kelaparan sumber daya (starvation) pada gang?

Kombinasikan antrean yang adil (fair queues), penuaan antrean (aging), batas ukuran grup, kuota tenant, dan pembatalan deadline sambil memantau waktu tunggu grup.

Apa bedanya ini dengan scheduling gates?

Sebuah gate mengontrol kapan satu Pod memasuki antrean yang dapat dijadwalkan. Scheduling Group membuat scheduler mengevaluasi satu set Pod melalui sebuah PodGroup. Keduanya dapat digabungkan, tetapi metrik dan semantik kegagalannya harus tetap dipisahkan.

Kapan Anda akan menunda peluncuran?

Tunda peluncuran jika versi klaster, feature gate, scheduler plugin, atau autoscaler tidak kompatibel, atau ketika upgrade alpha dan rollback belum diuji. Gunakan queue controller eksplisit sebagai desain sementara.

Referensi

• Dokumentasi Kubernetes: "Scheduling Group".
• Dokumentasi Kubernetes: "PodGroup Scheduling Policies".
• Dokumentasi Kubernetes: "Scheduling API Reference".