Marico's space

最近折腾了 Kubernetes 项目的成本优化，踩了几个坑，这篇把问题说清楚。

Kubernetes 本身不会让基础设施变贵。

它只是让基础设施的失误更容易规模化。

这才是让人不舒服的地方。

一个 VM 上的小部署错误很烦人。但如果同样的错误扩散到几十个服务、节点池、命名空间、自动扩缩容器（autoscaler）和环境上，就变成了每个月都解释不清的一笔账。

这就是为什么很多团队上了 Kubernetes 之后期待更好的基础设施效率，结果半年后发现云账单越来越难看懂了。

Kubernetes 不是罪魁祸首。但它也不是成本优化策略。

真正的问题所在

大多数团队以为 Kubernetes 的成本来自控制平面、托管集群费用，或者某种模糊的"容器开销"。

钱通常不是花在那里的。

真正的成本来自 Kubernetes 推动的运营模式：

• 每个服务都有独立的资源请求
• 每个团队都要预留缓冲空间
• 每个环境都开始看起来像生产环境
• 每个自动扩缩容器都在对不完美的信号做出反应
• 每个节点池都带着闲置容量
• 每个工作负载都变得比退役更容易部署

Kubernetes 让部署变简单了。这是好事。

但当部署变得简单，而成本反馈仍然薄弱时，基础设施就会悄悄扩张。

资源请求是账单的起点

在 Kubernetes 中，CPU 和内存请求不只是文档。它们是调度的输入。

如果一个 Pod 请求 2 个 CPU 和 8 GB 内存，Kubernetes 必须把它调度到看起来有足够可用容量的节点上，不管这个应用实际使用多少。

这意味着你的账单往往反映的是请求的容量，而不是实际有用的工作。

当团队基于恐惧设定请求时，这就特别危险：

• "它崩过一次，所以内存翻倍"
• "以后可能会有流量"
• "生产环境应该有更多缓冲"
• "跟旧部署的实例规格保持一致"

单独看，这些都不是什么疯狂的决定。

但放在一起，就创造了一个调度器看起来很忙、财务团队看起来很空的集群。

自动扩缩容不能修复错误的输入

很多团队以为自动扩缩容会解决这个问题。

它有帮助，但前提是信号是合理的。

水平 Pod 自动扩缩容（HPA）可以根据 CPU 或内存等指标添加或删除副本。节点自动扩缩容可以在 Pod 需要运行时添加或删除机器。

但如果资源请求被夸大了，Kubernetes 可能认为集群需要更多节点，即使实际利用率很低。

自动扩缩容不会神奇地理解业务价值。它只会执行你给它的数学运算。

错误的请求输入，昂贵的扩容输出。

隐性成本：碎片化

Kubernetes 集群很少干净地浪费容量。

浪费是碎片化的。

你通常不会有一台巨大的空机器在那儿闲置。而是有很多节点上分散的小块未使用的 CPU 和内存，被 Pod 形状、亲和性规则、守护进程集（daemonset）、中断预算、GPU 放置约束和环境特定假设所阻塞。

这种碎片化很重要。

一个节点的 CPU 和内存在整个集群范围内可能总量足够空闲，但对于下一个 Pod 来说，在正确的位置上没有足够的可用容量。

所以自动扩缩容器又加了一个节点。

这就是 Kubernetes 账单可能上涨，而仪表盘显示平均利用率很低的原因之一。

平均利用率不等于可调度的容量。

Kubernetes 也扩大了浪费的表面面积

在 Kubernetes 之前，一个团队可能在几台实例上运行少量服务。

上了 Kubernetes 之后，同样的组织往往有：

• 预发环境集群
• 预览环境
• 多个节点池
• 可观测性组件
• 入口控制器
• 服务网格
• CI 工作负载
• 备份任务
• 废弃的命名空间
• 重复的服务
• 团队级别的沙箱环境

其中一些是有用的。

其中一些只是披着 YAML 外衣的基础设施熵增。

成本问题不在于 Kubernetes 增加了开销。成本问题在于它让开销感觉上是正常运营的一部分。

什么时候 Kubernetes 值得用

当复杂性为你换来真正的东西时，Kubernetes 是值得的。

通常意味着：

• 很多服务有独立的部署周期
• 团队需要标准化的部署工作流
• 工作负载受益于 bin packing
• 流量模式支持自动扩缩容
• 有强大的平台工程纪律
• 规模大到调度效率开始重要
• 资源请求和集群成本有明确的负责人

当协作问题是比原始基础设施成本更大的问题时，Kubernetes 开始变得有意义。

如果你的主要问题是"我们需要以低成本运行两个应用"，Kubernetes 可能不是第一答案。

如果你的问题是"五十个服务跨多个团队需要可重复的部署、隔离、扩缩容和运营策略"，Kubernetes 可能是值得的。

什么时候 Kubernetes 不值得用

对于以下情况，Kubernetes 通常是错误的默认值：

• 早期产品部署需求简单
• 小团队没有平台所有权
• 低流量 API
• 可以在更简单基础设施上运行的批处理任务
• 调度和利用率还没有被很好理解的 GPU 工作负载
• 无法按工作负载测量利用率的团队

残酷的版本：

如果你今天无法解释计算费用花在哪里，Kubernetes 可能会让它变得更难，而不是更好。

GPU 版本更糟糕

CPU 浪费是痛苦的。

GPU 浪费是残酷的。

一个稍微超规格的 CPU 节点可能多花几百块。一个使用率不足的 GPU 节点可能烧掉几千块。

Kubernetes 可以帮助调度 GPU 工作负载，但它不会自动解决 GPU 经济问题。

常见失败模式：

• 为只需要部分容量的工作负载预留整个 GPU
• 让昂贵的 GPU 节点在任务之间空闲
• 把延迟敏感的推理和批处理工作负载混合得很差
• 扩容 Pod 时没有理解模型加载时间
• 只把 GPU 内存当作唯一瓶颈
• 忽视更便宜的区域、供应商或实例类型

对于 AI 团队，Kubernetes 可以是一个强大的编排层。但它不是利用率分析的替代品。

问题不是"我们在用 Kubernetes 吗？"

问题是"我们每花一块钱能得到多少有用的计算？"

一个简单的决策框架

在把工作负载迁移到 Kubernetes 之前，问自己五个问题：

1. 这个工作负载需要编排，还是只需要部署？
2. 自动扩缩容会减少实际支出，还是只会增加复杂性？
3. 我们是否知道实际的 CPU、内存、网络和 GPU 利用率？
4. 启动后谁负责正确调整请求的大小？
5. 更便宜的非 Kubernetes 选项是什么？

最后一个问题很重要。

Kubernetes 应该胜在替代方案，而不是胜在对"不够scalable"的模糊恐惧。

有时候更好的答案是托管容器服务。

有时候是单台 VM。

有时候是无服务器（serverless）。

有时候是专门的 GPU 提供商。

有时候 Kubernetes 是对的，但前提是工作负载足够复杂来证明它的价值。

务实的修复方案

如果 Kubernetes 已经在推高你的账单，不要从平台迁移开始。

从测量开始。

关注这些：

• 请求的 vs 实际的 CPU
• 请求的 vs 实际的内存
• 节点级别可分配 vs 已用容量
• 空闲的 GPU 时间
• 最近没有流量的 Pod
• 所有权不清晰的命名空间
• 从不缩容的工作负载
• 一直运行的预发环境和预览环境
• 利用率很低的昂贵节点池

然后先修那些无聊的东西。

正确调整请求大小。删除废弃的工作负载。按工作负载形状分离节点池。谨慎使用自动扩缩容。在添加更多容量之前审查 GPU 利用率。

无聊的工作通常在架构工作之前就有回报。

底线

Kubernetes 昂贵不是因为它没效率。

Kubernetes 昂贵是因为它给团队提供了对基础设施的强大抽象，却没有自动给他们成本纪律。

它绝对可以值得。

但只有当组织把调度、利用率和成本当作工程问题来对待，而不是财务清理工作时。

最好的 Kubernetes 团队不会问：

"我们怎么让集群变大？"

他们会问：

"从我们已经在付钱的计算力中，我们得到了多少有用的工作？"

这是更多基础设施团队应该问的问题。

原文链接：https://dev.to/apptopia/why-kubernetes-is-driving-up-your-cloud-bill-and-when-it-is-worth-it-4l3