VietTechiesHIỂU CÔNG NGHỆ. MỞ GÓC NHÌN.
☰ Chuyên mục

Cơ chế theo dõi inode của Kubelet khiến node Kubernetes đối mặt nguy cơ bị trục xuất pod đột ngột

06/10/2026 · VietTechies · Biên tập

Một chiếc đồng hồ cát bằng thủy tinh ở chính giữa chứa đầy các bánh răng đồng nhỏ làm nghẽn phần cổ hẹp, đặt trên nền xám đậm với đồng hồ chỉ báo màu xanh lơ.
Ảnh minh họa do AI tạo.

Các node công nhân (worker node) trong Kubernetes có thể cạn kiệt inode tệp khả dụng trước khi hết dung lượng đĩa do cách Kubelet quản lý việc dọn dẹp lưu trữ. Phân tích kỹ thuật từ Cloud Native Computing Foundation cho thấy cơ chế dọn dẹp ảnh chạy ẩn của Kubelet chỉ giám sát ngưỡng dung lượng byte, khiến sự gia tăng inode không được kiểm soát cho tới khi node chạm ngưỡng trục xuất bắt buộc.

Cơ chế giám sát tài nguyên bất đối xứng trong Kubelet

Kubelet quản lý dung lượng đĩa của ảnh container thông qua các cấu hình dựa trên byte: imageGCHighThresholdPercent (mặc định 85%) và imageGCLowThresholdPercent (mặc định 80%). Khi mức sử dụng đĩa vượt quá giới hạn trên, Kubelet sẽ tự động xóa các ảnh không dùng đến. Tuy nhiên, quy trình dọn dẹp tự động này không bao giờ đo lường số lượng tệp hay mức tiêu thụ inode.

Trên các node công nhân chạy Linux, Kubelet kích hoạt lệnh trục xuất bắt buộc khi inode khả dụng trên nodefs hoặc imagefs giảm xuống còn 5%. Trái ngược với quản lý dung lượng byte, không hề có cơ chế dọn dẹp thụ động nào dành cho inode. Khi một node phát sinh lượng tệp tăng đột biến, Kubelet sẽ không can thiệp cho đến khi dung lượng inode đạt mức 95%, thời điểm tiến trình này bắt đầu trục xuất các pod. Các cấu hình mặc định trên các nền tảng không phải Linux thậm chí loại bỏ hoàn toàn các tín hiệu trục xuất inode bắt buộc.

Phụ thuộc container và sự nhân bản của snapshot

Nguyên nhân chính dẫn đến mức sử dụng inode cao là các ảnh container chứa bộ sưu tập lớn các tệp nhỏ, chẳng hạn như thư mục phụ thuộc của Node.js hoặc môi trường ảo của các ngôn ngữ lập trình. Quá trình đóng gói container đơn đoạn (single-stage build) thường giữ lại các trình quản lý gói, tệp mã nguồn và các thư viện phụ thuộc ngay trong các lớp ảnh được phát hành.

Các trình điều khiển lưu trữ cho môi trường thực thi container như overlayfs snapshotter của containerd giải nén từng lớp thành các thư mục riêng biệt. Ngay cả khi các tệp bên dưới giống hệt nhau giữa các bản đóng gói, việc thay đổi mã băm (digest) của lớp sẽ ngăn cản việc tối ưu trùng lặp tệp, dẫn đến hàng nghìn inode mới được tạo ra trong mỗi đợt triển khai dần (rollout). Hệ thống tệp ext4 tiêu chuẩn thường gán giới hạn inode cố định ngay khi khởi tạo, khiến số lượng tệp lớn có thể làm cạn kiệt inode trong khi dung lượng byte trên đĩa vẫn còn rất thấp.

Chiến lược giảm thiểu và cảnh báo tùy chỉnh

Để giảm mật độ inode, các nhà phát triển có thể áp dụng phương pháp đóng gói container đa đoạn (multi-stage build) nhằm tách biệt các phụ thuộc trong quá trình biên dịch khỏi các lớp thực thi cuối cùng, giữ cho số lượng tệp ở mức thấp trong các sản phẩm môi trường thực tế. Quản trị viên cụm cũng có thể truy vết phân bố inode trên các đường dẫn lưu trữ containerd bằng các truy vấn thư mục cô lập tệp.

Do các quy trình Kubelet tiêu chuẩn không chủ động dọn dẹp ảnh dựa trên mức sử dụng inode, các đội ngũ kỹ thuật có thể thiết lập các quy tắc cảnh báo tùy chỉnh trên Prometheus để phát hiện sớm những node vượt quá các ngưỡng như 80% dung lượng inode. Việc phát hiện sớm cho phép nhà vận hành dọn dẹp thủ công các ảnh không sử dụng bằng các tiện ích thực thi container trước khi node chạm ngưỡng 95% dẫn đến trục xuất pod của Kubelet.

Ảnh minh họa do AI tạo, không phải ảnh tư liệu.

Nguồn: Kubelet watches inodes. Just not until it’s an emergency.