Wawancara Desain Sistem: Bagaimana Anda Mendesain Maintenance Orchestrator yang Mematuhi PDB dan Topology Spread?

Petunjuk dan ruang lingkup

Sebuah kluster memerlukan rolling node upgrade sementara beban kerja menggunakan batasan PodDisruptionBudget dan topology spread. Rancang maintenance orchestrator, yang mencakup kandidat node, konkurensi penggusuran, pengganti yang tidak dapat dijadwalkan, reservasi kapasitas, pemulihan, dan observabilitas.

Kubernetes mendefinisikan PDB untuk membatasi Pod yang terdampak oleh gangguan sukarela (voluntary disruptions); alat pemeliharaan harus menggunakan Eviction API agar anggaran diperhitungkan dalam admisi. Batasan topology spread mengontrol ketimpangan (skew) di seluruh domain kegagalan seperti zona dan node. Desain yang kuat menempatkan kedua batasan ini dalam satu loop kontrol daripada hanya memeriksa jumlah Pod sekali lalu menghapus suatu batch.

Apa yang dievaluasi oleh pewawancara

• Membedakan gangguan sukarela dari kegagalan tidak sukarela beserta batas jaminannya.
• Menggunakan Eviction API alih-alih menghapus Pod secara langsung.
• Mengevaluasi maxSkew, whenUnsatisfiable, dan pemilih label dari topology spread.
• Merancang konkurensi dan reservasi kapasitas per node dan domain kegagalan.
• Menangani pemblokiran PDB, Pod yang belum siap (unready), percobaan ulang, batas waktu (timeouts), dan rollback.
• Menjelaskan keputusan melalui events, metrik, dan catatan audit.

Pertanyaan klarifikasi yang perlu diajukan

1. Apakah ini pembaruan OS, penggantian instans, atau perbaikan darurat? Kegagalan darurat dapat melewati perlindungan PDB.
2. Berapa jumlah replika, pengaturan PDB, domain topologi, dan kapasitas cadangan?
3. Apakah prioritasnya adalah total durasi, risiko minimum bagi pengguna, atau redundansi yang ketat di setiap zona?
4. Apakah ada Cluster Autoscaler, node pool sementara, atau batas kapasitas lintas zona?
5. Berapa lama pengontrol boleh menunggu pada PDB sebelum menjeda, mendegradasi, atau meminta persetujuan?

Jawaban 30 detik

Saya akan membangun deklaratif controller yang membaca node, Pod, PDB, batasan topologi, dan kapasitas yang dapat dijadwalkan. Controller ini akan mensimulasikan dampak dari satu penggusuran terhadap replika yang sehat dan ketimpangan topologi, kemudian mengeksekusi batch kecil melalui Eviction API. Token node dan domain kegagalan menentukan konkurensi; controller menunggu hingga Pod pengganti menjadi Ready sebelum melanjutkan. Konflik PDB atau batasan topologi yang tidak terpenuhi akan menjeda batch disertai alasan, alih-alih memaksa penghapusan. Setiap operasi bersifat idempoten dan dapat diobservasi, dengan batas waktu, rollback, dan jalur risiko terpisah untuk kegagalan tidak sukarela.

Pembahasan mendalam langkah demi langkah

1. Tentukan status dan input batasan

Tugas mencakup node target, batch pembaruan, konkurensi maksimum, batas waktu akhir, dan kebijakan rollback. Simpan dalam cache label node, pemilik Pod, kesiapan (readiness), disruptionsAllowed PDB, batasan topologi, dan kapasitas cadangan, tetapi baca ulang status penting sebelum setiap keputusan daripada memercayai snapshot lama.

2. Pilih kandidat node dan batch yang aman

Filter node yang di-cordon, node yang memuat Pod sistem penting, dan node tanpa kapasitas pengganti. Kelompokkan kandidat berdasarkan zona, rak, dan beban kerja. Suatu batch harus tetap berada dalam batas toleransi PDB masing-masing beban kerja dan mensimulasikan ketimpangan topologi setelah penggantian. Utamakan node dengan kapasitas cadangan yang tidak menjadikan domain kegagalan sebagai titik kegagalan tunggal (single point of failure).

3. Gunakan Eviction API

Untuk pemeliharaan sukarela, panggil Eviction API dan biarkan Kubernetes mengevaluasi PDB. Catat PDB spesifik, beban kerja, dan waktu percobaan ulang saat terjadi konflik atau penolakan. Penghapusan langsung melewati anggaran dan harus dicadangkan untuk jalur darurat destruktif yang disetujui secara eksplisit.

read constraints -> choose one node -> create eviction request
                -> PDB allows? no: back off and re-evaluate
                -> yes: wait for Ready replacement and topology recovery
                -> success: mark node complete; failure: pause and recover

4. Bereaksi terhadap umpan balik topologi dan kapasitas

Penggusuran bukan berarti selesai. Pengganti dapat tetap dalam status Pending karena DoNotSchedule, kunci topologi yang hilang, afinitas, atau kapasitas yang tidak mencukupi. Pantau event penjadwal; perluas pool sementara atau ubah urutan batch jika sesuai, tetapi jangan melonggarkan batasan beban kerja secara diam-diam. ScheduleAnyway tetap memerlukan pencatatan ketimpangan aktual dan biayanya.

5. Rancang konkurensi, lease, dan idempotensi

Gunakan task lease untuk node dan generasi controller agar beberapa worker pemeliharaan tidak menggusur target yang sama. Mulailah dengan batas kecil per zona atau token bucket beban kerja. Dapatkan token berikutnya hanya setelah pengganti berstatus Ready, anggaran PDB pulih, dan ketimpangan topologi berada dalam batas yang diinginkan. Perlakukan penggusuran berulang sebagai sesuatu yang sudah ditangani dan pulihkan dari status API setelah controller dimulai ulang.

6. Kegagalan, batas waktu, dan rollback

Jika Pod tetap Pending, PDB tetap di angka nol, proses pengosongan (draining) mengalami batas waktu, atau node baru tidak sehat, jeda batch berikutnya dan hapus cordon yang tidak perlu. Jika node yang diperbarui tidak dapat dikembalikan ke image lama, pertahankan pool lama atau beralih ke image yang telah divalidasi. Rollback memulihkan redundansi layanan; ini tidak memaksakan persentase pemeliharaan harus mencapai 100%.

7. Observabilitas dan latihan (drills)

Catat node yang dipilih, beban kerja yang terdampak, toleransi PDB sebelum dan sesudah, jumlah topologi, respons penggusuran, alasan Pending, dan durasi. Ukur keberhasilan penggusuran, waktu pemblokiran PDB, ketimpangan maksimum, latensi Ready, lalu lintas lintas-zona, dan percobaan ulang. Lakukan latihan untuk kekurangan kapasitas satu zona, anggaran PDB nol, kegagalan penjadwal, controller restart, dan hilangnya node secara tiba-tiba.

Contoh jawaban berkualitas tinggi

Saya akan memodelkan orchestrator sebagai deklaratif controller yang bekerja berdasarkan node dan domain kegagalan. Controller ini membaca pemilik Pod, kesiapan, PDB, topology spread, label node, dan kapasitas yang dapat dijadwalkan; controller ini mensimulasikan efek dari satu penggusuran terhadap replika sehat dan maxSkew, lalu mengirimkan batch kecil melalui Eviction API. Setiap zona memiliki token konkurensi, dan node berikutnya menunggu pengganti Ready, anggaran PDB yang pulih, serta batasan topologi yang terpenuhi.

Konflik PDB, pengganti yang Pending, kekurangan kapasitas, atau batas waktu akan menjeda batch dan mencatat alasannya. Controller dapat memperluas pool sementara atau mengurutkan ulang kandidat, tetapi tidak pernah menghapus Pod secara langsung atau melonggarkan batasan secara diam-diam. Lease dan generasi membuat percobaan ulang bersifat idempoten, dan proses restart dipulihkan dari status API. Metrik mencakup pemblokiran anggaran, ketimpangan maksimum, latensi Ready, percobaan ulang, dan biaya lintas zona sebelum ukuran batch diperbesar.

Kesalahan umum

• Menghapus Pod agar pengosongan lebih cepat → melewati PDB → gunakan Eviction API untuk pemeliharaan sukarela.
• Hanya melihat disruptionsAllowed → pengganti mungkin melanggar topologi atau kekurangan kapasitas → simulasikan ketimpangan dan penempatan terlebih dahulu.
• Menggusur replika di beberapa zona sekaligus → kehilangan redundansi domain kegagalan → gunakan token konkurensi zona dan beban kerja.
• Mengedit PDB saat terblokir → memindahkan risiko ke pengguna → jeda, tambahkan kapasitas, atau minta persetujuan.
• Hanya menunggu penghapusan → layanan mungkin tidak memiliki pengganti yang Ready → kendalikan status dengan kesiapan, event penjadwal, dan batas waktu akhir.
• Mengabaikan controller lease → worker mengulangi operasi → simpan lease, generasi, dan status idempoten secara persisten.

Pertanyaan lanjutan dan jawaban

Bisakah PDB melindungi dari hilangnya node secara tiba-tiba?

Tidak sepenuhnya. PDB terutama membatasi gangguan sukarela; kegagalan perangkat keras dan kehabisan sumber daya dapat langsung menghapus replika. Redundansi tetap memerlukan beberapa domain kegagalan, replika, dan kapasitas cadangan.

Mengapa tidak menggunakan kubectl delete pod?

Penghapusan langsung melewati pemeriksaan admisi PDB. Controller pemeliharaan harus memanggil Eviction API sehingga API server mengembalikan keputusan izinkan atau konflik.

Bagaimana jika PDB mengizinkan penggusuran tetapi penggantinya tetap Pending?

Jeda batch, periksa event penjadwal dan hitungan topologi, lalu tambahkan kapasitas atau pilih node lain. Melanjutkan penggusuran akan menciptakan celah redundansi yang lebih besar.

Bisakah ScheduleAnyway dianggap sebagai pengabaian ketimpangan?

Tidak. Ini menginstruksikan penjadwal untuk memprioritaskan node yang mengurangi ketimpangan, tetapi ketimpangan mungkin tetap ada. Catat distribusi aktual, biaya, dan risiko redundansi.

Bagaimana restart controller menghindari penggusuran duplikat?

Gunakan task lease, penguncian node, generasi controller, dan status yang dipersistensikan. Saat pemulihan, percayai status Pod, Eviction, dan node dari API daripada memutar ulang antrean di dalam memori.

Kapan penghapusan paksa dapat diterima?

Hanya untuk keadaan darurat yang disetujui secara eksplisit ketika jalur sukarela tidak dapat menangani risiko tersebut, dengan otorisasi tingkat tinggi dan pencatatan bahwa PDB dan redundansi mungkin dilanggar.