企业官网建设流程全解析

如果让我用一个词来形容2014到2019年之间的容器编排器之争，我会说：这是一场还没有真正拉开大幕，就已经结束了的战斗。Kubernetes、Docker Swarm、Apache Mesos这三条技术路线同时在容器编排器这条赛道上竞速，当年很多人都在等着看一场旗鼓相当的硬仗，但实际的发展轨迹几乎是一边倒。Swarm 和 Mesos 并不是输在某个功能点上，而是输在接口策略、社区结构和技术理念的底层差异上。这篇文章想以我这些年在生产环境中摸爬滚打的视角，把这场战斗从头复盘一遍，也顺便聊聊我在切换技术栈时踩过的坑，以及这场竞争留给普通技术人的经验教训。

无论你当年是站 Swarm 的老运维，还是从一开始就押注 Kubernetes，我觉得这篇文章都不妨一读。它不只是讲谁赢了谁输了，更想讲清楚一个问题：为什么有些技术还没有开打，就已经分出了胜负。

1. 容器编排器这条赛道，为什么会在2014年前后突然拥挤

1.1 容器从“跑起来”到“管起来”：编排器的诞生逻辑

容器技术刚火起来那两年，大家最兴奋的是“一次构建，到处运行”。一个镜像打出来，无论在开发机还是生产服务器上，docker run一下就能跑起来，这比传统虚拟机快太多。我在2015年前后接手公司容器化改造时，最初的思路也很单纯：把每个服务打包成镜像，写个脚本批量启动就完事了。

但规模一上来，问题就来了。假设你只有三五台机器、二三十个容器，确实可以靠脚本和自制表格管理。可当你面对几十台服务器、几百个容器时，就会遇到一连串绕不开的问题：容器应该调度到哪台机器上？某台节点宕机了，容器会不会自动在其他机器恢复？A 服务怎么通过服务名找到 B 服务？滚动更新期间如何保证访问不中断？配置文件改了之后，怎么让所有实例同步感知？

这些问题加在一起，就是容器编排器要解决的核心命题：大规模容器的生命周期管理。它至少涵盖调度、服务发现、负载均衡、自愈、滚动更新、配置管理这几件事。我常拿物流调度中心来类比：容器像货物，每台服务器像仓库，只招几个人的时候，你自己开着叉车就能搞定配送；可货物上千件、仓库几十个之后，没有调度中心就只能靠运气。编排器就是这个调度中心。

1.2 赛前的三张入场券：Swarm、Mesos、Kubernetes

2014年到2015年是容器编排器最热闹的窗口期，三张最有分量的入场券分别握在 Docker、Mesos 和 Kubernetes 手里。

Docker Swarm 的出身最“根正苗红”，它由 Docker 官方推出，核心理念是“让编排像 Docker 本身一样简单”。在 Docker 1.12 之前，Swarm 还是一套独立集群工具；到了 Docker 1.12，Docker 直接把 Swarm Mode 内置进引擎，你只要用docker swarm init和docker service create就能拉起一个集群，学习路径几乎为零。它最大的优点是复用 Docker API，操作习惯和单机保持一致，缺点则是抽象能力偏弱，集群扩展有上限，生态也比较封闭。

Apache Mesos 则来自大数据圈子。它本来是加州大学伯克利分校 AMPLab 为了解决 Hadoop、Spark 等计算框架的资源共享问题而做的资源管理器。Mesos 把 CPU、内存、磁盘等资源池化，再通过框架（Framework）机制分配到不同上层应用。跑在 Mesos 上的 Marathon 负责管理长时间运行的服务，所以也可以当成容器编排器来用。Mesos 的资源调度效率很高，集群规模能到万级节点，但架构极重，组件多，概念多，一般团队很难驾驭。

Kubernetes 是 Google 基于内部 Borg 和 Omega 系统的经验打造的，2014年开源。它不像 Swarm 那样讨好“老 Docker 用户”，而是从一开始就引入了 Pod、Service、Label、ReplicaSet 这一整套新概念，还是以 API 为核心来驱动系统。早期学习曲线比较陡，但设计体系相当完整，也为后续大量生态项目预留了空间。后来我也慢慢理解，这种“陡峭”其实是用一次学习成本换来了更强大的表达力。

三者对比下来，Swarm 像电动车，好上手，城市通勤没问题，但跑长途货运就力不从心；Mesos 像重型卡车，能装很多货，但你需要配备专门的司机团队来伺候它；Kubernetes 则更像一整套物流系统，初看复杂，但它能用标准接口容纳各种车辆、仓库和配送方式。

1.3 被忽视的旁观者：Nomad、Rancher 和云厂商平台

除了这三家，旁观席上其实还有几个角色。HashiCorp 在2015年发布了 Nomad，主打单二进制部署，支持 Docker、QEMU、Java 等多种工作负载，调度能力也非常强。但 Nomad 的定位始终更偏向“调度器”，在服务发现、配置管理、应用发布这些“应用平台”能力上，它选择依赖 Consul、Vault 等自己生态里的其他产品，而不是做成一套统一的编排体系。我觉得这是 Nomad 当时没进入核心战局的重要原因。

Rancher 也是一个很有意思的变量。它起家的时候不是自己造编排器，而是做“容器管理平台”，早期对 Swarm、Kubernetes、Mesos 都有支持。但在2018年发布的 Rancher 2.0，它全面转向 Kubernetes 底座。这个选择本身就说明问题：连那些想“中立地管多种编排器”的平台，最后都意识到只能梭哈其中一家。云厂商也一样，各大公有云在2017年前后陆续推出托管的 Kubernetes 服务，由此彻底终结了“编排器仍在争论期”的局面。

2. 决定胜负的三个关键节点

2.1 接口标准：Kubernetes 如何用 CRI/CNI/CSI 打开生态

容器编排器之战里，Kubernetes 做得最聪明的一件事就是定义接口，而不是绑定具体实现。它自己并不关心你用的是哪个容器运行时、哪家网络方案、哪种存储插件，只要你实现了它约定的标准接口，就能无缝接入。

容器运行时层面有 CRI（Container Runtime Interface），网络层面有 CNI（Container Network Interface），存储层面有 CSI（Container Storage Interface）。这三个接口的威力在于：它们把“编排器”和“底层组件”彻底解耦。你用 Flannel、Calico 还是 Cilium，只取决于你的网络需求，而不是被编排器锁死。你用 containerd、CRI-O 还是其他运行时，只要满足 CRI 就能被调度。这种“可插拔”的设计，让所有人的创新都能长在 Kubernetes 身上。

反观 Swarm，它绑定在 Docker Engine 里，网络和存储方案虽然也能用插件，但整体设计是以 Docker 为中心的。用起来方便是方便，可一旦你把问题从“跑容器”提升到“搭一套容器平台”，这种绑定就开始显得碍手碍脚。生态位的差距就是从这里拉开的：当所有人的目光从“用 Docker 跑容器”转向“用 Kubernetes 搭建平台”时，谁的边界更开放，谁就能吸收最多的生态力量。后来 Kubernetes 甚至通过 CRI 把 Docker 从核心运行时变成了“可选项”，这一步对整个战局来说是决定性的。

2.2 设计哲学：声明式 API 为什么比命令式服务抽象更有生命力

Kubernetes 还有一个让我后来非常着迷的设计，就是声明式 API。它不是告诉系统“去创建5个副本”，而是告诉系统“我希望有5个副本”。Controller 会持续观察当前状态，一旦发现实际状态和期望状态不一致，就会自动触发动作，直到把它修正回来。这种控制循环模型在分布式系统里非常优雅，因为它天然具备自愈能力。节点挂了，控制器看到副本数不足，就立刻在别的节点上补起来。

Swarm 虽然是服务抽象，但从 API 模型看仍然偏命令式。你执行的是一条创建服务、扩容副本的命令，系统也会努力维持副本数量，但它的资源模型相对单薄，缺少像 Deployment、Service、ConfigMap、Ingress、NetworkPolicy 这样面向不同场景的资源表达。我举个具体的例子：Kubernetes 做金丝雀发布，可以通过 Deployment 和 Service 的 label selector 控制流量走向，配合 Ingress 的流量权重调整，整个过程都在 API 对象里显式表达；Swarm 的滚动更新也能做，但你要做到更复杂的灰度、分批暂停、精细回滚，就得自己写很多外围脚本。

API 的抽象层级决定了上层生态能长多高。Kubernetes 的声明式模型和丰富的资源类型，让 Helm、Operator、GitOps 这些实践都有了发挥空间。一个技术如果能承载“更复杂的表达”，它就能吸引更多工具在它上面生长；工具越多，用户的迁移成本就越高，后来者想要弯道超车的难度就越大。

2.3 社区与厂商：从“多家押注”到“全体站队”

技术竞争到后期，拼的往往不是代码，而是社区和厂商的密度。Kubernetes 在开源之后就捐给了 CNCF（Cloud Native Computing Foundation），这意味着它不再属于 Google 一家，而是由基金会治理。Red Hat 基于它做 OpenShift，IBM 收编 Red Hat 之后继续大举押注，VMware、CoreOS 等企业也都投入了资源，各大云厂商更是把托管 Kubernetes 作为标准产品去推。

社区形成了一种“复利效应”：每一个新的开源项目，比如 Helm、Prometheus、Istio、Knative，都优先支持 Kubernetes；支持得越好，用户越愿意迁移过来；用户越多，反过来又吸引了更多项目。而 Swarm 几乎只有 Docker 一家在维护，社区热度和代码演进速度在2018年开始明显掉队；Mesos 虽然也有一批铁粉，但核心维护方太少，生态丰富度完全跟不上。

我到现在还记得2017年 Docker 官方宣布在自己的企业版里支持 Kubernetes 时，那种说不出话的心情。连“对手”自己都在拥抱 Kubernetes，这已经说明问题——不是 Docker 不想打，而是生态的吸引力和商业的现实压力让它根本没法继续打下去。到2018年 Kubernetes 从 CNCF 毕业时，市场上再谈 Swarm 和 Mesos，基本就只剩下“怀旧”和“迁移”两个话题了。

3. “还没拉开大幕就结束了”到底发生在哪一刻

3.1 一张时间表看 Kubernetes 如何从开源走向定局

我这两年复盘这场战争时，习惯用时间线把关键节点列出来，它比很多抽象讨论都更直观：

• 2013年：Docker 开源并迅速引爆容器化概念，人人都在讨论镜像和容器。
• 2014年6月：Google 开源 Kubernetes，背后是 Borg/Omega 多年的内部实践。
• 2014年底：Docker Swarm 发布，Mesos 也开始进入容器调度领域。
• 2015年：CNCF 成立，Kubernetes 作为首个项目被捐入基金会；Docker 1.12 内置 Swarm Mode 则是在2016年。
• 2017年：Docker 企业版宣布支持 Kubernetes；Rancher 等平台陆续转向 Kubernetes 底座；各大云厂商托管 Kubernetes 服务成标配。
• 2018年3月：Kubernetes 成为 CNCF 第一个毕业项目，生态版图基本定稿。
• 2019年起：Mesosphere 转向 DC/OS 企业市场，Docker 将容器运行时相关技术逐步移交给社区，通用容器编排之争进入尾声。

如果你认真看这份时间表，会发现一个残酷的事实：2016年到2017年，胜负实际已经落定。所谓“战斗”，其实只有短短两三年。很多团队可能还在办公室里争论 Swarm 简单还是 Kubernetes 复杂，外围的生态、厂商、社区已经用脚投票完毕。这就是我说“还没有拉开大幕就结束了”的含义：大家本来以为会有一场势均力敌的冠军赛，结果裁判还没来得及吹开场哨，赢家就已经穿好冠军外套了。

3.2 Docker 的失焦：被自己的成功和商业路径困住

Docker 的失败并不是“技术不行”，而是它的注意力和商业模式被分散了。Docker 公司那几年不仅要维护开源引擎，还要运营 Docker Hub、推 Docker Enterprise，同时还得应付容器行业快速变化带来的商业模式转型。公司精力是有限的，当 Swarm 需要持续投入来对抗 Kubernetes 时，Docker 却要同时打多场仗。

更关键的是，Kubernetes 最初其实非常依赖 Docker Runtime，可后来 CRI 接口一出，Docker 的位置就变得“可以替换”了。我记得 Kubernetes 在 v1.20 宣布弃用 dockershim、并在 v1.24 正式移除的时候，很多人第一反应是“以后还能不能直接用 docker 命令了”。事实上，Docker 命令只是一个客户端，真正运行容器的是 containerd 这类运行时。Kubernetes 通过 CRI 把运行时标准握在自己手里，等于是顺手把 Docker 从“不可替代的核心”变成了“可以替换的一环”。Docker 在编排器之战里输掉就算了，连运行时这个老家都有点站不住脚，这是我当时完全没想到的。

这段历史给我的感觉是：一个公司如果被自己的既有优势捆住手脚，往往很难在下一场技术浪潮里继续领先。Docker 在“让容器跑起来”这件事上做到了极致，但“让容器在平台上跑好”这件事，它有太多包袱。

3.3 Mesos 的错位：资源调度不等于业务编排

Mesos 没赢下通用容器编排市场，我觉得核心问题是“错位”。Mesos 最擅长的是资源调度，也就是把一堆机器的 CPU、内存、磁盘统一抠出来，按需分配给上层框架。这个模型适合大数据作业，因为一个 Spark 任务可能需要数百台机器同时并行，用完资源马上释放，Mesos 能把碎片资源集中再利用，效率很高。但微服务应用平台需要的是另一套东西：服务发现、配置下发、滚动发布、网络策略、多租户隔离、运维可观测。这些能力在 Mesos 的世界里都要靠 Marathon 和一堆外围组件拼凑，体验就像是自己安装操作系统里的每一个驱动。

另外，社区话语权也决定了技术传播的路径。Mesos 的话语权主要在大数据和分布式计算圈，而容器编排器的用户群是更广泛的运维和基础架构团队。当这些人想找一个“用 YAML 描述应用状态”的工具时，Kubernetes 给出的答案显然更符合直觉。后来我也跟一些用 Mesos 的老前辈聊过，他们承认 Mesos 在超大规模调度上至今依然有优势，但通用场景里，没人为它的复杂性和社区规模买单。资源调度能力和业务编排能力是两回事，这是 Mesos 给所有后来者留下的一课。

4. 亲历者视角：三个编排器在生产环境里的真实手感

4.1 Swarm 的上手体验：简单是真的简单，天花板也是真的低

2016年我第一次用 Swarm Mode 时，感觉确实舒爽。docker swarm init --advertise-addr 10.0.0.10初始化集群，然后一条docker service create --name web --replicas 3 --publish published=80,target=80 nginx:1.16就把服务拉起来了。整个操作过程不需要学新概念，不需要写 YAML，几分钟就能建出一个像模像样的集群。对小团队、小项目来说，这种体验非常友好。

但随着服务数量增长，我开始感觉到 Swarm 的表达力不够。比如我想对不同的服务做不同的滚动更新策略，或者按自定义指标做水平伸缩，Swarm 的支持都比较有限。它的服务抽象太简单，上层工具很难在它身上做二次开发。更麻烦的是网络策略细化、多集群管理这些进阶需求，Swarm 基本只能靠外部方案硬凑。我后来开玩笑说，Swarm 适合“服务数量不超过二三十个”的场景，再往上走，你就要开始跟它笨拙的抽象搏斗了。

4.2 Kubernetes 的复杂度：组件多，但表达力强

Kubernetes 刚上手时，我被它那套组件吓到了。API Server、Controller Manager、Scheduler、etcd、kubelet、kube-proxy，每个都是独立的可执行文件，还需要搭配 CNI 插件，第一次部署难免手足无措。早期的 kubeadm 也不像现在这么成熟，我踩过很多环境初始化的坑。但一旦你理解了它的模型，写一个 Deployment 并把它跑起来，你立刻会感受到声明式 API 带来的清晰感。

比如我经常会用一个很简单的 YAML 部署服务：

apiVersion: apps/v1 kind: Deployment metadata: name: web spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.16 ports: - containerPort: 80

配合kubectl get pods、kubectl rollout status deployment/web、kubectl set image这些命令，你能很清楚地看到整个系统如何在一个控制循环里运作。想更新镜像，修改 YAML 后kubectl apply；想回滚，kubectl rollout undo deployment/web。整个操作过程有状态、有记录、可审计，这对生产环境和团队协作太重要了。Swarm 的docker service update虽然也能发布，但它的可观测性、扩展性和生态工具链跟 Kubernetes 完全不在一个量级。

4.3 Mesos 的硬核：适合大数据，不适合绝大多数微服务团队

我接触 Mesos 的时候，第一感受是“这玩意不是给普通运维用的”。你要先部署 Zookeeper、Mesos Master、Mesos Agent，再装 Marathon，还得理解 Framework 的机制。为了清理故障状态，我经常要看日志找某个 Agent 的状态是不是“卡死”了。在几千台节点下，Mesos 的调度效率确实强，资源利用率和任务隔离能力都是当时顶尖的。但对于一个主要跑微服务的小团队来说，这些优势体现不出来，反而要承担高得多的维护成本。

Mesos 更适合那种拥有专门基础架构团队、以大数据批处理任务为主的大型企业。如果你就是“用容器跑一个订单服务”这种场景，Mesos 给你的更多的是负担，而不是收益。它和 Kubernetes 之间的关系有点像：高端工具和通用工具的区别。问题在于，市场最终选择了通用，因为通用意味着更低的使用门槛、更厚的生态、更容易招到人。

4.4 从 Swarm 迁移到 Kubernetes 的踩坑实录

对我来说最痛的实战经历，就是把一个已经跑在小规模 Swarm 集群上的业务系统迁移到 Kubernetes。表面看起来都是容器，实际坑非常多。

首先是网络策略差异。Swarm 的 ingress 网络默认把流量负载均衡到所有节点，你只要暴露端口就能访问；Kubernetes 里则需要自己定义 Service，如果要对外提供 HTTP 访问，还要配 Ingress。有一天我为了图方便，直接把 Swarm 的端口映射翻译成了 NodePort，结果服务是通了，但绕过了 Ingress 那层路由，很多基于域名的转发规则全部失效。排查了一下午，才意识到通信模型完全不同。

其次是服务发现。Swarm 里服务名就是 DNS 名，服务之间直接靠服务名调用；Kubernetes 则必须为每个工作负载创建对应的 Service 对象，DNS 才会生效。我当时迁移了一批微服务，只搬了 Deployment，没建 Service，结果服务之间连域名解析都失败。这个认知差异在初期不知道坑了多少人：Kubernetes 的最小部署单元是 Pod，但在集群内部的访问入口是 Service，这两者必须一起规划。

还有状态守护的问题。Swarm 的 service 自带重启策略，节点挂了会自动在其他节点拉起任务；Kubernetes 里这个职责落在 Deployment、StatefulSet 这类控制器上，如果你图省事直接kubectl run跑一个裸 Pod，节点宕机后这个 Pod 不会自动恢复。很多从 Swarm 迁移过来的同事最初都踩过这个坑，以为 Pod 和容器一样，挂了就重启一下，没意识到“控制器”和“实例”是两层概念。

存储迁移也值得单独说。Swarm 的 volume 基于 Docker volume 的概念，而 Kubernetes 里是 PV 和 PVC 的两层抽象，需要先准备好 StorageClass 和 CSI 驱动。我们有一个用本地盘的历史服务，迁移时直接写 hostPath 硬用，结果 Pod 被重新调度到其他节点后数据丢了。这个坑让我现在无论做什么有状态服务，都先把存储方案想清楚再动手。

5. 关于容器编排器的选型与迁移，高频问题速查

5.1 三选一，常见疑问与我的回答

这些年我被问得最多的问题，就是“当年如果选了 Swarm/Mesos 会怎样？”。我的回答通常很直接：短期可能没事，长期会很痛。这不是马后炮，而是生态的存续周期直接影响技术栈的寿命。选 Swarm，你确实省了学习成本，但几年后服务规模上涨时，你还是要面对网络策略、多集群管理、生态工具缺失这些问题，而且那时候已经没有大团队帮你解决这些问题了。

还有人会问：“Kubernetes 会不会太重了？我一个小项目有必要吗？”我的看法是，如果你的项目就是一台服务器上的几个容器，用docker-compose完全够用，没必要上 K8s。但只要你计划做多节点部署、有自动扩缩容需求、或者想统一管理多个环境，那从第一天就上 Kubernetes 反而能少走很多弯路。所谓“重”，在今天的托管 Kubernetes 服务面前已经不是大问题了。

5.2 迁移期间的典型报错和排查思路

我整理了迁移过程中最常遇到的几个问题，做成速查表：

始终记住一条经验：遇到问题先kubectl describe而不是猜，事件里通常已经告诉你原因。这条经验帮我在迁移排障时省掉大量时间。

5.3 几个“如果早点知道就好了”的小技巧

如果让我穿越回去给当年的自己提建议，我会说三件事。第一，迁移时先梳理清楚应用之间的调用关系，再设计 Service 和 DNS 命名，顺序反了会引发大量调用链故障。第二，不要把 Docker Compose 文件直接机械翻译成 Kubernetes YAML，要先理解控制器、Service、Ingress 之间的分工，再按 Kubernetes 的模型重构。第三，做好标签（Label）设计，从一开始就用统一的标签规范管理应用、版本、环境，后面做灰度发布和故障定位都会轻松很多。

还有一个容易被忽略的点：etcd 是 Kubernetes 的脑子，备份非常重要。我见过不止一次集群挂了结果发现 etcd 备份是坏的，只能从头重建。不管在哪个环境，都应该把 etcd 快照作为最高优先级运维任务之一。

6. 这场战斗给技术从业者留下的真正教训

6.1 赢的从来不是功能最多的那一个

容器编排器之战最值得琢磨的一点是：Swarm 简单，Mesos 能扛超大规模，Kubernetes 早期被吐槽复杂，但最后赢的是 Kubernetes。原因不在于它每个功能都比别人强，而在于它成为了一套“标准底座”，能够承载各种上层创新。可插拔的接口、声明式 API、开放治理，这些才是真正的胜负手。功能可以被追赶，标准却很难被绕过。

技术选型的时候，我一直提醒自己：你选择的不是一个工具，而是一个生态位。Swarm 的生态位太窄，Mesos 的生态位太垂直，只有 Kubernetes 站在了“通用容器平台”这个最宽阔的位置上，于是所有周边资源都向它汇聚。市场最终会奖励那些能让别人的能力长在自己身上的技术。

6.2 Kubernetes 胜出后，我们又面临哪些新问题

不过 Kubernetes 赢得太彻底，也带来了一些“幸福的烦恼”。控制面不轻，etcd、API Server 都要资源，几十个 Pod 的小集群也要养着这几个组件；文化变重，很多团队为了上 K8s 而上 K8s，把简单应用塞进复杂架构里，运维成本反而上升。生态内卷也明显，光服务网格就有 Istio、Linkerd、Consul Connect 一堆方案，网关又有 Gateway API 和各类 Ingress Controller，概念越来越多，新手学习路径越来越长。

这些反思并不是否定 Kubernetes，而是提醒我们：任何技术一旦成为绝对标准，就会出现“大而全”的惯性。也正因为这样，后面才有了 K3s、k0s 这类轻量实现，也有了 Wasm 工作负载、Serverless 容器这类新方向。但要注意，这些新东西大多不是“推翻 Kubernetes”，而是在它的生态位上做加法或减法。赢家不会轻易被取代，这一点至少在未来几年里不会变。

6.3 新一轮“容器编排器之战”还会发生吗

有人会问，未来还会不会出现下一个“Kubernetes 干掉 Swarm”这样的翻盘？我的看法是，真正的变量不在编排器本身，而在工作负载模型。当主流工作负载从“容器”变成“WebAssembly 模块”或者其他更轻量的沙箱形态时，底层基础设施的选择就可能发生变化。正因如此，containerd-wasm-shim、KWasm 这类工作才有意义——它们不是推翻 Kubernetes，而是让 Kubernetes 去适配新的工作负载。

作为普通工程师，我觉得最值得做的不是赌哪家赢，而是把那些稍微底层一点、通用一点的原理吃透：调度是资源匹配的过程，控制循环是系统自愈的灵魂，接口解耦是生态繁荣的前提。把这几件事想明白，不管未来底层技术怎么换，你都能快速切换而不慌。

我个人的体会是，技术在变，但技术竞争的规律变来变去就那么几条：开放接口往往战胜封闭实现，社区生态往往战胜单一厂商，表达力强的模型往往战胜上手舒服但上限低的模型。容器编排器之战是一场还没拉开大幕就结束的战斗，但它给后来者留下的思考题，足够我们做很多轮技术选型时慢慢回味。