除CPU与内存外Docker还有哪些资源限制？多容器同启失败排查

这种“单容器运行正常，同时启动两个就失败”的场景，我碰到过好几次，大概率不是CPU/内存资源不足导致的，更可能是容器间的资源冲突或者镜像内服务的单实例限制，给你梳理几个核心排查方向：

1. 先查端口冲突 #

很多容器镜像会默认绑定固定端口（比如SSH的22、Web服务的80/443），如果启动vm1时用了-p 宿主机端口:容器端口映射了某个端口，启动vm2时没修改映射端口，就会因为端口被占用而启动失败。

• 用docker ps查看vm1的端口映射情况，确认有没有重复的端口占用
• 如果是端口冲突，启动vm2时指定不同的宿主机端口，比如：docker run -d -p 8081:80 --name vm2 你的镜像名

2. 检查容器名称与网络配置 #

• 容器名称冲突：Docker不允许同时运行两个同名容器，如果你的启动命令里给两个容器都指定了同一个名称，肯定会失败。启动vm2时记得用--name vm2明确指定唯一名称，或者去掉--name参数让Docker自动生成名称。
• 静态IP冲突：如果两个容器都加入了同一个自定义Docker网络，并且手动指定了相同的静态IP，也会启动失败。用docker network inspect 你的网络名查看已分配的IP，给vm2设置不同的静态IP：docker run -d --network 你的网络名 --ip 172.18.0.3 --name vm2 你的镜像名

3. 查看容器启动日志找线索 #

不管是什么问题，容器启动失败的日志都是最直接的排查依据，赶紧看看vm2的启动日志：

docker logs vm2

如果日志里出现“address already in use”“could not lock file”“IPC resource exists”这类提示，就能直接定位到具体的冲突点（比如端口、文件锁、IPC资源）。

4. 检查Docker Daemon的全局限制 #

虽然你说系统剩余资源充足，但可以检查下Docker daemon的全局配置有没有隐藏的限制：

• 查看/etc/docker/daemon.json文件，有没有设置default-ulimits、cpu-shares或者memory相关的全局限制，可能单个容器没触发，但两个容器加起来就触发了阈值。
• 尝试重启Docker daemon：sudo systemctl restart docker，有时候daemon的临时状态异常也会导致这种奇怪的启动失败问题。

内容的提问来源于stack exchange，提问作者Daniel YC Lin