容器存储配额是启动时设定的Rootfs空间上限，不可运行时动态调整，需依存储驱动配置：devicemapper用--storage-opt dm.basesize，overlay2通过daemon.json设overlay2.size，Kubernetes中则依赖节点级预设与Pod资源请求间接管控。
容器存储配额不能像内存、CPU那样在运行时动态调整，它属于启动时设定的底层存储参数，需结合存储驱动类型和宿主机环境来配置。关键在于明确“配额”指的是容器根文件系统（Rootfs）的空间上限，而非挂载卷（volume）或绑定挂载（bind mount）。
使用 --storage-opt 设置单个容器的 basesize
适用于 devicemapper 存储驱动（已逐步弃用，但部分旧环境仍在用）。该参数决定每个容器初始 rootfs 大小，也是其可增长的硬上限。
- 启动新容器时直接指定：
docker run --storage-opt dm.basesize=20G -d ubuntu:22.04 - 注意：
dm.basesize仅对 devicemapper 有效；overlay2 不支持此参数 - 该值必须小于底层 thinpool 总容量，否则容器无法启动
通过 daemon.json 全局配置 overlay2.size
适用于主流的 overlay2 驱动。此配置影响所有新建容器的默认 upperdir+workdir 空间上限（不含镜像层）。
- 编辑
/etc/docker/daemon.json，添加：{"storage-driver": "overlay2", "storage-opts": ["overlay2.size=30G"]} - 重启 Docker 服务：
sudo systemctl restart docker - 新创建的容器将按此值限制可写层大小；已有容器不受影响
- 该设置不改变镜像层占用空间，只约束容器运行时产生的数据
在 Kubernetes 中控制 Pod 容器存储配额
云原生场景下，通常通过节点级配置 + Pod 资源请求间接管理容器存储压力。
- CCE 或类似平台中，在节点重置时设置“Pod 容器空间分配”（即 basesize），例如设为 15G
- 该值会作用于该节点上所有 Pod 的容器 Rootfs，默认路径如
/var/lib/docker/overlay2/... - 建议不超过节点数据盘可用空间的 80%，避免因磁盘满导致调度失败或 OOM
- 可通过
kubectl exec -it <pod> -- df -h /</pod>查看实际生效容量
无法热扩容的注意事项
容器 Rootfs 配额本质上是文件系统层面的限制，Docker 不提供类似 docker update 的运行时修改命令。
- 想调整已存在容器的存储上限？只能重建容器，并确保新命令含
--storage-opt或宿主机已更新daemon.json - ext4 文件系统 + devicemapper 才支持
lvextend + resize2fs手动扩容，但操作复杂且有风险，生产环境不推荐 - 真正需要弹性存储的业务，应改用 named volume 并单独管理其所在逻辑卷或 NFS 后端
