来两杯美式
返回

Docker 集群演进史：Swarm → Compose → Kubernetes

By 来两杯美式
发布于

本系列前 4 篇把 Docker 单机的能力讲透了——但单机 Docker 撑不起生产级 AI 系统。当你的服务要部署到几十台机器、几百个容器，跨主机调度、自动伸缩、滚动升级、灰度发布、跨节点网络——每一个都是全新的挑战。

这一篇我们走一遍容器编排 10 年的演化历程。它不是技术八卦，而是一堂架构课——理解每个方案为什么出现、又为什么被替代，你才能在自己的项目里做出正确选择。

一、Docker Swarm：编排 1.0（2014-2017）

1.1 出现的背景

2014 年 Docker 1.0 发布后，开发者们迅速意识到：单机 Docker 太舒服，但生产环境不可能只有一台机器。当时 Docker 公司的策略很清晰——「容器是新的进程，编排是新的 init」，Docker 应该像 Linux 内核之于进程一样，做容器世界的底层。

1.2 Swarm 是什么

Docker Swarm 是 Docker 公司在 2014 年底推出的内置集群方案。它把一组 Docker 引擎聚合成一个「虚拟的 Docker 引擎」，对外暴露统一的 API。

# 初始化集群（第一个 init 的节点自动成为 manager/leader）
docker swarm init

# 其他节点加入（worker 角色）
docker swarm join --token <worker-token> <manager-ip>:2377

# 查看节点列表
docker node list

# 创建一个 overlay 网络
docker network create -d overlay --attachable swarm_mysql

# 创建跨主机分布式服务
docker service create --replicas 3 --name web -p 80:80 nginx

1.3 Swarm 的关键设计

1.4 Swarm 的真实使用

在 2015-2017 年间，Swarm 是 Docker 官方主推的方案。当时很多中小团队用它做生产部署——相比自己写脚本维护多台机器，Swarm 已经是巨大的进步。

1.5 Swarm 失利的三个原因

到 2020 年前后，Swarm 在生产环境基本被 Kubernetes 取代。但它作为「容器编排入门」的概念——服务、副本、overlay 网络、声明式 API——全部被 Kubernetes 继承。

二、Docker Compose：单机王者

2.1 定位

如果说 Swarm 是「多机编排」，Compose 就是「单机编排的极致」。在前一篇 《Docker Compose 多容器编排》 我们已经详细讲过——它把一组 docker run 命令浓缩成一份 docker-compose.yml。

2.2 Compose vs Swarm

维度ComposeSwarm
部署范围单机多机集群
学习曲线平缓（一个 YAML 文件）较陡（节点角色、overlay 网络）
适用场景开发、测试、CI、小型生产中型生产（已被 K8s 取代）
现状依然活跃基本停止演进

2.3 为什么 Compose 没死

虽然 Swarm 死了，但 Compose 活得很好——因为它解决了一个 Swarm/Kubernetes 都没解决好的问题：本地开发体验。

docker-compose.yml 是开发环境的事实标准：

Kubernetes 本身有 Kustomize、Helm，但「在笔记本上跑 K8s」始终是个痛点。Compose 凭借极简的语法赢了这个场景。

三、容器编排群雄逐鹿（2014-2017）

容器编排不是只有 Swarm 和 Kubernetes。事实上在 2014-2017 年间，至少有四款主流编排器同时竞争：

3.1 Apache Mesos（2009 启动，2014 引入容器）

3.2 HashiCorp Nomad（2015）

3.3 Docker Swarm（2014）

3.4 Kubernetes（2014 年开源，2015 年 v1.0）

3.5 竞争终局

2017 年 KubeCon 后，Kubernetes 实际上赢得了容器编排之战。到 2020 年，市场上几乎所有新的容器编排项目都选择「运行在 K8s 上」或「与 K8s 集成」，而不是另起炉灶。

四、为什么 Kubernetes 赢了

4.1 设计上：声明式 + 控制循环

Kubernetes 全部 API 都是声明式的——你告诉它「想要什么状态」（比如「3 个副本、CPU > 80% 时扩容」），控制循环持续把「实际状态」向「期望状态」收敛。这种模型对大规模系统极其友好。

4.2 生态上：CNCF 基金会

2015 年 Google 联合 Linux 基金会成立 CNCF（Cloud Native Computing Foundation），把 Kubernetes 捐给了基金会。这一步棋的深远影响是：没有任何一家公司能垄断它的演进方向——AWS 贡献 networking、Red Hat 贡献 operator、华为贡献 edge、CNCF 自己也做培训认证。

4.3 功能上：完整覆盖

4.4 厂商绑定上：避免锁定

Kubernetes 在所有主流云上都是一等公民——EKS（AWS）、GKE（Google）、ACK（阿里云）、TKE（腾讯云）、AKE（百度云）、华为云 CCE。「可移植性」是它击败所有云厂商私有编排器的关键。

五、特殊集群方案：分布式数据库

在 Swarm 主导的 2015-2017 年间，还有一类「应用层集群」方案值得专门讲——它们解决的是有状态服务（特别是数据库）的集群问题，与容器编排平级但目标不同。

5.1 PXC（Percona XtraDB Cluster）

# 拉取 PXC 镜像
docker pull percona/percona-xtradb-cluster

# 启动主节点（必须先初始化集群）
docker run -d -p 9001:3306 \
  -e MYSQL_ROOT_PASSWORD=root_pwd \
  -e CLUSTER_NAME=PXCCluster \
  -e XTRABACKUP_PASSWORD=cluster_pwd \
  -v /root/pxc_data:/var/lib/mysql \
  --privileged \
  --name=pxc-node1 \
  --net=swarm_mysql \
  percona/percona-xtradb-cluster

# 启动从节点（通过 CLUSTER_JOIN 加入）
docker run -d -p 9002:3306 \
  -e MYSQL_ROOT_PASSWORD=root_pwd \
  -e CLUSTER_NAME=PXCCluster \
  -e XTRABACKUP_PASSWORD=cluster_pwd \
  -e CLUSTER_JOIN=pxc-node1 \
  -v /root/pxc_data:/var/lib/mysql \
  --privileged \
  --name=pxc-node2 \
  --net=swarm_mysql \
  percona/percona-xtradb-cluster

PXC 的特性：

5.2 MySQL Replication 集群

# 拉取 replication 镜像
docker pull mishamx/mysql

# 启动主节点
docker run -d -p 9001:3306 \
  -e MYSQL_MASTER_PORT=3306 \
  -e MYSQL_ROOT_PASSWORD=root_pwd \
  -e MYSQL_REPLICATION_USER=repl_user \
  -e MYSQL_REPLICATION_PASSWORD=repl_pwd \
  -v rep_data:/var/lib/mysql \
  --privileged \
  --name=mysql-master \
  --net=swarm_mysql \
  mishamx/mysql

# 启动从节点
docker run -d -p 9002:3306 \
  -e MYSQL_MASTER_PORT=3306 \
  -e MYSQL_ROOT_PASSWORD=root_pwd \
  -e MYSQL_REPLICATION_USER=repl_user \
  -e MYSQL_REPLICATION_PASSWORD=repl_pwd \
  -e MYSQL_MASTER_HOST=mysql-master \
  -v rep_data:/var/lib/mysql \
  --privileged \
  --name=mysql-slave \
  --net=swarm_mysql \
  mishamx/mysql

Replication 的特性：

5.3 PXC vs Replication：何时选哪个

场景推荐理由
金融、订单、账户PXC强一致，零数据丢失
读多写少的报表库Replication一主多从，线性扩展读
全球部署（多机房）Replication异步复制可容忍跨地域延迟
高频写Replication同步等待会拖慢 PXC 写性能

在 Kubernetes 时代：PXC、Replication 这些方案依然有效，但通常通过 Operator 部署（如 Percona Operator for MySQL、MySQL Operator for Kubernetes），由 Operator 处理集群生命周期、备份、恢复、自动故障转移。

六、容器生态的当下与未来

6.1 当下格局

6.2 AI 时代的新趋势

6.3 选型决策树

你的项目需要多机部署吗？
├── 否 → Docker Compose
└── 是
    ├── 需要自动伸缩、滚动更新、跨主机网络？
    │   ├── 是 → Kubernetes
    │   └── 否 → 考虑 K3s（轻量 K8s 发行版，单二进制）
    └── 有特殊 workload（非容器）？
        └── 是 → Nomad

七、系列总结

走到这里，本系列 5 篇就告一段落了。我们走过的路：

  1. 《Docker 入门》：为什么需要容器化
  2. 《Docker 核心概念与安装》：镜像、容器、仓库、Dockerfile + 第一次构建
  3. 《Docker 数据持久化与网络》：Volume + 容器间通信
  4. 《Docker Compose 多容器编排》：声明式管理多容器应用
  5. 本篇：容器编排 10 年演化，理解 Swarm/Compose/K8s/PXC/Replication 的位置

一句话总结：Compose 是开发环境的王者，Kubernetes 是生产环境的标准，PXC/Replication 等应用层集群是有状态服务的搭档。理解它们各自解决的问题和历史定位，你就能在「单机 Compose」和「生产 K8s」之间游刃有余。

分享这篇文章：
通过邮件分享这篇文章✓ 链接已复制
所属专题
Docker
第 5 / 5 篇
›查看系列全部文章
  1. 01.Docker 入门：为什么容器化是 AI 时代的必备技能
  2. 02.Docker 核心概念与安装：镜像、容器、仓库、Dockerfile
  3. 03.Docker 数据持久化与网络：Volume 与容器间通信
  4. 04.Docker Compose 多容器编排：从命令到声明式
  5. 05.Docker 集群演进史：Swarm → Compose → Kubernetes
上一篇
设计模式之状态模式：状态变，行为变
下一篇
Docker Compose 多容器编排：从命令到声明式