K3s 嵌入式节点 containerd 镜像 GC 策略如何调优才能不伤 eMMC 写入寿命？

背景

我在做一批 ARM Cortex-A53（2C4G）的边缘网关，存储是 8GB eMMC（标称 50k P/E），上面跑 K3s v1.31 + containerd 1.7.x。业务镜像大概 180MB~350MB，每周有 2~3 次滚动更新（拉新镜像 → 建新 Pod → 删旧 Pod → 旧镜像变 unreferenced）。

现象

跑了两个月后，df -h 显示 overlay 分区从初始 1.2GB 涨到 3.8GB（总共就 8GB），其中大量是 unreferenced 的 overlay 层（ctr -n k8s.io images ls 能看到十几个旧版本镜像还占着空间）。用 mmc extcsd read 查 eMMC 的 erase count，已经过了 12k，按当前速率估算 18 个月就会到 P/E 寿命上限。

已尝试的排查

1. crictl rmi --prune——只清 unreferenced 镜像，但 overlayfs 的 lower diff 层文件不会立刻释放（要等 dentry 回收），手动 sync + echo 3 > /proc/sys/vm/drop_caches 后空间才回来，但这个过程有 3~5 秒的 IO 抖动，期间同节点上正在跑的容器偶发 200ms+ 延迟毛刺。
2. containerd config.toml 里设了 image_gc_high_threshold = "2GiB"、image_gc_low_threshold = "1GiB"，GC 确实会触发，但触发时是批量删 layer，IO 峰值很高（iostat -x 1 看到 eMMC 的 %util 打到 95%+），对业务容器影响明显。
3. 试过把 image store 放到单独的 tmpfs 分区（4GB），短期能撑，但重启就丢；而且 tmpfs 吃 RAM，4GB 机器上分 1GB 给 tmpfs 之后业务可用内存只剩 3GB，不太现实。
4. 想过用 ctr -n k8s.io content 手动清 blob，但没找到安全的操作顺序，怕清了正在被容器引用的层导致运行时崩溃。

期望得到的答案形态

• 有没有一种方式能让 containerd 的镜像 GC 变成"低优先级、限速、小批量"的后台行为，而不是 burst 式一次性清理？（比如 containerd 本身有没有限速参数？或者外部 cron + nice/ionice 限速脚本？）
• 在 eMMC 这种写入寿命有限的介质上，有没有人踩过这个坑？你们的实际做法是什么？（比如：限制镜像更新频率、用 A/B 分区只保留两个版本、换 F2FS + 压缩、或者干脆用 stargz/nydus 这类 lazy-pull snapshotter 减少落盘？）
• 如果你们在类似资源受限节点（≤4GB RAM、≤16GB 存储）上跑 K3s，镜像存储这块的容量规划和 GC 策略是怎么定的？有没有一个"够用的最小配置"可以分享？