容器编排解决什么问题
容器编排的核心能力是四件事：把容器调度到合适的节点、按期望状态自愈、做滚动发布与回滚、按配额约束资源使用。Kubernetes 是常见事实标准，能力最全但运维复杂度也最高；托管集群把控制面运维交给云厂商，节点、网络插件与权限模型仍需自己管；服务数量少、发布频率低时，更轻量的调度方案甚至虚拟机加脚本也能支撑。
基本信息
| 能力 | 调度、服务发现、滚动发布与回滚、自愈与配额管理 |
|---|---|
| 形态 | 自建集群与托管控制面，运维边界不同 |
| 门槛 | 网络模型、存储插件、权限与多租户需要专门能力建设 |
| 成本结构 | 控制面与节点费用之外，还要算平台团队的人力投入 |
典型使用场景
- 服务数量多、发布频繁：需要统一调度与发布流程，减少手工操作
- 弹性伸缩需求明显：与大促或业务峰谷匹配，自动增减实例
- 多环境一致性：容器镜像保证开发、测试与生产的运行环境一致
- 平台化建设：为多个团队提供统一的部署与资源配额入口
- 灰度与回滚要求高：需要按版本比例切流并快速回滚
编排形态对照
| 层级 | 适用 | 注意 |
|---|---|---|
| 轻量调度 | 少量服务、发布频率低 | 自愈与配额能力有限 |
| 托管 K8s | 需要弹性与生态、可接受学习成本 | 控制面托管，节点与网络仍自管 |
| 自建 K8s | 有平台团队与定制要求 | 升级、备份与加固全部自担 |
引入前盘点清单
引入前盘点清单
1. 服务数量与语言栈：是否多到需要统一调度？
2. 发布频率与回滚要求：手工发布是否已成为瓶颈？
3. 弹性需求：峰值与日常的容量差异有多大？
4. 网络与存储能力：谁维护 CNI、Ingress、存储类与备份？
5. 权限模型：多团队多租户如何隔离？
6. 人力：是否有能承接集群升级与故障处置的团队？使用要点
- 先盘点服务数量、发布频率与弹性需求，再决定编排深度
- 网络、存储与权限模型的能力缺口通常会在试点阶段暴露，试点要覆盖这三项
- 把集群升级纳入常规运维排期：大版本升级往往涉及工作负载 API 变更
- 为工作负载设置 requests 与 limits，否则调度与隔离都无从谈起
- 明确回退路径：保留在虚拟机上直接运行关键服务的能力作为兜底
编排平台带来的复杂度要有对应收益：服务数量与发布频率不高时，在虚拟机上运行容器并配合简单脚本也足以支撑，先积累容器化经验再上编排。
控制面托管不等于运维托管：节点池升级、网络插件配置、存储类选择、镜像仓库与密钥管理仍由使用方负责，低估这部分工作量是常见踩坑点。