当我不再把 Kubernetes 看作一个可以自动伸缩的神奇黑盒子时，才开始发现那些你完全能想象到的浪费无处不在：闲置的工作负载、过大的 Pod、海量的日志记录，以及实际上从未真正扩展的自动扩缩器。
我曾经以为我们不断上涨的 Kubernetes 账单只是云端开展业务的必要成本。
每个月，它都在攀升，每个月，都有人说：“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% 都是自己造成的。
作者｜Mohab 编译｜Rio
来源｜网址：https://aws.plainenglish.io/how-we-cut-our-kubernetes-costs-by-40-without-moving-to-another-platform-25304feb6494
