docker-swarm-集群完整详解

Docker Swarm 集群完整详解

·9 分钟阅读·3348 字
📋 目录

Docker Swarm 集群完整详解

核心概念 Docker Swarm 是 Docker Engine 原生内置的容器集群编排工具,实现多主机容器统一调度和高可用。

1. 基础定义

Docker Swarm(全称 Swarm Mode)是 Docker Engine 原生内置的容器集群编排工具,从 Docker 1.12 版本起集成进引擎,无需额外安装组件,可以把多台装有 Docker 的服务器统一成一个分布式集群,实现跨主机容器统一调度、高可用、负载均衡、滚动发布。

通俗区分:

  • docker run / docker-compose:仅管理单台机器容器;
  • Docker Swarm:管理多台机器组成的集群,属于容器编排体系(同类竞品 Kubernetes)。

2. 集群架构:两类节点

Swarm 集群所有主机统称为 Node(节点),分为 Manager(管理节点)Worker(工作节点),一台节点可同时兼任两种角色。

2.1. Manager 管理节点(集群控制平面,大脑)

2.1.1. 核心职责

  1. 维护集群全局状态、配置、服务定义;
  2. 通过 Raft 一致性算法 在多台 Manager 之间同步集群数据;
  3. 选举 Leader 主节点,唯一负责调度容器任务;
  4. 接收客户端 docker service 指令,下发任务;
  5. 监控所有节点与容器健康状态,自动自愈。

2.1.2. 高可用规范

生产必须部署奇数个 Manager(3/5台),Raft 要求超过半数节点在线集群才可正常写入配置;
1台 Manager:无高可用,宕机集群不可操作;
3台 Manager:允许1台故障;
5台 Manager:允许2台故障。

2.2. Worker 工作节点(执行层,干活)

  1. 接收 Manager 下发的 Task(容器任务),创建并运行容器;
  2. 持续上报自身资源、容器健康状态给 Manager;
  3. 不参与 Raft 投票、不存储完整集群元数据;
  4. 默认 Manager 同时也是 Worker,可设置纯管理节点不跑业务容器。

3. 三大核心抽象概念(调度最小单元层级)

3.1. Service(服务,顶层定义)

对应业务应用,描述期望状态:镜像、副本数量、端口、网络、资源限制、更新策略。
命令:docker service create,等价 K8s Deployment。
示例:一个 Nginx 服务,期望运行5个容器副本。

3.2. Task(任务,调度最小单位)

Service 的单个实例,Swarm 调度的最小单元;
一个 Service 对应 N 个 Task,每个 Task 只会被调度到一个节点,一一对应一个容器。
容器异常退出 → Manager 新建 Task 补副本,实现自愈。

3.3. Container(容器)

Task 在节点上最终创建的运行时载体。

层级关系:
Service(业务蓝图) → 多个Task(调度单元) → 每个Task生成一个容器

4. 核心底层机制

4.1. Raft 一致性算法(Manager 集群核心)

  • 所有集群配置(服务、网络、节点标签)只写入 Leader;
  • Leader 同步日志到其他 Manager,过半节点同步成功才确认生效;
  • Leader 宕机,剩余 Manager 自动重新选举新 Leader,集群不中断。
  • 集群元数据持久化在各 Manager 本地磁盘,无独立 etcd 组件(对比 K8s)。

4.2. Scheduler 调度器(容器分配策略)

Leader 内置调度器,3种内置节点打分策略,自动选择最优节点部署 Task:

  1. spread(默认均衡)
    优先选择当前运行容器最少的节点,容器均匀分散,单节点故障影响最小,生产首选。
  2. binpack(装箱压缩)
    尽可能把容器挤在少量节点,节省机器资源,适合资源紧张环境。
  3. random(随机)
    随机分配,仅用于测试调试。

支持自定义节点标签约束、资源过滤(CPU/内存),只把服务调度到匹配节点。

4.3. Routing Mesh 内置集群负载均衡

Swarm 自带四层负载均衡,无需额外 Nginx:

  1. 集群任意节点开放服务端口,流量自动转发到所有副本;
  2. 跨主机容器自动互通,内置 overlay 覆盖网络;
  3. 支持端口发布、会话保持、流量转发。

4.4. Overlay 跨主机网络

集群全局虚拟网络,不同节点上的容器直接内网互通,自动分配虚拟IP,天然支持服务发现。

5. 集群核心能力

  1. 一键集群初始化/扩容
# 初始化集群,生成manager
docker swarm init
# 节点加入集群(worker/manager两种token)
docker swarm join
  1. 自愈故障恢复
    节点宕机、容器崩溃,Manager 自动在其他健康节点新建 Task,维持副本数。
  2. 滚动零停机更新
    支持分批更新、暂停回滚、更新间隔控制,灰度发布。
  3. 弹性扩缩容
    一条命令增减副本:docker service scale nginx=10
  4. 内置服务发现
    集群内服务名称直接 DNS 解析,无需注册中心。
  5. 原生密钥、配置管理
    docker secretdocker config,安全存储密码、配置文件,不暴露到镜像。
  6. 统一存储卷管理
    支持跨节点共享存储卷。

6. Swarm vs Kubernetes 核心区别(运维面试高频)

对比维度Docker SwarmKubernetes
架构复杂度极简,内嵌Docker,无额外组件重,etcd/apiserver/controller/scheduler多组件
学习成本极低,复用原有docker命令极高,大量CRD、yaml新概念
资源占用轻量,低配机器可跑资源开销大,至少3台节点起步
功能丰富度基础编排够用,无StatefulSet、Ingress完善生态企业级完整:StatefulSet、CRD、服务网格、多租户、GPU调度、自动HPA
适用规模小规模集群、边缘、测试环境、内部工具大型微服务、AI算力集群、生产核心业务
自动扩缩容仅支持手动scale,无基于CPU/内存自动HPA内置HPA,支持自定义指标弹性
存储网络基础overlay/卷,扩展弱CSI持久化、多种CNI网络策略隔离

7. 适用场景 & 不推荐场景

7.1. 适合使用 Swarm

  1. 小型业务、测试/预发环境、内部管理工具;
  2. 边缘设备、ARM低配置服务器(资源有限);
  3. 团队仅掌握 Docker,无专人维护复杂 K8s;
  4. 短期快速交付、简单单体/少量微服务。

7.2. 不推荐使用 Swarm

  1. 大规模线上核心业务、上百服务复杂微服务;
  2. AI训练/推理集群(需要GPU调度、Gang调度、StatefulSet);
  3. 需要多租户、细粒度RBAC权限、完善监控告警生态;
  4. 要求基于负载自动弹性扩缩容、灰度金丝雀发布。

8. 优缺点总结

8.1. 优点

  1. 零额外安装,Docker 原生自带,一条命令搭建集群;
  2. 命令与单机 Docker 高度统一,学习曲线平缓;
  3. 架构极简,故障排查简单,维护成本低;
  4. 内置负载均衡、overlay网络、密钥管理,开箱即用。

8.2. 缺点

  1. 生态单薄,第三方插件少;
  2. 无原生自动HPA,只能手动扩缩;
  3. 无完善有状态应用支持(无独立StatefulSet抽象);
  4. 大规模集群调度性能、容错能力弱于 K8s;
  5. 缺乏多租户、精细网络安全隔离能力。

9. 面试精简背诵版

  1. Docker Swarm 是 Docker Engine 内置原生集群编排,多台Docker主机组成集群,分为Manager管理节点(Raft一致性同步状态,选Leader调度)、Worker工作节点(运行容器)。
  2. 三层抽象:Service(期望副本)→ Task(调度最小单元)→ Container;
  3. 内置Routing Mesh负载均衡、Overlay跨主机网络、三种调度策略,自动故障自愈、滚动更新;
  4. 轻量易上手,适合小规模/边缘环境;功能弱于K8s,不适合大型微服务、AI算力集群。