从波动到节约：Kubernetes 成本优化

我们的 AWS 账单在一个季度内激增了 34%。 产品路线图并未发生变化。 原因很简单：我们的 Kubernetes 集群在浪费资金。

工程师经常凭直觉猜测服务需要多少 CPU 和内存。 为了保险起见，他们通常会向上取整。 这会产生“虚假容量”。 你在为应用程序从未使用的资源买单。

以下是我们如何解决这一问题并节省 34% 月度成本的方法。

核心问题：Requests 与 Limits

Requests 是你所保证的资源量。 Kubernetes 使用这个数值将你的 Pod 调度到节点上。 这个数值决定了你的账单金额。

Limits 是上限。 如果 Pod 达到 CPU Limit，它会变慢。 如果它达到内存 Limit，它就会被终止。

许多团队将 Requests 设置为等于 Limits。 这意味着即使在服务空闲时，你也在全天候为峰值容量付费。

我们的节约策略

  • 先测量再行动：使用 Prometheus 和 Grafana 查看实际使用情况。
  • 使用分位数：查看 4 周内的 p95 使用率。不要使用平均值，因为平均值会掩盖峰值。
  • 合理设置 Requests：将 Requests 设置为 p95 使用率加上 20% 的缓冲。
  • 管理 CPU Limits：避免对敏感服务设置过紧的 CPU Limits，以防止限流。
  • 自动化扩缩容：使用 HPA 处理流量激增，使用 VPA 调整单个 Pod。

结果

我们将节点数量从 40 个减少到了 26 个。 平均 CPU 利用率从 14% 提升到了 52%。 每月计算成本从 $48,200 降至 $31,900。 延迟实际上降低了 35%。

优化不是一次性的项目。 它是一种习惯。 如果你根据猜测来编写资源请求，你就是在浪费钱。

集群检查清单：

• 构建一个显示 Requests 与实际使用量对比的仪表板。 • 根据 4 周的数据设置 Requests。 • 在让 VPA 执行更改之前，先以推荐模式运行。 • 每季度审查一次资源规格。 • 让工程团队能够直观地看到自己的成本。

来源：https://dev.to/samarth_05/from-spikes-to-savings-practical-k8s-cost-optimization-for-2026-75k

可选学习社区：https://t.me/GyaanSetuAi