Petunjuk dan cakupan
Ini adalah pertanyaan desain sistem mengenai batas antara control-plane node dan runtime. ListContainers, ListPodSandbox, dan ListImages pada CRI standar merupakan RPC unary yang mengembalikan setiap hasil dalam satu respons. Pada node yang padat, hasil yang diserialisasi dapat melebihi batas default pesan gRPC sebesar 16 MiB, sehingga mencegah rekonsiliasi kubelet. Kubernetes v1.36 memperkenalkan feature gate alpha CRIListStreaming sehingga kubelet dapat menerima hasil melalui RPC streaming sisi server. Desain ini harus mengatasi throughput, memori, fallback kompatibilitas, dan risiko peluncuran secara bersamaan.
Hal yang dievaluasi pewawancara
- Apakah Anda menghubungkan ukuran pesan, alokasi serialisasi, dan kegagalan rekonsiliasi, alih-alih hanya mengatakan bahwa node tersebut berukuran besar.
- Apakah Anda membedakan transport list streaming dari watch atau event stream sambil tetap menjaga konsistensi list-plus-events.
- Apakah konsumen memiliki backpressure, pembatalan, tenggat waktu (deadlines), dan semantik hasil parsial yang eksplisit.
- Apakah Anda memahami feature gate alpha yang dinonaktifkan secara default, kapabilitas runtime, dan fallback otomatis.
- Apakah Anda dapat menentukan kondisi canary, metrik, peringatan, dan rollback.
Pertanyaan klarifikasi yang perlu diajukan
- Berapa banyak objek running, stopped, dan sandbox yang ada pada puncaknya, dan seberapa cepat jumlah tersebut bertambah?
- Apakah container runtime mengimplementasikan ketiga RPC streaming tersebut, dan versi mana saja yang ada dalam jendela upgrade?
- Apakah gejalanya berupa galat batas pesan, tekanan memori kubelet, atau pembuatan list yang lambat di dalam runtime?
- Apakah percobaan ulang (retry) rekonsiliasi singkat dapat diterima, dan kegagalan mana yang harus fail closed?
- Bisakah gate alpha diaktifkan pada node pool yang terisolasi, dan seberapa cepat gate tersebut dapat di-rollback?
Jawaban 30 detik
“Pertama, saya akan memverifikasi bahwa list CRI unary memasukkan setiap objek ke dalam satu pesan gRPC, sehingga sekitar sepuluh ribu objek dapat mencapai batas default 16 MiB dan menciptakan lonjakan alokasi. Gate CRIListStreaming pada Kubernetes v1.36 berstatus alpha dan dinonaktifkan secara default; jika diaktifkan, kubelet menggunakan tiga RPC streaming sisi server dan runtime mengirimkan chunk yang digabungkan konsumen secara bertahap. Saya hanya akan melakukan canary pada runtime yang mendukung RPC tersebut, membatasi buffer, menyebarkan pembatalan, serta memantau durasi list, byte pesan, memori, dan galat rekonsiliasi. Runtime yang tidak didukung secara otomatis melakukan fallback ke unary, namun node padat tetap memerlukan peringatan (alert) karena mode kegagalan lama masih ada.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Mengisolasi kegagalan pesan tunggal
Respons unary berisi daftar lengkap, sehingga klien mengalami lonjakan dari decoding protobuf, alokasi objek, dan penggabungan status. Batas pesan default gRPC adalah sekitar 16 MiB; jumlah objek, panjang field, dan nama image menentukan apakah batas tersebut terlampaui. Sekitar sepuluh ribu kontainer adalah sinyal skala berdasarkan pengalaman, bukan ambang batas protokol; konfirmasikan dengan ukuran objek, log runtime, dan metrik kubelet.
Langkah 2: Menentukan kontrak streaming
Dengan diaktifkannya CRIListStreaming, kubelet menggunakan StreamContainers, StreamPodSandboxes, dan StreamImages. Runtime, sebagai server, mengirimkan batch; klien mendekode dan menggabungkan setiap batch alih-alih menempatkan seluruh list dalam satu pesan. Daftar akhir tetap memerlukan snapshot yang konsisten sebelum logika rekonsiliasi yang ada dilanjutkan. List streaming bukanlah watch dan tidak membuat langganan peristiwa (event subscription) yang berkelanjutan.
Langkah 3: Mengontrol backpressure, pembatalan, dan kegagalan
Tetapkan batas waktu (deadline) dan batasi batch yang belum diproses serta buffer objek. Jika pemrosesan tertinggal, jeda pembacaan atau biarkan runtime mengamati kontrol aliran (flow control). Tutup stream saat node menghilang, versi sinkronisasi kedaluwarsa, atau pemanggil membatalkan, guna mencegah kebocoran goroutine dan koneksi. Pemutusan koneksi di tengah stream tidak boleh dilaporkan sebagai keberhasilan penuh: buang snapshot sementara dan coba lagi, atau gunakan checkpoint dengan versi eksplisit beserta pemulihan idempoten sebelum menerapkan status penuh. Percobaan ulang tidak boleh menghitung objek dua kali.
Langkah 4: Meluncurkan dengan kompatibilitas
Inventarisasi apakah runtime mengimplementasikan ketiga RPC streaming, lalu aktifkan feature gate pada node pool yang terisolasi. Runtime yang tidak didukung secara otomatis melakukan fallback ke unary untuk kompatibilitas mundur; fallback tersebut bukanlah perbaikan kapasitas. Beri label kapabilitas node dan buat peringatan pada node berkepadatan tinggi yang tetap menggunakan unary. Selama canary, bandingkan durasi list, puncak RSS, antrean decode, percobaan ulang stream, dan tingkat kegagalan rekonsiliasi antara node streaming dan node fallback.
Langkah 5: Menambahkan observabilitas dan perlindungan kapasitas
Catat jumlah objek, jumlah batch, byte per batch, total durasi, waktu hingga batch pertama, pembatalan stream, dan alasan percobaan ulang untuk setiap list. Hubungkan data tersebut dengan working set kubelet, CPU runtime, jumlah koneksi, dan tekanan node untuk melihat apakah lonjakan memori berubah menjadi waktu pemrosesan yang lebih lama. Tetapkan batas objek, batas waktu, dan kontrol admisi; kembalikan galat yang dapat didiagnosis saat batas terlampaui daripada memotong (truncate) list secara diam-diam. Keberhasilan berarti status rekonsiliasi yang lengkap, bukan sekadar batch pertama yang cepat.
Langkah 6: Menentukan batasan rollback dan upgrade
Gate alpha dinonaktifkan secara default, dan cakupannya harus dapat dibalik melalui konfigurasi kubelet. Jika runtime mengalami crash, pemutusan koneksi meningkat, konsistensi list gagal, atau memori tidak membaik, nonaktifkan gate dan restart kubelet yang terpengaruh, lalu periksa log runtime dan kubelet. Pertahankan deteksi kapabilitas dan fallback selama peningkatan runtime; perluas node pool hanya setelah matriks multi-versi berhasil lolos pengujian.
Contoh jawaban berkualitas tinggi
“Saya akan mengaitkan insiden ini dengan lonjakan pesan tunggal dan alokasi objek pada list CRI unary, bukan hanya menaikkan batas gRPC. CRIListStreaming pada Kubernetes v1.36 adalah kapabilitas alpha yang dinonaktifkan secara default; setelah diaktifkan, kubelet memanggil tiga RPC streaming sisi server dan runtime mengirimkan hasil kontainer, sandbox, dan image dalam bentuk batch. Klien menggabungkan batch ke dalam snapshot sementara dengan deadline, buffer terbatas, dan pembatalan. Pemutusan koneksi akan membuang snapshot yang tidak lengkap dan mencoba ulang secara idempoten sebelum rekonsiliasi. Canary pertama-tama memverifikasi dukungan RPC runtime, lalu membandingkan jumlah batch, durasi awal dan total, RSS kubelet, percobaan ulang, dan galat status. Runtime yang tidak didukung melakukan fallback ke unary, sehingga node fallback yang padat tetap memerlukan peringatan karena risiko 16 MiB dan lonjakan memori masih ada. Setiap galat konsistensi akan memicu rollback gate.”
Kesalahan umum
- Memperlakukan list streaming sebagai watch dan kehilangan batasan antara snapshot dan event.
- Hanya meningkatkan batas gRPC sambil mengabaikan puncak serialisasi dan decoding kubelet.
- Melakukan komit rekonsiliasi sebelum semua batch tiba, meninggalkan status parsial setelah pemutusan koneksi.
- Menganggap fallback otomatis telah menyelesaikan masalah tanpa mengidentifikasi runtime yang tidak didukung.
- Hanya mengukur durasi rata-rata alih-alih RSS, ukuran batch, percobaan ulang, dan kelengkapan status.
- Menyajikan sekitar sepuluh ribu kontainer sebagai pemicu tetap alih-alih memeriksa ukuran objek dan metrik.
Pertanyaan lanjutan dan jawaban
Bisakah objek yang sudah diterima disimpan setelah pemutusan koneksi di tengah stream?
Secara default tidak bisa dianggap sebagai list lengkap. Tulis batch ke snapshot sementara dan buang setelah koneksi terputus, atau pulihkan secara idempoten dari checkpoint berversi. Lakukan komit hanya setelah penanda kelengkapan protokol dan validasi berhasil.
Bagaimana jika runtime hanya mengimplementasikan satu RPC streaming?
Periksa kapabilitas per metode dan pertahankan metode yang tidak didukung pada RPC unary. Catat label kapabilitas per node dan buat peringatan pada node padat; pengaktifan parsial tidak menghilangkan setiap mode kegagalan list.
Mengapa tidak menaikkan batas ukuran pesan saja?
Batas yang lebih besar hanya menunda kegagalan pesan tunggal sambil meningkatkan lonjakan alokasi, penyalinan, dan GC. Hal ini juga dapat memperbesar lonjakan latensi kubelet/runtime. Lebih disarankan menggunakan streaming terbagi (chunked) dan menggunakan metrik untuk membuktikan status lengkap serta peningkatan kapasitas.