为什么必须限制资源
容器默认没有任何资源限制。一个容器可以申请全部内存,占满所有 CPU 核心。 内存泄漏的服务会吃光宿主机内存。死循环的进程会占满所有 CPU。结果是宿主机和其他容器一起变慢甚至崩溃。内存限制
--memory-swap 与 --memory 的关系:--memory-swap 减去 --memory 就是可用的 swap 大小。两者相等表示禁用 swap。
OOM Killer 行为
容器内存用超上限时,Linux 的 OOM Killer 会直接杀掉容器内的进程。容器退出码是 137。OOM 杀的是容器内存占用最大的进程。它不会提前警告,进程直接消失。排查「容器无故重启」时先查 OOM。
CPU 限制
验证限制生效
docker stats 输出里的 MEM USAGE / LIMIT 一列直接显示用量与上限的比例。
Compose 文件里的资源限制
deploy.resources 在 Swarm 模式下原生生效。普通 docker compose up 也会识别 limits。较旧的 Compose v2 写法是顶层 mem_limit 和 cpus。与 Kubernetes 的概念对照
Docker 的资源限制概念在 Kubernetes 里几乎一一对应。
理解 Docker 资源限制后,Kubernetes 的 requests 和 limits 只是同一思想的调度器版本。
blkio 与 IO 限制
磁盘 IO 也可以用--device-read-bps、--device-write-bps 等参数限速。这类 blkio 参数在日志爆炸或备份任务场景下有用,日常用得少,知道存在即可。
延伸阅读
- Docker 容器:容器运行参数总览
- Docker 日志与监控:持续观测资源使用情况
- Docker 生产实践:生产环境的完整配置清单
- Kubernetes 调度与资源:requests 与 limits 深入讲解