北京
如果你的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.
