Gesaan dan skop
Anda mengendalikan ratusan kluster Kubernetes. Dalam v1.36, komponen teras mendedahkan /statusz, mengembalikan teks yang boleh dibaca manusia secara lalai dan API berstruktur melalui perundingan kandungan yang jelas. Reka bentuk pengumpulan, kebenaran, keserasian versi, amaran dan pengasingan kerosakan. Sesetengah kluster masih menjalankan keluaran lama, dan titik akhir satah kawalan tidak boleh didedahkan secara awam.
Perkara yang diuji oleh penemu duga
Penemu duga mahu anda memisahkan prob kebolehhidupan (liveness probes), keadaan komponen dan SLO perniagaan sambil mereka bentuk pengesahan, had kadar, penghuraian versi dan degradasi untuk banyak kluster. Jawapan yang kukuh mengendalikan medan sensitif, ribut amaran (alert storms), kegagalan pengumpul dan satah kawalan yang tidak dapat dicapai.
Soalan untuk dijelaskan terlebih dahulu
- Adakah anda memerlukan kebolehhidupan, keadaan kebergantungan, atau medan diagnostik berversi?
- Adakah pengumpul berjalan di dalam setiap kluster, atau adakah satah pusat menarik data?
- Peranan manakah yang boleh membaca statusz, dan adakah respons boleh mendedahkan topologi dalaman atau versi?
- Adakah pengesanan dijangkakan dalam masa beberapa saat, atau adakah kapasiti dan trend peringkat minit sudah mencukupi?
Jawapan 30 saat
"Saya akan menganggap statusz sebagai isyarat diagnostik, bukan isyarat kesihatan perniagaan. Pengumpul dalam kluster mengakses titik akhir melalui rangkaian peribadi dengan keistimewaan paling rendah, meminta output berstruktur apabila tersedia, dan menyimpan teks untuk diagnosis manusia; kluster yang lebih lama menggunakan prob keserasian. Platform pusat mengagregatkan mengikut kluster, komponen dan versi dengan had kadar, caching dan penyahduplikasian amaran. Satah kawalan yang tidak dapat dicapai adalah kegagalan laluan pengumpulan, bukan secara automatik kegagalan komponen dalaman."
Penyelesaian langkah demi langkah
1. Tentukan isyarat dan kontrak versi
Rekod identiti komponen, versi, format respons, pemeriksaan dan cap masa. Huraikan medan berstruktur mengikut versi, mengekalkan medan yang tidak diketahui tanpa bergantung padanya; gunakan teks untuk paparan dan bukti. Pastikan statusz berasingan daripada /livez, /readyz dan metrik perniagaan.
2. Reka bentuk topologi pengumpulan
Jalankan pengumpul ringan di dalam setiap kluster dan akses pelayan API, penjadual (scheduler) dan pengurus pengawal (controller manager) melalui rangkaian tempatan. Pusat menerima peristiwa keadaan yang telah disunting (redacted) dan mengagregat, mengelakkan titik akhir satah kawalan awam. Berikan pengumpul barisan gilir (queue), undur (backoff) dan cache tempatan.
3. Kuat kuasakan pengesahan dan kebenaran
Cipta identiti pengumpul baca sahaja dengan skop sumber terkecil, mengehadkan titik akhir komponen dan laluan rangkaian. Audit pembaca, kekerapan dan saiz respons; jangan sekali-kali menggunakan semula kelayakan pentadbir. Tapis medan versi atau topologi mengikut penyewa dan peranan operasi apabila perlu.
4. Kawal beban dan kegagalan
Tetapkan keserentakan bagi setiap komponen, masa tamat (timeouts), tempoh cache dan saiz respons maksimum. Lakukan undur (backoff) apabila satah kawalan sibuk atau tidak dapat dicapai dan bukannya memburukkan lagi insiden dengan percubaan semula. Modelkan kegagalan yang dilaporkan komponen, kegagalan HTTP, ketidaktercapaian rangkaian dan tunggakan pengumpul secara berasingan.
5. Agregat dan beri amaran
Bina siri masa mengikut kluster, komponen, versi dan jenis kegagalan, menggunakan cap jari peristiwa untuk penyahduplikasian. Perlukan tetingkap berterusan dan skop impak, seperti beberapa komponen gagal atau penumpuan dalam satu versi. Satu masa tamat adalah isyarat diagnostik berkeutamaan rendah.
6. Kenari dan undur balik (rollback)
Dayakan pengumpulan berstruktur pada set kecil kluster v1.36 terlebih dahulu. Bandingkan beban API, kestabilan medan, ketepatan amaran dan kependaman pengumpulan sebelum berkembang. Jika medan atau beban mengalami regresi, lumpuhkan penghurai baharu, kembali kepada prob keserasian, dan kekalkan respons mentah serta rekod audit.
Jawapan model
Saya akan meletakkan statusz sebagai diagnostik satah kawalan di samping prob kebolehhidupan dan SLO perniagaan. Setiap kluster menjalankan pengumpul baca sahaja dengan keistimewaan paling rendah melalui rangkaian peribadi; pusat menerima keadaan yang disunting dan mengagregat, manakala keluaran yang lebih lama menggunakan prob keserasian. Huraikan respons berstruktur mengikut versi, bertolak ansur dengan medan yang tidak diketahui, dan kekalkan teks untuk pengendali. Bataskan keserentakan, masa tamat, cache dan saiz respons, memisahkan kegagalan komponen, kegagalan rangkaian dan tunggakan pengumpul. Nyahduplikasi amaran mengikut cap jari dan tetingkap masa. Lakukan kenari pada beberapa kluster v1.36 dan lumpuhkan hanya penghurai baharu apabila diperlukan.
Kesilapan biasa
- Menganggap statusz sebagai SLO perniagaan → pengalaman pengguna tersalah klasifikasi → lapiskannya dengan metrik perniagaan.
- Membuat pertanyaan titik akhir awam secara berpusat → permukaan serangan berkembang → kumpul dalam kluster dan hantar keadaan secara berpusat.
- Menggunakan semula kelayakan pentadbir → bacaan mempunyai keistimewaan berlebihan → cipta identiti baca sahaja yang minimum.
- Menggagalkan keseluruhan saluran paip pada medan yang tidak diketahui → peningkatan mengganggu pengumpulan → huraikan secara fleksibel mengikut versi.
- Memberi amaran pada setiap masa tamat → ribut amaran → pisahkan kegagalan laluan daripada kegagalan komponen dan nyahduplikasi.
Soalan susulan dan respons
Mengapa mengekalkan respons teks?
Medan berstruktur adalah untuk pengagregatan mesin; teks membantu pengendali membaca dan memelihara bukti insiden dengan cepat. Kedua-duanya datang daripada satu titik akhir tetapi mempunyai tujuan yang berbeza.
Bagaimanakah anda mengelakkan positif palsu apabila satah kawalan tidak dapat dicapai?
Modelkan ketidaktercapaian rangkaian, kegagalan pengesahan, tunggakan pengumpul dan kegagalan yang dilaporkan komponen secara berasingan. Eskalasikan kerosakan komponen hanya dengan bukti yang mencukupi.
Bagaimanakah anda menyokong kluster yang lebih lama?
Uji titik akhir dan versi terlebih dahulu, kemudian pilih penghuraian berstruktur, penghuraian teks atau prob keserasian. Kekalkan matriks keupayaan dan bukannya menganggap setiap kluster menyokong antara muka Beta.
Bagaimanakah anda menghalang pengumpulan daripada memperlahankan pelayan API?
Batasi kekerapan dan keserentakan, gunakan cache dan undur (backoff), hadkan saiz respons dan kurangkan kekerapan pengumpulan secara automatik apabila beban pelayan API meningkat.