我们常聊 Swarm 管理节点、聊 Raft 共识、聊调度策略但真正让业务流量落地的是集群里默默干活的 Worker 节点。这个系列做到第 3 篇我把标题定为“Swarm Worker-补充”不是想重复官网上那些基础概念而是想把 Worker 在架构里被一笔带过的部分挖出来补完整——它如何接入网络、流量如何经过它转发、调度器按什么逻辑把任务塞给它、节点出问题时你又该怎么安全摘除和替换。这篇内容主要面向两类人一类是刚把 Swarm 集群搭起来、想搞明白 Worker 在整体架构里承担什么职责的初学者另一类是已经在生产环境维护 Swarm、正准备规划扩容或排查 Worker 故障的实操者。我会把 Worker 相关的配置命令、流量路径、调度原理、运维手法和踩坑经验都过一遍内容会偏工程实践同时尽量讲清楚背后的“为什么”因为很多问题排查到最后拼的就是你对这些机制的准确理解。1. 为什么架构里要单独划分出 Worker 这个角色1.1 Worker 与 Manager 的分工边界Swarm 集群里的节点默认分为两类角色Manager 和 Worker。Manager 负责集群状态管理、任务调度、API 入口以及维护 Raft 共识日志Worker 则只负责一件事——接收 Manager 下发的任务创建并运行对应的容器再把任务状态反馈回去。从 Docker 官方文档的表述来看Worker 节点参与的是 Swarm 的服务执行面它不参与 Raft 共识也不参与调度决策。但很多人会忽略一个细节Manager 节点本身也可以当作 Worker 来运行任务。默认情况下Manager 节点同样拥有可调度属性也就是说 Swarm 可以把服务副本调度到 Manager 上。只有当 Manager 的 Availability 被设置为 Drain 时它才会停止接收新任务。所以在实际生产环境里常见做法是让 Manager 只承担控制面职责把所有业务负载放在专用 Worker 节点上。这样做的本质是把控制平面和数据平面隔离开避免业务容器占用管理节点资源后影响集群调度和状态同步的稳定性。这个设计和 Kubernetes 里控制面与数据面分离的思路很像只是 Swarm 的实现更轻量它没有像 kubelet 那样复杂的组件分层而是通过 Engine 内置的 Swarm 模块来区分角色。对于中小规模的集群这种内聚设计反而带来了部署简单的优势——不需要额外安装 Agent也不需要独立部署控制面组件一条docker swarm init就能把管理面拉起来。1.2 单独划分 Worker 的三个实际收益第一个收益是故障域的隔离。如果把一批节点设为 WorkerManager 节点出现故障时Worker 上运行的服务不会因为控制面短暂不可用而自动停止。任务执行是独立的容器生命周期由本地 Docker Engine 管理Manager 挂了只会导致新的调度决策暂时无法下发存量业务不会立刻中断。第二个收益是资源规划的边界清晰。把 Worker 与管理节点分开可以针对性地做资源预留。例如给 Manager 节点预留足够的 CPU 和内存来支撑 API 请求、Raft 心跳和调度计算给 Worker 节点则按业务容器的资源需求做规格选型。没有角色划分的集群容器混部很容易导致管理面资源被业务挤占造成调度变慢、心跳超时甚至集群脑裂的一系列连锁反应。第三个收益是维护操作更安全。当你需要对 Worker 做内核升级、硬件更换、网络维护时可以先把节点置为 Drain 并驱逐任务再执行操作。而 Manager 节点数量本身就受 Raft 奇数规则约束维护窗口和风险控制比 Worker 复杂得多。角色分离以后你可以在最小化控制面影响的前提下灵活调整业务承载面的规模。1.3 角色变更的灵活性与边界Swarm 支持节点角色动态调整你可以用docker node promote把一个 Worker 提升为 Manager也可以用docker node demote把 Manager 降级为 Worker。这个灵活性很实用比如你临时需要一个高可用管理面就可以把某个备用 Worker 提升上来反过来某个老旧的 Manager 需要退役也可以先降级再安全移除。但角色变更不是无代价的。Manager 数量的变化会直接影响 Raft 共识的安全阈值。Swarm 使用 Raft 协议保证集群状态一致存活 Manager 必须超过半数才能正常作出决策。一个 Worker 被提升为 Manager 后它就开始参与日志复制和选举投票这意味着集群里任何一次 Manager 节点的变更都需要你重新计算可用容错数。比如原来 3 个 Manager 最多允许挂 1 个变成 5 个 Manager 后允许挂 2 个这个变化会直接影响故障转移的容错空间。2. Worker 侧的网络模型与业务流量走向2.1 Overlay 网络与 VXLAN 数据面的关系Swarm 模式下创建 Overlay 网络本质上是为跨节点的容器通信搭建了一张虚拟二层网络。这张网络默认基于 VXLAN 技术实现数据包会被封装在 UDP 报文里通过宿主机的物理网络传输。Worker 节点在这张网络里承担的角色是 VXLAN 的 VTEP 端点之一每个 Worker 都会为 Overlay 网络维护一个本地的转发平面。很多朋友看 Overlay 网络觉得抽象我用一个生活化的类比来解释可以把网络数据报看作是快递包裹容器是包裹的收寄人Worker 节点是小区里的快递驿站。不同节点上的容器要通信快递先发到各自小区的驿站驿站负责把包裹按小区编号重新封装再通过城市主干道送到对方小区驿站最后由驿站转交给收件人。VXLAN 在这里就是那套跨小区封装的规则VTEP 就是驿站的处理柜台每个 Worker 上的 Overlay 网络都会创建对应的虚拟网卡接口通常是 docker_gwbridge 之外的另一个 bridge 域。创建 Overlay 网络时Swarm 会在所有 Worker 节点上同步网络定义但只有在节点上有容器接入该网络时才会真正创建对应的网络命名空间和端口。这也是为什么你在一台新建 Worker 上执行docker network ls时看不到集群里某个 Overlay 网络——直到有任务被调度到这台节点上网络接口才会初始化。2.2 Ingress Routing Mesh 在 Worker 上的流转过程Swarm 的 Routing Mesh路由网格是容易被误解的机制之一。我遇到过不少同事以为服务端口只在运行实例的节点上暴露实际上 Swarm 的做法是当创建一个发布端口Publish Port的服务时集群内所有 Worker 和 Manager 节点都会监听这个端口无论该节点上是否跑着对应服务的容器。流量到达任意一个 Worker 节点后会先经过宿主机的 iptables DNAT 规则把目标地址从宿主机 IP 和发布端口改写为服务对应的 VIP 和内部服务端口。这个 VIP 是 Swarm 为每个服务分配的虚拟 IP通过内核 IPVS 规则在所有节点上做负载均衡最终把请求转发到某个具体的容器副本所在节点的 VIP 地址。也就是说Worker 不仅运行容器还承担了服务入口负载均衡器的角色。这里有个实际案例假设你有一个全局模式的监控服务副本数为 3但集群里有 5 个 Worker。外部请求只要打到其中任意一个 Worker 的 8080 端口都会被 Routing Mesh 转发到这个服务在集群内部的某个 VIP 上再由 IPVS 挑选一个健康的容器副本处理。哪怕目标副本不在当前节点数据包也会通过 Overlay 网络跨节点转发过去。所以你在任意节点上执行ss -lntp都能看到服务发布端口的监听状态。2.3 端口规划与三个常见问题端口规划直接决定 Worker 之间数据面是否稳定。Swarm 集群需要开放的端口主要包括TCP 2377 用于集群管理指令TCP/UDP 7946 用于节点间通信UDP 4789 用于 VXLAN Overlay 网络。Worker 节点理论上只需要开放 7946 和 4789但在实际部署中我建议把 2377 也放通因为 Worker 也会作为 API 请求的转发目标而且你可能随时需要执行docker node promote把 Worker 提升为 Manager到时再开端口反而容易出现配置遗漏。常见问题有三个第一个是防火墙只放行了 TCP 端口漏了 UDP 4789。Overlay 网络的 VXLAN 封装依赖 UDP 通信漏掉就会导致跨节点容器网络不通但单节点内部容器通信正常。排查时非常容易误判为业务问题实际上就是宿主机间数据面断了。第二个问题是同一集群节点间时钟偏差过大。VXLAN 封装本身不强制时钟同步但 Swarm 的证书机制和 Gossip 协议对时间敏感节点间时钟偏差会导致 TLS 证书校验失败和 gossip 信息不同步。生产环境里我会要求所有 Worker 统一走同一套时间同步源偏差控制在 1 秒以内。第三个问题是服务发布端口与宿主机其它服务端口冲突。Swarm 在创建服务时如果发现端口冲突会报错并拒绝创建但如果你修改了宿主机上已有服务的监听端口Swarm 不会实时感知。结果就是请求被宿主机本地的其它进程截获表现为服务间歇性不可达。遇到这类问题优先检查节点上有没有非 Docker 进程占用了相同的监听端口。3. 调度器如何挑选 Worker 并部署任务3.1 调度决策链路当我们执行docker service create --replicas 3 --name demo nginx:latest时命令会先打到 Manager 节点Manager 把服务定义写入 Raft 日志然后由内置调度器为每个副本选择目标节点。调度器的决策依据主要有三类节点可用性、资源满足度、约束条件。节点可用性由节点的 Availability 状态决定。Active 状态的节点可以接收新任务Pause 状态的节点不会接收新任务但已有任务继续运行Drain 状态的节点既不会接收新任务还会把已有任务逐渐迁移到其它可用节点上。这个状态设计非常实用尤其做节点维护时可以先把 Availability 改为 Drain让 Swarm 帮忙做优雅驱逐而不是直接强制停止节点上的容器。资源满足度是指 Swarm 在调度时会参考容器声明的 CPU、内存预留Reserve和最大限制Limit。这一点和 Docker Compose 里的资源限制写法很相似但在 Swarm 里如果没有显式声明调度器会认为容器没有资源请求因此可能把大量副本塞到同一台 Worker 上造成实际运行时资源争抢。约束条件则包括节点标签Node Label、服务角色Role、节点 ID 等。你可以通过docker node update --label-add给 Worker 打标签然后在服务创建时用--constraint限制副本必须落在带有某个标签的节点上。这是 Swarm 里实现亲和性部署最直接的手段。3.2 一个实际调度例子的完整拆解我在运维一个多可用区业务时会通过节点标签把 Worker 按区域划分。假设有 6 台 Worker3 台标记zonea3 台标记zoneb部署服务时执行docker service create \ --name web \ --replicas 6 \ --constraint node.labels.zone a \ --constraint node.labels.usage web \ --publish published8080,target80 \ nginx:latest这条命令把 6 个副本全部约束到 zonea 且 usageweb 的节点上。不加资源声明时调度器会尽可能把副本分散到不同节点也就是所谓的 Spread 策略。这个策略默认存在目的是提高容错性如果一个节点宕机只有该节点上的副本受影响不会引起多个副本同时丢失。但你要明白Swarm 的调度器不是强分布式的。它的过滤和优选过程在 Manager 端完成Manager 会把节点按照资源余量和当前副本分布排序然后逐个为副本挑选目标节点。实际运维中我见过一种情况执行 scale 扩容后新副本几乎全部堆在同一台 Worker 上原因是这台 Worker 的资源剩余量显著高于其他节点并且之前没有声明资源请求。这个问题不是 Swarm 的 bug而是资源声明缺失导致调度器认为它的“容量”无限大。3.3 Worker 节点的资源宣告与监控指标让 Worker 的资源被调度器准确感知最直接的手段是在服务定义里写清楚--reserve-memory和--reserve-cpu。例如docker service create \ --name api \ --replicas 4 \ --reserve-memory 256m \ --reserve-cpu 0.25 \ --limit-memory 512m \ --limit-cpu 0.5 \ your-registry.api:latest这里--reserve-memory告诉调度器容器最少需要 256MB 内存--limit-memory表示运行时最多使用 512MB。调度器在排布副本时会基于节点总资源减去已保留资源得到剩余资源然后判断能否容纳新的保留值。注意保留值和限制值不等同于 cgroup 的 quota它更多影响的是调度决策而限制值会被转换为容器运行时的资源约束。所以生产环境里我会同时设置这两个参数既能合理分布副本又能防止某个容器把 Worker 节点的内存耗尽。另外我建议在每个 Worker 上起一个轻量级的系统监控容器采集 CPU、内存、磁盘吞吐、网络带宽和句柄数。Swarm 本身自带docker node ls和docker service ps但这些都是集群状态层面的视图看不到节点内核级指标。把监控维度分开Swarm 看任务分布和健康状态外部监控看节点资源水位。排查问题时两套数据互相印证会快很多。4. Worker 节点维护与扩缩容实践4.1 把新 Worker 接入集群的正确流程新 Worker 接入 Swarm 集群的标准动作非常简单在 Manager 上执行docker swarm join-token worker获取加入命令然后在 Worker 节点上执行docker swarm join。看起来一行命令就能搞定但我建议在做生产级扩容时加上几个前置检查。先确认新 Worker 的 Docker 版本与集群内现有节点保持一致。Swarm 模式对版本差异容忍度有限尤其是跨大版本的节点可能会出现节点间 TLS 握手失败或 Raft 日志同步异常。我的习惯是先在测试环境验证版本兼容性再上线生产集群。再检查防火墙和端口。前面提过 2377/7946/4789 三条链路都要通另外还要确保 Worker 能访问到 Manager 的 API 端口。如果 Manager 配置了 TLS 证书认证还要检查 Worker 加入时使用的 Token 是否有效。Token 有默认有效期过期后需要重新获取。执行加入命令后在 Manager 上通过docker node ls确认节点状态。这里要注意 STATUS 显示为 Ready 只代表节点与 Manager 的通信正常真正影响调度的是 AVAILABILITY 列。新加入的 Worker 默认 Availability 是 Active可以立即接收任务。如果想先观察节点状态再让它承载业务可以先用docker node update --availability drain把该节点置为不可调度等确认一切正常后再恢复 Active。4.2 摘除、晋升与驱逐的实操姿势维护 Worker 节点时最安全的操作路径是先标记为不可调度、再等待任务迁移完成、然后下线节点。具体命令如下# 在 Manager 上执行 docker node update --availability drain worker-01执行后Swarm 调度器会将该节点上所有任务重新调度到其它 Active 节点。对于有状态服务这个过程会先触发旧任务停止、再在新节点启动新任务中间存在短暂停机窗口。如果你希望尽量缩短中断时间可以在服务创建时增加--update-order start-first让新副本先启动并健康检查通过后再停止旧副本。这个参数在 Worker 下线维护时特别有用。节点上的任务全部迁移完成后可以在 Worker 本机执行docker swarm leave也可以直接在 Manager 上执行docker node rm --force。我通常会先在 Worker 上调用docker swarm leave再在 Manager 上删除节点记录这样可以避免 Manager 端残留过期的节点状态。把 Worker 晋升为 Manager 的操作是docker node promote worker-01晋升后需要留意该节点是否已经更新了防火墙规则。Worker 原本不要求开放 2377 端口晋升后它要参与 Raft 通信如果 2377 被防火墙拦截会导致 Manager 之间无法正常同步严重情况下会触发新的选举。所以你在做角色晋升前一定要确保所有计划成为 Manager 的节点都放通了完整的集群通信端口。4.3 批量替换 Worker 的操作顺序生产环境里常常会遇到机房整批替换硬件的情况。假设你有 6 台旧 Worker 需要替换为 6 台新 Worker最优的做法不是一台一台直接删掉旧的再建新的而是先把新节点全部加入集群再逐步对旧节点做 Drain 和删除。我建议整个替换流程分为三个阶段第一阶段新节点加入后先不打业务标签保持 Active 但通过约束条件让它们暂时不承载流量。例如服务都带node.labels.usage legacy的约束新节点默认不带这个标签就不会被调度。第二阶段把新节点的标签补成和旧节点一致然后对第一台旧 Worker 执行docker node update --availability drain观察任务是否平滑迁移到新节点上。确认集群心跳、服务健康、网络吞吐都正常后再继续处理下一台旧节点。第三阶段所有旧节点任务清空后在 Manager 上执行docker node rm移除旧节点记录再在旧节点本机执行docker system prune -a清理残留的容器和镜像。这样整个集群就完成了一次无感知的 Worker 批量替换并且任何一步出现异常都可以通过调整标签和 Availability 快速回滚。5. Worker 常见故障排查与避坑清单5.1 Worker 加入集群失败加入失败最常见的报错是Error response from daemon: rpc error: code 7 desc Permission denied或context deadline exceeded。前者多半是 Token 失效后者多半是网络不通。Token 失效的解决办法是重新生成加入 Tokendocker swarm join-token worker输出中会自带一条完整的docker swarm join命令复制到 Worker 上重新执行即可。需要提醒的是生成新 Token 不会让旧 Token 立即全部失效Docker 会同时保留新旧 Token 一段时间但生产环境为了安全建议在变更后执行docker swarm join-token --rotate worker让旧的 Token 作废。网络不通的排查则要先确认 Worker 到 Manager 的三条链路是否全部放通。可以用telnet或nc分别验证 2377、7946 和 4789 的连通性。我之前遇到过一种诡异情况2377 端口能通但节点始终加入失败后来发现是 Manager 节点上的 Docker 服务监听的是内网 IP而 Worker 解析 Manager 主机名时走了公网 DNS导致 TLS 证书里的 IP 地址不匹配。解决办法是在docker swarm join命令里显式指定 Manager 的内网 IP并在/etc/hosts里固定主机名解析。5.2 任务一直卡在 Preparing 或 Faileddocker service ps看到任务状态一直是Preparing说明镜像拉取出了问题。这种情况最常见的原因是 Worker 节点无法访问镜像仓库比如私有仓库未配置 TLS 信任、镜像地址写错、或者仓库服务临时不稳定。如果看到Failed状态则需要用docker service ps --no-trunc查看完整报错信息。千万不要直接看docker logs因为服务还没有成功启动容器本身并不存在日志可看。镜像拉取问题还有一个容易忽视的坑Worker 节点磁盘空间不足。镜像拉取会先落盘再解压如果根分区或者 Docker 数据目录所在分区空间不够拉取就会反复失败。排查时可以执行df -h查看磁盘使用率以及docker system df查看镜像和容器的空间占用。任务卡在Preparing还可能和工作目录权限有关。如果你用了 bind mount 类型的卷需要确保 Worker 节点上对应的宿主机目录存在且权限正确。Swarm 不会帮你自动创建宿主机目录目录不存在时容器启动会直接报错。5.3 证书轮换与节点重启后的 Bug 排查Swarm 节点之间的通信使用内置的 TLS 证书默认有效期是 90 天。距离过期时间不足 30 天时节点的证书轮换是自动完成的。你可以通过docker system info查看Swarm: NodeID、Is Manager、ClusterID等状态里的证书信息也可以直接去/var/lib/docker/swarm/certificates/目录看一下证书文件的时间戳。如果证书轮换失败常见表现是某台 Worker 在docker node ls里显示Unknown或者Down但节点的 Docker 进程看起来是正常的。处理方法是在 Worker 节点上重启 Docker 服务让它重新拉取证书systemctl restart docker如果重启后依然无法恢复可以试试强制重新加入集群。做法是先docker swarm leave --force再重新获取 Token 加入。要注意的是这个操作会丢弃这台节点曾经运行过的所有服务任务状态所以操作前一定要确认该节点上的服务已经通过其它节点完成副本冗余。5.4 常见问题速查表症状可能原因快速排查命令解决方向Worker 无法加入Token 过期 / 端口不通docker swarm join-token worker重新获取 Token检查 2377/7946/4789任务反复 Failed镜像拉取失败 / 磁盘满docker service ps --no-trunc检查仓库连通性清理磁盘空间节点 Down证书过期 / 网络抖动docker node ls重启 Docker或强制重新加入Overlay 网络不通UDP 4789 未放行iptables -L开放 UDP 4789检查 VXLAN 端口服务访问间歇失败端口冲突 / 本地进程占用ss -lntp确认宿主机端口占用并调整发布端口副本集中在某节点缺少资源声明docker service inspect增加 reserve 参数并重建服务这张表是排查问题的第一道抓手。实际排障时我通常先用docker service ps和docker node ls把集群状态看一遍再结合对应节点的journalctl -u docker定位具体错误。大多数问题并不会同时爆发锁定状态异常的节点和服务排查范围就能缩小很多。6. 给新手的额外忠告与我的运维体会我在实际维护 Swarm 集群的过程中最深刻的感受是Worker 节点永远不会成为集群里最亮眼的角色但它恰恰是决定业务稳定性的底座。调度器再聪明控制面再高可用Worker 节点资源规划不合理、网络链路配置错误业务照样会出问题。第一个忠告是千万不要在一台 Worker 上塞满所有副本。虽然 Swarm 的 Spread 策略默认会分散副本但你如果手动指定了--constraint让所有副本都落在同一台节点上那就等于把整个业务的可用性押在一台机器的硬件健康和网络状态上。我在生产环境里见过单台 Worker 挂了以后整个服务不可用的事故原因就是服务约束写了node.id xxx把副本全锁死在了那台机器上。第二个忠告是Worker 的升级和重启一定要有节奏。别看 Worker 不参与 Raft但它参与 Gossip 协议和证书轮换大量 Worker 同时重启会造成集群通信风暴。我通常会在维护窗口内分批重启每次只处理总节点数的四分之一然后观察节点重新加入集群是否稳定。稳妥永远比速度重要。第三个建议是在 Worker 上开启日志轮转。Docker 容器日志默认会无限增大如果 Worker 节点的磁盘容量没有提前规划日志会先占满磁盘接着镜像拉取失败、容器启动失败最终整个节点变成一个只会报错的“废节点”。建议在/etc/docker/daemon.json里配置log-driver为json-file并设置max-size为10m、max-file为3然后重启 Docker 服务生效。第四个延伸方向是结合自动弹性能力来使用 Worker 标签。你可以在集群外部通过调用 Manager API 或定时任务根据 Worker 的资源水位自动调整服务的副本数或节点状态。比如在业务高峰前把一批预备 Worker 的 Availability 从 Drain 改为 Active让调度器把副本扩展上去高峰结束后再切回 Drain把多余的副本回收。这样既不需要频繁增减节点也能让 Swarm 的调度能力更贴合业务的真实波动。Swarm Worker 这个角色看起来简单但它牵扯到网络、调度、安全认证、存储、系统维护多个层面。把这一块理解透你对整个 Swarm 架构的掌控力会明显上一个台阶。后面如果时间允许我还会继续在这个系列里补充 Manager 节点选主细节、服务更新策略和存储卷在 Worker 上的挂载方案大家可以持续关注。