比较托管与自建 Kubernetes 的控制面、升级、组件、故障恢复和完整运维成本。
托管 Kubernetes 与自建 Kubernetes 都允许部署容器，但控制面、升级、etcd、网络组件和故障恢复的责任不同。托管并不等于免运维，自建也不等于更灵活就更专业；应根据必须掌控的组件和团队长期值守能力选择。
默认选择：已经确认需要 Kubernetes 的多数团队优先托管服务，让云厂商维护控制面；节点、网络插件、工作负载、权限、升级窗口和数据仍由用户负责。只有必须深度定制控制面、运行离线环境，且团队能维护 etcd、证书、升级和灾备时，才自建。
先给结论
大多数希望使用 Kubernetes 但不需要修改控制面的团队，优先评估托管服务。只有存在平台不支持的组件、版本、拓扑、边缘环境或监管控制要求，并具备集群生命周期能力时，自建才有充分理由。
责任边界对比
| 工作 | 托管 Kubernetes | 自建 Kubernetes |
|---|---|---|
| 控制面运行 | 平台承担主要责任 | 团队负责 |
| 版本升级 | 平台提供流程与支持窗口 | 团队规划、执行和回退 |
| 工作节点 | 通常仍由用户配置与维护 | 用户负责 |
| 应用治理 | 镜像、权限、资源、发布、备份均由团队负责 | |
托管服务仍然要做什么
团队仍需设计命名空间、RBAC、网络策略、镜像供应链、Secret、资源请求限制、自动扩缩容、日志监控、Pod 中断预算和有状态数据备份。平台控制面可用，不代表应用一定可用。
自建最容易低估哪些成本
除了三台控制面节点，还包括 etcd 备份恢复、证书轮换、版本偏差、CNI/CSI 兼容、API Server 容量、节点升级和安全公告响应。若只有一个熟悉集群的人，人员单点比技术单点更危险。
迁移验证清单
- 盘点 CRD、Admission、CNI、CSI、Ingress 和云厂商集成。
- 确认版本支持窗口及逐版本升级路径。
- 在新集群恢复有状态应用，而不是只迁移无状态 Deployment。
- 验证节点故障、可用区故障、控制面不可达和镜像仓库故障。
- 计算控制面、节点、负载均衡、NAT、日志和运维人力的完整成本。
边界条件
托管产品的控制面 SLA、节点责任、支持版本和网络能力因平台与模式而异。自动模式可能进一步减少节点管理，但也增加规格、网络或组件限制，必须以目标产品文档为准。
先问是否真需要
只有少量服务、发布不频繁、没有多团队调度时，虚拟机加容器或托管应用平台可能更便宜。Kubernetes 不会自动让应用无状态，也不替你解决数据库备份和容量规划。先算最低节点、负载均衡、磁盘、日志、仓库和人力。
| 责任 | 托管 | 自建 |
|---|---|---|
| 控制面可用性 | 云厂商按边界维护 | 团队自建冗余恢复 |
| 节点工作负载 | 用户 | 用户 |
| 升级 | 受支持版本约束 | 全链路自行验证 |
| 定制 | 受产品限制 | 自由且责任高 |
创建前硬检查
核对区域、版本周期、CNI、Pod/Service 网段、负载均衡、CSI、身份、审计和配额。网段不能与 VPC、办公室重叠。有状态应用要独立备份，PVC 不是备份。
演练、迁移和回退
测试集群发布真实应用，执行节点替换、版本升级、镜像拉取、日志查询、网络策略和恢复。自建还要从 etcd 备份恢复控制面。新集群用测试域名和少量流量灰度，旧集群保持可发布。失败时恢复 DNS/负载均衡并冻结新环境写入；没有旧集群和备份时不得原地升级生产控制面。
托管不等于免运维
云厂商维护控制面，并不替用户修复错误的 Deployment、网络策略、资源限制、镜像漏洞或数据库。团队仍需处理节点池升级、Pod 驱逐、PDB、配额、日志、密钥和成本。创建页显示集群可用，只证明控制面准备完成，不证明业务具备高可用。
自建的否决条件
没有至少两名能处理证书、etcd、网络和升级的值守人员，没有离线恢复演练，或无法承担三个控制面节点与备份成本时，不应自建生产集群。依赖单个专家和一份未验证脚本的方案，在故障和人员变动时无法维持。
还要核对供应商支持范围：控制面 SLA 不覆盖用户节点、工作负载和区域级设计。托管集群若只放一个节点或单可用区，仍然是单点；自建三节点若全部在同一故障域也不等于高可用。用节点和可用区故障演练验证调度、存储挂载、Pod 中断预算和入口健康。
所有集群创建参数、插件版本和权限应进入可审查配置，避免只能依赖控制台手工重建。
完成当前任务后继续检查
官方资料
需要核对云平台托管容器的区域和规格时，可联系黑鲨云 @heishayun。
联系 Telegram 客服 