---

群雄并起

一、Docker 平台化战略解析

1.1 战略动机

Docker 在 2014~2015 年从单一容器工具转向平台化，主要出于以下考虑：

• 商业价值提升：基础容器功能难以直接变现，而平台化（如提供编排、网络、存储等高级功能）可形成付费点。
• 用户需求转变：用户更关注应用部署与管理（PaaS 能力），而非底层容器技术。
• 竞争压力：CoreOS、Mesosphere 等公司已推出更完整的平台方案，Docker 需扩展生态以避免被边缘化。

1.2 关键技术举措

• 推出 Swarm：提供原生集群管理，强调 API 兼容性与无感迁移。
• 收购 Fig（后更名 Compose）：引入“容器编排”概念，完善多容器应用部署能力。
• 整合网络与存储：通过 SocketPlane（网络）、Flocker（存储）等收购增强平台能力。

---

二、Swarm 与 Compose 技术细节

2.1 Docker Swarm

• 核心特点：
  • 完全兼容 Docker API，用户可通过 -H 参数指定 Swarm 端点。
  • 内置调度算法，支持节点选择策略（如资源余量、标签匹配）。
• 示例命令：

  # 单机命令
  docker run -d --name web nginx:alpine
  
  # 集群命令（通过 Swarm Manager）
  docker -H tcp://swarm-manager:2375 run -d --name web nginx:alpine
  

2.2 Docker Compose

• 编排理念：通过 YAML 文件定义服务拓扑、依赖关系、网络和存储。
• 典型 docker-compose.yml：

  version: '3'
  services:
    web:
      image: nginx:alpine
      ports: ["80:80"]
      depends_on: ["db"]
    db:
      image: mysql:5.7
      environment:
        MYSQL_ROOT_PASSWORD: 123456
  

• 常用操作：

  docker-compose up -d    # 启动所有服务
  docker-compose down     # 停止并删除容器
  docker-compose scale web=3  # 扩容 web 服务实例
  

---

三、竞争格局：CoreOS、Mesos 与 Kubernetes

3.1 CoreOS rkt + Fleet

• 技术特点：
  • 强调安全性（基于 systemd 隔离）、开放标准（CNI 网络）。
  • 但生态较弱，未能形成主流。

3.2 Mesos + Marathon

• 优势：
  • 支持超大规模集群（万级节点）。
  • 可混合部署容器与传统大数据任务（如 Spark、Hadoop）。
• 局限：
  • 学习曲线陡峭，API 不与 Docker 兼容。

3.3 Kubernetes 的崛起

• 诞生背景：
  • Google 基于 Borg 经验推出，2014 年开源。
  • 得到 RedHat、CoreOS 等支持，成为对抗 Docker 垄断的出口。
• 成功因素：
  • 声明式 API、丰富调度策略、开放生态（CRI/CNI/CSI）。
  • 中立性（由 CNCF 托管），吸引多云厂商支持。

---

四、面试题深度解析

4.1 简单题：Docker Compose 中 depends_on 的作用与局限

• 作用：控制服务启动顺序（如先启动数据库，再启动应用）。
• 局限：仅控制容器启动顺序，不保证服务可用性（需应用层重试或健康检查）。

4.2 中等题：Swarm vs Mesos+Marathon

维度	Docker Swarm	Mesos + Marathon
API 兼容性	✅ 完全兼容 Docker API	❌ 需学习 Marathon API
集群规模	千级节点	万级节点（生产验证）
使用场景	纯容器环境、中小规模	混合任务（容器+大数据）
学习成本	低（Docker 用户无缝迁移）	高（需理解 Mesos 两层调度）

4.3 高难度题：Kubernetes 为何能最终胜出？

• 技术优势：
  • 声明式 API：用户定义期望状态，系统自动协调（Swarm 为命令式）。
  • 开放接口：支持多种容器运行时、网络、存储插件。
• 生态优势：
  • 由 CNCF 托管，中立性强，吸引多云支持。
  • 社区活跃，迭代快（每3个月一版本），功能丰富（Service、Ingress、HPA 等）。

---

五、实践与架构启示

5.1 开发环境标准化实践

使用 Docker Compose 统一开发环境：

# docker-compose.yml
services:
  app:
    build: .
    ports: ["3000:3000"]
    env_file: .env
    depends_on: ["redis"]
  redis:
    image: redis:6-alpine

# 通过 Makefile 封装常用命令
up:
	docker-compose up -d
logs:
	docker-compose logs -f

5.2 架构设计启示

• 兼容性优先：如 Swarm 兼容 Docker API，降低迁移成本。
• 模块化整合：像 Docker 收购 Fig 一样，整合成熟组件而非重复造轮子。
• 生态化思维：选择具有开放生态的技术（如 Kubernetes），避免厂商绑定。

---

六、附录：关键时间节点

• 2014.6：Google 发布 Kubernetes
• 2014.12：Docker 发布 Swarm
• 2015：Docker 收购 Fig → Compose
• 2015：CNCF 成立，Kubernetes 成为首个托管项目

---

尘埃落定

---

一、核心背景与矛盾起点（2014-2015年）

1. Docker生态初期繁荣：Docker公司凭借容器技术站稳云计算市场，推出Compose、Swarm、Machine“三件套”，同时围绕Docker的网络、存储、监控等创业项目涌现（如Rancher、Tutum），容器社区热闹非凡。
2. 社区担忧与核心矛盾：Docker项目逐渐成为公司商业产品，开源仅作为吸引开发者的手段；更关键的是，Docker公司在开源项目发展中保持绝对权威，多次挑战CoreOS、RedHat、谷歌、微软等玩家利益，引发不满。

二、关键事件与行业应对（2015-2016年）

（一）OCI成立：容器标准的初步尝试（2015年6月）

1. 发起与核心动作：由Docker牵头，联合CoreOS、谷歌、RedHat等公司，将Docker的Libcontainer捐出并改名为RunC，交由中立基金会管理，同时制定容器和镜像标准OCI（Open Container Initiative）。
2. OCI目标：将容器运行时和镜像实现从Docker中剥离，打破Docker一家独大，为其他玩家构建平台层能力提供可能。
3. 局限性：OCI是各方利益妥协的结果，Docker虽为创始成员，但极少参与技术推进和标准制定，导致OCI组织效率长期低下，未改变Docker主导地位。

（二）CNCF成立：对抗Docker的关键布局

1. 发起与核心目标：谷歌、RedHat等牵头成立CNCF（Cloud Native Computing Foundation），以Kubernetes为核心，建立开源基础设施厂商主导的平台级社区，对抗Docker商业生态。
2. CNCF的两大核心任务与落地
   • 任务1：提升Kubernetes编排竞争力
     • 差异化路径：避开Swarm（擅长Docker生态集成）、Mesos（擅长大规模集群调度）的同质化竞争，基于谷歌Borg/Omega系统的实践经验，推出Pod、Sidecar等“超前”设计，避免同质化。
     • 联盟支持：谷歌联合RedHat（补充Kubernetes团队工程能力短板），开启容器编排“三国鼎立”（Kubernetes、Docker Swarm、Mesos）局面。
     • 竞争结果：Kubernetes凭借创新设计和生态号召力，GitHub指标远超Swarm，Mesos因Apache社区封闭性缺乏创新，逐渐边缘化。
   • 任务2：以Kubernetes为核心覆盖多场景
     • 生态扩展：纳入Prometheus（监控）、Fluentd（日志）、OpenTracing（追踪）、CNI（网络）等容器生态工具，吸引大量公司针对CNCF制定推广策略。
     • Kubernetes架构革新：推进“民主化”架构，每一层均提供可扩展插件机制，催生出Istio（微服务治理）、Operator（有状态应用部署）、Rook（容器存储插件）等二次创新项目，形成以Kubernetes为核心的“百花争鸣”生态。

（三）Docker的应对与战略失误（2016年）

1. 关键动作：宣布放弃现有Swarm项目，将容器编排、集群管理功能内置到Docker中，试图通过“Docker Native”最大化生态集成优势。
2. 问题所在：内置功能虽扩大Docker边界至PaaS范畴，但大幅增加技术复杂度和维护难度，且未应对Kubernetes的差异化竞争，“Docker Native”说辞缺乏杀伤力。

三、尘埃落定：Docker退出开源竞争（2017-2018年）

1. Docker的战略收缩
   • 2017年：将Docker容器运行时Containerd捐赠给CNCF，标志Docker全面升级为PaaS平台；将Docker项目改名为Moby交由社区维护，商业产品独占“Docker”商标，放弃与Kubernetes的开源竞争，专注商业化。
   • 2017年10月：在Docker企业版中内置Kubernetes，“编排之争”正式落幕。
2. 行业关键收尾事件
   • 2018年1月：RedHat以2.5亿美元收购CoreOS。
   • 2018年3月：Docker CTO Solomon Hykes辞职，容器技术圈纷争告一段落。

四、核心总结

1. Docker的兴衰逻辑
   • 成功基础：通过开源运作在容器技术初期取得巨大成功。
   • 失败关键：拒绝微软收购后，选择“开源项目与商业产品强绑定”的封闭生态路线，违背开发者信任；面对CNCF和Kubernetes的开放生态，战略应对失误。
2. Kubernetes成功的必然性：以开发者为核心，构建民主、开放的生态，承接Docker未竟的“容器普及”事业，符合云计算产业对中立、可扩展平台的需求。
3. 行业启示：云计算产业具有垄断特性，技术型创业公司（如Docker）需平衡开源与商业，过度封闭或对抗巨头联盟，易陷入战略被动。

五、补充：读者疑问与作者解答（核心概念关系）

概念	关系说明
Libcontainer与Containerd	前后继承关系，Libcontainer是Containerd的前身，现多提及Containerd
Docker、Containerd、RunC、OCI	Docker（上层平台）→ Containerd（容器运行时）→ RunC（OCI标准实现），均遵循OCI容器/镜像标准
CRI、CNI、CSI	均为Kubernetes的扩展接口，分别对应容器运行时、网络、存储领域
Moby与Docker	Moby是Docker项目的社区维护版，Docker公司商业产品独占“Docker”商标，社区日常交流仍习惯称“Docker”