Docker Swarm全生命周期实践：从集群初始化到安全销毁的10个关键范例

1. 从单机到集群:为什么 Swarm 依然值得认真对待我最早接触 Docker Swarm 是 2017 年前后,那时候 K8s 还没像现在这么一统天下,Swarm 自带“原生、轻量、零额外依赖”的光环,确实吸引了一批不想折腾的人。坦白说,后来 K8s 生态越来越猛,一度我也以为 Swarm 会慢慢边缘化。但真到生产环境里对比了一圈,现实是:Swarm 并没有消失,反而在“中小规模集群、运维人力有限、追求简单直接”的场景里,活得相当滋润。Docker Swarm 的全生命周期管理,简单说就是把这几个阶段串起来:集群初始化、节点管理、服务编排、配置变更、扩缩容、更新回滚、监控排障、安全加固到最终销毁。很多教程只讲docker swarm init和docker service create,这种“会用”和“能生产”之间差的不是一点半点。真正踩过坑的人会知道,Swarm 的坑往往不在命令本身,而在集群状态的理解、服务更新的策略、网络层面的细节、以及故障时怎么快速定位。这篇文章不是跑一遍 demo,而是基于我实际维护过多套 Swarm 集群的经验,整理出 10 个覆盖全生命周期的精要实践范例。每个范例都有背景、有操作、有参数取舍、有我当时踩过的坑。如果你正准备从单机 Docker 往集群走,或者在 K8s 和 Swarm 之间犹豫,这篇内容可以给你一个很实在的参考。如果你已经在用 Swarm,那里面不少细节应该能让你有“原来还能这样搞”的感觉。2. 全生命周期设计的核心思路与选型背景2.1 生命周期各个阶段到底在管什么很多人对“生命周期管理”的理解是“部署上去就完事”,其实那是把最轻松的环节当成了全部。一个 Swarm 集群的实际生命周期,至少包含下面这些阶段,而且每个阶段都有独立的决策点:集群设计:网络模式选型、管理器节点数量、跨机房还是单机房、OS 和 Docker 版本锁定。集群初始化:swarm init只是开始,后续的 join 令牌管理、节点标签规划、集群名称规范都要想清楚。服务发布:镜像来源、副本数、健康检查、重启策略、日志驱动、资源限制、端口透传方式。配置与密钥:从环境变量到 Config 和 Secret,涉及敏感信息怎么管理、更新后如何滚动生效。扩缩容与更新:手动scale、自动感知负载、滚动更新参数、失败回滚条件。观测与排障:节点状态、服务状态、日志采集、关键指标监控、容器异常退出定位。节点维护与替换:优雅腾挪容器、节点下线、新节点加回、数据持久化兜底。安全加固:CA 轮换、双向 TLS、约束条件、镜像签名校验。集群备份与恢复:Raft 数据备份、manager 节点故障恢复、灾难场景演练。集群销毁:服务清理、节点 leave、数据销毁、资源回收。一句话概括:Swarm 的坑不在“起不来”,而在“跑着跑着出了问题怎么处理,以及计划内变更怎么不引发意外”。2.2 为什么选 Swarm 而不是 K8s 或 Compose选型这件事,从来没有“最好”,只有“最适合”。Swarm 和 K8s 我都生产用过,我的判断标准很简单:集群规模、团队认知、变更频率、故障容忍度。Swarm 最大的优势是“无侵入”。它内嵌在 Docker Engine 里,不需要额外的 etcd、不需要独立的控制平面组件、不需要为高可用再部署一堆运维系统。一个 5 节点的 Swarm 集群,资源开销小得可以忽略,而同样规模的 K8s 集群,光是系统组件就要吃掉不少内存和 CPU。对于几十个服务、单个服务副本数个位数、变更频率以一两个星期一算的场景,Swarm 的复杂度完全够用,反而更省心。它的劣势也很明显:自动伸缩能力基本等于没有,存储卷的支持停留在“本地卷 NFS”这类方案,服务发现和负载均衡的细粒度控制不如 K8s 的 Ingress 和 Service Mesh。如果你需要大数据量、复杂调度策略、多租户隔离,Swarm 会变得很吃力。所以我的经验是:30 节点以内、服务编排复杂度有限、想要“一条命令跑起来”的团队,Swarm 是性价比很高的选择。同时,我在生产里也保留了一些 K8s 集群,但那些是为了特定业务需求,不是为了“跟上潮流”。2.3 十个范例覆盖的逻辑闭环在规划这篇内容时,我特意把 10 个范例组织成一条完整链路,从“创建一个高可用的集群”开始,到“安全地销毁集群”结束,中间覆盖了服务发布、网络、配置更新、伸缩、监控、备份恢复这些日常高频操作。这样安排的逻辑是:既然是全生命周期,每个阶段都应该有拿得出手的实操样本,不是挑几个点零星展示,而是让读者看到每个环节之间是怎么衔接的。后面三个部分,我会把这 10 个范例的主要操作流程、参数选择依据、现场排障经历,掰开揉碎讲清楚。3. 核心细节解析与实操要点3.1 范例一:高可用集群初始化与节点角色分配创建一个 Swarm 集群,大多数人会用docker swarm init --advertise-addr IP一条命令搞定。但生产环境里,必须把高可用和角色分工想在前头。我的推荐拓扑是:3 个 manager N 个 worker。3 个 manager 可以保证一台挂掉之后集群仍然有法定人数,管理面不会脑裂。worker 节点数量根据业务量扩展,但建议至少 2 个,否则副本调度没有容错空间。注意一点:Raft 要求奇数个 manager,所以要么 3、要么 5,千万别图省事搞 2 个 manager。初始化命令我一般这样写:docker swarm init \ --advertise-addr 192.168.1.10 \ --listen-addr 0.0.0.0:2377 \ --data-path-addr 192.168.1.10 \ --availability active \ --task-history-limit 10参数说明:--advertise-addr:告诉其他节点“连接我时用这个 IP”,多网卡服务器必须显式指定,否则 Swarm 可能选错网卡,导致跨节点通信失败。--data-path-addr:指定 VXLAN 数据面使用的 IP,如果服务器有多块网卡,建议把管理和数据面分离,避免业务流量大时影响控制面。--task-history-limit:控制每个服务保留多少条历史任务记录,设小一点能减少 Raft 存储压力。默认是 5,我给的 10 是为了排障时能看到更多旧任务状态,这个看需求调。初始化完成后,拿到的 join 命令是 24 小时有效的,但我习惯在初始化时就把 worker 和 manager 的 join token 分别存好,免得后面重新生成。docker swarm join-token -q worker docker swarm join-token -q manager把 token 直接复制到需要加入的节点上执行:docker swarm join \ --token SWMTKN-1-xxxxxxxx \ 192.168.1.10:2377加入之后,新节点默认是 worker。如果我把某些机器规划成 manager,可以docker node promote hostname提升。但建议在集群规划阶段就把角色定清楚,别没事频繁 promote/demote,每次角色变更都会触发 Raft 成员变更,频繁搞容易出问题。重要提示:manager 节点数量不是越多越好。每增加一个 manager,Raft 写入需要同步的节点就多一个,写性能会下降。3 个 manager 可以容忍 1 台故障,5 个可以容忍 2 台故障,再多就是给自己找麻烦。生产环境我最多见过 7 个 manager,但那已经是为了多机房容灾的特殊场景了。3.2 范例二:服务发布时的资源限制与健康检查发布一个服务,基础命令谁都会:docker service create \ --name nginx \ --replicas 3 \ --publish 80:80 \ nginx:1.26但直接这么干,生产环境会埋雷。我的建议是,从一开始就把资源限制和健康检查加上:docker service create \ --name nginx \ --replicas 3 \ --publish modehost,target80,published8080 \ --limit-cpu 0.5 \ --limit-memory 256m \ --reserve-cpu 0.1 \ --reserve-memory 64m \ --health-cmd wget -q -O - http://localhost/ || exit 1 \ --health-interval 10s \ --health-timeout 5s \ --health-retries 3 \ --restart-condition on-failure \ --restart-delay 5s \ --restart-max-attempts 5 \ nginx:1.26这里有几个点值得展开:第一,端口发布模式。我用了modehost,这样是纯宿主机端口映射。Swarm 还支持modeingress,走的是内置的 routing mesh,所有节点都能响应服务端口,再把请求转发到实际运行任务的节点。ingress 模式的好处是任意节点 IP 都能访问服务,坏处是多了一层网络转发,而且会占用所有节点的端口。如果服务数量多、端口多,ingress 模式会让端口管理变得混乱。我的建议:对外提供 HTTP 服务的,用 ingress 模式挺好;对延迟敏感的内部服务,尽量用 host 模式。第二,健康检查。Swarm 的任务调度依赖健康检查状态,健康检查失败的任务会被杀掉重建。一定要给服务加健康检查,尤其是数据库、消息队列这类有状态服务。不然容器进程活着,但业务实际不可用,Swarm 不会帮你做任何事。健康检查的命令要尽量简单可靠,wget对 HTTP 服务足够,但要注意容器里是否装了 wget。第三,资源限制。--limit-cpu和--limit-memory是硬上限,超过会被限制或被杀;--reserve-cpu和--reserve-memory是调度时的资源预留,保证节点上所有任务的内存总和不超过节点资源。这里我踩过一个坑:只设 limit 不设 reserve,高负载时调度器可能把多个服务堆在同一台节点上,资源一下子就爆了。后来统一规划,每个服务都标明 reserve,Swarm 调度时会把任务分散到不同节点上。3.3 范例三:用 Docker Config 管理非敏感配置文件很多人把配置文件塞进镜像里,或者用 volume 挂载宿主机路径。这在小规模玩一玩没问题,但镜像一旦变多,配置文件的管理会变得非常痛苦。Swarm 原生的 Config 功能,其实是被低估的。我举一个实际案例:一个 Nginx 服务需要自定义nginx.conf,用 Config 的方式是这样:docker config create nginx-conf ./nginx.conf docker service create \ --name nginx \ --config srcnginx-conf,target/etc/nginx/nginx.conf \ nginx:1.26创建 Config 时可以指定 target 路径,容器里看到的就是这个路径。Config 是只读的,运行时不会被修改,适合放配置,但不适合放需要动态读写的文件。Config 更新是个容易被忽略的点。直接重新执行docker config create再创建一个新版本,然后更新服务引用:docker config create nginx-conf-v2 ./nginx.conf docker service update --config-rm nginx-conf --config-add srcnginx-conf-v2,target/etc/nginx/nginx.conf nginx这里要注意:Swarm 的 Config 一旦创建是不能编辑的,只能新建再热替换。而且 Config 的更新不会自动触发服务滚动重启,需要配合docker service update --force强制重启服务才能让新配置生效。我的习惯是,每次改配置后明确执行一次强制更新,不要指望 Swarm 自动感知。实操心得:不要把 Config 当 volume 用。Config 适合“这个文件在创建时确定,服务运行期间不会被程序修改”的场景。像日志路径、证书文件这种需要动态变化的内容,该用 volume 还是用 volume。3.4 范例四:Secret 管理敏感信息的最佳实践敏感信息(数据库密码、API Key、私钥)直接写在 Dockerfile 或环境变量里,这是我见过最多的安全漏洞来源。Swarm 的 Secret 机制可以在不写入镜像和宿主机明文的前提下,把敏感信息传给服务容器。用法很简单:echo my-db-passw0rd | docker secret create db-pass -然后创建服务时挂载 Secret:docker service create \ --name api \ --secret srcdb-pass,target/run/secrets/db_pass \ --env DB_PASS_FILE/run/secrets/db_pass \ api:latest默认情况下,Secret 会被挂载到容器内的/run/secrets/secret名称,我习惯用target参数重命名一下,免得名称里带横杠之类的字符搞得程序不好读。Secret 和 Config 最大的区别在于安全性:Secret 只有在被分配给某个服务任务时,才会通过加密的 Raft 日志同步到对应节点上,最终写入容器内的是运行时生成的 tmpfs 文件。也就是说,只要你不用docker secret inspect直接打印内容,敏感信息不会出现在宿主机磁盘上。有一个细节我特别提醒:环境变量里的 Secret 会在 docker inspect 的时候以明文形式出现在事件流里,虽然有时间限制,但终究多了一道暴露面。我的建议是程序优先从/run/secrets路径读取文件,而不是依赖环境变量。然后应用内部尽量做到“文件即配置源”。3.5 范例五:基于 NFS 的数据持久化方案Swarm 的原生 volume 只支持本地方向,也就是说,同一个服务的多个副本如果要共享数据,必须考虑外部存储。生产里我用的最多的是 NFS。NFS 在 Swarm 里被定义为docker volume create的--driver local配合--driver-opt typenfs。docker volume create \ --driver local \ --opt typenfs \ --opt oaddr192.168.1.100,nfsvers4,soft,timeo30,retrans3 \ --opt device:/data/shared \ shared-data-v1创建完成后,在服务里挂载:docker service create \ --name uploader \ --mount typevolume,sourceshared-data-v1,target/data \ uploader:latest这里有几个注意点:NFS 的soft选项很重要。如果用hard,NFS 服务端一抖动,客户端进程会一直卡在 IO 等待上,容器看起来活着但实际已经无法提供服务了。用soft配合timeo和retrans,IO 出错时会快速返回,配合 Swarm 的 restart 策略,让容器重建会比一直卡死强得多。NFS 服务端最好使用独立的磁盘或 NAS 设备,不要拿 Swarm 节点本身当 NFS 服务端,一台节点挂了数据就全挂了。Swarm 模式下,同一份 volume 被多个不同节点上的任务同时挂载时,NFS 是相对靠谱的选择。但要注意业务是否支持并发写同一文件,如果不支持,要么把副本数控制为 1,要么在应用层做好文件锁。3.6 范例六:滚动更新与自动回滚策略服务不可能一发布就永远不变。Swarm 的滚动更新是我认为它做得比较顺手的功能之一,但默认参数往往不够安全。以一个 Web 服务为例:docker service update \ --image demo/web:v2.1 \ --update-delay 10s \ --update-parallelism 1 \ --update-order start-first \ --update-failure-action rollback \ --rollback-delay 10s \ --rollback-parallelism 1 \ --rollback-monitor 20s \ web参数解读:--update-delay:每个任务更新完成后的等待时间,10 秒给健康检查留出窗口。--update-parallelism:同时更新的任务数,1 表示一次只更新一个,最大化保障可用性,但耗时较长。如果服务副本很多,可以调大到 2 或 3,但要评估服务是否有状态、是否能承受多个实例同时重启。--update-order start-first:先启动新容器,等新容器健康后再停旧容器。这是零停机更新的关键设置。--update-failure-action rollback:一旦新任务启动失败或健康检查失败,直接触发回滚。--rollback-*系列参数:控制回滚过程的节奏。我设置的 monitor 20s 意思是回滚后要观察 20 秒新任务状态正常,才继续回滚下一个。这个方案的实际效果:更新期间,服务始终保持着可用状态,坏版本会被自动撤回。比起人肉盯日志然后手动回滚,省心太多。不过要提醒一句:回滚动作本身依赖健康检查,如果你的健康检查写得不准,回滚决策也会不准。所以前文强调的健康检查,是整套机制的地基。3.7 范例七:服务的动态扩缩容扩缩容是 Swarm 最基础但也最容易被误用的功能。很多人以为docker service scale就是加/减副本数,实则它有自己的一套逻辑。docker service scale web5就是这么简单。但执行缩容时,你有没有想过 Swarm 会先停掉哪个容器?答案是:它会尽量均衡地选择,没有固定规律。如果你的服务副本共享状态,缩容时被停掉的容器可能恰恰持有重要任务,这一点要警惕。我的做法是:有状态的业务,缩容之前先把该实例从负载均衡摘掉,或者直接通过健康检查把容器标记为不健康但不删除,等待任务自然结束。不过这类操作在 Swarm 原生层面不太好做,所以我通常建议:有状态服务尽量不用 Swarm 做弹性伸缩,副本数保持固定;无状态服务随便扩缩,没毛病。另一个容易被忽略的点是:扩缩容之后,要考虑节点资源是否足够。如果集群资源不足,Swarm 不会把新任务调度到任何节点上,任务会卡在 pending 状态。此时用docker service ps看任务的 error 信息,会明确告诉你资源不足。所以扩缩容不是只调一个数字,还要观察节点资源余量。3.8 范例八:零停机节点维护与排空计划内维护节点、升级内核、更换硬件,这是每个运维都躲不开的事。Swarm 提供了node availability的概念:active、pause、drain。把节点置为 drain,Swarm 会把该节点上运行的所有任务迁走:docker node update --availability drain node2执行后,node2 上的任务会自动在别的可用节点上重新调度。如果原节点上有数据卷但目标节点没有,任务会无法启动,因此有状态服务在 drain 之前一定要确认数据卷方案的可用性。维护完成后把它恢复:docker node update --availability active node2恢复以后,该节点不会自动把任务再拉回来,需要额外手段。我的经验是:如果希望恢复后马上重新平衡服务,直接用docker service update --force触发一轮强制重启,Swarm 会重新评估调度约束。但要注意,--force 会重启所有副本,如果服务有互斥资源(比如只允许一个实例运行),别乱用。这里有一个我在实际运维中非常依赖的里程碑:在发版、配置变更、节点维护之前,先确认服务处于“无新变更”的状态,再动节点。Swarm 有个特性:如果服务正在滚动更新,此时你把节点 drain 了,可能会触发部分任务的新旧版本交替混乱。虽然系统最终会收敛,但过程会很难看。所以操作顺序最好是:先等更新完成,再排空节点。3.9 范例九:日志收集与监控指标Swarm 任务调度的黑盒程度比 K8s 高,日志和监控就是你的另一双眼睛。Swarm 里每个容器的日志默认由 Docker Engine 接管,默认 driver 是 json-file,单容器日志太大时会严重影响磁盘空间。我的实践是统一改用local驱动,并为每个服务设置日志轮转参数:docker service create \ --name api \ --log-driver local \ --log-opt max-size50m \ --log-opt max-file5 \ api:latest这样单个容器的日志文件最多 5 个、每个最大 50MB,满 250MB 后自动裁剪老文件,不再需要频繁清理磁盘。比起 json-file 动辄几十个 GB 的日志目录,这种方式省心太多了。日志的系统级收集,我走的方案是:每个 Swarm 节点部署一个 Filebeat 或 Promtail,采集/var/lib/docker/containers/*/*.log,然后把日志汇聚到 ELK 或 Loki。这套方案的好处是不侵入应用容器,采集端由运维统一管理,坏了一个节点最多丢一部分日志,不影响业务。监控方面,我用 cAdvisor Prometheus 采集节点和容器的 CPU、内存、网络指标,再配合 Alertmanager 做告警。Swarm 本身不暴露 metrics 接口,但每个节点的 Docker Engine 都暴露了/metrics,原生的 Exporter 可以直接抓。3.10 范例十:Raft 备份、灾难恢复与集群销毁最后这个范例很关键,但也最少被认真对待:备份与恢复。Swarm 的所有集群状态都存放在 manager 节点的 Raft 日志里,所以备份 Swarm 实际上就是备份/var/lib/docker/swarm目录。推荐做法是选一台 manager 节点,定时做快照:systemctl stop docker tar czf /backup/swarm-backup-$(date %F).tar.gz /var/lib/docker/swarm systemctl start docker不过这种热备份方式要停 Docker,生产环境很难接受。我后来改用文件系统层面的快照,比如 LVM snaphost 或者云硬盘快照,对 manager 节点做整盘快照,这样可以不用停服。注意,备份最好从同一个 manager 节点上做,不要今天备份 manager1、明天备份 manager2,因为不同节点的 Raft log 可能不完全一致。灾难恢复时,假设一台 manager 彻底损坏,做法是:从备份中恢复/var/lib/docker/swarm到新节点。启动 Docker。用docker swarm init --force-new-cluster重新初始化集群,Swarm 会从恢复的 Raft 日志里重建旧状态。这个方案有前置条件:备份的 Raft 日志必须是多数派(比如 3 个 manager 中至少有 2 个的日志还在)才能恢复。所以平时做好备份 保证 manager 节点分布在不同故障域,才是真正的保险。集群销毁相对简单,但顺序有讲究:docker service rm $(docker service ls -q) docker node update --availability drain 每个节点 docker swarm leave --force # 在 worker 上执行 docker swarm leave --force # 在 manager 上执行先删除所有服务,避免 leave 后残留任务在其他节点上失控;然后逐个节点强制 leave。最后清空各节点 Docker 数据目录时,至少要把/var/lib/docker/swarm目录删掉,否则残留的集群状态会影响下一轮重建。这一步每个节点都要执行,别漏。实操心得:集群销毁前,先对所有有状态服务做过数据导出。这个动作看似废话,但真到销毁那天,总有人因为“以为已经备份过了”而丢数据。没确认过“恢复演练成功”的备份,都不算备份。4. 常见问题与排查技巧实录十来个范例跑下来,谁都会在环境里遇到一些奇奇怪怪的问题。这里我整理几个最典型的排查路径,都是从现场问题里提炼的。4.1 节点状态一直是 Down 或 Unknown现象:某台 worker 节点在docker node ls里显示 Down,上面的服务任务也起不来。排查步骤:先确认该节点到 http://manager:2377 的端口通不通。2377是控制面端口,不通的话大概率是防火墙或安全组限制了。再确认该节点到其他节点的7946(TCP/UDP) 和4789(UDP) 端口是否放行。这两个端口分别是 gossip 和 VXLAN 用的,少了任何一个,节点之间的心跳和数据面都会出问题。如果网络没问题,检查该节点 Docker 版本是否和集群其他节点一致。Swarm 对版本不一致容忍度有限,大版本之间很容易出现兼容问题。如果节点已经无法恢复,建议直接docker node rm --force node-id,再重新加入集群。4.2 服务任务一直处于 Pending 状态现象:docker service ls显示副本数符合预期,但docker service ps xxx里一堆 pending。排查思路:先看 pending 任务的 error 信息:docker service ps service --no-trunc,尾部会给出具体原因。最常见的是资源不足、端口冲突、卷挂载失败。资源不足就扩容节点或调低 reserve;端口冲突就在调度约束上把互斥的任务分到不同节点。如果是约束条件(placement constraint)写的太紧,比如必须落在标签为ssdtrue的节点上,但集群里没有满足条件的节点,任务就会一直 pending。检查一下节点的 label 是否存在。经验之谈:出现 pending 不要反复service update --force,先看清楚真正原因再动手。Swarm 不会告诉你“这个任务为什么启动不了”的完整上下文,但 p s 的 error 字段已经把线索给出来了。4.3 滚动更新时服务短暂不可用现象:更新过程中,服务的部分请求 502 或超时。原因多数是健康检查太宽松或更新参数设置不当。我之前遇到过:服务本身启动很慢(比如要加载大模型、连接外部依赖),健康检查设置的间隔和重试次数太短,导致新容器还没就绪就被判为不健康,直接触发回滚;而回滚后的旧版本也被同样对待,整个更新过程一团糟。解决方案是三步:把服务的--health-start-period参数调大,给新容器一段“宽限期”。把--update-delay调到 15~30 秒,让每批次更新之间有充分的稳定观察时间。在服务自身日志中确认启动完成时间,根据实际值设置健康检查的超时和重试次数。4.4 Config 更新不生效现象:更新了 Config,但容器里的配置文件还是旧内容。原因有两类:服务没有被强制重启,新 Config 不会自动注入。执行docker service update --force service即可。多个 Service 引用了同一个 Config,但更新时只更新了其中一个服务的引用。Swarm 的 Config 版本是独立的,每个服务都要显式切换引用版本,我建议在 Config 名称里带上版本号,比如nginx-conf-v2,这样一目了然。4.5 Secret 文件权限问题现象:应用读取/run/secrets/xxx时提示权限不足。Swarm 挂载的 secret 文件默认权限是0444,对普通用户只读。如果应用以非 root 身份运行,读取没问题,但如果应用需要修改该文件(比如某些程序会动态重写配置文件),就会报权限错误。解决方式有两种:在应用镜像里把 secret 文件复制到自定义路径,并调整权限。直接用 Config 代替 Secret,如果内容并不是高度敏感的密钥。Config 默认也是只读,但不会触发和 secret 相关的权限告警。结合我的经验,secret 文件最好只给应用读取,不要在容器内做二次修改,一旦修改,容器的“不可变基础设施”属性就崩塌了。5. 长期运维中的几个关键心得抛开具体命令和参数,真正把一个 Swarm 集群维护好,很大程度上靠的是运维意识和操作习惯。这里分享几个我用血泪换来的原则:第一,变更先备份,升级先观察。Swarm 本身升级比较简单,直接在节点上更新 Docker 版本就行。但要注意顺序:先升级 worker,再逐个升级 manager。每次升级完,观察节点状态是否恢复 Active、服务任务是否被重新调度,再动下一台。一次全部升级,万一新版 Docker 有 bug,整个集群就一起遭殃了。第二,把服务配置视作代码管理。我所有 Swarm 的 service create/update 命令都写成脚本或 Makefile 放在 Git 仓库里,包括 Config 和 Secret 的创建过程。这样做的好处是:任何集群变更都可以追溯,重搭集群时不必靠记忆去还原。第三,定期做故障演练。我每隔一段时间会故意 drain 一台 manager 节点或 kill 一个 worker 上的容器,看看服务是否按预期恢复。不演练,你就不知道自己配的自动回滚、健康检查、调度约束到底有没有真正生效。之前一次演练就发现,我的 Secret 挂载路径写错了,整个服务一直启动失败,如果不是演练,这个问题可能会在真正的故障中才暴露出来。第四,留意 Docker 版本的生命周期。举例来说,Docker Engine 24 和 25 在一些网络细节上对 Swarm 的支持有差异,如果集群节点跨版本太多,Raft 通信的稳定性会受影响。我现在的习惯是:所有节点保持同一个 Docker 小版本,升级时按批次操作,升级后跑一遍核心服务健康检查,然后才继续下一批。第五,关于是否该从 Swarm 迁移到 K8s,我的建议是:如果业务量还没到“Swarm 真心管不过来”的程度,迁移成本远大于收益。Swarm 的简单、直接,本身就是一种生产力。反过来,如果你已经确定未来两年集群规模会翻几倍、计划深度使用自定义调度策略和服务网格,那就早点规划迁移。迁移不是“能用就行”,而是要把服务依赖的网络、存储、日志体系全部梳理清楚,再动手。最后说一个日常最容易忽略的小事:给 Swarm 节点设置统一的时区和主机名规范。看似和编排无关,但在排查日志、分析监控指标时,时区不一致会让你崩溃。节点主机名我统一用role-region-编号的格式,比如worker-01-bj-01、manager-prod-01,这样一眼就能从任务列表中判断服务跑在哪个环境、哪个区域。这些小细节积累起来,全生命周期管理的体感会完全不同。