Masalah dan skop
Ini ialah soalan reka bentuk sistem satah kawalan (control-plane) untuk jurutera platform dan Kubernetes. Kubernetes v1.36 memperkenalkan List dan Watch yang dishardkan di bahagian pelayan sebagai ciri alfa di sebalik get ShardedListAndWatch. Anggap ciri ini sebagai pilihan dan reka pengawal yang kekal tepat apabila get tersebut dinyahdayakan.
Perkara yang dinilai oleh penemu duga
- Model pemilikan shard yang merangkumi ruang kunci (keyspace) tepat sekali.
- List awal yang betul, pengendalian resource-version, dan tingkah laku penyambungan semula Watch.
- Pengesanan pelayan API yang mengabaikan pemilih (selector).
- Penshardan semula (resharding), pertukaran replika (replica churn), dan pertukaran antara pertindihan dan jurang.
- Penaakulan kapasiti untuk CPU pelayan API, rangkaian, memori informer, dan ribut pemulihan.
Apakah kunci pemilikan?
Pelaksanaan alfa menyokong object.metadata.uid dan object.metadata.namespace. Pencincangan UID memberikan pengedaran yang stabil; pencincangan namespace boleh mengekalkan lokaliti penyewa tetapi mungkin condong. Pilihan ini mengubah pengimbangan, sempadan keselamatan dan kos penghijrahan.
Apakah sasaran ketepatan?
Tanya sama ada penyesuaian sekurang-kurangnya sekali (at-least-once) boleh diterima dan sama ada pemprosesan pendua adalah idempoten. Jika kesan sampingan perniagaan tidak boleh bertolak ansur dengan pendua, tambahkan kunci kerja tahan lasak dan pemagaran (fencing) daripada hanya bergantung pada strim peristiwa semata-mata.
Bolehkah setiap pelayan API dan klien dinaik taraf bersama?
Andaikan versi bercampur melainkan pasukan platform membuktikan sebaliknya. Pengawal mesti memeriksa metadata tindak balas dan kembali kepada penapisan bahagian klien tanpa membuat dakwaan secara senyap bahawa beban telah dikurangkan.
Rangka jawapan 30 saat
“Saya akan membahagikan ruang cincangan 64-bit yang deterministik kepada julat yang tidak bertindih dan menetapkan setiap julat kepada satu replika pengawal. Setiap informer menghantar pemilih shard pada kedua-dua List dan Watch, kemudian mengesahkan tindak balas mengandungi metadata shard yang sepadan. Pengakuan yang hilang mencetuskan fallback strim penuh yang selamat atau menyahdayakan pengoptimuman. Penshardan semula menggunakan generasi dan protokol penyerahan (handoff) dengan pertindihan, penyesuaian idempoten, dan metrik untuk liputan, pendua, lag, dan trafik fallback.”
Reka bentuk langkah demi langkah
Pembahagian dan penetapan
Wakilkan pemilikan sebagai julat separuh terbuka [start, end) ke atas cincin 64-bit. Simpan generasi, pemilik dan pajakan (lease) untuk setiap julat. Pelaksanaan dua replika boleh membahagikan cincin kepada dua; lebih banyak replika menggunakan jadual julat yang diuruskan oleh pengawal. Jangan memperoleh pemilikan daripada ordinal replika sahaja kerana memulakan semula (restart) sebaliknya boleh mewujudkan jurang.
Replica A: [0000..., 8000...)
Replica B: [8000..., 1000...)Jadikan List dan Watch satu protokol
List awal dan setiap penyambungan semula Watch mesti membawa pemilih yang sama dan resource version. Informer menggantikan stor setempatnya hanya selepas list awal selesai, kemudian memulakan watch daripada resource version yang dikembalikan. 410 Gone atau versi yang tamat tempoh menyebabkan list baharu untuk shard tersebut, bukan memainkan semula julat lain secara membuta tuli.
Sahkan sokongan pelayan
Blog v1.36 menerangkan medan tindak balas shardInfo yang menggemakan pemilih yang digunakan. Jika ia tiada, anggap pelayan mengembalikan keseluruhan koleksi. Klien boleh menapis secara setempat untuk ketepatan, tetapi mesti mengeluarkan metrik fallback dan menggunakan tekanan belakang (backpressure) supaya pelayan yang tidak disokong tidak menggandakan penggunaan memori merentasi replika.
Shard semula tanpa jurang
Cipta generasi julat baharu. Semasa penyerahan, pemilik lama terus menyesuaikan diri manakala pemilik baharu memanaskan list dan menunggu watch pada resource version yang diketahui. Lakukan komit perubahan pemilikan hanya selepas kedua-dua pihak melaporkan kesediaan; peristiwa pendua boleh diterima apabila penyesuaian adalah idempoten. Jika kesediaan gagal, tamatkan pajakan dan kekalkan pemilik lama.
Kapasiti dan laluan kegagalan
Penapisan bahagian pelayan mengurangkan bait dan penyahsiriian untuk objek yang dibuang, tetapi pelayan API kini melakukan penilaian pencincangan dan pemilih. Lindunginya dengan feature gate, had keserabutan setiap pengawal, dan kenari pelancaran. Apabila pelayan API terlebih beban, kawal selia sambungan semula dan gunakan pengunduran eksponen (exponential backoff); jangan biarkan semua replika menyenaraikan semula (relist) serentak.
Contoh jawapan berkualiti tinggi
“Saya akan menggunakan jadual julat bercop generasi ke atas cincangan deterministik UID. Informer menyertakan pemilih tersebut pada List dan Watch serta memerlukan shardInfo sebelum mengira pengoptimuman sebagai aktif. Medan yang hilang akan kembali kepada penapisan setempat dengan belanjawan keserabutan global. Penshardan semula mencipta generasi baharu, memanaskan pemilik masuk daripada resource version, dan menukar pajakan hanya selepas kesediaan; penyesuaian adalah idempoten jadi pertindihan adalah selamat. Saya akan menguji kenari pada feature gate dan membandingkan CPU API, bait, kependaman list, sambungan semula watch, liputan shard, pendua, dan kadar fallback.”
Kesilapan biasa
- Menetapkan shard mengikut indeks replika → Pemulaan semula menukar pemilikan dan mewujudkan jurang → kekalkan jadual julat bercop generasi.
- Menggunakan pemilih hanya pada Watch → List awal masih membebankan pelayan dan boleh tidak konsisten dengan strim → gunakan pemilih dan peraturan resource-version yang sama untuk kedua-duanya.
- Mempercayai pelayan yang tidak disokong → Setiap replika menerima strim penuh → wajibkan
shardInfodan dedahkan trafik fallback. - Mengalihkan julat serta-merta → Peristiwa boleh terlepas semasa penyerahan → tindihkan pemilik, pagar dengan generasi, dan jadikan penyesuaian idempoten.
- Hanya mengukur CPU pengawal → Pencincangan pelayan API atau ribut penyambungan semula kekal tidak kelihatan → pantau metrik satah kawalan dan klien bersama-sama.
Rubrik pemarkahan dan semakan kendiri
Nilaikan ketepatan pembahagian, semantik list-watch, fallback, penshardan semula, kapasiti dan kebolehperhatian. Jawapan yang kukuh menyatakan invarian: setiap objek tergolong dalam satu generasi julat aktif, dan setiap penyerahan mempunyai sempadan resource-version. Ia juga menerangkan sebab pendua lebih selamat daripada jurang apabila penyesuaian adalah idempoten.
Tindakan susulan dan lanjutan
Bagaimana jika satu namespace jauh lebih besar daripada yang lain?
Utamakan pencincangan UID untuk keseimbangan, atau bahagikan namespace yang panas kepada beberapa julat UID. Ukur beban julat dan bukannya menganggap bilangan objek yang sama.
Bagaimanakah anda mengesan jurang senyap (silent gap)?
Bandingkan persampelan bilangan objek global dengan kesatuan bilangan shard, rekod generasi pemilih dan jalankan objek sintetik berkala melalui setiap julat. Beri amaran tentang lag atau hanyutan liputan.
Apakah yang berlaku semasa peningkatan pelayan API?
Pastikan feature gate dinyahdayakan sehingga kenari memerhatikan shardInfo daripada setiap titik akhir yang berkhidmat. Tindak balas bercampur mencetuskan fallback dan kadar penyambungan semula yang terhad.
Bolehkah pengawal memproses objek yang sama dua kali?
Ya, semasa pertindihan atau penyambungan semula. Gunakan versi objek dan kunci kerja tahan lasak untuk menjadikan kesan sampingan idempoten; jangan sekali-kali menukar penyesuaian pendua dengan risiko kehilangan keadaan yang tidak terhad.