daemon.json 是配置容器及 dockerd 资源限制的核心入口，需区分容器默认限制（如 default-ulimits）、dockerd 自身 systemd 限制（MemoryLimit、TasksMax 等）、日志与镜像并发管控三类策略协同生效。
daemon.json 本身不提供“资源限制策略”的一键开关，但它是配置容器级和守护进程级资源约束的核心入口。关键在于区分两类限制：一类是影响所有新建容器的默认值（如内存、cpu、进程数），另一类是约束 dockerd 自身运行资源（需配合 systemd）。配置得当，能有效防止单个容器或大量容器拖垮宿主机。
设置容器默认资源上限
通过 default-ulimits 和 default-runtime 相关参数，可为每个新创建的容器设定基础资源边界：
- 限制每个容器最多 512 个进程（含线程）：
"default-ulimits": { "pids": { "Name": "pids", "Hard": 512, "Soft": 512 } } - 限制单个容器打开文件数上限为 65536：
"default-ulimits": { "nofile": { "Name": "nofile", "Hard": 65536, "Soft": 65536 } } - 若使用 runc 运行时并启用实验特性，还可设 memory-reservation 和 cpu-reservation（单位分别为字节和核数），为系统保留基础资源，避免被容器完全抢占。
统一启用安全基线（间接实现资源防护）
部分安全配置虽不直接标为“资源限制”，却能显著降低异常行为引发的资源耗尽风险：
- 关闭容器间默认互通：
"icc": false —— 防止横向扫描或恶意容器发起大量连接打爆网络栈 - 加载最小化 seccomp profile：
"seccomp-profile": "/etc/docker/seccomp-default.json" —— 屏蔽 fork、clone 等高危调用，从源头抑制进程爆炸 - 显式裁剪 capabilities：
结合 default-runtime 或启动时 --cap-drop，禁用 CAP_SYS_ADMIN、CAP_NET_RAW 等非必要权限，减少内核态资源滥用可能
配合 systemd 约束 dockerd 自身
仅靠 daemon.json 不足以保护宿主机——如果 dockerd 进程自身因并发构建、镜像拉取失控，照样会吃光内存或触发 OOM。必须用 systemd 施加硬限：
- 在 /etc/systemd/system/docker.service.d/override.conf 中添加：
[Service]
MemoryLimit=2G
CPUQuota=80%
TasksMax=4096 - 其中 TasksMax 尤其重要，它限制 dockerd 能创建的总任务数（进程+线程），是防 fork 爆炸的最后一道闸门
- 配置后务必执行 sudo systemctl daemon-reload && sudo systemctl restart docker
日志与镜像层资源管控
日志和镜像缓存常被忽略，却是磁盘耗尽的主因：
- 全局限制容器日志大小与数量：
"log-driver": "json-file",
"log-opts": { "max-size": "50m", "max-file": "3" } - 控制镜像构建并发数，降低临时资源峰值：
"max-concurrent-downloads": 5,
"max-concurrent-uploads": 3,
"max-concurrent-sched": 20 —— 这些参数直接限制后台任务并发量 - 指定存储驱动优化（如 overlay2）并设 storage-opts，防止镜像层无序增长
