swarm集群通过原生命令实现容器跨物理机自动调度，核心是调度器依据节点状态、资源约束和标签策略自主决策。需部署≥3个manager节点确保高可用，打标后用constraint精确控制服务分布，service命令支持扩缩容与滚动更新，故障时自动重建任务并启用路由网格负载均衡。
配置 swarm 集群实现容器跨物理机自动化调度，关键不在“手动分配”，而在于让 swarm 调度器根据节点状态、资源约束和策略自主决策。整个过程不依赖外部工具，全部通过 docker 原生命令完成。
初始化高可用管理节点集群
至少部署 3 个 Manager 节点（如 manager1/manager2/manager3），避免单点故障。每台机器先设好唯一主机名并写入 /etc/hosts，再执行：
- 在首台机器运行：
docker swarm init --advertise-addr 192.168.1.101 - 获取 worker 加入命令：
docker swarm join-token worker - 在其余 Manager 节点上，用
docker swarm join --token SWMTKN-... --advertise-addr 192.168.1.102 manager1:2377加入，并立即提升为 Manager：docker node promote manager2
完成后运行 docker node ls，确认所有节点状态为 Ready Active，且有多个 Leader 或 Reachable 状态的 Manager。
设置节点资源标签与调度约束
Swarm 默认使用 Spread 策略（优先往负载最轻的节点分发任务），但生产环境需结合硬件或业务属性精细化控制。例如：
- 给 SSD 服务器打标：
docker node update --label-add storage=ssd worker1 - 给 GPU 服务器打标：
docker node update --label-add hardware=gpu worker2 - 限制服务只能跑在 SSD 节点：
--constraint 'node.labels.storage == ssd' - 禁止某服务跑在 Manager 节点：
--constraint 'node.role == worker'
标签不是装饰，是调度器实际读取的决策依据。没有标签时，Swarm 仍会自动调度；加上标签后，才真正实现“按需分配”。
定义服务并启用自动扩缩与滚动更新
服务（Service）是 Swarm 的调度单元，副本数、网络、资源限制共同决定调度行为：
- 启动带资源限制的 Web 服务：
docker service create --name web --replicas 4 --limit-cpu 1 --limit-memory 1g -p 80:80 --network my-overlay nginx - 动态扩容：
docker service scale web=8，Swarm 自动选择空闲节点补足副本 - 触发滚动更新：
docker service update --image nginx:alpine web，旧容器逐个停、新容器逐个起，全程服务不中断
只要节点资源充足且满足约束，Swarm 就会在后台完成实例创建、网络接入、健康检查、负载注册全流程，无需人工干预节点选择。
验证调度效果与故障自愈能力
调度是否生效，不能只看命令返回，要查实际分布：
- 查看服务任务分布：
docker service ps web，输出中 NODE 列应显示多个不同主机名 - 模拟节点宕机：关掉 worker1 的 Docker 服务，等待约 30 秒，
docker service ps web会显示部分任务变为 Failed，随后自动在其他可用节点重建 - 检查路由网格是否生效：从任意节点访问
http://，请求应被均衡转发到不同物理机上的容器
自动调度的价值，在于它把“哪台机器跑哪个容器”这个运维问题，转化成“我需要多少副本、满足什么条件”的声明式描述——剩下的交给 Swarm 内核处理。
