Wawancara system design: bagaimana Anda mendesain topology-aware gang scheduling untuk beban kerja Kubernetes?

Masalah dan skenario yang berlaku

Anda mengelola platform pelatihan terdistribusi (distributed training) di Kubernetes. Beban kerja direpresentasikan oleh PodGroup, dan Pod-Podnya harus berbagi rak atau zona untuk mengurangi latensi komunikasi. Jika satu domain topologi tidak dapat memuat setidaknya minCount Pod, beban kerja harus tetap tidak dapat dijadwalkan (unschedulable).

Ini cocok untuk wawancara platform engineering, SRE, dan system design. Asumsikan Topology-Aware Scheduling Kubernetes v1.36 alpha, dinonaktifkan secara default, dengan satu batasan topologi per PodGroup.

Apa yang dievaluasi oleh pewawancara

• Apakah Anda membedakan penyeimbangan lintas domain dengan persebaran topologi (topology spread) dari penempatan domain yang sama untuk sebuah gang.
• Apakah PodGroup, label node, penempatan kandidat, kelayakan sumber daya, dan pengikatan atomik (atomic binding) membentuk satu aliran data.
• Apakah Anda menjelaskan minCount, kekurangan kapasitas, scale-up, dan ketiadaan preemption yang dipicu oleh topologi.
• Apakah Anda mengidentifikasi status alpha, grup heterogen, dan risiko rollback sebelum menyatakan desain siap untuk produksi.

Pertanyaan klarifikasi sebelum menjawab

1. Apakah Pod harus berbagi rak, zona, atau domain NUMA? Setiap kunci topologi mengubah asumsi latensi dan kapasitas.
2. Apakah setiap Pod harus mulai bersama-sama, atau apakah minCount cukup untuk membuat kemajuan? Ini menentukan kebijakan Gang dan elastisitas.
3. Apakah Pod bersifat homogen? Permintaan sumber daya yang berbeda memengaruhi apakah penempatan kandidat dapat ditemukan.
4. Apakah kluster boleh melakukan penskalaan atau preemption? v1.36 TAS tidak melakukan preemption semata-mata untuk memenuhi topologi.

Kerangka jawaban 30 detik

“Saya mendefinisikan tujuannya sebagai kelayakan tingkat grup di dalam satu domain topologi, bukan penyebaran replika. Template Workload membuat PodGroup dengan gang dan minCount; label node menyediakan kunci topologi. Penjadwal (scheduler) menghasilkan subset node kandidat, memeriksa seluruh grup, dan memberi skor pada penempatan yang layak. Jika tidak ada yang cocok, grup tetap tidak dapat dijadwalkan. Pengontrol (controller) dan autoscaler mempertimbangkan keseluruhan bentuk sumber daya, dan preemption ditangani secara terpisah karena v1.36 TAS tidak memicunya. Saya menguji kapasitas domain, hilangnya node, dan permintaan heterogen di balik feature gate alpha.”

Pembahasan mendalam langkah demi langkah

1. Nyatakan ko-lokasi, bukan penyebaran

topologySpreadConstraints menggunakan maxSkew untuk menyeimbangkan Pod di seluruh domain; pertanyaan ini mengharuskan semua anggota berbagi satu nilai label topologi. Mencampur semantik menghasilkan penempatan yang berlawanan, jadi tuliskan invarian sebagai “satu domain harus memuat setidaknya minCount.”

2. Tentukan kontrak PodGroup

Template mendeklarasikan kebijakan Gang, minCount, dan satu kunci topologi. Konfigurasi ilustratif adalah:

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
spec:
  schedulingPolicy:
    gang:
      minCount: 4
  schedulingConstraints:
    topology:
      - key: topology.example.com/rack

Node memerlukan nilai label yang stabil dan terkelola. PodGroup mengekspresikan penempatan; pengontrol Workload tetap memiliki pembuatan anggota, versi, dan siklus hidup.

3. Jelaskan penempatan kandidat

Penjadwal pertama-tama menghasilkan subset node kandidat menggunakan sumber daya, taints, afinitas, dan kunci topologi. Penjadwal kemudian memeriksa apakah seluruh PodGroup cocok di dalam setiap subset dan memberi skor pada penempatan yang layak. Ini menghindari pengikatan Pod awal di seluruh domain yang menyebabkan anggota yang tersisa tidak dapat memenuhi minCount.

4. Tangani kapasitas, scale-up, dan preemption

Jika tidak ada domain kandidat yang memiliki kapasitas cukup, seluruh grup tetap tidak dapat dijadwalkan. Autoscaler harus mengonsumsi bentuk CPU, memori, GPU, dan domain yang lengkap daripada melakukan penskalaan untuk Pod Pending pertama. v1.36 TAS tidak memicu preemption Pod atau Workload untuk memenuhi topologi, jadi reservasi kapasitas, antrean, atau kebijakan preemption hulu (upstream) yang eksplisit adalah persyaratan terpisah.

5. Tangani pembuatan ulang anggota dan keterikatan domain (domain stickiness)

Ketika anggota sudah berjalan di suatu domain, Pod yang dibuat ulang dipaksa masuk ke domain yang sama; mereka tetap Pending jika domain tersebut kekurangan kapasitas meskipun domain lain memiliki ruang. Tampilkan ini sebagai penantian terikat domain (domain-sticky wait) dan putuskan apakah akan menunggu, memulihkan checkpoint, atau membuat generasi PodGroup baru dengan batasan berbeda.

6. Evaluasi batas alpha dan heterogen

API v1.36 berstatus alpha dan dinonaktifkan secara default. Catatan rilis resmi menyatakan bahwa PodGroup yang heterogen atau dependensi antar-Pod tidak dijamin menemukan penempatan bahkan ketika ada yang tersedia. Gate produksi harus mencakup versi, feature gate, plugin penjadwal, autoscaler, dan rollback; satu penjadwalan yang berhasil bukanlah jaminan universal.

7. Bangun loop verifikasi dan rollback

Jalankan beban kerja pelatihan yang sama dengan kapasitas domain yang pas-pasan, satu node hilang, label topologi hilang, jenis GPU berbeda, dan pembuatan ulang anggota. Catat domain kandidat, jumlah anggota yang layak, alasan Pending, waktu tunggu, lalu lintas lintas-domain, dan throughput pelatihan. Jika pengujian canary gagal, nonaktifkan feature gate atau kembali ke penjadwalan Gang biasa sambil mempertahankan peristiwa PodGroup untuk audit.

Contoh jawaban berkualitas tinggi

Saya akan mendefinisikan invarian sebagai “setidaknya minCount anggota muat secara bersamaan dalam satu domain topologi,” daripada menggunakan batasan penyebaran untuk keseimbangan. Pengontrol Workload membuat PodGroup dengan Gang, minCount, dan satu kunci topologi, lalu membuat Pod yang merujuknya. Penjadwal menghasilkan domain kandidat dari sumber daya dan label node, memeriksa grup lengkap, dan hanya memberi skor pada domain yang layak; jika tidak ada yang berhasil, grup tetap Pending. Autoscaler menskalakan dari bentuk grup, sementara preemption terpisah karena v1.36 TAS tidak memicunya. Anggota yang dibuat ulang mempertahankan keterikatan domain; jika domain tersebut hilang, buat generasi baru. Terakhir, uji kehilangan node, label yang hilang, GPU heterogen, dan rollback di balik gate alpha sambil mengukur waktu tunggu, lalu lintas lintas-domain, dan throughput pelatihan.

Kesalahan umum

• Gejala: Menjelaskan penempatan domain yang sama dengan maxSkew. Mengapa gagal: penyebaran menargetkan distribusi, berlawanan dengan ko-lokasi Gang. Perbaikan: nyatakan invarian domain tunggal PodGroup terlebih dahulu.
• Gejala: Mengikat Pod satu per satu. Mengapa gagal: pengikatan awal menghabiskan kapasitas di beberapa domain dan tidak menyisakan cara untuk mencapai minCount. Perbaikan: evaluasi penempatan kandidat lengkap terlebih dahulu.
• Gejala: Mengasumsikan TAS secara otomatis melakukan preemption. Mengapa gagal: v1.36 secara eksplisit menyatakan bahwa penjadwalan sadar-topologi tidak memicu preemption. Perbaikan: desain reservasi, antrean, atau pengontrol preemption hulu.
• Gejala: Mengabaikan grup heterogen dan status alpha. Mengapa gagal: penempatan tidak dijamin dan fitur dinonaktifkan secara default. Perbaikan: tambahkan pemeriksaan versi, gate, plugin, dan rollback.

Pertanyaan lanjutan dan jawaban

Bagaimana jika satu rak tidak dapat memuat minCount, tetapi dua rak bersama-sama dapat memuatnya?

Invarian domain yang sama tidak terpenuhi, jadi pertahankan grup dalam status Pending atau turunkan minCount hanya jika aplikasi mengizinkan elastisitas. Jangan diam-diam beralih ke penempatan lintas rak karena asumsi komunikasi telah berubah.

Bagaimana seharusnya autoscaler melakukan penskalaan dengan benar?

Perlakukan permintaan sumber daya penuh, kunci topologi, dan minCount sebagai satu unit penskalaan. Prediksikan jenis dan jumlah node yang diperlukan dalam domain target, buat ulang kandidat setelah scale-up, dan terapkan batas waktu tunggu (wait deadline).

Mengapa anggota yang dibuat ulang tidak dapat pindah ke domain lain?

Perilaku yang terdokumentasi mempertahankan anggota baru di domain tempat anggota yang ada berjalan; memindahkan satu anggota akan mengubah asumsi latensi dan sumber daya bersama. Jika domain hilang secara permanen, buat generasi PodGroup baru alih-alih mengubah yang lama secara diam-diam.

Bagaimana ini bisa hidup berdampingan dengan batasan persebaran topologi (topology spread constraints)?

Gunakan TAS untuk menempatkan anggota bersama di dalam satu job pelatihan; gunakan spread untuk mendistribusikan replika di beberapa job. Sebelum menempatkan keduanya pada satu Pod, uji apakah batasan ketat (hard constraints) mereka memiliki irisan yang tidak kosong atau Pod dapat tetap Pending.

Kapan penjadwalan Gang biasa lebih baik daripada TAS?

Pilih Gang biasa ketika komunikasi lintas domain murah, kapasitas domain sering kali ketat, fitur alpha belum siap untuk peluncuran Anda, atau beban kerja tidak memerlukan rak bersama. Aktifkan TAS hanya jika peningkatan throughput sebanding dengan kapasitas dan biaya operasional.