Perintah dan cakupan
Anda mengoperasikan ratusan kluster Kubernetes. Di v1.36, komponen inti mengekspos /statusz, mengembalikan teks yang dapat dibaca manusia secara default dan API terstruktur melalui negosiasi konten eksplisit. Rancang pengumpulan, izin, kompatibilitas versi, peringatan, dan isolasi kesalahan. Beberapa kluster masih menjalankan rilis yang lebih lama, dan endpoint control-plane tidak boleh bersifat publik.
Hal yang sedang diuji oleh pewawancara
Pewawancara ingin Anda memisahkan probe kesehatan, status komponen, dan SLO bisnis sambil merancang autentikasi, batas laju, penguraian versi, dan degradasi untuk banyak kluster. Jawaban yang kuat menangani bidang sensitif, badai peringatan (alert storms), kegagalan kolektor, dan control-plane yang tidak dapat dijangkau.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah Anda memerlukan liveness, status dependensi, atau bidang diagnostik berversi?
- Apakah kolektor berjalan di dalam setiap kluster, atau apakah bidang pusat menarik data?
- Peran mana yang boleh membaca statusz, dan dapatkah respons mengekspos topologi internal atau versi?
- Apakah deteksi diharapkan dalam hitungan detik, atau apakah kapasitas dan tren tingkat menit sudah cukup?
Jawaban 30 detik
"Saya akan memperlakukan statusz sebagai sinyal diagnostik, bukan sinyal kesehatan bisnis. Kolektor di dalam kluster mengakses endpoint melalui jaringan privat dengan hak istimewa terendah, meminta output terstruktur jika tersedia, dan menyimpan teks untuk diagnosis manusia; kluster yang lebih lama menggunakan probe kompatibilitas. Platform pusat mengagregasi berdasarkan kluster, komponen, dan versi dengan batas laju, caching, dan deduplikasi peringatan. Control-plane yang tidak dapat dijangkau adalah kegagalan jalur pengumpulan, bukan otomatis merupakan kegagalan komponen internal."
Solusi langkah demi langkah
1. Tentukan sinyal dan kontrak versi
Catat identitas komponen, versi, format respons, pemeriksaan, dan stempel waktu. Urai bidang terstruktur berdasarkan versi, pertahankan bidang yang tidak dikenal tanpa bergantung padanya; gunakan teks untuk tampilan dan bukti. Jaga agar statusz tetap terpisah dari /livez, /readyz, dan metrik bisnis.
2. Rancang topologi pengumpulan
Jalankan kolektor ringan di dalam setiap kluster dan akses server API, scheduler, dan controller manager melalui jaringan lokal. Pusat menerima peristiwa status yang telah disunting (redacted) dan mengagregasi, menghindari endpoint control-plane publik. Berikan antrean, backoff, dan cache lokal kepada kolektor.
3. Terapkan autentikasi dan otorisasi
Buat identitas kolektor read-only dengan cakupan sumber daya terkecil, membatasi endpoint komponen dan jalur jaringan. Audit pembaca, frekuensi, dan ukuran respons; jangan pernah menggunakan kembali kredensial administrator. Filter bidang versi atau topologi berdasarkan penyewa dan peran operasi jika diperlukan.
4. Kendalikan beban dan kegagalan
Tetapkan konkurensi per komponen, batas waktu (timeouts), durasi cache, dan ukuran respons maksimum. Lakukan backoff saat control-plane sibuk atau tidak dapat dijangkau alih-alih memperparah insiden dengan percobaan ulang (retries). Modelkan kegagalan yang dilaporkan komponen, kegagalan HTTP, ketidakterjangkauan jaringan, dan backlog kolektor secara terpisah.
5. Agregasi dan beri peringatan
Bangun deret waktu berdasarkan kluster, komponen, versi, dan jenis kegagalan, menggunakan sidik jari peristiwa untuk deduplikasi. Wajibkan jendela waktu yang berkelanjutan dan cakupan dampak, seperti beberapa komponen yang gagal atau konsentrasi dalam satu versi. Batas waktu habis tunggal adalah sinyal diagnostik berprioritas rendah.
6. Canary dan rollback
Aktifkan pengumpulan terstruktur pada sebagian kecil kluster v1.36 terlebih dahulu. Bandingkan beban API, stabilitas bidang, presisi peringatan, dan latensi pengumpulan sebelum melakukan perluasan. Jika bidang atau beban mengalami regresi, nonaktifkan pengurai baru, kembali ke probe kompatibilitas, dan pertahankan respons mentah serta catatan audit.
Jawaban model
Saya akan menyusun statusz sebagai lapisan diagnostik control-plane di samping probe liveness dan SLO bisnis. Setiap kluster menjalankan kolektor read-only berhak istimewa terendah melalui jaringan privat; pusat menerima status yang telah disunting dan mengagregasi, sementara rilis yang lebih lama menggunakan probe kompatibilitas. Urai respons terstruktur berdasarkan versi, toleransi bidang yang tidak dikenal, dan pertahankan teks untuk operator. Batasi konkurensi, batas waktu, cache, dan ukuran respons, memisahkan kegagalan komponen, kegagalan jaringan, dan backlog kolektor. Deduplikasi peringatan berdasarkan sidik jari dan jendela waktu. Lakukan canary pada beberapa kluster v1.36 dan nonaktifkan hanya pengurai baru jika diperlukan.
Kesalahan umum
- Memperlakukan statusz sebagai SLO bisnis → pengalaman pengguna salah diklasifikasikan → susun berlapis bersama metrik bisnis.
- Melakukan kueri endpoint publik secara terpusat → bidang serangan meluas → kumpulkan di dalam kluster dan kirim status secara terpusat.
- Menggunakan kembali kredensial administrator → pembacaan memiliki hak istimewa berlebih → buat identitas read-only minimal.
- Menggagalkan seluruh alur kerja karena bidang yang tidak dikenal → pemutakhiran mengganggu pengumpulan → urai secara longgar berdasarkan versi.
- Memberi peringatan pada setiap batas waktu habis → badai peringatan → pisahkan kegagalan jalur dari kegagalan komponen dan lakukan deduplikasi.
Pertanyaan lanjutan dan tanggapan
Mengapa mempertahankan respons teks?
Bidang terstruktur ditujukan untuk agregasi mesin; teks membantu operator membaca dan menyimpan bukti insiden dengan cepat. Keduanya berasal dari satu endpoint tetapi melayani tujuan yang berbeda.
Bagaimana Anda menghindari positif palsu ketika control-plane tidak dapat dijangkau?
Modelkan ketidakterjangkauan jaringan, kegagalan autentikasi, backlog kolektor, dan kegagalan yang dilaporkan komponen secara terpisah. Eskalasi kesalahan komponen hanya jika terdapat bukti yang cukup.
Bagaimana Anda mendukung kluster yang lebih lama?
Periksa endpoint dan versi terlebih dahulu, lalu pilih penguraian terstruktur, penguraian teks, atau probe kompatibilitas. Pertahankan matriks kemampuan alih-alih mengasumsikan setiap kluster mendukung antarmuka Beta.
Bagaimana Anda mencegah pengumpulan memperlambat server API?
Batasi frekuensi dan konkurensi, gunakan cache dan backoff, batasi ukuran respons maksimum, dan turunkan frekuensi pengumpulan secara otomatis saat beban server API meningkat.