Building-permits VMs have tiny root disks; after join, kubelet is expected to hit DiskPressure quickly. What should platform ops correct before install?
Select an answer to reveal the explanation.
Short Explanation
A closet-sized disk fills up the moment images and logs move in. Size node disks for image layers, kubelet state, and logs before joining. etcd is not an image registry, and silencing eviction just hides the fire.
Full Explanation
Building-permits VMs with tiny root disks will hit kubelet DiskPressure quickly after join because image layers, container runtime data, and logs consume local disk. Platform ops must provide adequate local disk for container images, logs, and kubelet data on each node before install—sizing the closet before moving the filing cabinets in. Capacity planning for those paths is part of civic infrastructure prep, not an afterthought once eviction storms begin. Setting every imagePullPolicy to Never does not remove the need for space when images must exist locally to run, and it breaks pulls for missing layers. Storing all container images inside etcd to spare the root filesystem misunderstands etcd’s role as the API datastore, not an image registry. Disabling kubelet eviction so DiskPressure never appears only hides the fire; workloads still fail when the disk is full. Exam caveat: DiskPressure and eviction are symptoms of undersized node storage—fix capacity rather than silencing signals. Operational check: size root or dedicated container filesystem to the image catalog plus headroom, monitor df on kubelet/containerd paths, join nodes, and confirm no early DiskPressure conditions under baseline permitting workloads.