Temu Bual Reka Bentuk Sistem: Bagaimanakah Anda Mereka Bentuk Maintenance Orchestrator yang Menghormati PDB dan Topology Spread?

Gesaan dan skop

Sebuah kluster memerlukan peningkatan nod secara bergilir (rolling upgrade) semasa beban kerja menggunakan kekangan PodDisruptionBudget dan topology spread. Reka bentuk maintenance orchestrator, merangkumi nod calon, konkurensi pengusiran, pengganti yang tidak boleh dijadualkan, tempahan kapasiti, pemulihan, dan kebolehcerapan.

Kubernetes mentakrifkan PDB untuk mengehadkan Pod yang terjejas oleh gangguan sukarela (voluntary disruptions); alat penyelenggaraan harus menggunakan Eviction API supaya bajet terlibat dalam kemasukan (admission). Kekangan topology spread mengawal kecondongan (skew) merentas domain kegagalan seperti zon dan nod. Reka bentuk yang mantap meletakkan kedua-dua kekangan dalam satu gelung kawalan berbanding hanya menyemak bilangan Pod sekali dan memadamkan satu kelompok (batch).

Perkara yang dinilai oleh penemu bual

• Membezakan gangguan sukarela daripada kegagalan tidak sukarela dan sempadan jaminannya.
• Menggunakan Eviction API dan bukannya memadam Pod secara terus.
• Menilai maxSkew, whenUnsatisfiable, dan pemilih label daripada topology spread.
• Mereka bentuk konkurensi dan tempahan kapasiti bagi setiap nod dan domain kegagalan.
• Mengendalikan sekatan PDB, Pod yang belum sedia (unready), percubaan semula, tamat masa, dan rollback.
• Menjelaskan keputusan melalui peristiwa (events), metrik, dan rekod audit.

Soalan penjelasan untuk ditanya

1. Adakah ini peningkatan OS, penggantian tika (instance), atau pembaikan kecemasan? Kegagalan kecemasan mungkin memintas perlindungan PDB.
2. Apakah jumlah replika, tetapan PDB, domain topologi, dan kapasiti ganti?
3. Adakah keutamaan diberikan kepada jumlah tempoh, risiko minimum pengguna, atau redundansi ketat dalam setiap zon?
4. Adakah terdapat Cluster Autoscaler, kolam nod sementara, atau had kapasiti merentas zon?
5. Berapa lama pengawal boleh menunggu pada PDB sebelum menjeda, menurunkan taraf, atau meminta kelulusan?

Jawapan 30 saat

Saya akan membina pengawal deklaratif yang membaca nod, Pod, PDB, kekangan topologi, dan kapasiti yang boleh dijadualkan. Ia akan mensimulasikan kesan satu pengusiran terhadap replika yang sihat dan kecondongan topologi, kemudian melaksanakan kelompok kecil melalui Eviction API. Token nod dan domain kegagalan mentakrifkan konkurensi; pengawal menunggu Pod pengganti menjadi Ready sebelum meneruskan. Konflik PDB atau kekangan topologi yang tidak dipenuhi akan menjeda kelompok dengan menyatakan sebab dan bukannya memaksa pemadaman. Setiap operasi adalah idempoten dan boleh dicerap, dengan tamat masa, rollback, dan laluan risiko berasingan untuk kegagalan tidak sukarela.

Perbincangan mendalam langkah demi langkah

1. Takrifkan keadaan dan input kekangan

Tugasan ini mengandungi nod sasaran, kelompok peningkatan, konkurensi maksimum, tarikh akhir, dan dasar rollback. Simpan dalam cache label nod, pemilik Pod, kesediaan (readiness), disruptionsAllowed PDB, kekangan topologi, dan kapasiti ganti, tetapi baca semula keadaan kritikal sebelum setiap keputusan dan bukannya mempercayai snapshot lama.

2. Pilih nod calon dan kelompok yang selamat

Tapis nod yang di-cordon, nod yang membawa Pod sistem kritikal, dan nod tanpa kapasiti penggantian. Kumpulkan calon mengikut zon, rak, dan beban kerja. Sesuatu kelompok mesti kekal dalam peruntukan PDB setiap beban kerja dan mensimulasikan kecondongan topologi selepas penggantian. Utamakan nod dengan kapasiti ganti yang tidak menjadikan domain kegagalan sebagai titik kegagalan tunggal (single point of failure).

3. Gunakan Eviction API

Untuk penyelenggaraan sukarela, panggil Eviction API dan biarkan Kubernetes menilai PDB. Rekodkan PDB khusus, beban kerja, dan masa percubaan semula apabila berlaku konflik atau penolakan. Pemadaman terus memintas bajet dan harus dikhaskan untuk laluan kecemasan pemusnah yang diluluskan 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. Bertindak balas terhadap maklum balas topologi dan kapasiti

Pengusiran bukan bermakna selesai. Pengganti boleh kekal dalam keadaan Pending disebabkan oleh DoNotSchedule, kunci topologi yang hilang, afiniti, atau kapasiti yang tidak mencukupi. Pantau peristiwa penjadual; luaskan kolam sementara atau tukar urutan kelompok apabila sesuai, tetapi jangan melonggarkan kekangan beban kerja secara senyap. ScheduleAnyway masih memerlukan perekodan kecondongan sebenar dan kos.

5. Reka bentuk konkurensi, pajakan (lease), dan keidempotenan

Gunakan pajakan tugasan untuk nod dan generasi pengawal supaya beberapa pekerja penyelenggaraan tidak boleh mengusir sasaran yang sama. Mulakan dengan had kecil bagi setiap zon atau baldi token beban kerja. Dapatkan token seterusnya hanya selepas pengganti berstatus Ready, bajet PDB pulih, dan kecondongan topologi berada dalam batas yang dimaksudkan. Anggap pengusiran berulang sebagai telah dikendalikan dan pulihkan daripada keadaan API selepas pengawal dimulakan semula.

6. Kegagalan, tamat masa, dan rollback

Jika Pod kekal Pending, PDB kekal pada sifar, pengosongan (draining) tamat masa, atau nod baharu tidak sihat, jeda kelompok seterusnya dan alih keluar cordon yang tidak diperlukan. Apabila nod yang ditingkatkan tidak dapat dikembalikan kepada imej lama, kekalkan kolam lama atau beralih kepada imej yang telah disahkan. Rollback memulihkan redundansi perkhidmatan; ia tidak memaksa peratusan penyelenggaraan mencapai 100%.

7. Kebolehcerapan dan latih tubi

Rekodkan nod yang dipilih, beban kerja yang terjejas, peruntukan PDB sebelum dan selepas, kiraan topologi, respons pengusiran, sebab Pending, dan tempoh masa. Ukur pengusiran yang berjaya, masa sekatan PDB, kecondongan maksimum, kependaman Ready, trafik merentas zon, dan percubaan semula. Lakukan latih tubi untuk kekurangan kapasiti zon tunggal, bajet PDB sifar, kegagalan penjadual, permulaan semula pengawal, dan kehilangan nod secara tiba-tiba.

Contoh jawapan berkualiti tinggi

Saya akan memodelkan orchestrator sebagai pengawal deklaratif yang maju mengikut nod dan domain kegagalan. Ia membaca pemilik Pod, kesediaan, PDB, topology spread, label nod, dan kapasiti yang boleh dijadualkan; ia mensimulasikan kesan satu pengusiran terhadap replika yang sihat dan maxSkew, kemudian menghantar kelompok kecil melalui Eviction API. Setiap zon mempunyai token konkurensi, dan nod seterusnya menunggu pengganti yang Ready, bajet PDB yang dipulihkan, dan kekangan topologi yang dipenuhi.

Konflik PDB, pengganti Pending, kekurangan kapasiti, atau tamat masa akan menjeda kelompok dan merekodkan sebabnya. Pengawal boleh meluaskan kolam sementara atau menyusun semula calon, tetapi ia tidak sekali-kali memadam Pod secara terus atau melonggarkan kekangan secara senyap. Pajakan dan generasi menjadikan percubaan semula bersifat idempoten, dan permulaan semula dipulihkan daripada keadaan API. Metrik meliputi sekatan bajet, kecondongan maksimum, kependaman Ready, percubaan semula, dan kos merentas zon sebelum saiz kelompok diperbesarkan.

Kesilapan lazim

• Memadam Pod untuk mengosongkan dengan lebih cepat → memintas PDB → gunakan Eviction API untuk penyelenggaraan sukarela.
• Hanya melihat pada disruptionsAllowed → pengganti mungkin melanggar topologi atau kekurangan kapasiti → simulasikan kecondongan dan penempatan terlebih dahulu.
• Mengusir replika dalam beberapa zon sekali gus → kehilangan redundansi domain kegagalan → gunakan token konkurensi zon dan beban kerja.
• Menyunting PDB apabila ia menyekat → memindahkan risiko kepada pengguna → jeda, tambah kapasiti, atau minta kelulusan.
• Hanya menunggu pemadaman → perkhidmatan mungkin tiada pengganti yang Ready → pacu keadaan dengan kesediaan, peristiwa penjadual, dan tarikh akhir.
• Mengabaikan pajakan pengawal → pekerja mengulangi operasi → kekalkan pajakan, generasi, dan keadaan idempoten.

Soalan susulan dan jawapan

Bolehkah PDB melindungi daripada nod yang hilang secara tiba-tiba?

Tidak sepenuhnya. PDB terutamanya mengehadkan gangguan sukarela; kegagalan perkakasan dan keletihan sumber boleh mengalih keluar replika secara terus. Redundansi masih memerlukan berbilang domain kegagalan, replika, dan kapasiti ganti.

Mengapa tidak menggunakan kubectl delete pod?

Pemadaman terus memintas semakan kemasukan PDB. Pengawal penyelenggaraan harus memanggil Eviction API supaya pelayan API mengembalikan keputusan membenarkan atau konflik.

Bagaimana jika PDB membenarkan pengusiran tetapi penggantinya kekal Pending?

Jeda kelompok, periksa peristiwa penjadual dan kiraan topologi, serta tambah kapasiti atau pilih nod lain. Meneruskan pengusiran akan mewujudkan jurang redundansi yang lebih besar.

Bolehkah ScheduleAnyway dianggap sebagai mengabaikan kecondongan?

Tidak. Ia memberitahu penjadual untuk mengutamakan nod yang mengurangkan kecondongan, tetapi kecondongan mungkin masih wujud. Rekodkan pengedaran sebenar, kos, dan risiko redundansi.

Bagaimanakah permulaan semula pengawal mengelakkan pengusiran pendua?

Gunakan pajakan tugasan, kunci nod, generasi pengawal, dan keadaan yang dikekalkan. Semasa pemulihan, percayai keadaan Pod, Eviction, dan nod daripada API dan bukannya memainkan semula baris gilir dalam ingatan.

Bilakah pemadaman paksa boleh diterima?

Hanya untuk kecemasan yang diluluskan secara eksplisit apabila laluan sukarela tidak dapat menangani risiko tersebut, dengan kebenaran tahap tinggi dan rekod bahawa PDB serta redundansi mungkin dilanggar.