How do you monitor container disk usage without an ephemeral storage limit?

November 15, 2026 4 answers
Asked by 4e!tramspindle_826

We have Windows AKS pods using containerd, with no ephemeral-storage requests or limits. The fsUsedBytes metric shows host-side container usage, while fsCapacityBytes appears to report node capacity rather than a container ceiling.

Is there a meaningful percentage to alert on without a limit, or should we monitor usage and node disk pressure separately?

Answers

r.437+foldmarker

Without a configured limit, there isn't a meaningful container percent used. The available space is shared with other workloads and node activity, so dividing node capacity by the number of pods would be an arbitrary budget, not a real ceiling.

For node protection, monitor available space on the relevant node filesystems against the kubelet eviction thresholds. For a runaway container, alert on its absolute usage or growth rate. Those are different questions and need different alerts.

4e!tramspindle_826:

The immediate concern is pods becoming unresponsive and restarting when disk space fills up, so the node pressure alert sounds particularly relevant.

Reply to this answer
Mireva-6p

If you want a percentage against a defined workload budget, consider setting an ephemeral-storage limit and comparing usage with that limit. A LimitRange can provide a default for containers that don't specify one.

Check how ephemeral-storage accounting and enforcement work for your Windows AKS configuration before relying on that percentage or expecting a limit to trigger eviction. A configured limit also won't replace monitoring the shared node disk.

Reply to this answer
_s71!parcelmortar.6

For troubleshooting, check the kubelet summary metrics if they're available in your setup. Container rootfs.usedBytes and logs.usedBytes can help separate writable layer growth from log growth. That's more actionable than a single percentage when you're trying to find what is filling the disk.

Also keep the measurement boundaries straight. A filesystem reading inside the container is not necessarily the same as its host-side scratch layer plus stdout and stderr logs.

8e!claspnotebook_615:

Metric availability and accounting can vary by runtime and platform, so it's worth checking that those fields are actually populated for the Windows nodes.

Reply to this answer
Veslin-6q

A practical starting point is an alert on node filesystem availability with some margin above the configured eviction threshold, plus a separate alert for a sharp rise in container usage. Tune the growth threshold to normal workload behavior so routine bursts don't drown out the useful alerts.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions