1. 为什么我还在用 Docker Swarm 而不是 K8s
先把结论摆在前面：这套 Swarm 集群我用了快两年，跑着十几个生产服务，日均处理几十万次请求，中间除了两次硬件故障触发自动迁移，没有因为编排层本身挂过。这不是说 Swarm 比 K8s 强，而是想说——选型这件事，合适比先进重要得多。
我最初接触容器编排是从 K8s 开始的，文档啃了一大堆，集群也搭起来了，但真正要维护的时候发现问题来了：团队里没人能完全吃透那一堆 CRD、Operator、Ingress Controller 的组合拳，出问题排查链路太长。后来一个内部项目需要快速上线，规模不大——三台机器、七八个服务、日请求量也就几万——我抱着试试看的心态用了 Swarm，结果一用就是两年。
Swarm 的核心价值在于：它是 Docker 原生自带的编排能力，不需要额外装一堆组件，学习曲线几乎是平的。你只要会写docker-compose.yml，稍微改几个字段就能变成docker stack deploy的部署文件。对于中小规模、服务数量在几十个以内、团队没有专职运维的场景，Swarm 的投入产出比高得离谱。
这篇文章我会把整套部署过程拆开讲清楚：从集群初始化、节点管理、网络规划、存储方案，到服务编排、滚动更新、监控告警，再到实际踩过的坑和排查思路。适合那些手上有几台服务器、想把服务容器化但不想被 K8s 复杂度劝退的开发者，也适合已经用了 Swarm 但想看看有没有更优实践的朋友。
提醒一句：Swarm 不是银弹。如果你的服务规模到了几百个微服务、需要精细的流量治理和自动扩缩容策略，那还是老老实实上 K8s。但如果你的场景是"十几台机器跑几十个服务"，Swarm 能让你少掉很多头发。
2. 集群规划与初始化：动手之前先想清楚这几件事
2.1 节点角色怎么分，管理节点到底要几个
Swarm 的节点分两种角色：Manager（管理节点）和Worker（工作节点）。Manager 负责集群状态维护、任务调度、API 响应；Worker 只负责跑容器。这里有个关键点很多人会忽略：Manager 节点默认也可以跑任务，但生产环境我强烈建议把 Manager 设为"只管理不干活"。
为什么？因为 Manager 节点要维护 Raft 一致性协议，节点之间需要频繁通信同步状态。如果 Manager 上还跑着吃 CPU 和内存的业务容器，一旦负载高了，Raft 心跳超时，集群可能触发重新选举，严重的时候整个集群会短暂不可用。我踩过这个坑——早期把 Manager 和 Worker 混在一起，某次一个 Java 服务内存泄漏把节点压垮，连带集群管理都出了问题。
Manager 节点数量有个硬性要求：必须是奇数，推荐 3 个或 5 个。原因是 Raft 协议需要多数派（Quorum）才能完成写操作。3 个 Manager 能容忍 1 个挂掉，5 个能容忍 2 个挂掉。2 个 Manager 反而比 1 个更脆弱，因为任何一台挂了都凑不齐多数派。我现在的配置是 3 个 Manager + N 个 Worker，Manager 配置不高（2C4G 足够），Worker 根据业务负载来定。
节点规划建议用表格理清楚：
| 节点角色 | 数量 | 配置建议 | 职责 | 是否跑业务 |
|---|---|---|---|---|
| Manager | 3 | 2C4G | 集群管理、调度、API | 否 |
| Worker | 按需 | 按业务定 | 运行容器任务 | 是 |
| Manager+Worker | 不推荐 | - | 混合 | 是 |
2.2 网络规划：Overlay 网络的坑比你想的多
Swarm 内置了 Overlay 网络，让不同节点上的容器能像在同一台机器上一样通信。听起来很美好，但实际用起来有几个必须提前规划的点。
第一，Overlay 网络会带来额外的封装开销。容器间的跨节点通信会经过 VXLAN 封装，MTU 会从默认的 1500 降到 1450 左右。如果你的应用对 MTU 敏感（比如某些老旧的 RPC 框架），可能会出现大包丢失、连接卡顿的问题。我的做法是：能走 host 网络的就走 host，必须跨节点通信的才用 Overlay。
第二，Overlay 网络的加密选项要慎用。--opt encrypted会启用 IPSec 加密，安全性提升但性能下降明显，实测吞吐量会掉 30% 以上。内网环境如果本身已经隔离得比较好，没必要开这个。
第三，服务发现依赖 DNS 轮询。Swarm 内置的 DNS 会把服务名解析到所有副本的 IP，客户端拿到的是轮询结果。这意味着它没有健康检查感知——如果某个副本挂了但还没被调度器剔除，DNS 可能还会返回它的 IP。所以应用层最好自己做重试和熔断。
我一般会创建两个网络：一个frontend给对外服务用，一个backend给内部服务通信用。这样既能隔离流量，又方便后面做网络策略。
# 创建 overlay 网络 docker network create \ --driver overlay \ --subnet 10.0.10.0/24 \ --attachable \ backend docker network create \ --driver overlay \ --subnet 10.0.20.0/24 \ --attachable \ frontend--attachable这个参数很关键，加上之后单机的普通容器也能接入这个网络，方便调试。
2.3 存储方案：数据持久化到底怎么选
这是 Swarm 相比 K8s 最弱的一环。K8s 有 PV/PVC/StorageClass 一整套抽象，Swarm 只有volume和bind mount两种，而且默认不支持跨节点共享存储。
我的实践经验是分场景处理：
- 无状态服务：直接用 volume 或者不持久化，随便调度到哪台机器都行。
- 有状态但单副本的服务（比如某些定时任务）：用节点标签约束把服务固定到特定节点，然后用 bind mount 挂本地盘。
- 需要跨节点共享数据的服务（比如多个副本要读同一份文件）：必须自己搭 NFS 或者用云厂商的共享存储，然后所有节点都挂载同一个目录，再用 bind mount 引用。
节点标签约束的用法：
# 给节点打标签 docker node update --label-add storage=ssd node-01 # 在 stack 文件中约束 deploy: placement: constraints: - node.labels.storage == ssd注意：Swarm 的 volume 默认是 local driver，数据只存在容器所在节点。如果服务重新调度到别的节点，数据就"丢"了。有状态服务一定要配合约束使用，或者上共享存储。
3. 核心部署实操：从零到跑起第一个服务
3.1 初始化集群与加入节点
在选定的第一台 Manager 上执行：
docker swarm init --advertise-addr 10.0.0.1--advertise-addr必须指定，否则多网卡机器上 Swarm 可能选错网卡，导致其他节点连不上。执行完会输出加入集群的命令，分 Manager 和 Worker 两种 token。
在另外两台 Manager 上执行docker swarm join --token SWMTKN-xxx 10.0.0.1:2377，然后回到第一台机器把新加入的 Manager 提升为管理角色（其实用 manager token 加入的自动就是 Manager）。
Worker 节点用 worker token 加入即可。
验证集群状态：
docker node ls应该能看到所有节点，Manager 节点前面有Leader或Reachable标记。
3.2 编写 stack 文件：比 compose 多了什么
Swarm 的部署文件本质上是 compose 文件的超集，多了deploy这一层。我拿一个典型的 Web 服务举例：
version: "3.8" services: web: image: nginx:1.25-alpine ports: - "80:80" networks: - frontend deploy: replicas: 3 update_config: parallelism: 1 delay: 10s order: start-first restart_policy: condition: on-failure max_attempts: 3 resources: limits: cpus: "0.5" memory: 256M placement: constraints: - node.role == worker api: image: myapp/api:v1.2.0 networks: - backend environment: - DB_HOST=db deploy: replicas: 2 resources: limits: cpus: "1.0" memory: 512M networks: frontend: external: true backend: external: true几个关键字段解释一下：
update_config.order: start-first是滚动更新的策略。默认是stop-first，先停旧容器再起新的，会有短暂的服务中断。改成start-first会先起新容器，健康后再停旧的，实现零停机。但要注意端口冲突——如果服务占用了固定 host 端口，start-first会因为端口被占而失败，这时候只能用stop-first。
resources.limits是硬限制，超过会被 OOM Kill 或者 CPU 被限流。Swarm 不支持 requests（K8s 有），所以调度时不会预留资源，这点要注意——可能出现多个重负载服务被调度到同一节点的情况。
placement.constraints用来控制调度位置。node.role == worker确保业务不会跑到 Manager 上。
3.3 部署与更新：命令背后的逻辑
部署：
docker stack deploy -c stack.yml myapp更新服务（改了镜像版本后）：
docker stack deploy -c stack.yml myappSwarm 会自动对比差异，只更新变化的服务。查看更新进度：
docker service ps myapp_web --no-trunc会看到新旧任务的交替过程。如果更新卡住了，可以回滚：
docker service rollback myapp_web实操心得：滚动更新时
parallelism不要设太大。我一般设 1，最多 2。设太大如果新版本有问题，会瞬间大面积故障。delay给 10-30 秒，留出健康检查的时间窗口。
3.4 健康检查配置：别让坏容器继续接流量
Swarm 支持 HEALTHCHECK，但和 K8s 的 liveness/readiness 探针不一样——Swarm 的健康检查不会自动重启不健康的容器，也不会把它从负载均衡里摘除。它只是标记状态，需要配合restart_policy或者外部工具使用。
healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/health"] interval: 30s timeout: 5s retries: 3 start_period: 40sstart_period很重要，给应用启动留出时间，避免刚启动就被判定为不健康。我见过有人没设这个，Java 应用启动要 30 秒，结果健康检查 10 秒就失败，容器被反复重启。
4. 监控、日志与故障排查实录
4.1 监控方案：Prometheus 怎么接进来
Swarm 本身没有内置监控，需要自己搭。我的方案是cAdvisor + Node Exporter + Prometheus + Grafana。
cAdvisor 负责采集容器指标，但它有个问题：在 Swarm 模式下，cAdvisor 只能看到本节点的容器。所以需要在每个节点都部署一个 cAdvisor，用global模式：
cadvisor: image: gcr.io/cadvisor/cadvisor:latest volumes: - /:/rootfs:ro - /var/run:/var/run:ro - /sys:/sys:ro - /var/lib/docker/:/var/lib/docker:ro deploy: mode: global resources: limits: memory: 256Mmode: global表示每个节点都跑一个副本，这是 Swarm 特有的模式，非常适合监控代理这类服务。
Prometheus 配置里用dns_sd_configs自动发现 Swarm 服务：
scrape_configs: - job_name: 'cadvisor' dns_sd_configs: - names: - 'tasks.cadvisor' type: 'A' port: 8080tasks.cadvisor是 Swarm 内置的 DNS 记录，会返回所有副本的 IP。
4.2 日志收集：别再用 docker logs 了
docker logs在单机时代够用，但集群环境下你要一台台机器去查，效率极低。我的做法是接入Loki + Promtail，轻量且和 Grafana 集成好。
Promtail 同样用global模式部署，采集/var/lib/docker/containers下的日志文件。配置里加上 Swarm 的元数据标签，这样在 Grafana 里可以按服务名、节点、任务 ID 过滤。
踩坑记录：Docker 默认的 json-file 日志驱动如果不限制大小，日志会把磁盘撑爆。一定要在
/etc/docker/daemon.json里配置：
{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } }改完要重启 Docker 才生效，而且只对新容器生效，老容器需要重建。
4.3 常见问题速查表
| 现象 | 可能原因 | 排查命令 | 解决思路 |
|---|---|---|---|
| 服务一直 Pending | 资源不足或约束不满足 | docker service ps --no-trunc | 检查节点资源、约束条件 |
| 容器反复重启 | 健康检查失败或 OOM | docker inspect <container> | 调整健康检查参数或内存限制 |
| 跨节点通信失败 | Overlay 网络问题 | docker network inspect | 检查 MTU、防火墙 4789/7946 端口 |
| 更新卡住不回滚 | 更新策略配置问题 | docker service inspect | 手动 rollback 或调整 parallelism |
| Manager 失联 | Raft 心跳超时 | docker node ls | 检查网络延迟、Manager 负载 |
| DNS 解析失败 | 服务名拼写或网络隔离 | docker exec <c> nslookup <svc> | 确认服务在同一网络 |
4.4 独家避坑技巧
技巧一：用docker node promote/demote做 Manager 维护。需要重启 Manager 时，先把它 demote 成 Worker，等维护完再 promote 回来，避免影响 Raft 多数派。
技巧二：服务名不要用下划线。Swarm 的 DNS 解析对下划线支持不好，用中划线更稳妥。
技巧三：定期清理未使用的镜像和 volume。Swarm 不会自动清理旧镜像，时间长了磁盘会满。写个定时任务：
docker system prune -af --filter "until=168h"技巧四：docker stack deploy是幂等的，可以放心重复执行。但要注意它会覆盖手动改的配置，所以所有变更都要落到 stack 文件里，别手动docker service update。
技巧五：节点下线前先 drain。docker node update --availability drain node-01会把该节点上的任务迁移到其他节点，避免服务中断。
5. 这套方案后续还能怎么扩展
跑通基础部署之后，我陆续加了一些东西让整套体系更完善。一是加了 Traefik 做反向代理和自动 HTTPS，通过监听 Docker socket 自动发现服务，打上 label 就能暴露，比手动配 Nginx 省事很多。二是接入了 Watchtower 做镜像自动更新，配合 CI 推送新镜像后自动滚动更新，适合开发环境。三是用 Portainer 做可视化管理，虽然命令行够用，但有个 Web 界面看集群状态确实方便，尤其是给团队其他人用的时候。
如果规模继续增长，下一步可以考虑把有状态服务拆出去用独立数据库，Swarm 只跑无状态应用，这样调度会简单很多。再往上如果真到了 Swarm 撑不住的量级，迁移到 K8s 也不是从零开始——compose 文件转 K8s manifest 有现成工具，网络和存储的概念也有对应关系，过渡成本比想象中低。
我个人在实际操作中的体会是：编排工具的选择应该服务于团队的实际能力，而不是反过来让团队去追工具。Swarm 让我把精力放在业务上而不是基础设施上，这两年的时间省下来，够我多迭代好几个版本了。
