iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Kubernetes kubelet does monitor inode availability on Linux, but its default inode thresholds are hard eviction thresholds—not the byte-based triggers used for image garbage collection. That means a node can run short of inodes while still showing plenty of free disk space, then reach kubelet’s inode threshold with no grace period. The exact behavior depends on Kubernetes version, kubelet configuration, filesystem layout and container runtime.
Why can a Kubernetes node run out of inodes while disk space remains?
Disk capacity has two separate limits: the number of bytes a filesystem can store and the number of files and directories it can represent. Each file or directory consumes an inode. A workload that creates many tiny files can exhaust available inodes before it fills the filesystem’s byte capacity.
The CNCF-published article describes an ext4 demonstration in which an image of 64 MiB containing 4,000 small files used 97.9% of its inodes but 32.6% of its blocks, leaving 84 inodes free. Those are figures from that demonstration, not a prediction for other filesystems or workloads. In the author’s account of a separate incident, containerd’s overlayfs snapshot store held inode-heavy content associated with repeated small-file dependency trees. The author reported 21,553 files in a dependency directory per snapshot and more than 40,000 files in the image, but noted that the cluster was no longer available to recheck the original captures. CNCF’s article presents these as a case study, not an independently verified or universal cause.
Free tools Windows power users keep installed
One-click scans. No signup required.
What does kubelet monitor, and what triggers cleanup?
Kubernetes v1.37 node-pressure documentation lists separate default hard thresholds for inodes and bytes on Linux. A hard eviction threshold has no grace period: once its condition is met, kubelet can respond without waiting through a grace period. The documented defaults are:
#1 Best Overall
| Signal | Default hard threshold | What it measures |
|---|---|---|
nodefs.inodesFree |
Below 5% | Free inodes on the filesystem kubelet identifies as nodefs |
imagefs.inodesFree |
Below 5% | Free inodes on the filesystem kubelet identifies as imagefs |
nodefs.available |
Below 10% | Available bytes on nodefs |
imagefs.available |
Below 15% | Available bytes on imagefs |
These are defaults in the Kubernetes v1.37 node-pressure eviction documentation, accessed in 2026; administrators can override them. The inode signals are Linux-only in that documentation. nodefs.inodesFree is derived from node.stats.fs.inodesFree; imagefs.inodesFree uses node.stats.runtime.imagefs.inodesFree.
Image garbage collection is a different mechanism. The CNCF article describes kubelet image-GC defaults of 85% high and 80% low thresholds, based on byte use; verify those values against the Kubernetes release and configuration in use. Image GC does not become an inode cleanup policy simply because images contain many files. As the article puts it, “Both of those are percentages of bytes. Image GC never looks at file counts.”
What happens when a threshold is crossed?
Kubernetes documentation says kubelet evaluates eviction thresholds at a default housekeeping interval of 10 seconds. This is the documented default for v1.37, and may be configured differently. When a pressure signal is detected, kubelet first attempts applicable node-level reclamation; if that does not bring the signal below its threshold, it begins evicting pods.
- For nodefs or containerfs pressure, reclamation can include garbage-collecting dead pods and containers.
- For imagefs pressure, kubelet can delete unused images.
- For inode or PID starvation, relative pod priority is used to determine eviction order because pods do not have requests for those resources.
The particular reclamation path depends on how the node’s filesystems are laid out. Also, if any eviction-hard parameter is customized, the other defaults are not automatically inherited unless MergeDefaultEvictionSettings is enabled. Check the complete effective configuration rather than assuming unchanged settings retain their defaults.
Rank #3
What do nodefs, imagefs and containerfs mean?
These are kubelet-observed filesystem identifiers, not a promise that a node has three separate mount points. Depending on the supported runtime and storage layout, a node may keep everything on nodefs; separate the runtime’s image and writable layers onto another filesystem; or use an arrangement in which images, writable layers and local ephemeral data map to different observed filesystems.
The current v1.37 documentation says containerfs use requires the KubeletSeparateDiskGC feature gate and identifies CRI-O v1.29 or later as the runtime with support for that release. Treat this as version-specific: verify the feature gate, runtime, and Kubernetes release on the actual node. The Kubernetes local ephemeral-storage documentation also cautions that usage may not be reported correctly when extra filesystems are mounted under paths such as /var/lib/kubelet, /var/log, or runtime storage outside supported layouts. A tmpfs-backed emptyDir is tracked as memory use, not local ephemeral storage.
How to diagnose inode pressure on a node
- Check bytes and inodes independently. On the affected host, run
df -h /anddf -i /as an initial check. Then identify the actual filesystem and mount under pressure; root is not necessarily the relevant mount. - Find directories with many files. For example,
du --inodes -xS /var/lib/containerd | sort -rh | head -n 20can help locate inode-heavy directories. Here-xkeeps the scan on one filesystem and-Savoids summing descendants into parent-directory totals. Check that the host’sduimplementation supports these options, and adjust the path to the runtime and mount in use. - Map the result to kubelet’s filesystem view. Establish whether the affected mount corresponds to nodefs, imagefs or a supported containerfs layout. Do not infer the mapping from a directory name alone.
- If image snapshots dominate, inspect image contents and build layers. Review whether source trees or development dependencies are copied into runtime images, whether dependency installs are repeated across layers, and whether
.dockerignore, build caching or a multi-stage build can avoid carrying unnecessary small files into the final image. The CNCF article proposes these as mitigations; it does not report a measured before-and-after result. - Use cleanup commands cautiously. The article notes that
crictl rmi --pruneremoves images not currently used by containers, which may need to be downloaded again. It also warns that removing stopped containers can remove access to their prior logs. Validate command behavior against the installed runtime and operational requirements before acting.
How should inode pressure be monitored before eviction?
Alert on inode consumption separately from byte consumption. A node can have low byte use and high inode use, so a byte-only dashboard or alert can miss the approach to inode exhaustion. The CNCF article gives 80% inode use as an example alert threshold, but explicitly treats it as a judgment call—not a Kubernetes default. Choose a threshold that leaves enough response time for the workload and the team’s recovery process.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWhere Prometheus metrics are available, compare inode-use percentage with byte-use percentage for the same filesystem, and confirm that metric labels identify the mount you intend to monitor. Do not assume that a metric for one path represents every runtime or kubelet storage filesystem. For the definitive signals, thresholds and configuration caveats, consult the node-pressure eviction documentation alongside the ephemeral-storage documentation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
