Kubernetes 不贵，糊涂才贵

聊聊如何量化 Namespace / 团队的真实成本

搞 Kubernetes 的朋友，迟早都会遇到一个灵魂拷问：

👉 “我们这套 K8s，一年到底烧了多少钱？”
👉 “哪个团队最费钱？”
👉 “为啥老板总觉得集群是个无底洞？”

更扎心的是——
你是运维，你心里大概有个数，但你算不清，也说不明。

于是常见画面就出现了：

• 业务方：

  “我们也没用多少资源啊？”

• 运维：

  “集群快满了，再加节点要钱。”

• 老板：

  “钱花哪儿了？谁花的？”

如果你点头了，那这篇文章，就是写给你的。

一、先说个大实话：Kubernetes 本身不懂“钱”

这是很多人一开始就拧巴的地方。

Kubernetes 只关心三件事：

• CPU
• 内存
• 调度

它完全不关心：

• 谁在用
• 用来干嘛
• 值不值这个钱

所以：

👉 K8s 天生不具备“成本视角”

成本，是我们运维后来硬塞进去的概念。

而 Namespace，恰好成了这件事里最像“账本”的东西。

二、为什么一定要按 Namespace / 团队算成本？

我见过不少团队，一上来就想：

“直接算 Pod 成本不就完了？”

理论上可以，现实中基本翻车。

原因很简单：

• Pod 太碎
• 生命周期太短
• 没业务语义

而 Namespace 通常满足三个条件：

1. 和团队 / 项目强绑定
2. 生命周期相对稳定
3. 天然隔离（权限 / 配额）

所以在绝大多数公司里：

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 的成本问题，
从来不是“算不算得清”，
而是“你敢不敢算”。

算清楚了，
你就不只是“管集群的”，
而是帮公司守钱的那个人。