跑过几套Swarm集群之后你会发现真正决定集群稳定性上限的往往不是Manager那套复杂的Raft协议而是被很多人忽略的Worker节点。这篇是Swarm系列的第003篇专门给Worker节点做一次补充梳理。之前聊过集群初始化、Manager选举机制这次把视角拉到执行层讲讲Worker节点在任务流转链路中的真实角色、Join令牌背后的细节、任务调度的完整链路以及我在维护过程中踩过的坑和排查思路。1. Worker节点在Swarm集群中的真实定位1.1 Manager与Worker的边界到底在哪里很多刚接触Swarm的朋友容易把Worker节点理解成“跑容器的小工”觉得它就是把镜像拉下来、把容器跑起来就完事了。这个理解没错但不完整。Worker节点在Swarm集群里承担的角色比表面看起来要复杂得多它不只是“执行者”还同时参与了集群状态同步、服务发现、网络转发等一系列工作。从Swarm的架构设计来看节点角色分Manager和Worker两种。Manager节点负责集群的管理面包括维护集群期望状态、处理服务编排、调度任务、处理各种API请求。关键的是Manager节点内部维护了Raft共识组所有集群状态变更都要经过Raft组确认。Worker节点则不参与Raft投票也不存储集群状态副本它只做一件事执行Task。但这里有个容易忽略的细节Worker节点其实也在参与集群状态的分发。Swarm使用了一种叫gossip协议的内部通信机制Manager会把任务分配信息通过gossip扩散到整个集群Worker节点之间也会通过gossip交换某些成员信息。也就是说即使某个Worker节点和Manager之间的长连接暂时出了问题它依然有可能通过其他Worker节点获得部分任务更新信息。这一点在排查“为什么Manager那边显示任务状态变了Worker这边却没反应”的时候特别重要。再往细了说Worker节点还承载了一个常被忽视的组件内置的DNS解析器。Swarm集群内部有一个分布式的DNS服务每个节点上都有一个本地解析器用于解析服务名和容器名。当你部署了一个服务服务A访问服务B的时候就是通过这个DNS服务来解析的。Worker节点需要维护这个本地DNS代理的正常运行一旦节点上的DNS代理挂了服务间的通信就会大面积异常。所以Worker节点在Swarm里的真实定位应该这样理解它既是任务的执行者也是集群数据面的组成部分还承担了一部分集群状态同步的职责。理解了这一点后面遇到很多看起来“莫名其妙”的问题时排查思路就会清晰很多。1.2 Worker节点上的核心组件拆解一个健康的Worker节点上实际上跑着一整套Docker引擎组件不只是容器运行时那么简单。逐个拆开来看第一个核心组件是dockerd这是Docker守护进程本身负责管理容器生命周期、镜像、网络、存储。在Swarm模式下dockerd内部还会启动一个swarmkit的agent模块这个模块专门负责和Manager节点通信。第二个是containerd这是容器运行时的核心层负责真正创建和销毁容器。dockerd会把容器创建请求转发给containerdcontainerd再通过runc去调用内核的namespace、cgroup能力完成最后的容器启动。第三个是vxlan相关的数据面组件。Swarm集群默认使用VXLAN技术构建overlay网络当节点加入Swarm集群后dockerd会在节点上创建一个名为docker_gwbridge的网关桥接网络同时为各个overlay网络创建对应的VXLAN接口。Worker节点上有多少overlay网络就会创建多少对应的网络命名空间和VXLAN设备。第四个是gossip协议组件。这个不像前面几个组件那么直观它不产生独立进程而是在dockerd内部以goroutine的形式存在。它负责节点间的成员状态扩散定期和其他节点交换信息保证集群内每个节点都能感知到其他节点的存活状态。我经常用一句话来概括Worker节点上的组件体系它必须同时跑好管理面agent、运行时、网络数据面、DNS解析这四个角色任何一个出问题这个节点都可能在集群里表现为各种诡异状态。这也是为什么排查Worker节点问题时不能只看容器状态而是要整体看节点健康度。2. 服务从创建到运行的完整链路拆解2.1 服务创建时Worker节点上发生了什么当你执行一条docker service create命令时整个事件的流转过程是分阶段的。命令首先打到Manager节点的API接口上Manager把这个期望状态写入Raft日志并同步给其他Manager节点得到多数派确认后期望状态才算正式记录。然后调度器开始介入它根据当前集群的资源情况、标签约束、亲和性规则等决定这个服务的副本应该放在哪些节点上。当调度器选中某个Worker节点后Manager会打包一个Task定义这个Task定义里包含了容器配置、网络配置、环境变量、挂载卷、重启策略等所有信息。Manager把这个Task推送给目标Worker节点上的agent模块两者之间走的是gRPC长连接。Worker节点上的agent收到Task后执行流程是这样的先检查本地是否有对应的镜像如果没有就去镜像仓库拉取。镜像拉取完成后agent会调用dockerd的API创建容器dockerd再调用containerd去真正启动容器。容器起来之后如果这个服务挂在某个overlay网络上dockerd还会把容器接入对应的网络命名空间并分配对应的VXLAN IP。这里有几个值得注意的细节。第一Manager推送Task的时候Worker节点不需要向Manager“确认收到”因为它基于gossip协议会反复同步状态即使推送消息丢失了后续的状态同步也能补上。第二容器启动后健康检查状态也由Worker节点上的agent负责上报Manager不主动去Worker节点上探测容器状态只被动接收Worker汇报。第三任务运行期间Worker节点会周期性上报心跳心跳间隔默认是5秒如果连续多个心跳周期Manager没收到这个节点就会被标记为Down。2.2 调度器选节点时到底看什么调度决策是整个Swarm集群里最核心的逻辑之一它发生在Manager节点上但最终影响的是Worker节点。调度器在做决策时会综合以下几个因素第一是可用资源。Swarm调度器会查看每个Worker节点的可用CPU和内存这里的可用资源是节点的总资源减去已经分配给所有现有任务保留的资源。需要注意这里统计的是任务在创建时声明的资源预留值而不是容器的实时实际使用量。所以如果你创建服务时不声明--limit-cpu、--limit-memory调度器只能按没有任何预留来分配这时候多个任务可能被塞到同一个节点上实际运行后资源跑满导致各种问题。第二是可用性状态。调度器不会把新任务分配到状态为Drain或Down的节点上。Drain状态一般是你主动执行的表示这个节点上的任务需要被排空是一个比较优雅的维护方式。第三是标签和约束。通过--constraint和--placement-pref这两个参数可以控制服务的任务只能调度到带某些标签的节点上或者优先调度到满足某种条件的节点上。比如可以用node.labels.role database这种表达式让某个服务只跑到专用的数据库节点上。第四是节点在哈希环上的分布。Swarm调度器会基于任务名称和节点ID计算出一个哈希值确保同一个服务的副本尽量分散到不同节点上避免所有副本都挤在同一台机器上。这个机制叫spread策略虽然没有Kubernetes那样复杂的打分排序但在中小规模集群里效果已经不错了。了解调度逻辑后有个很实用的经验是给每个Worker节点打上清晰的标签比如机柜位置、磁盘类型、是否SSD、承担的应用类型等。这能让调度器的约束配置变得非常灵活而不是把整个集群当成一块无差别的资源池去用。2.3 任务状态机与状态回传Task在Swarm里是有明确生命周期状态的这个状态机对排查问题非常有用。一个Task从下发到Worker节点开始会经历这些状态NEW → PENDING → ASSIGNED → ACCEPTED → PREPARING → STARTING → RUNNING → COMPLETE/SHUTDOWN/FAILED每个状态的含义要搞清楚。NEW是任务刚创建还未分配节点PENDING是等待调度ASSIGNED是已经指定了某个WorkerACCEPTED是Worker的agent已经收到任务PREPARING是Worker正在做准备工作比如拉镜像、创建网络、准备挂载卷STARTING是容器正在启动中RUNNING表示容器稳定运行COMPLETE是任务正常结束一般用于一次性任务FAILED则意味着任务启动或运行过程中出错。Worker节点上的agent是状态回传的执行者它会定期向Manager汇报任务状态。这里有个比较隐蔽的机制Worker并不是“状态变化就立刻推送”而是周期性地同步。所以你在Manager上执行docker service ps看到的任务状态和Worker上的真实状态之间存在一个时间差。这个时间差通常几秒内但在极端情况下比如Worker节点负载非常高、gRPC长连接拥堵时状态同步可能会延迟更久。排查时如果发现Manager那边任务状态总是“慢半拍”不要急着重启节点先看看是不是Worker节点本身负载太高了或者网络之间出现了丢包。我曾经遇到过一次任务镜像拉取极慢的问题就是因为Worker节点上同时有好几个服务都在拉镜像导致磁盘IO爆满后面的任务一直卡在PREPARING状态。3. Worker节点加入集群的完整实操细节3.1 Join令牌的两种角色差异Worker节点加入集群核心操作是执行docker swarm join命令后面跟着Manager节点的地址和Join令牌。很多人只知道拿令牌运行命令不理解令牌背后的机制。Join令牌本质上是一串经过签名的加密字符串里面包含了集群的Raft日志加密密钥如果有启用、Manager地址列表、节点角色信息。使用令牌加入集群时这个令牌告诉集群“我要以Worker身份进入”Manager验证令牌合法后把这个新节点的信息注册到集群成员表里。大家注意Manager和Worker的Join令牌是不同的这不仅是角色标识的区别还牵扯到权限控制。一个拥有Worker令牌的节点永远无法通过Raft参与Manager决策。拿到Manager令牌则可以直接加入控制面。所以在实际运维中Manager令牌要当最高权限凭证来保管绝对不能泄露更不能提交到代码仓库里。有一个很常见的坑是集群已经运行很久了某个Worker节点因为系统重装需要重新加入。如果你手上还拿着几个月前的旧令牌重新执行join是可能失败的。因为Swarm集群的Join令牌支持轮换而且Rotate操作相当简单直接。我在实际维护中习惯在每次重大变更或者定期巡检时轮换一次令牌同时把新令牌同步到内部的凭证管理系统里。执行join时还需要控制一个细节叫--availability它有三个取值active、pause、drain。默认是active表示节点正常参与调度。如果新加入的节点需要先做初始化准备比如预拉镜像、配置存储可以先以drain状态加入等准备工作做完了再切回active。这样能避免刚加入的节点立刻被调度器分配任务导致任务在初始化期间就被启动产生各种连锁问题。3.2 端口要求与防火墙配置要点Worker节点加入集群需要开放的端口经常被轻视但这一步出错是所有入门级问题的源头。Swarm集群的节点间通信主要涉及三个端口2377端口是管理面通信端口用于Manager与节点间的gRPC通信和集群管理7946端口是节点间gossip通信端口TCP和UDP都需要放行4789端口是VXLAN数据面端口用于overlay网络的数据封装传输UDP协议。有些文档会建议三个端口都在所有节点上放开但实际上2377端口只有在节点和Manager通信时才需要Worker和Worker之间并不会走2377。这里最常见的问题是组策略或者云平台安全组只放行了2377结果集群虽然能建立但服务之间的跨主机通信全部失败因为在VXLAN模式下4789端口没开。还有一点容易被忽视Swarm的overlay网络数据面会使用内核的VXLAN模块。如果你的Worker节点操作系统比较精简内核里没有加载vxlan模块那么overlay网络的数据包就无法正常封装和转发。检查方法很简单在节点上执行lsmod | grep vxlan如果没有输出就需要先加载内核模块。这类问题在容器化部署比较重、节点操作系统版本差异较大的环境中经常出现。防火墙配置好之后验证节点间通信是否正常最直接的办法是在两个节点之间测试连通性。但要注意光能ping通不代表VXLAN口工作正常还需要实际在overlay网络里创建服务用业务容器之间的访问来验证数据面是否完整贯通。3.3 Worker节点退出集群的正确方式Worker节点要退出集群可以使用docker swarm leave命令。这个命令在节点上执行后会让该节点主动离开Swarm集群并向Manager汇报离开。节点离开后原本运行在这个节点上的任务会被标记为shutdown然后Swarm会按照服务的副本策略在其他可用节点上重新创建任务保证副本数满足期望值。这里有一个值得展开的细节如果你只是想让节点暂时不接收新任务但不影响上面已经运行的任务应当使用docker node update --availability drain而不是执行leave。Drain状态可以理解为“只出不进”已经分配的任务可以继续运行但调度器不会再往这个节点上分新任务。这对日常维护、硬件升级、内核重启这类操作非常友好。另外一个容易踩的坑是Worker节点执行leave后如果后面又想重新加入不能直接再次join因为集群里可能还残留着该节点的旧记录Agent会尝试恢复旧任务。比较稳妥的做法是如果这个节点只是临时维护优先用drain而非leave如果确实要彻底离开等Manager这边确认节点已经消失之后再重新通过join令牌接入。4. Worker节点的资源管理与策略调优4.1 从资源预留到实际限制的完整配置资源控制是Swarm集群里最容易被低估的部分。Swarm支持通过--reserve-memory、--reserve-cpu来预留资源也支持通过--limit-memory、--limit-cpu来限制容器的资源使用上限。预留资源和限制资源是两个概念我见过很多人在使用的时候把它们混为一谈。预留资源的意思是调度器会把这个节点的资源扣减掉其他任务在调度时只能使用剩余的资源。比如一个Worker节点有4核8G如果一个任务预留了1核2G那么调度器看到的可用资源就是3核6G。但预留资源并不会真正限制容器的运行上限容器依然可以在运行时抢占更多资源。限制资源则是对容器真实的约束。设置--limit-memory后容器一旦超过这个内存上限就可能触发OOM被杀掉。设置--limit-cpu后容器的CPU使用会被限制在设定的配额内不会无限制占用。在给Worker节点做资源规划的时候我通常建议留出一定的系统冗余空间。比如一个4核8G的Worker节点不要把可分配资源全部分完至少要留出10%-15%给操作系统本身、Docker守护进程、日志收集Agent等系统组件。否则一旦业务流量上来人还没反应过来节点上的OOM Killer就会先帮你做决策把容器杀掉一堆。4.2 数据面网络的选型与影响Worker节点上的网络模式直接影响跨主机通信的性能表现。Swarm支持两种主要的网络驱动overlay和macvlan。overlay网络是最常用的选择。它基于VXLAN技术在每个节点上建立一个虚拟隧道跨主机的容器通信数据都会被封装成VXLAN报文。好处是部署简单、不依赖物理网络的特殊配置坏处是封装解封装会带来一定的性能开销尤其是在小包和长连接场景下CPU消耗会比较明显。macvlan网络则是直接把容器的虚拟网卡挂到物理网卡上容器直接获得物理网络IP通信不需要走隧道封装性能几乎等同于宿主机网络。但macvlan的缺点也很明显容器IP和宿主机IP在同一网段里IP容易冲突跨节点通信依赖底层交换机的VLAN配置而且很多云环境下的VPC网络不支持非标准macvlan配置容易翻车。在选型的时候我的建议是追求简单、灵活、可移植性优先overlay对性能有极致要求、且底层网络环境可控再考虑macvlan。大多数业务场景下overlay的性能消耗不到10%完全在可接受范围内。4.3 健康检查与日志采集在Worker侧的做法健康检查是保证业务容器高可用的重要手段。在Swarm中声明服务时可以通过--health-cmd、--health-interval、--health-retries等参数为容器配置健康检查。这些参数定义好之后Worker节点上的dockerd会按照设定的时间间隔在容器内执行健康检查命令当一个容器连续多次检查失败Swarm会认为这个任务不健康然后根据服务配置决定是否重启这个容器。在实际配置中有个容易忽略的点健康检查不是在调度阶段检查的而是在容器运行过程中持续进行的。所以Worker节点的负载情况、容器的启动耗时都会影响健康检查的结果。比如容器启动需要10秒但你配置的健康检查间隔只有2秒启动期间检查肯定失败。连续失败几次后Swarm就会重启容器形成“启动失败-重新启动-再失败”的循环。我自己习惯是把健康检查的启动宽限期--health-start-period设置得比容器实际启动时间稍微长一点留出足够的缓冲。日志采集方面Worker节点上运行的容器日志会以JSON文件格式记录在/var/lib/docker/containers/下。生产环境如果直接用本地文件方式收集磁盘占用会持续增长必须配置日志轮转策略。建议在dockerd的启动配置里加上max-size和max-file限制同时在每个节点上部署一个独立的日志采集Agent将容器日志转发到集中的日志平台。不要把日志只留在本地一旦节点不可恢复日志也跟着丢了。5. 常见故障排查与实战技巧5.1 Worker节点显示Down的排查思路Manager节点显示某个Worker为Down是容器运维里最经典的故障场景。导致Down的原因很多但基本可以归结为三类网络不通、心跳超时、节点负载过高。网络不通是最常见也最容易排查的。用docker node ls可以看到节点的状态如果显示Down先确认节点是否还能通过命令行访问。如果可以直接用telnet测试Manager的2377端口是否通。有时是Manager和Worker之间的防火墙规则发生了变化有时是云安全组策略调整了都可能导致管理面失联。心跳超时通常和网络质量有关。Worker节点默认每5秒发一次心跳如果Manager超过一定时间没收到心跳就会把节点标记为Down。这里有一种特殊情况Worker节点本身没有宕机只是心跳报文被网络抖动或防火墙丢包了。恢复的办法很简单网络恢复后节点会自动重新连上Manager。节点负载过高也可能导致心跳无法及时发出。系统的CPU、内存、磁盘IO任意一个被写满dockerd进程会出现调度延迟心跳报文发不出去。这种情况要先登录节点看负载把跑满资源的容器停掉再恢复。我遇到过一次比较极端的情况某个节点因为日志文件写满了/var/lib/docker所在的磁盘分区dockerd直接挂起Manager把节点标记为Down但节点本身只剩一点点剩余资源看起来像是半死状态。清掉磁盘空间后dockerd慢吞吞地恢复节点状态也随之回到Ready。5.2 任务卡在Preparing状态的排查路径docker service ps显示任务一直处于Preparing状态就说明容器的准备工作始终没有完成。准备工作主要是两件事拉镜像和创建网络。如果是拉镜像的问题需要登录对应的Worker节点用docker pull手动拉一下业务镜像看看耗时。如果镜像仓库链路不稳定或者镜像特别大拉取时间会很长。还有一种情况是镜像仓库需要认证节点上没有配置对应的docker login凭据导致拉取直接失败。但失败会进入FAILED状态Preparing更像是“一直在拉但永远拉不完”。如果是网络创建的问题一般是overlay网络的初始化卡住了。这一般和VXLAN模块有关也可能和节点上的网络命名空间残留有关。排查时先看系统日志常见的错误是ioctl失败、bridge创建失败、VXLAN设备创建失败。碰到这种问题优先检查内核模块和断网残留空间。5.3 跨主机容器通信异常的完整排查顺序跨主机容器通信异常我一般按以下顺序排查先验证同一节点上的容器通信是否正常。如果同一台机器上的容器也访问不了目标服务说明问题在服务本身或本地网络栈。如果同一节点正常再考虑跨节点的数据面问题。其次验证overlay网络状态。在Worker节点上docker network ls查看overlay网络是否存在然后检查对应网络命名空间的VXLAN设备是否存在。如果VXLAN设备缺失可能是vxlan内核模块没加载或者网络创建失败。再验证数据面连通性。找到两台节点上分别运行的两个容器用docker exec进入容器直接ping对端容器IP。ping通说明数据面基本正常ping不通则要检查4789端口是否放行、交换机上是否有VLAN限制、宿主机防火墙是否有抑制。数据面通了再测试实际的业务端口确认应用层服务是否正常监听。还有一个容易被忽略的点Swarm的DNS服务解析正常不代表业务联通正常。有时候容器能把服务名解析成IP但实际的网络策略阻止了访问。所以排查跨主机通信问题时不能只看DNS解析结果一定要配合实际的数据包路径逐层排查。6. 写在最后的几点实操心得维护Swarm集群这几年最大的体会是Worker节点的健康度决定了集群的下限但Manager的设计决定了集群的上限。很多人在集群出问题时第一反应是怀疑Manager实际上大部分故障发生在Worker侧或者发生在Manager与Worker之间的通信链路上。有一个细节想特别提醒docker node ps这个命令能从Manager视角看到每个节点上任务的真实分布情况但它显示的状态不一定和Worker本地一致。如果发现状态不一致优先重启节点上的dockerd而不是整个节点。单独重启Worker节点的dockerd一般不会影响该节点上已经运行的容器但会给容器网络带来短暂中断建议在维护窗口内执行。最后再分享一个小技巧Swarm集群在不使用Swarm模式的场景下可以随时docker swarm leave --force让节点退出集群这个操作不会删除节点上的容器数据。所以如果遇到节点异常先用了解状态再动手不要一上来就重装系统。Worker节点的补充到这里就告一段落。集群的运行维护没有太多高深的理论关键是把每一步操作背后的机制看明白。后面继续分享Swarm网络部分的细节特别是VXLAN模式下跨节点通信的完整数据路径。