Docker容器停止行为差异：docker stop与drain模式问题排查

这是个很细节且实用的观察，我来拆解一下Docker Swarm在这两种场景下的核心行为差异——问题的根源在于容器终止的触发逻辑、调度器的响应时机，以及资源释放的节奏不同。

一、docker stop <container-id>：即时触发的调度响应 #

当你在节点上手动执行docker stop时：

• Docker直接向目标容器发送SIGTERM信号（默认10秒后强制发送SIGKILL），容器进程会立刻进入终止流程。
• Swarm调度器会实时监测容器状态，一旦发现该容器脱离了running状态，会立刻对比服务的期望副本数——因为期望数还没满足，调度器会瞬间在其他可用节点上调度启动新的副本。
• 这个过程没有额外的状态同步延迟，旧容器的资源（端口、挂载卷等）也会快速释放，所以新容器一次就能启动成功。

二、drain节点/约束变更：有序终止+状态同步延迟 #

当你执行docker service update --availability drain <node>或者修改服务约束时，Swarm的处理逻辑要复杂得多：

1. 先更新调度规则：调度器首先标记目标节点不可用，或者更新服务的约束条件，这个规则的全局同步需要一点时间。
2. 有序终止容器：Swarm会对目标节点上的服务容器发起终止请求，但这个过程是批量且有序的——它会确保容器按一定节奏终止，避免瞬间的资源波动，而不是像docker stop那样立刻强制终止。
3. 调度器的启动时机限制：调度器不会立刻启动新副本，它需要等待旧容器完全进入exited状态，并且全局状态同步完成后，才会发起新的调度。如果这个同步过程有延迟，或者旧容器的资源（比如端口、锁文件）还没完全释放，第一次启动尝试就会失败（比如端口被旧容器残留的进程占用）。
4. 重试机制触发第二次启动：当第一次启动失败后，Swarm的重试机制会检测到副本数未满足，才会发起第二次启动尝试——此时旧容器已经完全释放资源，规则同步也完成了，所以第二次就能成功。

三、验证与解决方向 #

如果你想进一步定位问题，可以试试这些方法：

• 查看服务的启动日志：执行docker service logs <service-name>，看第一次启动失败的具体原因（比如端口占用、依赖资源未就绪）。
• 配置健康检查：给服务添加--healthcheck参数，让调度器能更精准地判断容器的存活状态，减少误判导致的重试。
• 跟踪Swarm事件：实时查看docker system events，你能清晰看到旧容器终止、新容器启动的时间线，以及两次启动之间的状态变化。

内容的提问来源于stack exchange，提问作者Yannic Bürgmann