Gesaan dan konteks
Pengawal Kubernetes membaca objek daripada cache Informer dan menulis keadaan yang diingini ke pelayan API. Di bawah beban, kelewatan watch, atau mula semula, cache boleh ketinggalan di belakang pelayan API; pengawal mungkin mengulangi penulisan, menskalakan secara salah, atau menganggap Lease lama telah tamat tempoh. Reka bentuk pengesanan kelapukan dan mitigasi yang hanya menyekat objek yang terjejas.
Ini relevan untuk peranan kejuruteraan platform, SRE, dan pengawal natif awan. Kubernetes v1.36 dan KEP 5647 menerangkan AtomicFIFO, LastStoreSyncResourceVersion(), penjejakan versi sumber bagi penulisan, melangkau dan membariskan semula kunci lapuk, serta menyepadukan pengawal DaemonSet, StatefulSet, ReplicaSet, dan Job. Ini ialah latihan reka bentuk sumber awam, bukan tuntutan tentang bank temu duga mana-mana syarikat.
Perkara yang dinilai oleh penemu duga
Penemu duga ingin melihat sama ada anda memahami sempadan cache konsisten akhirnya (eventually consistent) dan boleh menukar "cukup segar" kepada syarat versi sumber yang boleh diuji. Jawapan yang mantap merangkumi penyegerakan cache, read-after-write, baris gilir setiap kunci, backoff, mula semula, pemantauan, dan feature gates. Jawapan yang lemah menjadikan setiap panggilan penyesuaian (reconcile) terus menghubungi pelayan API dan mengabaikan kos beban serta konsistensi.
Soalan penjelasan
- Keputusan manakah yang bersifat pemusnahan: memadamkan Pod, menurunkan skala (scale down), pertukaran ketua, atau kemas kini status biasa?
- Apakah tetingkap kelapukan yang boleh diterima, dan mampukah operasi kritikal menampung satu bacaan pelayan API?
- Adakah kita memerlukan read-after-write untuk satu objek atau susunan bersebab (causal ordering) merentas beberapa objek?
- Selepas mula semula, penyambungan semula watch, atau kegagalan pelayan API, patutkah pengawal menunggu secara konservatif atau membenarkan degradasi terhad?
Jawapan 30 saat
“Saya akan mengekalkan cache Informer sebagai laluan baca lalai dan menggunakan AtomicFIFO serta versi sumber diperhatikan terkini untuk mengukur kemajuan. Selepas menulis objek kritikal, pengawal merekodkan versi sasarannya; sehingga cache dapat mengejar, ia melangkau hanya kunci tersebut dan memasukkannya semula ke baris gilir dengan backoff eksponen. Tindakan pemusnahan menambah bacaan langsung terhad atau pemutus litar. Metrik mendedahkan kelengahan cache, penyesuaian yang dilangkau, dan usia baris gilir. Semasa mula semula, kekalkan perlindungan, selesaikan penyegerakan cache, kemudian sambung semula.”
Penyelesaian langkah demi langkah
Takrifkan kelapukan terlebih dahulu. Informer Store diisi oleh peristiwa watch yang boleh ditangguhkan, disusun semula, atau tidak lengkap buat sementara waktu semasa cache dibina semula. AtomicFIFO pada Kubernetes v1.36 menjadikan kelompok senarai awal atomik berbanding peristiwa bertahap, mengelakkan cache tidak konsisten yang disebabkan oleh pertindihan proses tersebut. LastStoreSyncResourceVersion() mendedahkan versi terkini yang diperhatikan oleh Store.
Bagi setiap penulisan kritikal, simpan objectKey -> resourceVersion. Apabila DaemonSet mengemas kini Pod, rekodkan versi yang dikembalikan oleh pelayan API. Setiap peristiwa pod informer memajukan versi tertinggi yang diperhatikan. DaemonSet boleh menjalankan penyesuaian seterusnya yang bergantung pada keadaan baharu hanya apabila versi yang diperhatikan mencapai penulisan terakhir. Jika tidak, masukkan semula kunci tersebut ke baris gilir dengan backoff eksponen biasa; jangan sekali-kali menghentikan keseluruhan kumpulan pekerja (worker pool).
Penulisan dan pemeriksaan mestilah beridempoten. Gunakan percubaan semula konflik versi sumber, dan pastikan penyesuaian berulang tidak mempunyai kesan sampingan tambahan. Mula semula menghilangkan pemetaan dalam ingatan, jadi permulaan menunggu penyegerakan cache informer sebelum membina semula keadaan terlindung daripada status objek atau peristiwa baris gilir. Jika pemetaan tidak lengkap, tangguhkan kerja pemusnahan dan bukannya menganggap ia segar.
Untuk keputusan sensitif masa, tambahkan pemutus litar. Gunakan cache untuk laluan pantas; apabila versi sasaran tidak diketahui atau kelengahan melebihi ambang, lakukan satu bacaan langsung terhad daripada pelayan API. Jika ia gagal, jeda hanya kunci tersebut dan rekodkan sebabnya. Menjadikan bacaan langsung sebagai lalai akan meningkatkan QPS pelayan API, kependaman, dan radius kegagalan.
Dedahkan versi sumber informer, versi penulisan sasaran, tempoh kelengahan, bilangan penyesuaian yang dilangkau, usia baris gilir, kadar kejayaan bacaan langsung, dan kiraan pemutus litar bagi setiap pengawal. Log merangkumi kunci objek, versi, dan tindakan, jangan sekali-kali nilai Secret. Makluman membezakan kelambatan pelayan API, watch terputus, kunci hangat (hot key), dan pemprosesan pengawal yang perlahan.
Keluarkannya di sebalik feature gate dan pelancaran kenari (canary). Dayakannya untuk satu pengawal berkontensi tinggi dan kumpulan nod kecil, kemudian sahkan penumpuan selepas langkauan, pemulihan mula semula, dan ketiadaan kebuluran baris gilir (queue starvation). Luaskan hanya selepas beban pelayan API boleh diterima. Undurkan dengan melumpuhkan laluan konsistensi baharu sambil mengekalkan metrik dan keadaan objek; jangan memadamkan pemetaan perlindungan secara pukal.
Jawapan model
Saya akan melaksanakan empat lapisan: bacaan utamakan cache, get versi sumber, baris gilir semula setiap kunci, dan pemutus litar untuk tindakan kritikal. AtomicFIFO memastikan pemprosesan senarai awal konsisten dengan peristiwa bertahap, dan Store melaporkan versi sumber diperhatikan terkini. Selepas menulis, pengawal merekodkan versi sasaran; ia memproses kunci tersebut hanya selepas cache mencapainya, jika tidak, ia memasukkannya semula ke baris gilir dengan backoff.
Pemadaman, penurunan skala, dan keputusan Lease menggunakan bacaan langsung terhad apabila kesegaran cache tidak diketahui atau melebihi ambang; kegagalan menjeda kunci tersebut. Metrik meliputi kelengahan versi, kerja yang dilangkau, usia baris gilir, dan nisbah bacaan langsung. Mula semula menunggu penyegerakan cache sebelum memulihkan pemetaan. Pelancaran kenari mengesahkan penumpuan, pemulihan, dan beban pelayan API; keadaan perlindungan tidak pernah dipadamkan secara global.
Kesilapan biasa
- Kesilapan → membaca secara langsung daripada pelayan API pada setiap penyesuaian; Sebab ia gagal → QPS dan kependaman meningkat dan cache kehilangan fungsinya; Pembaikan → baca secara langsung hanya untuk tindakan kritikal atau versi yang tidak diketahui.
- Kesilapan → menjeda setiap pekerja apabila satu objek lapuk; Sebab ia gagal → satu kunci hangat menyebabkan gangguan global; Pembaikan → langkau dan masukkan semula ke baris gilir mengikut kunci objek.
- Kesilapan → membandingkan cap masa tempatan sahaja; Sebab ia gagal → hanyutan jam (clock drift) tidak dapat membuktikan kebersebaban watch; Pembaikan → bandingkan versi sumber API.
- Kesilapan → mengosongkan semua perlindungan selepas mula semula; Sebab ia gagal → keputusan mungkin dijalankan semasa cache sedang dibina semula; Pembaikan → tunggu penyegerakan dan pulihkan keadaan dengan semakan versi.
Soalan susulan
Mengapakah versi sumber lebih selamat daripada cap masa tempatan?
Ia datang daripada jujukan perubahan objek pelayan API dan boleh membuktikan bahawa cache telah memerhatikan penulisan tertentu. Waktu tempatan dipengaruhi oleh hanyutan jam, kelewatan rangkaian, dan jeda proses. Versi sumber bukanlah jujukan transaksi merentas objek, jadi konsistensi pelbagai objek masih memerlukan reka bentuk eksplisit.
Bagaimanakah anda mengelakkan kebuluran (starvation) apabila satu kunci kekal lapuk?
Hadkan backoff eksponen dan berikan makluman pada masa menunggu maksimum sambil membenarkan kunci lain berjalan. Selepas melepasi ambang, beralih kepada pengesanan berfrekuensi rendah atau satu bacaan langsung. Kira langkauan berturut-turut supaya percubaan semula yang pantas tidak membebankan pelayan API.
Bilakah sesuatu operasi patut ditolak?
Untuk keputusan pemadaman, penurunan skala, failover, atau tamat tempoh Lease, jeda kunci dan kekalkan perlindungan apabila kesegaran tidak diketahui dan bacaan langsung gagal. Pelaporan status biasa boleh diteruskan dalam tetingkap kelapukan yang jelas, tetapi mesti menandakan keadaan terdegradasi dalam status dan metrik.