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