Gesaan dan skop
Ini ialah soalan reka bentuk sistem mengenai sempadan satah kawalan/runtime nod. ListContainers, ListPodSandbox, dan ListImages CRI standard ialah RPC unari yang mengembalikan setiap hasil dalam satu respons. Pada nod yang padat, hasil bersiri boleh melebihi had lalai gRPC sebanyak 16 MiB setiap mesej, menghalang penyesuaian kubelet. Kubernetes v1.36 memperkenalkan get ciri alfa CRIListStreaming supaya kubelet boleh menerima hasil melalui RPC penstriman bahagian pelayan. Reka bentuk ini mesti menangani pemprosesan (throughput), memori, sandaran keserasian, dan risiko pelancaran secara serentak.
Perkara yang dinilai oleh penemu duga
- Sama ada anda menghubungkan saiz mesej, peruntukan pensirilan, dan kegagalan penyesuaian dan bukannya hanya mengatakan bahawa nod itu besar.
- Sama ada anda membezakan pengangkutan senarai penstriman daripada aliran watch atau peristiwa sambil mengekalkan ketekalan senarai-tambah-peristiwa.
- Sama ada pengguna mempunyai tekanan balik, pembatalan, tarikh akhir (deadlines), dan semantik hasil separa yang jelas.
- Sama ada anda memahami get alfa yang dinyahdayakan secara lalai, keupayaan runtime, dan sandaran automatik.
- Sama ada anda boleh menentukan canary, metrik, amaran, dan syarat undur balik (rollback).
Soalan penjelasan untuk ditanya
- Berapakah bilangan objek yang sedang berjalan, dihentikan, dan sandbox yang wujud pada waktu puncak, dan seberapa cepat bilangan itu berkembang?
- Adakah runtime kontena melaksanakan ketiga-tiga RPC penstriman, dan versi manakah yang berada dalam tetingkap naik taraf?
- Adakah gejalanya ralat had mesej, tekanan memori kubelet, atau pembinaan senarai yang perlahan di dalam runtime?
- Adakah percubaan semula penyesuaian yang singkat boleh diterima, dan kegagalan manakah yang mesti gagal tutup (fail closed)?
- Bolehkah get alfa didayakan pada kolam nod yang terasing, dan berapa cepat ia boleh diundur balik?
Jawapan 30 saat
“Mula-mula saya akan mengesahkan bahawa senarai CRI unari meletakkan setiap objek ke dalam satu mesej gRPC, jadi kira-kira sepuluh ribu objek boleh mencapai had lalai 16 MiB dan mencipta lonjakan peruntukan. Get CRIListStreaming Kubernetes v1.36 adalah alfa dan dinyahdayakan secara lalai; dengan ia didayakan, kubelet menggunakan tiga RPC penstriman bahagian pelayan dan runtime menghantar ketulan yang digabungkan secara berperingkat oleh pengguna. Saya hanya akan melaksanakan canary pada runtime yang menyokong RPC tersebut, mengehadkan penimbal, menyebarkan pembatalan, dan memantau tempoh senarai, bait mesej, memori, dan ralat penyesuaian. Runtime yang tidak disokong secara automatik berundur kembali ke unari, tetapi nod padat masih memerlukan amaran kerana mod kegagalan lama kekal.”
Penyelidikan mendalam langkah demi langkah
Langkah 1: Mengasingkan kegagalan mesej tunggal
Respons unari mengandungi senarai lengkap, jadi klien mengalami lonjakan daripada penyahkodan protobuf, peruntukan objek, dan penggabungan keadaan. Had mesej gRPC lalai adalah kira-kira 16 MiB; bilangan objek, panjang medan, dan nama imej menentukan sama ada ia melebihi had. Kira-kira sepuluh ribu kontena ialah isyarat skala berasaskan pengalaman, bukan ambang protokol; sahkan ia dengan saiz objek, log runtime, dan metrik kubelet.
Langkah 2: Tentukan kontrak penstriman
Dengan CRIListStreaming didayakan, kubelet menggunakan StreamContainers, StreamPodSandboxes, dan StreamImages. Runtime, sebagai pelayan, menghantar kelompok (batches); klien menyahkod dan menggabungkan setiap kelompok dan bukannya meletakkan keseluruhan senarai dalam satu mesej. Senarai akhir masih memerlukan snapshot yang konsisten sebelum logik penyesuaian sedia ada diteruskan. Senarai penstriman bukanlah watch dan tidak mencipta langganan peristiwa berterusan.
Langkah 3: Kawal tekanan balik, pembatalan, dan kegagalan
Tetapkan tarikh akhir dan hadkan kelompok yang belum diproses serta penimbal objek. Jika pemprosesan ketinggalan, jedakan bacaan atau biarkan runtime memerhatikan kawalan aliran. Tutup strim apabila nod hilang, versi penyegerakan tamat tempoh, atau pemanggil membatalkan, mengelakkan kebocoran goroutine dan sambungan. Pemutusan sambungan pertengahan strim tidak boleh dilaporkan sebagai kejayaan lengkap: buang snapshot sementara dan cuba semula, atau gunakan titik semak versi yang jelas dengan pemulihan idempoten sebelum melakukan komitmen keadaan penuh. Percubaan semula tidak boleh mengira objek dua kali.
Langkah 4: Lancarkan dengan keserasian
Inventori sama ada runtime melaksanakan ketiga-tiga RPC penstriman, kemudian dayakan get ciri pada kolam nod yang terasing. Runtime yang tidak disokong secara automatik berundur kembali ke unari untuk keserasian ke belakang; sandaran itu bukan penyelesaian kapasiti. Labelkan keupayaan nod dan berikan amaran pada nod berketumpatan tinggi yang kekal pada unari. Semasa canary, bandingkan tempoh senarai, RSS puncak, baris gilir penyahkodan, percubaan semula strim, dan kadar kegagalan penyesuaian antara nod penstriman dan nod sandaran.
Langkah 5: Tambah kebolehcerapan dan perlindungan kapasiti
Rekodkan kiraan objek, kiraan kelompok, bait setiap kelompok, jumlah tempoh, masa ke kelompok pertama, pembatalan strim, dan sebab percubaan semula bagi setiap senarai. Kaitkannya dengan working set kubelet, CPU runtime, kiraan sambungan, dan tekanan nod untuk melihat sama ada lonjakan memori menjadi masa pemprosesan yang lebih lama. Tetapkan had objek, tarikh akhir, dan kawalan kemasukan; kembalikan ralat yang boleh didiagnosis apabila had dilebihi dan bukannya memotong (truncate) senarai secara senyap. Kejayaan bermaksud keadaan penyesuaian yang lengkap, bukan sekadar kelompok pertama yang pantas.
Langkah 6: Tentukan sempadan undur balik dan naik taraf
Get alfa dinyahdayakan secara lalai, dan skopnya harus boleh diterbalikkan melalui konfigurasi kubelet. Jika runtime ranap, pemutusan sambungan meningkat, ketekalan senarai gagal, atau memori tidak bertambah baik, nyahdayakan get dan mulakan semula kubelet yang terjejas, kemudian periksa log runtime dan kubelet. Kekalkan pengesanan keupayaan dan sandaran semasa naik taraf runtime; kembangkan kolam nod hanya selepas matriks berbilang versi lulus.
Contoh jawapan berkualiti tinggi
“Saya akan mengaitkan insiden itu dengan lonjakan mesej tunggal dan peruntukan objek senarai CRI unari, dan bukan hanya menaikkan had gRPC. CRIListStreaming Kubernetes v1.36 ialah keupayaan alfa yang dinyahdayakan secara lalai; setelah didayakan, kubelet memanggil tiga RPC penstriman bahagian pelayan dan runtime menghantar hasil kontena, sandbox, dan imej secara berkelompok. Klien menggabungkan kelompok ke dalam snapshot sementara dengan tarikh akhir, penimbal terhad, dan pembatalan. Pemutusan sambungan akan membuang snapshot yang tidak lengkap dan mencuba semula secara idempoten sebelum penyesuaian. Pelancaran canary mula-mula mengesahkan sokongan RPC runtime, kemudian membandingkan kiraan kelompok, tempoh pertama dan jumlah, RSS kubelet, percubaan semula, dan ralat keadaan. Runtime yang tidak disokong berundur kembali ke unari, jadi nod sandaran yang padat masih memerlukan amaran kerana risiko 16 MiB dan lonjakan memori kekal. Sebarang ralat ketekalan akan mencetuskan undur balik get.”
Kesilapan biasa
- Menganggap senarai penstriman sebagai watch dan kehilangan sempadan snapshot-ke-peristiwa.
- Hanya meningkatkan had gRPC sambil mengabaikan pensirilan dan lonjakan penyahkodan kubelet.
- Melakukan komitmen penyesuaian sebelum semua kelompok tiba, meninggalkan keadaan separa selepas pemutusan sambungan.
- Menganggap sandaran automatik menyelesaikan masalah tanpa mengenal pasti runtime yang tidak disokong.
- Mengukur hanya tempoh purata dan bukannya RSS, saiz kelompok, percubaan semula, dan kelengkapan keadaan.
- Membentangkan kira-kira sepuluh ribu kontena sebagai pencetus tetap dan bukannya menyemak saiz objek dan metrik.
Soalan susulan dan jawapan
Bolehkah objek yang telah diterima disimpan selepas pemutusan sambungan pertengahan strim?
Bukan sebagai senarai lengkap secara lalai. Tulis kelompok ke snapshot sementara dan buangnya selepas pemutusan sambungan, atau pulihkan secara idempoten daripada titik semak berversi. Lakukan komitmen hanya selepas penanda kelengkapan protokol dan pengesahan berjaya.
Bagaimana jika runtime hanya melaksanakan satu RPC penstriman?
Siasat keupayaan setiap kaedah dan kekalkan kaedah yang tidak disokong pada RPC unari. Rekodkan label keupayaan bagi setiap nod dan berikan amaran pada nod padat; mendayakan sebahagian tidak menghapuskan setiap mod kegagalan senarai.
Mengapa tidak menaikkan had mesej sahaja?
Had yang lebih besar hanya menangguhkan kegagalan mesej tunggal sambil meningkatkan lonjakan peruntukan, penyalinan, dan GC. Ia juga boleh menguatkan lonjakan kependaman kubelet/runtime. Utamakan penstriman berketul (chunked) dan gunakan metrik untuk membuktikan keadaan lengkap dan peningkatan kapasiti.