Wawancara system design: Bagaimana topology spread constraints pada Kubernetes meningkatkan ketersediaan?

Perintah dan konteks

Sebuah layanan stateless berjalan di beberapa zona dan diskalakan dari 2 hingga 30 replika. Selama kegagalan node, penskalaan, dan rolling release, tim ingin menghindari penumpukan replika dalam satu domain kegagalan tanpa membuat rilis baru menjadi mustahil untuk dijadwalkan. Rancang topologySpreadConstraints dan jelaskan kapan harus menggunakan DoNotSchedule, ScheduleAnyway, atau anti-affinity.

Hal yang dievaluasi pewawancara

• Apakah Anda mengubah ketersediaan menjadi target domain kegagalan node, zona, dan wilayah yang eksplisit.
• Apakah Anda menjelaskan maxSkew, minDomains, topologyKey, dan whenUnsatisfiable dengan benar.
• Apakah Anda menangani kasus khusus (edge cases) terkait selektor, ketiadaan label topologi, dan jumlah replika yang sedikit.
• Apakah penempatan, PDB, pembaruan bertahap (rolling updates), autoscaling, dan observabilitas bekerja sebagai satu kesatuan desain.

Pertanyaan klarifikasi

1. Apakah zona-zona tersebut independen dalam hal daya, jaringan, dan kapasitas, dan apakah kegagalan tingkat regional masuk dalam cakupan?
2. Berapa banyak replika yang harus tetap ada setelah kehilangan satu domain kegagalan?
3. Haruskah Pod yang tidak dapat dijadwalkan menunggu, mengurangi ketersediaan, atau mentolerir ketimpangan (skew) sementara?
4. Apakah label beban kerja, label topologi node, dan batasan default dikelola oleh platform?
5. Apakah versi lama dan baru menggunakan labelSelector yang sama selama rolling update?

Jawaban 30 detik

Saya akan mendefinisikan domain kegagalan dan kapasitas minimum terlebih dahulu, kemudian menetapkan target penempatan terpisah untuk node dan zona. Layanan penting (kritis) menggunakan batasan DoNotSchedule; beban kerja biasa atau elastis menggunakan ScheduleAnyway sebagai target fleksibel (soft). maxSkew membatasi selisih untuk satu selektor di seluruh domain yang memenuhi syarat, sedangkan minDomains mencegah kesalahan perhitungan saat ada domain yang hilang. Sebelum peluncuran, saya akan menguji label, penskalaan, rolling update, dan kegagalan domain tunggal; di tahap produksi, saya akan memantau replika per domain, durasi Pending, kapasitas yang tersedia, dan anggaran gangguan PDB.

Jawaban mendalam

Langkah 1: Tentukan domain dan kapasitas

Petakan node, zona, dan wilayah ke nilai topologyKey yang berbeda. Jika layanan harus bertahan dari kehilangan satu zona, pertahankan replika yang cukup di setidaknya dua zona; dengan hanya dua replika, Anda tidak dapat menjanjikan penempatan merata di tiga zona sekaligus dua replika yang sehat setelah kehilangan salah satunya. Nyatakan invarian kapasitas sebelum memilih tingkat ketatnya aturan.

Langkah 2: Pilih maxSkew dan minDomains

maxSkew adalah selisih yang diizinkan antara domain target dan nilai minimum global; dengan DoNotSchedule, melampaui batasan ini akan membuat Pod tetap berstatus Pending. minDomains menyatakan berapa banyak domain yang memenuhi syarat yang dibutuhkan dan mencegah sekumpulan domain yang kurang lengkap diperlakukan sebagai distribusi yang valid. Uji layanan dengan jumlah replika sedikit agar batasan tersebut tidak memblokir rilis.

Langkah 3: Pisahkan batasan ketat (hard) dan fleksibel (soft)

Layanan control-plane atau pembayaran dapat menggunakan DoNotSchedule di tingkat zona dan mengubah kegagalan penempatan menjadi peringatan kapasitas. Pekerjaan batch atau yang dapat ditunda dapat menggunakan ScheduleAnyway, meminta scheduler untuk mengurangi ketimpangan sambil mengizinkan ketidakseimbangan sementara. Hard anti-affinity cocok untuk aturan sederhana "jangan tempatkan bersama"; topologi bertingkat dan ketimpangan yang terukur biasanya lebih jelas jika menggunakan spread constraints.

Langkah 4: Jadikan selektor dan label dapat diandalkan

Batasan labelSelector harus cocok dengan template Pod yang sebenarnya, jika tidak, Pod baru dapat dihitung pada kumpulan yang salah. Node memerlukan label zona, wilayah, dan hostname yang stabil; node tanpa kunci topologi tidak akan berpartisipasi dengan benar dalam perhitungan domain tersebut. Pemeriksaan admisi harus memvalidasi selektor, label, dan nilai default sebelum tim menyalin manifes yang keliru.

Langkah 5: Koordinasikan rilis, PDB, dan penskalaan

Rolling update harus memperhitungkan replika lama, replika baru, dan maxUnavailable secara bersamaan. PDB membatasi gangguan sukarela; ini tidak menggantikan penempatan lintas domain. Autoscaler harus memahami Pod yang berstatus Pending dan kapasitas per domain, jika tidak, batasan yang ketat dapat menunggu tanpa batas waktu tanpa menambahkan node yang dapat digunakan.

Langkah 6: Tentukan tindakan kegagalan dan degradasi

Lakukan simulasi kehilangan node, kehilangan zona, dan label node yang hilang, lalu amati apakah Pod baru ditolak, timpang, atau berstatus Pending. Layanan kritis dapat menjeda rilis prioritas rendah, menambahkan kapasitas ke domain yang sehat, atau masuk ke mode read-only. Jangan menghapus batasan ketat (hard constraint) di lingkungan produksi tanpa mencatat risiko ketersediaannya. Berikan versi dan siapkan rollback untuk tindakan degradasi.

Langkah 7: Verifikasi dengan metrik distribusi

Catat replika, ketimpangan (skew), durasi Pending, alasan penjadwalan, kapasitas yang tersedia, gangguan PDB, dan kesalahan permintaan berdasarkan beban kerja, versi, dan domain topologi. Uji beban harus mencakup 2 hingga 30 replika, kapasitas domain yang tidak merata, rolling update, dan autoscaling. Tujuannya adalah membuktikan bahwa kapasitas yang tersisa memenuhi SLO setelah kehilangan domain, bukan sekadar membuktikan bahwa replika mendarat di node yang berbeda.

Jawaban model

Saya akan memodelkan node, zona, dan wilayah sebagai tiga lapisan domain kegagalan dan terlebih dahulu menetapkan replika minimum yang diperlukan setelah kehilangan sebuah zona. Pod layanan menggunakan selektor yang cocok dengan template; batasan diterapkan secara terpisah untuk hostname dan zona. Layanan kritis menggunakan nilai maxSkew zona yang kecil dengan DoNotSchedule, sedangkan pekerjaan batch menggunakan ScheduleAnyway. Jika domain yang memenuhi syarat berada di bawah minDomains, picu peringatan kapasitas alih-alih menerima distribusi yang keliru secara diam-diam. Validasi PDB, maxUnavailable, dan selektor lama/baru selama rolling update, serta pastikan autoscaler mengamati alasan Pending dan kapasitas domain. Terapkan dalam mode observasi, lalu aktifkan batasan ketat secara bertahap dengan menggunakan metrik replika per domain, durasi Pending, latihan domain kegagalan, dan SLO bisnis sebagai gerbang rollback.

Kesalahan umum

• Mengatakan “deploy lintas zona” tanpa menyebutkan topologyKey atau target kapasitas.
• Memperlakukan maxSkew sebagai batas replika per domain yang mutlak.
• Mengabaikan ketidakcocokan selektor sehingga menghitung kumpulan Pod yang salah.
• Memperlakukan PDB sebagai batasan scheduler atau sebagai perlindungan dari setiap kegagalan node.
• Menjanjikan penempatan merata di tiga zona tanpa degradasi setelah kehilangan satu zona hanya dengan dua replika.
• Menghapus DoNotSchedule untuk mengatasi status Pending tanpa mencatat kompromi pada ketersediaan.

Pertanyaan lanjutan

Pertanyaan lanjutan 1: Apakah ScheduleAnyway tetap membantu ketersediaan?

Ya. Ini menjadikan ketimpangan yang lebih rendah sebagai preferensi penjadwalan sambil tetap mengizinkan beban kerja berjalan ketika kapasitas terbatas. Ini cocok untuk pekerjaan yang dapat ditunda atau beban kerja dengan redundansi lain; layanan kritis dapat melakukan penskalaan terlebih dahulu dan menggunakan batasan yang ketat.

Pertanyaan lanjutan 2: Mengapa tidak hanya menggunakan pod anti-affinity?

Anti-affinity menetapkan untuk tidak menempatkan Pod secara bersamaan dengan Pod yang dipilih. Ini kurang mampu mengekspresikan multi-level topology, ketimpangan numerik, dan persyaratan domain minimum secara langsung. Spread constraints menggambarkan ketidakseimbangan lintas domain, sedangkan anti-affinity tetap berguna untuk satu aturan eksklusi.

Pertanyaan lanjutan 3: Apa yang terjadi jika minDomains salah?

Dengan domain yang memenuhi syarat terlalu sedikit, nilai minimum global yang digunakan untuk perhitungan skew dapat membuat batasan tampak terpenuhi atau membiarkan Pod tetap berstatus Pending. Sertakan ketersediaan domain dalam pemeriksaan admisi dan peringatan kapasitas, serta verifikasi perilaku field untuk versi klaster yang digunakan.

Pertanyaan lanjutan 4: Mengapa rolling release dapat merusak distribusi?

Versi lama dan baru mungkin menggunakan selektor yang berbeda, atau maxUnavailable dan maxSurge dapat menambahkan replika sementara di satu domain. Simulasikan status perantara dan periksa ketimpangan berdasarkan versi dan domain sebelum rilis.

Pertanyaan lanjutan 5: Bagaimana jika suatu node tidak memiliki label zona?

Node tersebut tidak akan berpartisipasi dengan benar dalam perhitungan topologi yang diminta. Perbaiki atau isolasi node tersebut; jangan menganggap node tanpa label sebagai domain kegagalan yang independen.

Pertanyaan lanjutan 6: Bagaimana Anda membuktikan bahwa SLO bertahan dari kegagalan zona?

Jalankan simulasi isolasi dan verifikasi kapasitas yang dapat dijadwalkan, replika yang sehat, kesalahan permintaan, dan waktu pemulihan di domain yang tersisa. Catat status PDB, alasan Pending, dan waktu scale-up untuk memvalidasi seluruh alur mulai dari penjadwalan hingga metrik bisnis.