Gesaan dan konteks
Anda memiliki perkhidmatan stateful lima replika yang mesti mengekalkan kuorum semasa penyelenggaraan nod dan penurunan skala (scale-down) kluster. Reka bentuk PDB, pilih antara minAvailable dan maxUnavailable, dan terangkan sebab gangguan (outage) masih boleh berlaku selepas mengkonfigurasinya. Andaikan penggunaan StatefulSet dan alat penyelenggaraan yang menggunakan Eviction API.
Perkara yang diuji oleh penemu duga
- Sama ada anda mentakrifkan kekangan ketersediaan dan kuorum sebelum menulis YAML.
- Sama ada anda membezakan gangguan sukarela (voluntary disruption) daripada kegagalan nod, tekanan sumber dan gangguan tidak sukarela (involuntary disruption) yang lain.
- Sama ada anda memahami bahawa PDB mengehadkan pengusiran (eviction), bukan bilangan mutlak Pod yang sihat (healthy) pada setiap masa.
- Sama ada anda mengesan pengecualian naik taraf bergulir (rolling-upgrade), pemilih (selector), pembundaran peratusan dan masalah terhenti pada proses pengosongan (drain) berkaitan kapasiti.
Soalan penjelasan sebelum menjawab
- Apakah kuorumnya? Perkhidmatan konsensus lima replika mungkin memerlukan tiga replika sihat; perkhidmatan stateless mungkin menyasarkan peratusan kapasiti.
- Siapakah yang melakukan pengusiran? PDB dipatuhi oleh Eviction API; pemadaman terus Deployment atau Pod boleh memintasnya.
- Adakah penyelenggaraan termasuk pelancaran (rollout) aplikasi? PDB tidak mengehadkan kemas kini bergulir Deployment atau StatefulSet; strategi beban kerja yang mengawalnya.
- Adakah terdapat kapasiti untuk Pod pengganti? Pengusiran yang dibenarkan tidak bermakna pengganti boleh dijadualkan serta-merta; kekurangan kapasiti boleh menyekat pengosongan (drain).
Rangka kerja jawapan 30 saat
"Mula-mula saya mengesahkan keperluan replika yang sihat dan laluan pengusiran. Untuk lima replika dan kuorum tiga, saya akan menggunakan minAvailable: 3, atau maxUnavailable: 2 yang setara apabila skala replika berubah, dengan pemilih yang sepadan dengan StatefulSet. PDB mengehadkan pengusiran sukarela; ia tidak boleh menghalang kegagalan nod atau menggantikan strategi pelancaran. Sebelum pelancaran, saya akan menjalankan kubectl drain terkawal, memeriksa disruptionsAllowed, dan mengesahkan bahawa Pod pengganti mempunyai kapasiti yang boleh dijadualkan."
Jawapan mendalam langkah demi langkah
1. Terjemahkan ketersediaan kepada bajet
Bajet PDB ialah bilangan replika yang boleh dialih keluar oleh gangguan sukarela pada satu-satu masa. Jika lima replika mesti mengekalkan tiga Pod yang sihat, bajetnya adalah paling banyak dua. minAvailable: 3 menyatakan baki bilangan yang sihat; maxUnavailable: 2 menyatakan bilangan tidak tersedia yang dibenarkan. Medan-medan ini saling eksklusif (mutually exclusive).
2. Pilih ungkapan yang sepadan dengan penskalaan
minAvailable adalah secara terus untuk kuorum tetap. Jika replika diskalakan secara automatik (autoscale), dokumentasi Kubernetes mengesyorkan agar mempertimbangkan maxUnavailable, yang dinilai berdasarkan replika yang diingini. Peratusan dibundarkan ke atas: dengan tujuh replika yang diingini dan maxUnavailable: 30%, tiga Pod mungkin tidak tersedia, bukan dua. Perancangan kapasiti mesti mengambil kira pembundaran tersebut.
3. Ikatkan beban kerja yang betul
Pemilih label PDB mesti sepadan dengan pemilih StatefulSet. Jika tidak, ia mungkin tidak melindungi mana-mana Pod sasaran atau menggabungkan pelbagai aplikasi secara tidak sengaja. Pastikan label stabil; jangan ubahnya semasa pelepasan versi untuk mengelak daripada bajet.
4. Nyatakan sempadan PDB
PDB mengehadkan gangguan sukarela seperti kubectl drain dan penyelenggaraan automatik. Kegagalan perkakasan, kehilangan nod dan pengusiran akibat tekanan sumber adalah tidak sukarela; PDB tidak boleh menghalangnya, dan ia tetap dikira dalam penggunaan bajet. Pemadaman terus Pod atau Deployment juga boleh memintasnya.
5. Terangkan proses pengosongan (drain) yang terhenti
Apabila bajet habis digunakan, Eviction API menolak pengusiran baharu dan proses pengosongan akan mencuba semula. Malah pengusiran yang dibenarkan boleh menyebabkan penggantinya kekal dalam keadaan Pending apabila tiada nod yang mempunyai kapasiti, menyebabkan pengosongan terus disekat. Ambil kira permintaan (requests) Pod, penyebaran zon (zone spreading), masa permulaan dan ruang lebihan (headroom) nod; PDB bukan sistem kapasiti.
6. Asingkan pelancaran dan dasar kesihatan
PDB tidak mengehadkan kemas kini bergulir Deployment atau StatefulSet; medan strategi kemas kini seperti maxUnavailable, maxSurge dan kesediaan (readiness) mengawal penggantian semasa pelepasan versi. Kubernetes juga menyediakan dasar pengusiran Pod tidak sihat (unhealthy-Pod eviction policy), yang harus dipilih berdasarkan sama ada Pod yang gagal perlu dibersihkan terlebih dahulu. Uji pelancaran, penyelenggaraan dan pemulihan insiden secara berasingan.
Contoh jawapan berkualiti tinggi
Saya akan mengesahkan bahawa perkhidmatan lima replika memerlukan tiga replika sihat untuk kuorum dan alat penyelenggaraan memanggil Eviction API. PDB asas ialah minAvailable: 3 dengan pemilih tepat StatefulSet. Jika replika diskalakan secara automatik, saya akan menilai maxUnavailable: 2 atau peratusan dengan gelagat pembundarannya. PDB hanya mengehadkan pengusiran sukarela; ia tidak menghalang kegagalan nod, tekanan sumber, pemadaman terus atau dasar kemas kini bergulir.
Semasa pelancaran, saya akan memeriksa disruptionsAllowed, menjalankan pengosongan terkawal, dan memerhati masa penamatan, penjadualan penggantian serta status kuorum. Pengosongan yang dijeda apabila bajet habis adalah perkara yang dijangkakan. Jika pengganti berstatus Pending, saya akan menambah kapasiti atau melaraskan permintaan (requests) dan bukannya meluaskan bajet. Akhir sekali, saya akan menguji laluan naik taraf, kehilangan nod dan pengunduran (rollback) penyelenggaraan secara berasingan.
Kesilapan lazim
- Kesilapan → Menganggap PDB menghalang setiap gangguan. Mengapa ia gagal: gangguan tidak sukarela berada di luar kawalannya. Pembetulan: nyatakan sempadan untuk kegagalan nod, tekanan sumber dan pengusiran penyelenggaraan.
- Kesilapan → Hanya menulis
maxUnavailable: 50%. Mengapa ia gagal: tingkah laku pembundaran ke atas boleh membenarkan lebih banyak kehilangan replika daripada jangkaan intuitif. Pembetulan: kiranya daripada replika yang diingini. - Kesilapan → Menganggap PDB sebagai dasar pelancaran. Mengapa ia gagal: kemas kini Deployment dan StatefulSet tidak dihadkan oleh PDB. Pembetulan: konfigurasikan strategi kemas kini beban kerja secara berasingan.
- Kesilapan → Menyalahkan PDB atas pengosongan yang tersekat. Mengapa ia gagal: bajet yang habis dan ketiadaan kapasiti nod mempunyai punca yang berbeza. Pembetulan: periksa
disruptionsAllowed, Pod Pending, permintaan (requests) dan kapasiti bersama-sama.
Soalan susulan dan respons
Hanya tiga daripada lima replika yang sihat. Bolehkah Pod lain diusir?
Dengan minAvailable: 3, pengusiran sukarela harus ditolak oleh Eviction API. Pulihkan replika yang sihat atau terima jeda penyelenggaraan; memadam PDB untuk membolehkan pengosongan selesai akan membuang perlindungan kuorum.
Penskala automatik kluster (Cluster Autoscaler) tersekat. Patutkah anda melonggarkan PDB?
Mula-mula sahkan bahawa penurunan skala adalah sukarela, bajet telah habis dan Pod pengganti boleh dijadualkan. Melonggarkan bajet perkhidmatan kuorum boleh merosakkan ketekalan (consistency). Tambah kapasiti, ubah kelompok pengosongan, atau gunakan peratusan kapasiti untuk beban kerja stateless daripada melemahkan bajet setiap aplikasi.
Mengapakah pemadaman Pod secara terus boleh memintas PDB?
PDB mengawal permintaan pengusiran sukarela melalui Eviction API, bukan setiap operasi pemadaman. Hadkan kebenaran pemadaman terus dan pastikan automasi penyelenggaraan menggunakan API, sambil mengekalkan pintasan pentadbir yang jelas untuk kecemasan.
Apakah risiko maxUnavailable: 0?
Ia memerlukan sifar Pod tidak tersedia secara sukarela, jadi pengosongan nod tidak akan dapat diselesaikan selagi beban kerja yang dipilih kekal di situ. Gunakannya hanya apabila perniagaan tidak boleh bertolak ansur dengan sebarang gangguan sukarela dan prosedur penyelenggaraan yang diselaraskan wujud.