第6章 编排层：从单机到集群

第 6 章 · 编排层：从单机到集群

章节摘要：容器数量超过三个，命令行就开始失控。本章先拆 Compose 如何用一份声明式文件驱动多容器应用，再俯瞰 Swarm 与 Kubernetes 两大集群方案的生态位，给出从单机到集群的演进路线。

学习目标

1. 写出含网络、卷、健康检查、依赖顺序的服务编排文件
2. 解释 Compose 的声明式模型与命令生命周期
3. 说出 Swarm 与 Kubernetes 各自的生态位与选型依据
4. 为不同规模的应用选择正确的编排起点

核心概念速览

编排的本质是把"容器怎么跑"的知识从人的脑子里搬进机器可读的文件。

编排生态全景

子章节导航

6.1 Compose 多服务编排

一份 compose 文件的完整解剖：服务、网络、卷、健康检查与依赖顺序，命令生命周期，以及开发与生产两套环境的参数分文件技巧。

6.2 Swarm 与 Kubernetes 生态全景

Swarm 的内置优势与停滞现状，Kubernetes 的核心对象模型，从 Compose 演进到集群的路线图与选型判断。

子章节之间的逻辑关系

6.1 是单机编排的终点，6.2 是多机编排的入口，两者的分界线是"一台机器还够不够"：

描述服务怎么跑（Compose 声明式文件）
   |
   v
描述服务在哪跑、怎么自愈（集群编排）
​

编排不是越大越好

本章要传递的一个反直觉观点是：编排工具的能力与你的需要没有必然关系，级别越高的编排器代价也越高。Compose 学一上午就能用，Kubernetes 学三个月未必敢上生产。本章 6.1 的内容对几乎所有读者都直接有用，6.2 的内容更多是地图性质的——知道边界在哪里、什么时候该动身，比现在就出发更重要。判断编排级别的唯一标尺是问题规模，这个判断框架请优先带走。

前置知识与后续延伸

• 前置：第 4 章自定义网络（Compose 服务互访的底层）、第 5 章卷（有状态服务进编排的前提）
• 为后续铺垫：健康检查驱动的自愈、资源声明，是第 7 章生产实战与监控告警的直接素材