Permintaan dan kasus penggunaan
Sebuah platform batch membuat ribuan Pod sekaligus, tetapi image, kuota, topologi, atau sumber daya eksternal belum siap. Rancang mekanisme yang membuat Pod tanpa langsung mengirimkannya ke scheduler Kubernetes, lalu melepaskannya ketika kondisi telah terpenuhi. Jelaskan cara menghindari pemborosan kerja scheduler dan Cluster Autoscaler pada Pod Pending yang tidak valid, serta cara menangani timeout gate, kegagalan controller, dan isolasi tenant.
Hal yang diuji oleh pewawancara
- Memisahkan status pembuatan (created state) dari status siap dijadwalkan (schedulable state).
- Memahami pembuatan, penghapusan, dan batasan tanpa penambahan (no-addition constraint) dari
spec.schedulingGates. - Merancang alur pelepasan idempoten, timeout, otorisasi, dan pemulihan.
- Membedakan SchedulingGated, Unschedulable, dan kegagalan runtime.
- Membuktikan bahwa sistem tidak dapat berhenti tanpa pemberitahuan (silent stall) menggunakan metrik, event, dan catatan audit.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Siapa yang menambahkan setiap gate, dan siapa yang mengonfirmasi kondisinya?
- Apakah kondisi tersebut mencakup lingkup Pod, batch, atau tenant, dan apakah gang scheduling diperlukan?
- Berapa latensi pelepasan, kebijakan kedaluwarsa (expiry policy), batas konkurensi, dan target biaya?
- Bagaimana perilaku restart controller, percobaan ulang API (API retries), penskalaan node, dan pencabutan izin?
Jawaban tiga puluh detik
Saya akan membuat Pod dengan schedulingGates yang dibatasi pada namespace serta menjadikan image warming, kuota, dan kesiapan sumber daya eksternal sebagai kondisi yang dapat diobservasi. Controller hanya menghapus gate miliknya sendiri dan tidak pernah menambahkan gate baru setelah pembuatan; controller memeriksa ulang kuota tenant dan kebijakan batch sebelum melepaskan. Metrik membedakan Pod yang tertahan gate (gated Pods) dari Pod yang benar-benar tidak dapat dijadwalkan (unschedulable), dan kedaluwarsa akan masuk ke status kegagalan eksplisit atau tinjauan manusia dengan kondisi berversi dan catatan audit.
Jawaban mendalam, langkah demi langkah
1. Tentukan state machine
Pisahkan Created, SchedulingGated, ReadyToSchedule, Unschedulable, Running, dan Expired. API masih dapat membaca Pod, tetapi scheduler tidak mencoba menjadwalkan Pod yang daftar gate-nya tidak kosong.
2. Pilih nama gate
Setiap gate adalah kondisi string, seperti batch.example.com/image-ready. Tempatkan versi namespace, batch, dan controller dalam label atau anotasi; pertahankan nama gate sebagai pernyataan kondisi yang belum terpenuhi, bukan sebagai wadah data dinamis.
3. Tetapkan gate pada saat pembuatan
Gate dapat diinisialisasi pada saat pembuatan Pod oleh klien atau admission mutator. Gate yang ada dapat dihapus dalam urutan apa pun setelah pembuatan, tetapi gate baru tidak dapat ditambahkan, sehingga setiap kemungkinan kondisi pemblokiran harus dihitung pada saat pembuatan.
4. Rancang controller pelepasan
Controller mengamati Pod, kuota, image warming, dan event sumber daya eksternal, menghitung rangkaian kondisi, dan menerapkan patch berversi sumber daya (resource-versioned patch). Event duplikat harus menghasilkan hasil yang sama; setiap controller hanya menghapus gate miliknya sendiri agar controller tidak saling menimpa.
5. Tangani batch dan konkurensi
Catat sumber daya tingkat batch dalam objek terpisah, sementara gate Pod menunggu keputusan controller batch. Hapus gate dalam batch yang memperhatikan tenant, prioritas, dan konkurensi agar scheduler dan autoscaler tidak menerima lonjakan beban mendadak.
6. Rancang kedaluwarsa dan intervensi manusia
Simpan waktu pembuatan, progres kondisi terakhir, dan tenggat waktu (deadline). Saat kedaluwarsa, jangan menghapus gate secara diam-diam; catat alasannya, pancarkan event, dan pilih pembatalan, percobaan ulang, atau antrean manusia. Percobaan ulang memerlukan backoff dan batas maksimum.
7. Amati antrean yang sebenarnya
Kubernetes mengekspos label gated pada scheduler_pending_pods untuk membedakan Pod yang secara eksplisit belum siap dari Pod yang telah dicoba dan ternyata tidak dapat dijadwalkan. Gabungkan label ini dengan kondisi Pod, event, panjang antrean controller, persentil umur gate, dan aktivitas autoscaler untuk menemukan bottleneck.
8. Batasi otorisasi dan lakukan pemulihan
Kebijakan admisi membatasi siapa yang boleh membuat gate, dan controller hanya boleh menghapus gate dengan namespace dan awalan yang diizinkan. Setelah restart, bangun kembali state dari API; jika terjadi konflik patch, baca ulang dan bandingkan versi sumber daya. Jika controller tetap tidak tersedia, staf on-call memerlukan prosedur pembatalan atau pelepasan yang aman yang didukung oleh jejak audit.
Trade-off dan batasan
Scheduling gates mengontrol apakah Pod masuk ke proses penjadwalan; fitur ini tidak menggantikan node affinity, permintaan sumber daya, batasan topologi, atau kesiapan runtime. Terlalu banyak gate menyembunyikan masalah kapasitas nyata di lapisan aplikasi; terlalu sedikit gate mengirimkan Pod yang belum siap ke scheduler. Bedakan kondisi yang belum terpenuhi dari kluster yang tidak memiliki kapasitas, dan jangan perlakukan gate sebagai kunci transaksi lintas objek secara umum.
Rencana peluncuran dan bukti
- Catat pemilik setiap gate, sumber kondisi, kedaluwarsa, dan izin penghapusan.
- Validasi awalan gate, kuota tenant, dan kumpulan kondisi waktu pembuatan yang lengkap dalam tahap admisi.
- Lakukan uji beban pada scheduler, autoscaler, API server, dan konflik patch controller dengan batch kecil terlebih dahulu.
- Pantau
scheduler_pending_pods{queue="gated"}, umur gate, tingkat kedaluwarsa, throughput pelepasan, dan konkurensi per tenant. - Uji restart controller, partisi jaringan, pencabutan izin, pembatalan batch, dan patch duplikat, lalu verifikasi log audit.
Kesalahan umum dan tindak lanjut
Kesalahan 1: Menambahkan gate setelah pembuatan
API hanya mengizinkan gate pada saat pembuatan dan mengizinkan penghapusan setelahnya. Kondisi dinamis harus diagregasikan sebelum pembuatan atau ditunggu melalui objek terpisah sebelum membuat Pod.
Kesalahan 2: Menyebut SchedulingGated sebagai kegagalan penjadwalan
Pod dengan gate yang tidak kosong belum pernah dicoba oleh scheduler. Bedakan antara gated, Unschedulable, ImagePullBackOff, dan kesiapan aplikasi.
Kesalahan 3: Menggunakan penghapusan gate sebagai kontrol kuota
Menghapus gate hanya mengizinkan upaya penjadwalan; ini tidak menjamin sumber daya. Periksa kembali kuota, prioritas, dan konkurensi batch sebelum melepaskannya.
Kesalahan 4: Menghilangkan peringatan umur gate dan kedaluwarsa
Tanpa persentil umur, macetnya proses secara diam-diam (silent stall) tidak akan terlihat. Catat kondisi, controller yang bertanggung jawab, progres terakhir, dan jalur pembatalan eksplisit.
Kesalahan 5: Mengabaikan biaya autoscaler
Sekumpulan besar Pod yang belum siap dapat memicu evaluasi scale-up yang sia-sia. Gunakan metrik antrean dengan gate dan pembatasan pelepasan (release throttling) untuk memverifikasi bahwa biaya benar-benar turun.