Kubernetes成本治理不是简单压缩资源，而是让平台团队、业务团队和财务视角对齐：哪些资源被谁使用，为什么需要这些容量，哪些闲置可以回收，哪些弹性策略会影响稳定性。本文会围绕成本治理与平台工程实践展开，重点说明成本口径、资源配额、闲置识别、FinOps 协作和自动化落地路径。
本文定位：面向平台工程、运维、安全或架构团队，关注生产环境中可执行、可审计、可回滚的成本治理实践。
先建立成本口径：资源账单要能回到团队和应用
Kubernetes成本治理的第一步不是删资源，而是先把账算清楚。很多集群的成本问题并不在云账单本身，而在账单无法映射到命名空间、应用、团队和业务线：节点费用在平台侧，Deployment 在业务侧，存储卷和负载均衡又可能落在不同账单项里，最终谁都知道成本高，却没人知道应该由谁调整。
建议先建立一套可以被团队共同接受的成本口径：
- 资源归属：命名空间、工作负载、PVC、LoadBalancer、镜像仓库和日志存储都要能回到团队或项目。
- 计量基线：区分 request、实际使用量、节点分摊成本和外部云资源成本，不把所有费用都简单归到 Pod。
- 环境维度：生产、预发、测试和临时环境分别统计，避免测试环境长期占用生产级资源。
- 时间窗口：按日看波动、按周看趋势、按月做预算复盘，避免只在账单异常时临时处理。
一个可落地的判断标准是：当某个团队收到成本报表时，能不能在 10 分钟内回答“钱花在哪些应用、哪些资源和哪些时间段”。如果做不到，先补标签、命名空间规范和成本映射，比直接下调配额更有价值。
配额与 LimitRange：防止资源申请长期失真
配额治理的目标不是把 request 压到最低，而是让资源申请接近业务真实需要。没有 ResourceQuota 和 LimitRange 的集群，很容易出现两类失真：一类是团队为了避免 OOM 或 CPU 抖动而长期高估 request；另一类是完全不设置 request，导致调度、扩容和成本核算都失去基线。
可以按下面的成熟度逐步推进：
| 阶段 | 典型问题 | 推荐动作 |
|---|---|---|
| 无基线 | Pod 不写 request/limit，成本无法归因 | 给新命名空间设置默认 request 和 limit 范围 |
| 有配额 | 配额按团队拍脑袋分配，长期不调整 | 按历史 P95 使用量、业务峰值和 SLO 重新评估 |
| 可优化 | 配额存在但缺少例外流程 | 建立临时扩容、压测窗口和审批记录 |
| 自动化 | 已有稳定指标和标签 | 接入推荐值、预算告警和变更检查 |
落地时要避免两个误区。第一，不建议把 limit 设置得过低来“强制省钱”，这可能把成本问题变成稳定性问题。第二，不要只看 CPU 和内存，PVC、日志、镜像缓存、外部负载均衡和公网流量同样会影响总成本。
闲置资源识别：从 Pod 到 PVC 的回收清单
闲置资源治理最适合从低风险对象开始，而不是直接处理生产核心工作负载。平台团队可以先把资源分成“可自动提示、可自动回收、必须人工确认”三类，再逐步扩大范围。
常见检查清单如下：
- 长期无流量的服务：Service 存在但 7 天或 14 天内没有入口流量，需要确认是否已下线。
- 低利用率工作负载：CPU、内存长期低于 request 的固定比例，但仍要结合业务峰谷和批处理时间判断。
- 孤立 PVC：PVC 未被 Pod 挂载，或所属应用已删除，是存储成本治理的高价值对象。
- 临时环境超期：测试、评审、PoC 命名空间缺少到期时间，容易长期占用节点和存储。
- 未使用的 LoadBalancer：入口对象删除后外部负载均衡仍保留，会产生额外费用。
- 日志和监控保留过长：非核心环境沿用生产保留周期，会让存储成本持续放大。
回收动作要有明确的安全边界。生产命名空间、状态服务、合规留存数据和事故取证数据不应直接自动删除。更稳妥的流程是先通知负责人，进入观察期，再在变更窗口执行回收，并保留恢复路径。
FinOps 协作：让成本优化进入平台日常流程
FinOps实践的价值在于把成本从“月底财务问题”变成“日常工程决策”。平台团队提供数据和能力，业务团队解释需求和峰值，财务或管理团队关注预算和趋势。三方口径一致后，成本治理才不会变成平台单方面压资源。
推荐建立四个固定动作：
- 月度成本复盘：查看团队成本趋势、异常增长、资源回收效果和下月容量计划。
- 预算告警：按团队、环境和资源类型设置阈值，告警要能定位到负责人。
- 变更前评估：新业务上线、大促、压测、日志策略调整前，提前评估容量和费用影响。
- 优化例外管理：允许关键业务在明确期限内保留冗余容量，但要有原因、负责人和复审时间。
成本优化还需要和稳定性指标一起看。比如降低 request 后，如果 HPA 频繁扩缩、延迟升高或 Pod 被驱逐，说明优化已经影响服务质量。成本治理的边界应由业务 SLO、容量风险和预算目标共同决定。
落地路线：从可视化到自动化治理
较稳妥的落地路线可以分为四步。第一步做可视化，把命名空间、团队、应用和资源类型的成本看清楚；第二步做规则化，把标签、配额、默认 request、临时环境生命周期写入平台规范；第三步做流程化，把成本检查接入发布、扩容、下线和月度复盘；第四步再做自动化，例如闲置提醒、低风险资源回收和预算阈值告警。
执行前建议定义验收指标：
- 成本归属覆盖率是否提升，例如主要命名空间都能映射到团队。
- 无 request 工作负载占比是否下降。
- 闲置 PVC、超期临时环境和无流量服务是否减少。
- 单位业务量成本是否稳定，而不是只看总账单下降。
- 优化后是否出现更多 OOM、驱逐、延迟或扩容失败。
如果一次性强推全量治理，容易引发业务抵触或稳定性风险。更适合先选择一个成本占比高、负责人清晰、业务风险可控的集群或团队试点，跑通报表、通知、回收和复盘流程后，再把规则沉淀到平台入口和自动化检查中。
小结
Kubernetes成本治理的关键是把资源、团队、应用和业务目标连接起来。先建立成本归属和计量基线，再通过配额、闲置识别和 FinOps 协作持续优化，通常比临时压缩资源更稳妥。对生产环境而言，任何节省动作都要同时验证稳定性、扩容能力和回滚路径，避免把账单问题转化为可用性问题。
常见问题
1. Kubernetes成本治理是不是只要降低 request？
不是。request 只是成本口径的一部分。更重要的是识别业务峰谷、SLO、扩缩容策略和团队责任边界，避免把稳定性问题转移给业务。
2. 哪些资源最容易造成浪费？
常见浪费包括长期 Running 但无流量的工作负载、过量 request、未清理 PVC、保留过久的测试环境、未使用的 LoadBalancer 和缺少生命周期策略的日志存储。
3. 平台团队应该先自动回收资源吗？
建议先做可视化和通知，再做低风险自动化。生产命名空间、状态服务和有合规保留要求的数据不应被简单自动删除。
