6.2 Swarm与Kubernetes生态全景：编排的下一站
6.2 Swarm 与 Kubernetes 生态全景：编排的下一站
摘要：当一台机器不够用，编排要解决调度、自愈与服务发现三个新问题。本节先看 Docker 内置的 Swarm 的极简模型与停滞现状，再俯瞰 Kubernetes 的对象模型与生态位，给出一份"什么时候迁移、迁到哪"的判断框架。
学习目标
- 说出 Swarm 的服务与任务模型及 ingress 路由网格的基本原理
- 列出 Kubernetes 的五类核心对象及各自职责
- 判断一个项目该停在 Compose、上 Swarm 还是上 Kubernetes
- 描述从 Compose 迁移到集群的基本路线
一台机器什么时候真的不够用
迁移的判断标准值得先立起来。三种信号说明单机到头了：资源饱和，CPU 或内存在峰值期持续吃紧，加机器比重构架构便宜；可用性要求升级，单机宕机不可接受，需要多机互备与自动接替；发布节奏加快，需要滚动更新、灰度分流这类单机做不了的动作。反过来，如果只是"感觉容器有点多"，那不是信号——几十个容器在一台配置合理的主机上相处融洽是常态。先把这段判断记在心里，再看多机世界的三个新问题。
多机带来的三个新问题
单机 Compose 已经解决了"描述一组服务"。多台机器后冒出三个新问题，编排器的核心工作就是回答它们：
调度——新起的容器放哪台机器？按什么依据选（剩余资源、亲和性、镜像是否已在本地）？
自愈——机器整机挂了，上面的容器谁负责在别的机器上重建？进程死了谁来重启？
服务发现与负载均衡——实例在不同机器上漂移，调用方怎么找到当下的实例集合？
Swarm：内置的极简答案
Swarm 模式内置在 Docker 引擎里，启用只要一条命令：
docker swarm init # 其他机器加入 docker swarm join --token <token> <manager-ip>:2377
它的模型刻意保持极小：service（期望 N 个副本）→ task（一个容器实例）。调度器把 task 分派到各节点，节点挂了自动在别处补齐副本；内置 DNS 把服务名解析到各副本；ingress 路由网格让任意节点收到的发布端口流量都能路由到正确容器——你访问任一节点的 80，流量可能实际由另一台机器上的容器处理。
docker service create --name web --replicas 3 -p 80:80 nginx:alpine docker service ls docker service ps web docker service scale web=5 docker service update --image nginx:1.27 web # 滚动更新
Swarm 的优点是学习曲线几乎为零：会 docker 就会 Swarm，一天上手。缺点同样明显：社区生态长期停滞，周边工具（监控、发布、策略）远不如 Kubernetes 丰富，云厂商的托管支持也趋于边缘。它的合理生态位：三五台机器的小集群、团队没有专职运维、需求就是"多机高可用跑这几个服务"。
Kubernetes：事实标准的对象世界
Kubernetes 把编排问题抽象成一组可组合的对象，核心五个：
| 对象 | 管什么 | 对应 Compose 世界的概念 |
|---|---|---|
| Pod | 一组共址共享网络的容器 | 一个服务实例（container 模式的延伸） |
| Deployment | 副本数、滚动更新、回滚 | service 的 replicas 与 update |
| Service | 稳定访问入口与负载均衡 | 服务名 DNS + 端口发布 |
| ConfigMap / Secret | 配置与机密注入 | environment 与 .env |
| PersistentVolumeClaim | 存储申请 | volumes 声明 |
一个最小部署示例（节选自典型清单）：
apiVersion: apps/v1 kind: Deployment metadata: name: web spec: replicas: 3 selector: matchLabels: { app: web } template: metadata: labels: { app: web } spec: containers: - name: web image: myrepo/web:1.4.2 resources: requests: { memory: "256Mi", cpu: "250m" } limits: { memory: "512Mi", cpu: "1" } readinessProbe: httpGet: { path: /healthz, port: 8080 }
值得注意的还是那些老朋友：resources 段就是第 3 章的 cgroup 参数（requests 保底、limits 封顶）；readinessProbe 就是健康检查；镜像用不可变 tag（第 2 章的分发纪律）。分层解剖的好处在这里兑现：换了编排器，层的知识原样适用。
代价是复杂度：etcd、控制面组件、RBAC、网络插件……自建一套生产级集群的运维成本对小团队是难以承受的。现实的主流路径是云厂商的托管 Kubernetes——控制面他们管，你只写业务清单。
选型与迁移路线
迁移路线通常是：Compose 跑稳开发与小规模生产；出现明确的单机瓶颈或高可用硬需求时，直接迁托管 Kubernetes（Swarm 作为跳板的价值随其生态萎缩而降低）。Compose 文件可以用配置转换工具生成 Kubernetes 清单初稿，人工校对资源与探针后接管。
⚠️ 最后泼一盆冷水：别为了简历好看上集群。业务还在单机绰绰有余的阶段就引入 Kubernetes，复杂度成本会先于任何收益压垮小团队。编排器的选型唯一判据是问题规模，不是技术时尚。
本节要点回顾
- 多机编排三问：调度、自愈、服务发现，所有编排器都在回答它们
- Swarm 极简易用但生态停滞，定位是小团队小集群
- Kubernetes 是对象世界，五大对象映射的仍是分层的老知识：cgroup、健康检查、卷、DNS
- 托管集群是主流落点，自建的控制面运维成本高
- 迁移时机看问题规模，Compose 到 Kubernetes 有工具辅助的平滑路径
编排之上，最后一层是治理：安全、监控、日志与一场收束全书的实战。