CNCF Kepler 重构：无需内核权限即可精确测量 Kubernetes Pod 的能耗

Kepler（基于 Kubernetes 的高效功率级别导出器，Kubernetes-based Efficient Power Level Exporter），这个自 2023 年起测量 Kubernetes 集群能耗的 CNCF 沙箱项目，已获得全新架构。团队发布了详细的技术重写说明、实验结果以及向社区寻求协作的呼吁——对于运营 AI 和 ML 工作负载（其能耗正成为越来越重要的指标）的组织而言尤为相关。

为什么 Kubernetes 对能耗「视而不见」？

Kubernetes 原生上不提供任何跟踪单个 Pod 或工作负载消耗多少能量的机制。集群管理员可以看到 CPU 和内存消耗，但看不到瓦数——当组织希望跟踪碳足迹、优化能源成本或满足 ESG 报告要求时，这就成了问题。Kepler 填补了这一空白：读取硬件功率计量器，将能耗归因于各个 Linux 进程和 Pod，并将结果导出为 Prometheus 指标。

旧架构及其问题

原始 Kepler 依赖 eBPF（扩展 Berkeley 数据包过滤器）来捕获使用率信号。这种方法在生产环境中存在几个严重限制：

它需要 CAP_BPF 和 CAP_SYSADMIN 权限——许多安全团队不允许标准监控工具拥有这些权限。生产 Kubernetes 集群通常有严格的容器权限策略，Kepler 在部署阶段就可能被阻止。

eBPF 方法会遗漏短暂进程——这些进程在内核探针来得及记录之前就已完成。在密集使用短批量任务的 AI/ML 工作负载中，这种不精确性可能会累积。

最明显的症状是测量中出现千瓦级跳变——这是实现层面的工件，并不反映真实的物理功耗，但会污染指标和仪表板。

无需内核权限的新架构

新架构与精度飞跃

新版 Kepler 完全放弃了 eBPF。相反，它读取 Linux 内核为所有进程暴露的标准 /proc 和 /sys 路径——无需内核权限。访问方式为只读：Kepler 不向内核写入内容，也不注入代码。

关键创新是运行时动态发现功率计结构。旧架构假设固定的硬件拓扑，这在具有不同 DRAM、socket 和 package 级别配置的服务器上会导致错误。新版本在启动时从 /sys 读取结构，无需手动配置即可自适应。

部署被简化为单一 Helm chart，大大降低了学习曲线和可配置参数的数量。

实验结果

团队进行了两项关键实验以验证新架构：

实验 1 将新的 kepler_node_cpu_watts 与 IPMI 基准测量（服务器硬件上的物理传感器）进行比较。结果：新指标在跟踪 IPMI 模式的同时不出现旧实现特有的千瓦级跳变。

实验 2 测量了进程级功率归因误差——所有进程归因功率之和与节点总测量功率之间的差距。误差降至毫瓦级（而非以前的瓦或千瓦级），证实新架构能一致地分配总功耗。

测试覆盖率达到 90%，对于这种类型的基础设施工具而言是很高的水平。

向社区的呼吁

Kepler 团队列出了四个寻求贡献的领域：

AI/ML 工作负载的 GPU 监控仍是未解决的问题——当前架构覆盖 CPU，但由于 NVIDIA 和 AMD 暴露指标的方式，每 Pod 的 GPU 能耗归因更为复杂。对于在 Kubernetes 中运行大语言模型推理或训练的组织而言，这一点尤为相关。

VM 环境的功率建模需要 ML 方法，因为虚拟化层隐藏了物理计量器。团队寻求能够训练功率估算模型的专家。

与物理测量仪器（IPMI、外部电能表）的验证，以及改进空闲功率归因，是另外两个开放问题。

对于已经在测量 AI 基础设施能耗的组织，新版 Kepler 为集成到现有 Prometheus/Grafana 堆栈提供了更稳定的基础，而无需在集群安全策略上做出妥协。