Kubernetes 不贵，糊涂才贵
聊聊如何量化 Namespace / 团队的真实成本
搞 Kubernetes 的朋友，迟早都会遇到一个灵魂拷问：
👉 “我们这套 K8s，一年到底烧了多少钱？”
👉 “哪个团队最费钱？”
👉 “为啥老板总觉得集群是个无底洞？”
更扎心的是——
你是运维，你心里大概有个数，但你算不清，也说不明。
于是常见画面就出现了：
业务方：
“我们也没用多少资源啊？”
运维：
“集群快满了，再加节点要钱。”
老板：
“钱花哪儿了？谁花的？”
如果你点头了，那这篇文章，就是写给你的。
一、先说个大实话：Kubernetes 本身不懂“钱”
这是很多人一开始就拧巴的地方。
Kubernetes 只关心三件事：
- CPU
- 内存
- 调度
它完全不关心：
- 谁在用
- 用来干嘛
- 值不值这个钱
所以：
👉 K8s 天生不具备“成本视角”
成本，是我们运维后来硬塞进去的概念。
而 Namespace，恰好成了这件事里最像“账本”的东西。
二、为什么一定要按 Namespace / 团队算成本？
我见过不少团队，一上来就想：
“直接算 Pod 成本不就完了？”
理论上可以，现实中基本翻车。
原因很简单：
- Pod 太碎
- 生命周期太短
- 没业务语义
而 Namespace 通常满足三个条件：
- 和团队 / 项目强绑定
- 生命周期相对稳定
- 天然隔离（权限 / 配额）
所以在绝大多数公司里：
Namespace ≈ 团队 / 项目 / 成本中心
这不是完美方案，
但这是最现实、最好落地的方案。
三、成本到底该怎么算？别一上来就搞复杂
很多人一提“成本量化”，脑子里就浮现：
- 账单拆分
- 云厂商 API
- 财务系统对账
我劝你一句：
👉 先别急着上“核武器”。
成本的第一性原理其实很朴素：
资源 × 单价 × 时间
在 Kubernetes 里，最核心的资源就两个：
- CPU
- Memory
四、第一步：算清楚 Namespace “要了多少资源”
注意，我这里用的是 “要了多少”，不是“实际跑了多少”。
为什么？
因为钱，是按 Request 付的，不是按 Usage 付的。
1️⃣ 从 Resource Request 下手
举个最常见的 Deployment：
resources:
requests:
cpu: "500m"
memory: "1Gi"
limits:
cpu: "1"
memory: "2Gi"
这意味着什么？
调度器会认为：
- 这个 Pod 至少要 0.5 核 CPU
- 至少要 1Gi 内存
- 节点容量被“锁定”
哪怕你程序在睡觉，
账单也在跑。
2️⃣ 聚合 Namespace 维度的 Request
可以用 kube-state-metrics + PromQL 很优雅地解决。
sum(
kube_pod_container_resource_requests_cpu_cores
) by (namespace)
sum(
kube_pod_container_resource_requests_memory_bytes
) by (namespace)
这一步，你就能拿到：
每个 Namespace 理论上“占用”了多少 CPU / 内存
五、第二步：给资源打上“价格标签”
没有价格，谈成本就是耍流氓。
一个实用但不完美的定价模型
假设你用的是云上节点：
单节点：
- 8 vCPU
- 32 GiB 内存
- 月费用：¥2400
那我们可以粗算：
CPU 单价 = 2400 / 8 = 300 元 / 核 / 月
内存单价 = 2400 / 32 = 75 元 / GiB / 月
别嫌粗，这已经比“拍脑袋”强 10 倍了。
计算 Namespace 月成本
Namespace 成本 =
CPU_Request × CPU_单价
+ Memory_Request × Memory_单价
你甚至可以用一段 Python 算给老板看：
cpu_cost = cpu_cores * 300
mem_cost = mem_gib * 75
total = cpu_cost + mem_cost
一行公式，立刻具象化。
六、第三步：把“共享成本”也算进去（很多人卡在这）
现实世界里，集群里不只有业务 Pod。
还有一堆：
- kube-system
- ingress
- monitoring
- logging
- cicd runner
这些怎么算？
我的建议很直接：
别纠结“绝对公平”，追求“可解释”。
常见三种分摊策略
1️⃣ 按 CPU Request 比例分摊（最常用）
团队 A 成本占比 =
团队 A CPU_Request / 全集群 CPU_Request
2️⃣ 按 Namespace 数量均摊（简单粗暴）
适合小团队、早期阶段。
3️⃣ 单独算平台成本（成熟团队）
- 平台团队兜底
- 业务团队只背业务 Pod
没有银弹，只有适合。
七、再往前一步：用 Label，而不是只靠 Namespace
当公司变大后，你会发现：
- 一个 Namespace 多个项目
- 一个项目多个环境
这时候，Label 才是王道。
labels:
team: search
project: recall
env: prod
配合 PromQL：
sum(
kube_pod_container_resource_requests_cpu_cores
) by (label_team)
你就能做到：
真正的“团队 / 项目 / 环境”维度成本洞察
这一步，是从“算账”走向“治理”的关键。
八、说点我自己的真实感受
我做运维这些年，有一个越来越坚定的认知：
成本不是财务的事，是运维的基本功。
你如果算不清成本：
- 就没资格谈扩容
- 也很难说服业务优化
- 最后只能被动挨骂
但一旦你能清楚地说：
“搜索团队这个月用了 120 核 CPU，
其中 40% 其实是空转的。”
那一刻，你的角色就变了。
九、最后一句话送你
如果你只记住一句，我希望是这句：
Kubernetes 的成本问题，
从来不是“算不算得清”，
而是“你敢不敢算”。
算清楚了，
你就不只是“管集群的”，
而是帮公司守钱的那个人。
