Wawancara umum: Bagaimana Kubernetes NodeLogQuery dapat mengekspos log sistem secara aman?

Petunjuk dan konteks

Sebuah platform operasi memerlukan log systemd dari node Kubernetes untuk proses debugging tetapi tidak boleh mengekspos sistem berkas node kepada penyewa (tenants). Jelaskan batasan dari NodeLogQuery yang stabil di Kubernetes v1.36, kontrol akses, parameter kueri, paginasi, pembatasan laju (rate limiting), serta apa yang harus dilakukan ketika suatu node tidak dapat dijangkau atau hasilnya terlalu besar.

Hal yang dievaluasi oleh pewawancara

• Membedakan NodeLogQuery dari pembacaan berkas node secara langsung, log kontainer, dan sistem logging terpusat.
• Menjelaskan enableSystemLogQuery, autentikasi dan otorisasi Kubelet, serta isolasi penyewa.
• Mempertimbangkan rentang waktu, tingkat keparahan (severity), ukuran keluaran, batas waktu (deadlines), dan batas konkurensi.
• Menyediakan alur kerja operasi yang dapat diamati (observable), dapat diaudit (auditable), dan dapat dibatalkan/dikembalikan (reversible).

Pertanyaan klarifikasi yang perlu diajukan

1. Apakah targetnya adalah layanan node, log kernel, atau stdout/stderr Pod? Semuanya memiliki titik masuk yang berbeda.
2. Apakah pemanggilnya adalah administrator kluster, SRE yang sedang bertugas (on-call), atau platform layanan mandiri penyewa?
3. Apakah kueri lintas-node, rentang panjang, atau pemantauan langsung (live-follow) diperlukan? Hal-hal tersebut memengaruhi beban node.
4. Apakah sistem pengumpulan log sudah tersedia untuk pencarian historis?

Kerangka jawaban 30 detik

Tetapkan batasannya terlebih dahulu: NodeLogQuery adalah kapabilitas log node Kubelet yang terkontrol, bukan akses berkas arbitrer. Kemudian berikan alurnya: autentikasi dan otorisasi pemanggil, validasi cakupan node dan kueri, biarkan Kubelet memanggil antarmuka log node, dan kembalikan hasil yang dibatasi. Akhiri dengan pengaman (guardrails): aktifkan enableSystemLogQuery, batasi waktu, baris, bita, konkurensi, dan batas waktu; kirim pencarian historis ke log terpusat; serta lakukan audit dan peringatan pada permintaan yang tidak normal.

Pembahasan mendalam langkah demi langkah

1. Menentukan sumber log dan batasan kapabilitas

NodeLogQuery menargetkan log sistem node seperti systemd dan log kernel. Stdout/stderr Pod harus menggunakan logging kontainer atau kolektor terpusat. Antarmuka kueri tidak boleh menerima jalur sistem berkas arbitrer, membaca direktori kredensial, atau melewati otorisasi Kubelet. Penyewa harus menerima event node yang difilter atau agregat, sementara log node mentah tetap terbatas pada peran SRE yang terkontrol.

2. Mengautentikasi, mengotorisasi, dan mengisolasi penyewa

Endpoint HTTPS Kubelet mengautentikasi klien sebelum mengevaluasi atribut permintaan. API Server atau proksi operasi menggunakan identitas khusus yang aturannya dibatasi pada kapabilitas log node yang diizinkan; penyewa tidak menerima nodes/proxy atau akses luas yang setara. Platform juga memverifikasi pengikatan (binding) penyewa-ke-node sehingga mengubah nama atau label node tidak dapat mengakses node milik penyewa lain.

3. Membatasi kueri dan melindungi sumber daya

Wajibkan penentuan node, unit layanan, rentang waktu, dan tingkat keparahan secara eksplisit, dengan jendela default yang singkat. Tetapkan durasi maksimum, bita yang dikembalikan, baris, konkurensi, dan laju per penyewa. Saat batas tercapai, kembalikan token halaman yang dapat dilanjutkan atau kesalahan yang jelas. Streaming dapat diterima, tetapi pemutusan koneksi, batas waktu (deadline), atau batas maksimum harus melepaskan sumber daya Kubelet dan proksi.

4. Mengamati, menangani kegagalan, dan melakukan rollback

Catat identitas pemanggil, node, ringkasan parameter, waktu mulai dan selesai, bita yang dikembalikan, alasan pemotongan (truncation), dan hasil otorisasi; jangan menyalin konten log ke dalam aliran audit. Gagal dengan cepat (fail fast) ketika suatu node tidak dapat dijangkau dan rekomendasikan log terpusat. Picu circuit breaker dan berikan peringatan saat Kubelet kelebihan beban. NodeLogQuery sudah stabil dan aktif secara default di v1.36, sementara enableSystemLogQuery tetap menjadi pengaturan operasional; luncurkan ke node canary dan pertahankan jalur penonaktifan.

Contoh jawaban model

Saya akan menjadikan NodeLogQuery sebagai antarmuka diagnostik node yang terkontrol, bukan penjelajah berkas. Pertama, pisahkan log sistem, log kontainer, dan pencarian historis terpusat. Pemanggil diautentikasi dan diotorisasi melalui Kubelet serta hanya dapat menanyakan node dan jenis log yang disetujui. Penyewa tidak menerima akses luas nodes/proxy, dan platform memverifikasi pengikatan penyewa-ke-node.

Setiap kueri menyertakan node, unit layanan, rentang waktu, dan tingkat keparahan dengan jendela default yang singkat. Terapkan batas bita, baris, konkurensi, laju, dan batas waktu; lakukan streaming atau paginasi hasil dan laporkan jika terjadi pemotongan. Audit menyimpan identitas, node, ringkasan parameter, durasi, ukuran, dan keputusan, bukan isi log. Node yang tidak dapat dijangkau dan Kubelet yang kelebihan beban akan gagal dengan cepat, memicu breaker, dan mengarahkan pengguna ke log terpusat. NodeLogQuery stabil dan aktif secara default di v1.36, tetapi saya akan menerapkan canary pada enableSystemLogQuery dan mempertahankan opsi rollback.

Kesalahan umum

• Memperlakukan NodeLogQuery sebagai akses berkas node arbitrer.
• Memberikan nodes/proxy kepada penyewa dan mengabaikan isolasi node dan penyewa.
• Mengizinkan rentang waktu, keluaran, atau konkurensi tanpa batas.
• Menuliskan isi log ke dalam aliran audit dan menyebabkan kebocoran data sensitif sekunder.
• Mencoba ulang node yang tidak dapat dijangkau tanpa batas dan memperbesar beban control-plane atau Kubelet.

Pertanyaan lanjutan dan tanggapan

Pertanyaan lanjutan 1: Mengapa tidak mengirim setiap kueri historis melalui NodeLogQuery?

Endpoint node cocok untuk diagnostik mendekati waktu nyata (near-real-time). Pengumpulan terpusat harus menangani pencarian historis, pengindeksan, isolasi penyewa, dan retensi tanpa menghabiskan sumber daya Kubelet untuk pembacaan yang lama.

Pertanyaan lanjutan 2: Bagaimana Anda membuktikan bahwa kueri tidak dapat melintasi batas penyewa?

Catat identitas, node, sumber daya, dan keputusan untuk setiap permintaan. Gunakan uji sintetik untuk membuktikan bahwa node yang diizinkan berhasil dan node milik penyewa lain ditolak, serta verifikasi bahwa proksi menolak jalur arbitrer dan parameter node yang tidak sah.

Pertanyaan lanjutan 3: Bagaimana jika log mengandung kredensial?

Jangan mengandalkan redaksi berbasis tebakan yang tidak dapat dibatalkan pada respons. Kurangi cakupan kueri, peran, dan retensi, serta lakukan redaksi terstruktur pada saat pengumpulan. Cabut akses yang terpengaruh dan lakukan rotasi kredensial saat bidang berisiko tinggi ditemukan.