k3s containerd image GC limits with frequent re-tagging and stale cache

k3s delegates image garbage collection to containerd, which by default prunes unused images on a fixed 10-minute interval across recent k3s releases. When images are re-tagged frequently, this default timing may create an upper bound on how long stale cache entries remain before removal. The default GC settings are fixed across k3s releases, though the timeout can be adjusted through containerd configuration.

Additional uncertainty exists around filesystem support: if a node's storage does not support overlay2 snapshot diffing, stale layers may persist even after an image is removed. k3s does not provide a built-in interface to inspect GC status, leaving operators to rely on external tooling to observe prune events.

Does the default 10-minute GC interval impose a hard limit on stale cache retention for frequently re-tagged images? Are there documented conditions where leftover layers survive garbage collection due to snapshotter or filesystem constraints? What is the supported way to confirm that stale layers have actually been pruned when no built-in k3s UI exists?