自建 vs 托管

路线图 should-you-manage-your-own-cluster 问的是：控制平面/etcd 的备份、升级、证书轮换，是否值得团队自己扛？本课给出决策框架——多数应用团队选 托管；自建适合有专职平台组、强合规或边缘/离线场景。

学习目标

• 列出自建控制平面的运维负担清单
• 用 TCO（总拥有成本）思维对比托管与自建
• 判断 CodeRoadMap 规模下哪种模式更合理

自建要管什么

控制平面（3+ 节点高可用）
  ├─ etcd 备份与恢复
  ├─ API Server / Scheduler / Controller Manager 升级
  ├─ 证书轮换（kubeadm / 自签 CA）
  └─ 控制平面监控与告警

工作节点
  ├─ OS 补丁、kubelet 版本对齐
  ├─ 容器运行时（containerd）维护
  └─ CNI / CSI 插件生命周期

kubernetes-essentials 在 minikube 上 隐式 跳过了上述全部工作；生产自建相当于把 minikube 的「魔法」换成真实 HA 与 on-call。

何时选托管

信号	建议
团队无专职 SRE/平台	托管
集群数 < 5，业务迭代优先	托管
需要快速跨 AZ 上线	托管
已有成熟 OpenShift / Rancher 平台组	可评估自建或半托管
边缘机房、无公网、强隔离	自建或离线发行版

托管细节见 k8a-managed；半托管（Bare Metal + 托管控制平面）是中间路线。

何时考虑自建

• 成本规模：超大规模节点时，控制平面费用占比下降，自建节点调度优化可能更划算（需精算）
• 定制：特定 CNI、内核参数、硬件加速调度
• 合规：数据与控制平面必须完全在内网
• 学习：平台工程职业路径——与 k8a-control-plane 衔接

即使自建，应用发布仍推荐 helm-gitops-essentials，避免 SSH 到节点改配置。

TCO 粗算维度

1. 人力：平台工程师 FTE × on-call 轮值
2. 基础设施：控制平面 VM、LB、etcd 存储
3. 风险：升级失败、etcd 数据丢失的 RTO/RPO
4. 机会成本：本可投入业务功能的人天

可观测投入不可省——自建更依赖 observability-essentials 与 prometheus-essentials 覆盖控制平面组件指标。

练习

• 为 CodeRoadMap（小团队、AWS 为主）写一段「选 EKS 而非自建」的决策说明（≤200 字）