Petunjuk dan konteks
Anda mengelola layanan stateful dengan lima replika yang harus mempertahankan kuorum selama pemeliharaan node dan scale-down kluster. Rancang PDB, pilih antara minAvailable dan maxUnavailable, dan jelaskan mengapa pemadaman (outage) masih dapat terjadi setelah mengonfigurasinya. Asumsikan penggunaan StatefulSet dan alat pemeliharaan yang menggunakan Eviction API.
Apa yang diuji oleh pewawancara
- Apakah Anda menentukan batasan ketersediaan dan kuorum sebelum menulis YAML.
- Apakah Anda membedakan gangguan sukarela (voluntary disruption) dari kegagalan node, tekanan sumber daya (resource pressure), dan gangguan tidak sukarela (involuntary disruption) lainnya.
- Apakah Anda memahami bahwa PDB membatasi penggusuran (eviction), bukan jumlah absolut Pod yang sehat (healthy) setiap saat.
- Apakah Anda memahami pengecualian rolling-upgrade, selector, pembulatan persentase, dan penghentian drain akibat kapasitas.
Pertanyaan klarifikasi sebelum menjawab
- Berapa kuorumnya? Layanan konsensus dengan lima replika mungkin memerlukan tiga replika sehat; layanan stateless mungkin menargetkan persentase kapasitas.
- Siapa yang melakukan penggusuran? PDB dipatuhi oleh Eviction API; penghapusan langsung Deployment atau Pod dapat melewatinya.
- Apakah pemeliharaan mencakup peluncuran (rollout) aplikasi? PDB tidak membatasi rolling update Deployment atau StatefulSet; strategi beban kerja yang mengaturnya.
- Apakah ada kapasitas untuk Pod pengganti? Penggusuran yang diizinkan tidak berarti pengganti dapat langsung dijadwalkan; kekurangan kapasitas dapat memblokir proses drain.
Kerangka jawaban 30 detik
"Pertama-tama saya mengonfirmasi kebutuhan replika sehat dan jalur penggusurannya. Untuk lima replika dan kuorum tiga, saya akan menggunakan minAvailable: 3, atau maxUnavailable: 2 yang setara ketika skala replika berubah, dengan selector yang cocok dengan StatefulSet. PDB membatasi penggusuran sukarela; PDB tidak dapat mencegah kegagalan node atau menggantikan strategi peluncuran. Sebelum peluncuran, saya akan menjalankan kubectl drain terkontrol, memeriksa disruptionsAllowed, dan memverifikasi bahwa Pod pengganti memiliki kapasitas yang dapat dijadwalkan."
Jawaban mendalam langkah demi langkah
1. Menerjemahkan ketersediaan menjadi anggaran (budget)
Anggaran PDB adalah jumlah replika yang dapat dihapus oleh gangguan sukarela sekaligus. Jika lima replika harus mempertahankan tiga Pod yang sehat, anggarannya maksimal dua. minAvailable: 3 menyatakan jumlah sehat yang tersisa; maxUnavailable: 2 menyatakan jumlah tidak tersedia yang diizinkan. Bidang-bidang ini bersifat mutually exclusive.
2. Memilih ekspresi yang sesuai dengan penskalaan
minAvailable bersifat langsung untuk kuorum tetap. Jika replika melakukan autoscale, dokumentasi Kubernetes merekomendasikan untuk mempertimbangkan maxUnavailable, yang dievaluasi terhadap replika yang diinginkan (desired replicas). Persentase dibulatkan ke atas: dengan tujuh replika yang diinginkan dan maxUnavailable: 30%, tiga Pod mungkin tidak tersedia, bukan dua. Perencanaan kapasitas harus memperhitungkan pembulatan tersebut.
3. Mengikat beban kerja yang benar
Label selector PDB harus cocok dengan selector StatefulSet. Jika tidak, PDB mungkin tidak melindungi Pod target mana pun atau secara tidak sengaja menggabungkan beberapa aplikasi. Jaga agar label tetap stabil; jangan mengubahnya selama rilis untuk menghindari anggaran.
4. Menyatakan batasan PDB
PDB membatasi gangguan sukarela seperti kubectl drain dan pemeliharaan otomatis. Kegagalan perangkat keras, hilangnya node, dan penggusuran akibat tekanan sumber daya bersifat tidak sukarela; PDB tidak dapat mencegahnya, dan hal tersebut tetap dihitung dalam pengurangan anggaran. Penghapusan langsung Pod atau Deployment juga dapat melewatinya.
5. Menjelaskan proses drain yang terhenti (stalled)
Ketika anggaran habis, Eviction API menolak penggusuran baru dan proses drain mencoba kembali (retry). Bahkan penggusuran yang diizinkan dapat meninggalkan penggantinya dalam status Pending ketika tidak ada node yang memiliki kapasitas, sehingga drain tetap diblokir. Sertakan requests Pod, penyebaran zona (zone spreading), waktu startup, dan ruang kosong (headroom) node; PDB bukanlah sistem manajemen kapasitas.
6. Memisahkan rollout dan kebijakan kesehatan
PDB tidak membatasi rolling update Deployment atau StatefulSet; bidang strategi pembaruan seperti maxUnavailable, maxSurge, dan kesiapan (readiness) mengontrol penggantian selama rilis. Kubernetes juga menyediakan kebijakan penggusuran Pod tidak sehat (unhealthy-Pod eviction policy), yang harus dipilih berdasarkan apakah Pod yang gagal harus dibersihkan terlebih dahulu. Uji rollout, pemeliharaan, dan pemulihan insiden secara terpisah.
Contoh jawaban berkualitas tinggi
Saya akan mengonfirmasi bahwa layanan lima replika membutuhkan tiga replika sehat untuk kuorum dan bahwa alat pemeliharaan memanggil Eviction API. PDB dasarnya adalah minAvailable: 3 dengan selector StatefulSet yang tepat. Jika replika melakukan autoscale, saya akan mengevaluasi maxUnavailable: 2 atau persentase beserta perilaku pembulatannya. PDB hanya membatasi penggusuran sukarela; PDB tidak mencegah kegagalan node, tekanan sumber daya, penghapusan langsung, atau kebijakan rolling-update.
Selama peluncuran, saya akan memeriksa disruptionsAllowed, menjalankan drain terkontrol, dan mengamati waktu terminasi, penjadwalan pengganti, serta status kuorum. Drain yang dijeda ketika anggaran habis adalah hal yang diharapkan. Jika pengganti berstatus Pending, saya akan menambah kapasitas atau menyesuaikan requests daripada memperlebar anggaran. Terakhir, saya akan menguji jalur upgrade, kehilangan node, dan rollback pemeliharaan secara terpisah.
Kesalahan umum
- Kesalahan → Mengasumsikan PDB mencegah setiap pemadaman. Mengapa ini gagal: gangguan tidak sukarela berada di luar kendalinya. Solusi: nyatakan batasan untuk kegagalan node, tekanan sumber daya, dan penggusuran pemeliharaan.
- Kesalahan → Hanya menulis
maxUnavailable: 50%. Mengapa ini gagal: perilaku pembulatan ke atas dapat memungkinkan hilangnya replika lebih banyak daripada yang diperkirakan secara intuitif. Solusi: hitung berdasarkan replika yang diinginkan. - Kesalahan → Memperlakukan PDB sebagai kebijakan rollout. Mengapa ini gagal: pembaruan Deployment dan StatefulSet tidak dibatasi oleh PDB. Solusi: konfigurasikan strategi pembaruan beban kerja secara terpisah.
- Kesalahan → Menyalahkan PDB untuk drain yang macet. Mengapa ini gagal: anggaran yang habis dan ketiadaan kapasitas node memiliki penyebab yang berbeda. Solusi: periksa
disruptionsAllowed, Pod Pending, requests, dan kapasitas secara bersamaan.
Pertanyaan lanjutan dan tanggapan
Hanya tiga dari lima replika yang sehat. Bisakah Pod lain digusur?
Dengan minAvailable: 3, penggusuran sukarela harus ditolak oleh Eviction API. Pulihkan replika yang sehat atau terima jeda pemeliharaan; menghapus PDB agar drain selesai akan menghilangkan perlindungan kuorum.
Cluster autoscaler macet. Haruskah Anda melonggarkan PDB?
Pertama, verifikasi bahwa scale-down bersifat sukarela, anggaran telah habis, dan Pod pengganti dapat dijadwalkan. Melonggarkan anggaran layanan kuorum dapat merusak konsistensi. Tambahkan kapasitas, ubah batch drain, atau gunakan persentase kapasitas untuk beban kerja stateless daripada melemahkan anggaran setiap aplikasi.
Mengapa penghapusan Pod secara langsung dapat melewati PDB?
PDB mengatur permintaan penggusuran sukarela melalui Eviction API, bukan setiap operasi penghapusan. Batasi izin penghapusan langsung dan buat otomatisasi pemeliharaan menggunakan API, sambil mempertahankan bypass administrator eksplisit untuk keadaan darurat.
Apa risiko dari maxUnavailable: 0?
Ini memerlukan nol Pod yang tidak tersedia secara sukarela, sehingga drain node tidak akan pernah selesai selama beban kerja yang dipilih tetap berada di sana. Gunakan hanya jika bisnis tidak dapat mentoleransi gangguan sukarela dan ada prosedur pemeliharaan terkoordinasi.