先建立成本口径
谈集群成本前，先确定口径：节点和系统实例、负载均衡、公网流量、存储、快照、日志、平台服务费，都要进入统计。只看节点费用会低估 20% 到 40% 的总成本，具体比例取决于工作负载类型。
第二步是确定分摊维度。常见做法是按命名空间、团队标签、业务服务或成本中心分摊。关键是选择一个与组织决策一致的维度，并保持标签强制校验。
# 成本标签示例
metadata:
labels:
app.kubernetes.io/part-of: content-platform
team: cloud-notes
cost-center: personal-site
environment: production
Requests 是调度成本，Usage 是真实消耗
Kubernetes 根据 Requests 调度 Pod。请求值过高，集群会提前扩容，账单上升；请求值过低，节点超卖严重，高峰期出现驱逐或 CPU 节流。Limits 则影响突发能力和稳定性。
成本治理要同时看三个数字：请求值、实际使用率、 throttling 或 OOM 次数。只压低请求值而不看服务质量，会得到一份好看但不可靠的报表。
| 现象 | 常见原因 | 下一步 |
|---|---|---|
| 请求 CPU 远高于使用量 | 历史经验值未回收 | 按 P95 使用量分批调整 |
| 节点 CPU 利用率低但内存高 | 内存请求碎片化 | 检查可迁移 Pod 与节点规格 |
| CPU 节流高 | Limit 过紧或突发负载 | 区分稳态与峰值，调整限流策略 |
| 频繁 OOM | 内存 Limit 低或泄漏 | 先看应用指标，再改限额 |
从压测到生产：调整请求值的流程
- 按容器收集至少一到两周的 CPU、内存 P95 和峰值。
- 区分在线服务、后台任务、定时任务和守护进程。
- 在预发环境验证新 Requests 和 Limits。
- 生产环境分批修改，同时观察重启、节流、延迟和错误率。
- 把最终值写回 Helm Values 或 IaC，禁止控制台手工漂移。
识别三类闲置
第一类是低利用率工作负载。它们占用了调度资源，但实际使用很少。第二类是闲置对象：旧 Deployment、未使用的 PVC、长期保留的快照、测试命名空间。第三类是平台能力重复：多套网关、多套监控代理、重复的日志采集器。
我会每季度做一次清单：列出所有命名空间、Deployment、CronJob、PVC、LB 和公网 IP，标注负责人和最近使用时间。没有负责人的资源先停止再删除，并保留恢复窗口。
用命名空间和配额推动责任归属
ResourceQuota 限制命名空间总量，LimitRange 给未指定资源的对象默认值，两者配合可以防止新服务无边界占用资源。对多团队集群，还应该把命名空间与团队标签绑定，让报表能落到具体负责人。
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-cloud-notes
namespace: cloud-notes
spec:
hard:
requests.cpu: "8"
requests.memory: 16Gi
limits.cpu: "16"
limits.memory: 32Gi
persistentvolumeclaims: "10"
配额不是为了制造审批墙，而是让资源申请变成显式决策。超过配额时，负责人需要说明扩容原因或优化方案。
自动化只解决一部分问题
自动扩缩容、节点池整合、抢占式实例和混部都能降本，但前提是服务有明确的优先级和可观测性。对个人项目或小团队，优先做三件事更有价值：清理闲置资源、校准请求值、统一标签体系。之后再考虑更复杂的调度策略。
成本报表应有的字段
- 命名空间、服务、环境、负责人。
- 请求成本与实际利用率成本。
- CPU 节流、OOM、重启次数。
- 存储、流量、负载均衡等非节点费用。
- 环比变化和异常说明。
当报表能回答“这个月为什么贵了”和“哪个服务浪费最多”，成本治理才真正进入工程流程。否则降本只会变成一次性删机器，几周后成本又悄悄回来。