容器存储配额是启动时设定的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 空间上限（不含镜像层）。

Docker Encyclopedia

Docker 文档优先工作流：针对 Docker 特定问题、故障排除、命令规划、镜像/构建、容器/运行时操作及 Compose 等

下载

• 编辑 /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 -- df -h / 查看实际生效容量

无法热扩容的注意事项

容器 Rootfs 配额本质上是文件系统层面的限制，Docker 不提供类似 docker update 的运行时修改命令。

• 想调整已存在容器的存储上限？只能重建容器，并确保新命令含 --storage-opt 或宿主机已更新 daemon.json
• ext4 文件系统 + devicemapper 才支持 lvextend + resize2fs 手动扩容，但操作复杂且有风险，生产环境不推荐
• 真正需要弹性存储的业务，应改用 named volume 并单独管理其所在逻辑卷或 NFS 后端