Temu duga reka bentuk sistem: Bagaimanakah Kubernetes patut mengemas kini kapasiti volum nod CSI secara dinamik?

Gesaan dan konteks

Kapasiti lampiran volum pemacu CSI berubah mengikut kuota awan dan kesihatan. Reka bentuk pelaporan kapasiti, ketekalan penjadual, perlindungan kegagalan, dan naik taraf untuk Mutable CSINode Allocatable Kubernetes. Terangkan sempadan tanggungjawab antara pemacu CSI, objek nod, penjadual, dan kegagalan lampiran (attach).

Perkara yang dinilai oleh penemu duga

• Memahami bahawa CSINode.spec.drivers[].allocatable.count ialah pembayang penjadualan (scheduling hint), bukan kunci masa nyata (real-time lock).
• Menerangkan cara pemacu CSI mengemas kini kapasiti secara berkala atau selepas ralat berlaku.
• Mengendalikan nilai lapuk, kemas kini serentak, cache penjadual, dan kegagalan lampiran.
• Mereka bentuk amaran, backoff, naik taraf keserasian, dan pemulihan kapasiti.

Soalan penjelasan untuk ditanya

1. Adakah kapasiti berubah disebabkan oleh kuota awan, kesihatan pemacu, atau sumber nod tempatan?
2. Apakah kelewatan kemas kini dan ralat yang boleh diterima, dan adakah tingkah laku Pending yang konservatif dibenarkan?
3. Adakah versi kluster dan pemacu CSI menyokong nilai allocatable yang boleh diubah (mutable)?
4. Selepas kegagalan lampiran, patutkah sistem mencuba semula, memindahkan Pod, atau membekukan nod terlebih dahulu?

Rangka jawapan 30 saat

Mulakan dengan objek: pemacu CSI menulis kapasiti volum yang boleh digunakan ke dalam CSINode, dan penjadual menapis menggunakannya; oleh sebab nilainya boleh mengalami kelengahan (lag), proses lampiran masih melakukan pemeriksaan akhir. Pemacu mengemas kini mengikut tempoh atau ralat kapasiti yang jelas, manakala pengawal dan penjadual menumpu melalui watch. Hadkan kadar kemas kini (rate-limit), lindungi susunan, dan kurangkan kapasiti secara konservatif semasa ketidakpastian supaya nilai tinggi yang tidak betul tidak tersebar ke seluruh kluster.

Perbincangan mendalam langkah demi langkah

1. Rangkaian tanggungjawab dan model data

Setiap pasangan nod-dan-pemacu mempunyai CSINode.spec.drivers[].allocatable.count. Pemacu CSI mengetahui had lampiran bahagian belakang storan dan melaporkan kapasiti yang boleh digunakan; penjadual menganggapnya sebagai maklumat pra-penapisan. Medan ini bukan kunci teragih dan tidak boleh menghalang race condition antara keputusan penjadualan. Pemacu dan pengawal mesti mengesahkan kapasiti sekali lagi apabila volum benar-benar dicipta atau dilampirkan.

2. Pencetus kemas kini dan ketekalan

Pemacu boleh menyegarkan mengikut tempoh yang dikonfigurasikan melalui CSIDriver, atau serta-merta selepas ralat kehabisan kapasiti yang jelas. Gunakan prasyarat versi sumber (resource-version preconditions) supaya pemacu yang lebih lama tidak boleh menulis ganti nilai yang lebih baharu. Tambahkan selang minimum dan jitter untuk mengelakkan penukaran hingar API awan menjadi amplifikasi penulisan satah kawalan. Penjadual menyegarkan cachenya melalui watch dan harus membuat keputusan konservatif semasa tetingkap ketidakkonsistenan yang singkat.

3. Perlindungan kegagalan dan pemulihan

Apabila pemacu tidak dapat memperoleh kuota atau kesihatan, ia tidak boleh melaporkan kapasiti tanpa had. Ia boleh mengekalkan nilai baik terakhir yang diketahui dengan tamat tempoh atau mengurangkan kapasiti kepada sifar supaya Pod baharu kekal dalam status Pending. Kelaskan kegagalan lampiran sebagai ralat kapasiti, kebenaran, topologi, atau rangkaian sementara; hanya ralat kapasiti yang patut mengemas kini allocatable. Tingkatkan kapasiti secara beransur-ansur selepas pemulihan sambil memerhatikan kejayaan lampiran.

4. Naik taraf, perhatikan, dan sahkan

Kubernetes v1.36 menjadikan Mutable CSINode Allocatable stabil. Sebelum menaik taraf, sahkan matriks versi API Server, penjadual, kubelet, dan pemacu CSI, kemudian dayakan kemas kini berkala pada nod kenari (canary) yang kecil. Pantau kelewatan kemas kini objek, kekerapan perubahan kapasiti, sebab Pending, kelas kegagalan lampiran, QPS penulisan satah kawalan, dan penggunaan nod sebenar. Jika isyarat merosot, jedakan kemas kini, pulihkan tetapan yang serasi, dan kekalkan kapasiti dipercayai yang terakhir.

Jawapan model

Saya akan menganggap allocatable yang boleh diubah sebagai pembayang penjadualan, bukan kunci masa nyata. Pemacu CSI melaporkan kapasiti lampiran nod-dan-pemacu dalam CSINode.spec.drivers[].allocatable.count, menyegarkan secara berkala atau selepas ralat kehabisan kapasiti yang jelas. Penjadual memerhatikan objek melalui watch, tetapi pemacu masih melakukan pemeriksaan lampiran akhir.

Kemas kini memerlukan had kadar, syarat versi sumber, dan jitter. Jika kuota tidak boleh dipercayai, kurangkan kapasiti secara konservatif dan bukannya menulis nilai tinggi yang sebarangan. Kelaskan kegagalan lampiran mengikut kapasiti, kebenaran, topologi, dan rangkaian; hanya kegagalan kapasiti yang mencetuskan kemas kini. Selepas v1.36 menstabilkan ciri ini, gunakan nod canary dan perhatikan lag kemas kini, sebab Pending, kegagalan lampiran, QPS penulisan, dan penggunaan sebenar. Jedakan kemas kini dan pulihkan nilai dipercayai yang terakhir apabila isyarat merosot.

Kesilapan biasa

• Menganggap allocatable sebagai kunci masa nyata tanpa pertikaian (contention-free).
• Mengurangkan kapasiti kepada sifar untuk setiap kegagalan lampiran dan menyebabkan Pod Pending kolateral.
• Membiarkan pemacu menulis CSINode pada kekerapan tinggi dan menguatkan beban satah kawalan.
• Melaporkan kapasiti tinggi apabila carian kuota gagal.
• Hanya menaik taraf versi API sambil mengabaikan keserasian pemacu CSI, penjadual, dan kubelet.

Soalan susulan dan jawapan

Susulan 1: Mengapakah lampiran boleh gagal selepas penjadual melihat kapasiti yang mencukupi?

Medan tersebut mempunyai kelewatan penyebaran (propagation delay) dan pengguna serentak boleh menggunakan kuota yang sama. Penapis penjadualan merendahkan kebarangkalian kegagalan; pemacu CSI mesti mengesahkan semula semasa lampiran dan mengembalikan ralat yang dikelaskan.

Susulan 2: Berapa kerapkah kapasiti patut disegarkan?

Ia bergantung pada kekerapan perubahan kuota, belanjawan penulisan satah kawalan, dan toleransi perniagaan untuk Pod Pending. Mulakan secara konservatif, selaraskan daripada lag kemas kini, kadar kegagalan, dan QPS penulisan, serta gunakan kemas kini yang dicetuskan oleh backoff selepas ralat.

Susulan 3: Bagaimanakah anda menghalang pemacu lama daripada menulis ganti kapasiti baharu?

Gunakan kemas kini bersyarat versi sumber dan pagar versi pemacu, mengehadkan penulisan daripada pemacu lama semasa naik taraf. Pantau identiti penulis, cap masa, dan regresi; jedakan pengembangan automatik apabila pengunduran (rollback) dikesan.