如果你的Kubernetes集群正在悄悄吞掉预算,你会指望 AWS 账单页面来报警吗?
上个月某个周四,一位运维在例行对账时看到 EC2-Other 栏位跳涨,随即打开终端敲下 brew install tanrikuluozlem/burn/burn,三分钟后,一份按命名空间、服务类型甚至单个 Pod 拆分的成本报告直接显示在屏幕上——没有安装集群内代理,没有配置持久化存储,也没有 YAML 文件需要维护。
![]()
这就是 Burn 带给团队的第一个惊讶:零设置。macOS 上用 Homebrew 一行安装,Linux 下从 GitHub 拉取二进制文件,Docker 或 Helm 部署也都只需要命令克隆与一条 helm install。不论集群在 AWS EKS、Azure AKS、GCP GKE 还是本地机房,工具启动那一刻就能拉取实时云定价,把计算、存储、负载均衡和 GPU 算力的每小时费用全部摊开。
过去想拿到这样的明细,往往需要先派 Prometheus 采集指标,再写查询组合,最后拼进电子表格。Burn 直接跳过这些步骤:不带任何指标源运行时,它利用集群自身资源申请量做估算;接入 Prometheus 端点后,它会自动读取实际用量并换算为每个工作负载的花销。比如一份 burn analyze --prometheus http://prometheus:9090 --period 7d 的输出,给的是过去七天的日均费用,而不是某个瞬间的快照,恰好对得上云服务商按日结算的节奏。
这还不是全部。周五下午,另一位工程师在 Slack 里敲下 /burn,一条即时成本概况被贴进频道。他接着打 /burn ask “哪个命名空间上个月增长最快?”,几秒后收到的不是图表链接,而是一行 kubectl 命令,可以直接复制去终端执行。这个“AI 驱动”的交互背后,工具把自然语言提问转成了可落地的运维指令,省去了翻文档和拼查询字段的功夫。
随着使用深入,团队发现了更多隐藏开销:两个不同入口声明的负载均衡因为 Hostname 相同,其实指向同一台 ALB,账单却差点被重复计算。Burn 的 Ingress LB 探测会自动去重,把那些从 Service 和 Ingress 资源分别暴露出来的负载均衡归并,避免吓人的虚高数字。另一项让人眼前一亮的特性是 Spot 就绪度分析——工具实时对比按需实例与竞价实例的折扣率及中断概率,明确指出哪些工作负载可以安全迁移到 Spot 实例上,直接压低浮动开支。
从第一天 brew install 到团队全员在 Slack 里用 /burn 追踪成本,整个过程不过一周。没有新面板要学习,没有新 Agent 要运维,熟悉的终端和群聊就是全部入口。正如项目 README 里那句直白的话:“Your Kubernetes cluster is burning money. Find out where.” 这个发现“在哪里烧钱”的过程,现在只需要一次安装、一条命令。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.