1. 从“三节点集群”说起为什么我单独把Worker拎出来讲前两篇我们把Swarm的整体架构和Manager节点聊透了这一篇专门拆Worker。原因很简单Manager决定了集群“想干什么”Worker决定了集群“能不能干成”。很多人搭集群时习惯把三台机器全部docker swarm init再join成manager图省事结果生产环境一打补丁、一重启才发现worker节点的角色边界没搞清调度、排障全糊成一团。先把概念钉死Swarm里的Worker节点就是运行Docker引擎、以Swarm模式加入集群、专门承载服务任务Task执行的工作机。它不参与Raft共识不存储集群控制面状态不参与服务编排决策。Manager负责“发号施令”Worker负责“埋头干活”。这种分工和微服务架构里的“控制面/数据面”分离是一回事——控制面要稳数据面要快两者混在一起迟早出问题。这篇文章适合三类人一是刚把Swarm集群搭起来、想搞清节点角色的新手二是已经在生产环境用Swarm、但遇到“任务一直starting”“节点状态卡住”等怪问题的运维三是准备把集群从单Manager升级成多节点、需要理清调度逻辑的架构师。我会从角色定位、内部组件、任务状态流转、加入与运维操作、问题排查五个维度把Worker节点从头到尾拆干净。提示本篇默认你已经完成了docker swarm init并且用docker swarm join把至少一台机器拉进了集群。如果还没搭建议先看本系列前两篇再回来读这篇会顺很多。2. Worker节点在架构里的真实位置2.1 控制面与数据面Manager和Worker各管一段Swarm集群从架构上可以粗暴地分成两段控制面和数据面。Manager节点跑着swarmkit的manager模块维护整个集群的期望状态desired state——比如“nginx服务要跑3个副本”“这3个副本要分布在不同主机上”。这些信息存在Raft日志里Manager之间通过共识算法同步。但Manager不负责真正跑容器它只负责算。任务落到Worker头上之后Worker节点上的swarmkit agent模块会收到Manager下发的Task Spec然后调用本机的Docker引擎去创建容器、挂载网络、配置服务发现。执行结果再上报回Manager。可以这样理解Manager是公司的“管理层”制定计划和考核指标Worker是“执行层”拿计划干活干完汇报。管理层可以不干活但执行层不能不做决策——这就是角色分离的本质。2.2 Worker节点内部到底有哪些组件在协作一个Worker节点上真正干活的不是单个进程而是一串组件的接力Docker Enginedockerd对外提供API和CLI对内协调容器生命周期。Worker上docker ps能看到的容器全部由它管理。Swarmkit Agent内嵌在dockerd里。它负责和Manager通信接收任务状态变化指令更新Worker侧的任务状态。containerd和runc真正的容器运行时。dockerd把“要跑一个容器”的请求转给containerdcontainerd再调用runc去创建和运行容器进程。libnetwork负责Overlay网络的创建和VXLAN隧道的维护。Worker节点上的容器之间以及跨节点的容器通信都走这一层。这串组件的调用链就是一次任务从“下发”到“运行”的完整路径。任何一个环节卡住容器就起不来。排障时如果只盯着docker service ps的输出看很容易漏掉下面运行时层的问题。2.3 Worker不碰Raft这对架构意味着什么这个设计不是偷懒而是有意为之。Raft协议要求参与节点定期通信、持久化日志节点越多共识达成越慢。Swarm的设计目标是“控制面高可用”不是“所有节点都参与决策”。所以生产环境的标配是三到五个Manager节点其余全是Worker。Worker掉线不影响集群决策Manager掉线只要多数派还在集群继续工作。这也解释了为什么docker node ls里Manager节点列表前面会标“Leader”或“Reachable”而Worker节点显示的是“Ready”和“Active”。状态含义完全不同Ready表示节点与Manager通信正常Active表示愿意接收新任务。如果你把Worker节点标记为Drain它依然是Ready但不会拿到新任务。3. 任务调度和状态流转Worker视角下的生命周期3.1 一次服务部署Worker经历了什么状态当我们执行docker service create --replicas 3 nginx时Manager会生成三个Task并按照调度策略分配到三个不同的Worker节点上默认会尽量分散避免同一服务副本挤在一台机器上。Worker收到Task后任务状态会经历如下变化AssignedManager已决定该Task由哪个Worker执行并将Task下发。此刻Task还在“纸上谈兵”阶段。PreparingWorker开始拉取镜像、创建网络、准备存储等前置条件。Starting容器运行时正在创建容器启动进程。Running容器正常运行。Complete对于一次性任务比如docker service create --restart-condition none跑一个批处理任务执行完毕。Failed / Rejected任务执行失败或被Worker拒绝比如节点处于Drain状态、资源不足。3.2 状态卡住时问题出在哪个环节我在生产环境里最常遇到的就是任务卡在Preparing或Starting。卡在Preparing通常是镜像拉取失败、私有仓库凭据过期、或者磁盘空间不足。卡在Starting多半是容器启动命令出错、健康检查永远不通过、或者Overlay网络没建好。比如有一次一个服务在A节点上Running在B节点上一直Starting。查了半天发现B节点的防火墙把VXLAN的4789端口挡了。Overlay网络建不起来容器进程根本没法加入网络命名空间。这个坑单看docker service ps的日志根本看不出原因——日志只显示“task repeatedly failed”真实原因藏在journalctl -u docker里。3.3 Worker怎么向Manager汇报状态Worker不是闷头干活不吭声的。Swarmkit Agent会通过gRPC和Manager保持长连接定期上报节点的资源使用情况CPU、内存、任务运行状态、节点健康信息。Manager根据这些上报数据做调度决策和故障转移。这里有个容易被忽略的细节Worker上报的是“结果”不是“过程”。比如容器内部业务代码挂了但只要容器进程还活着Worker就认为任务正常。所以千万别把docker service ps里的“Running”当成业务健康——那是“容器活着”不是“业务OK”。要感知业务健康必须依赖服务配置里的--health-cmd健康检查。4. 实操从加入集群到运维Worker的完整命令手册4.1 三种加入方式对应不同的安全级别Worker加入集群最常规的方式是在Manager上执行docker swarm join-token worker拿到Token然后在Worker机器上执行docker swarm join --token SWMTKN-1-xxxxx 192.168.1.10:2377其中2377是Swarm控制面通信端口4789是VXLAN数据面端口7946是节点间gossip协议端口。加入后可以通过docker node ls确认节点状态。除了常规的Token方式Swarm还支持自动加入在Manager上指定--advertise-addr和--listen-addr并开启自动接受docker swarm init --autolock这个和自动加入无关自动加入配置在集群初始化时用--availability配合。但实际生产里我最推荐的还是Token方式因为Token可以滚动更新安全性可控。4.2 Worker的可用性调整Drain和ActivateWorker机器要维护、要升级内核、要换硬件不能直接关机否则正在运行的容器会被强行终止。正确操作是先把节点设为Draindocker node update --availability drain worker-01Drain后Swarm会将该节点上的任务平滑迁移到其他活跃节点然后Worker节点变成“不再接收新任务已有任务主动排空”的状态。维护完成后重新激活docker node update --availability active worker-01这个操作背后的逻辑是“优雅下线”比直接docker node rm --force要安全得多。docker node rm是强删节点如果节点上还有容器在跑会直接杀死容器可能导致数据丢失。我踩过这个坑后来把Drain写进了运维手册的强制操作清单里。4.3 Worker的标签约束让任务精确落位Swarm支持给节点打标签然后让服务只调度到符合条件的Worker上。比如给GPU机器打上gputrue标签docker node update --label-add gputrue worker-gpu-01创建服务时加约束docker service create \ --constraint node.labels.gputrue \ --replicas 2 \ nvidia/cudaWorker节点在调度中的价值从这一步开始体现。没有标签约束时Swarm默认把任务均匀分散在所有可用的Worker上加了节点标签后服务可以精确落位到指定硬件或指定机房。这里要注意约束只对新建任务生效已存在的任务不会自动重新调度。改完约束后需要docker service update --force强制执行一次滚动更新。5. Worker节点常见故障与排查实录5.1 “卡死的任务”任务一直Rejected怎么办典型场景某天发现某个服务在docker service ps里显示一堆Rejected而且报错信息全是task: non-zero exit (137)。137意味着容器被强制杀死通常是内存超限OOM或外部kill。排查思路就三步# 第一步看服务日志确认是哪个task挂在哪个worker上 docker service ps service-name --no-trunc # 第二步到对应Worker上看真实容器日志 docker logs container-id --tail 200 # 第三步看系统层面有没有被杀进程的痕迹 dmesg | grep -i kill如果确认是OOM就该调整服务的内存限制或者检查Worker节点本身是否内存不足。这里有个技巧用docker node inspect worker-01 --pretty查看节点内存信息对比已调度任务的内存总和提前发现资源超卖。5.2 Worker失联Manager端显示Down但机器没关机Worker失联是群聊里最常见的求助帖。排查方向有四个网络连通性Worker到Manager的2377/tcp是否通telnet manager-ip 2377测一下。时钟同步Swarm要求节点间时钟偏差不能太大默认300ms时钟漂移会导致gRPC心跳失败。Docker服务异常systemctl status docker看dockerd有没有挂掉。磁盘写满Worker节点磁盘满导致containerd无法写日志任务静默失败。还记得一次对方说“节点Up了又Down反反复复”。我让他检查Manager上的时钟同步一查发现NTP没配偏差越来越大。配好NTP后问题立刻消失。这类问题不做系统排查光靠重启节点持久不了多久。5.3 Worker节点上的容器不见了谁删了我的容器有人问为什么我在Worker上用docker ps看不到Swarm的服务容器答Swarm管理的容器默认在Worker节点上执行docker ps是能看到的但如果你在Manager上用docker ps看不到是因为Manager节点默认不直接运行服务容器除非Manager也作为Worker参与调度。如果Worker上连容器都看不到先看是不是节点被Drain了Drain后的节点Swarm会把容器强制迁移走容器会被stop并删除。这个“删除”动作是设计行为不是故障。但如果你需要保留容器的日志或数据务必挂载volume或把日志输出到宿主机文件否则迁移后日志全部丢失。6. 生产环境里Worker节点的一些“反直觉”经验6.1 Worker节点必须禁用Swarm之外的重型负载我在生产环境见过一个最典型的反面教材运维觉得Worker节点闲着浪费直接在Worker上跑了一个数据库容器还用-p 3306:3306把端口映出到宿主机。结果Swarm调度时不知道这个端口被占用新任务绑不上端口导致docker service create反复失败。Swarm的资源调度只管“自己管理的任务”宿主机上的其他进程和容器它看不见。所以Worker节点最好保持“只跑Swarm任务”的原则。6.2 Worker上的本地操作会干扰Swarm调度器还有人在Worker节点上手动执行docker run来测试镜像。这本身没问题但如果这个docker run占了端口、占了内存Swarm调度器再调度新任务时就可能资源不足。Swarm在调度时并不是先去宿主机上看“还剩多少资源”而是根据Worker上报的资源总和减去已分配任务的资源来估算。手动docker run不会纳入估算所以它可能导致Swarm“认为有资源实际没资源”。换句话说你在Worker上做的每一个“临时测试”都在给调度器添乱。6.3 别混淆docker node ls里的状态和任务健康docker node ls里的STATUS列显示Ready只能说明这个节点的dockerd还活着能和Manager通信。它完全不能反映节点上的容器是不是在正常对外服务更不能代替真正的健康检查和监控告警。生产环境一定要做两层监控一层是Swarm层面的节点和任务监控比如docker service ls、docker node ls另一层是业务层面的健康检查HTTP探活、端口巡检。两套都通才算真的“健康”。7. 写在后面的一点个人体会Worker这个角色在Swarm里看着简单好像就是把Manager算好的任务跑起来但真正运维一段时间就会发现集群里八成以上的怪问题最后都是落在Worker节点上暴露的。镜像拉不下来、磁盘撑爆、网络连不通、时钟漂了、标签写错、端口撞车这些故障的“案发现场”全在Worker。所以我个人建议搭集群时别心疼机器Manager节点可以少一点3到5个足够Worker节点要留足余量尤其是磁盘和网络带宽。Worker节点上尽量统一系统版本、统一内核参数、统一挂载路径能少踩很多“同配置不同表现”的坑。如果你正准备从单机Docker迁移到Swarm集群希望这篇能帮你把Worker节点的定位和工作机制理清楚——它是整个集群的“体力担当”而“体力”出问题往往比“脑力”更致命。