每个月，它都在攀升，每个月，都会有人说：“Kubernetes 就是这样工作的。”

并非如此。

问题不在于 Kubernetes，而在于我们使用它的方式。

当我不再把 Kubernetes 看作一个可以自动扩展的神奇黑盒子时，我开始发现你能想象到的所有方面都存在臃肿：空闲工作负载、过大的 Pod、大量的日志记录以及实际上没有扩展的自动扩缩器。

经过几周的清理和调整，我们的账单下降了 40%。

我们没有更换供应商，也没有获得任何秘密折扣，只是更好地利用了现有资源。

我们的设置就是一个典型的“YAML越多，问题越多”的例子。

• 数十个用于几乎没有流量的小型服务的命名空间。

   

• 自动扩缩容功能已开启，但 CPU 请求量过大，导致自动扩缩容功能从未触发。

   

• 定时任务每小时运行一次，而这些任务原本每天只运行一次。

   

• Fluentd 流水线正在向高级存储发送数 GB 的调试日志。

我们把 Kubernetes 搞得很贵，因为我们不相信它简单易用。

大多数团队要么让细胞挨饿，要么让它们吃得过饱。我们两种都试了。

我们使用Prometheus 指标和垂直 Pod 自动扩缩器 (VPA)的推荐模式，对比了实际使用量与声明的限制。

结果发现，大约 70% 的 Pod 请求的 CPU 和内存资源是实际使用量的 2-3 倍。

我们将这些限制降低到了合理的数值。一夜之间，集群自动扩缩容程序缩减了几个节点。

节省了大约15%，而且东西也没坏。

接下来，我们查找了无人记得创建的工作负载。

使用以下命令快速查询：

kubectl get pods --all-namespaces --sort- by =.metadata.creationTimestamp

…揭露了整个测试集群、旧的批处理作业以及在不再需要数月后仍在运行的PR 预览应用程序。

我们删除了它们，并在自动过期预览环境中添加了TTL 控制器。

结果：账单又节省了10% ，彻底消除了浪费。

我们原本以为运行大型节点（32 个 vCPU 以上）可以降低管理开销。

但 Kubernetes 并不擅长将工作负载完美地打包到大型节点中。

半个节点会闲置，白白浪费成本。

我们切换到了更小的实例类型（例如，m6i.large而不是m6i.4xlarge），并让自动扩缩容程序处理实例容量的调整。

通过混合使用较小的节点，资源利用率大幅提升，并且我们节省了8% 的成本。

启用水平 Pod 自动扩缩容 (HPA)并不意味着它正在执行任何操作。

我们的 CPU 阈值设置得非常高，所以从未触发过。

我们重新调整了自动扩缩容目标，第 90 百分位使用指标而不是猜测，并根据以下因素进行缩放：自定义指标（例如通过 Prometheus Adapter 请求速率）。

结果：在低流量时段，pod 缩减规模，节点也随之缩减，集群最终恢复了应有的运行状态。

节省：多5-7% 。

这是最难的一步。

我们在 EBS 卷和存储日志上的花费远远超过了实际计算资源上的花费。

我们发现审计日志、调试跟踪和系统日志都存储在高级块存储中。

然后，我们将这些日志移至 S3 Glacier 进行冷数据存储，将非关键日志的日志保留期从 1 年缩短至 7 天，并完全停止在生产环境中生成调试日志。

节省：约 6%。

Kubernetes 本身成本不高，成本主要来自运行不善的 Kubernetes 服务。

我们很容易把问题归咎于云费用，而实际上问题出在我们自身以及我们如何利用资源上。

清理之后，我们的集群更小、更快、更容易维护，而且最终成本也达到了它原本应有的水平。

我现在每周检查一次资源使用情况，积极减少资源占用，并质疑每个新的工作负载是否必须始终运行。

如果您觉得 Kubernetes 的成本难以控制，请不要放弃该平台。

检查你的请求，减少噪音，调整节点大小，并停止记录每个心跳。

你可能会发现，你账单的 40% 都是自己造成的。