A parks worker node runs out of inodes after image sprawl even though df -h still shows free bytes. What problem should be investigated?
Select an answer to reveal the explanation.
Short Explanation
Free gigabytes with zero free inodes is a classic trap—too many tiny files or image layers used up the filename slots.
Full Explanation
When a parks worker node runs out of inodes after image sprawl even though df -h still shows free bytes, investigate disk or inode exhaustion from accumulated images and files preventing new file creation. Free gigabytes with zero free inodes is a classic trap—too many tiny files or image layers used up the filename slots, blocking Pod starts and triggering pressure symptoms on municipal nodes.
This is not insufficient Service ClusterIP addresses in the service CIDR. It is not a missing default StorageClass name in kube-public. It is not an RBAC Role missing get on Nodes in the parks namespace.
Exam caveat: use df -i as well as df -h. Prune unused images carefully; avoid deleting files needed by the runtime. DiskPressure may appear even when byte free looks acceptable.
Operational check: run df -i on the node, prune unused container images and orphaned files per platform policy, confirm free inodes return, and verify new parks Pods can create files again. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Prefer reversible steps and verify Ready or Bound state before closing the incident.