给昂贵的云降降本

[cesign]

云 K8s 太贵，来看看用 Karpenter 给其降本一下： https://mp.weixin.qq.com/s/1QANbWZ6Sx7HGzez74rGRw

结合我的实践，大概能降60%左右！

[sampeng]

@cesign 第一个点：spot 最大问题是有可能不通知回收机器，最常见的是 60 秒前才通知。普通伸缩是可以优雅关机优雅降级。spot 就是看 aws 通知了，还是那个点，业务要能忍受和鲁棒。如果全靠通知自动伸缩，锅从天上来。

fargate 相信你没用过，所以你才说和 ec2 一个体验。第一，ec2 的 as 有延迟，默认时间是 300s 。可以改，但有问题，他缩回去也有延迟，也可以改。我一开始也用过这个方案，但是 k8s 的 as 的逻辑极其诡异，很容易一会弹出 10 个机器，一会全缩完了。来回蹦跶。如果是 java 业务就更蛋疼了，在默认情况下，如果集群很大，在刚起来的时候所有 pod 的 cpu 巨高，就会弹出一堆机器。然后缩回去的时候又集群平衡。pod 一直处于不稳定状态，需要几分钟的稳定时间。所有值都需要经验去增加 buf 时间，我们高峰期就十分钟，你扛不住今天就损失几十万…

[sampeng]

哦，补充一句，你一直计算 spot 都是按最低计算的。这样的机器也是要看库存的。拿最低的 spot 申请的机器容易被回收。然后申请不到新的请问阁下如何应对…
一半拿 spot 做一定业务机，顶天了按 50%的折扣也就是 ri 的折扣水平去申请，而且要为没有机器做好准备的一些防御措施。因为…我就碰到过好几次 spot 不给我机器了，还是在高峰期。我当场脑子就炸了，后来一看哦，是开发测试环境，那没事了。

[cesign]

@sampeng

> spot 最大问题是有可能不通知回收机器，最常见的是 60 秒前才通知

是你瞎猜的还是什么？
近期 2 个月，我们这边会记录中断数据，数百个节点，通知都是>=2min, 有的甚至能到 5min(rebalance recommendation)。

如果一个业务的 grace termination seconds < 1min ，并且没有严苛的 PDB ，完全能优雅关闭。

而且谁让一个业务只用 spot ，10%部分调度到 od,50%部分调度到 spot 不行吗，就算 spot 中断也有兜底（如客户端重试）。


> 所以你才说和 ec2 一个体验。第一，ec2 的 as 有延迟，默认时间是 300s 。可以改，但有问题，他缩回去也有延迟，也可以改。我一开始也用过这个方案，但是 k8s 的 as 的逻辑极其诡异，很容易一会弹出 10 个机器，一会全缩完了。

谁跟你说用 as(如果指 asg)。我通过程序直接调用的 ec2 fleet 接口，，弹性速度是 40s 左右一个节点，如果结合预热(从 shutdown 的机器拉起)可以达到更短，虽然可能没有 fargate 那么快，但是应该非常接近。

对于 java 应用，弹机器是根据 pod request 弹的，不是 usage ，这点你似乎没明白。所以也就不会有“缩回去的时候又集群平衡，pod 一直处于不稳定状态” ，能不能专业点。

[sampeng]

哦。你刚说的有问题…谁说白天 100u ，晚上 10u 我就要买 100u 了。我就不能买 10u ，然后补个 saves plan 么？我就这一个集群啊？运维是一个系统工程，那 90u 可以在其他的成本里面均摊。通常我是直接一个 savesplan 的。也没浪费多少。楼上有小伙伴说的对，优化成本是一个动态变化的，如果白天 90u 是必须的，晚上不需要 90u ，我为啥机器一定要开着呢？弹性伸缩嘛。还有其他的集群均摊成本，各种不同业务特征均摊成本。


跟你掰扯半天就是因为看过这个东西，如果用一个东西你节省了 60%成本。要么本来是 1000 节省到 400 每月。这也是节省 60%。要么就是之前浪费太多了，集群平均利用率水位压根不达标。我见过不少集群常年利用率水位在 10%上下的，还美其名曰留空间。这种就是你稍微关注一下就是一大笔钱省下来。工具只是提高管理效率，用一个工具就省钱就是本末倒置了。是因为省钱我需要用某个功能，正巧这个工具可以帮我做到这个功能而不用我自己开发。而不是因为这个工具可以省 60%成本，所以我要用这个工具……

[cesign]

> 我就不能买 10u ，然后补个 saves plan 么

你知道 sp 的计费逻辑吗？ sp 是按小时承诺的。1 天 10 小时只有需要 10u ，那你这 sp 覆盖了啥，咋覆盖，只要 1 小时内没用超过 10u ，这个 sp 就是白白浪费的钱。他不是算你每天平均值去覆盖的。

> 要么就是之前浪费太多了，集群平均利用率水位压根不达标。

我承认之前浪费非常严重，

> 工具只是提高管理效率，用一个工具就省钱就是本末倒置了

首先，我没强推这个工具，友好交流。降本和提升利用率，本质是一个事物的一体两面。提升钱的利用率难道不是提升利用率吗？

[sampeng]

@cesign 继续和你掰扯，第一个，我自己碰到过突然机器没了没通知，或者一分钟内就会回收了。场景是大数据的 job 机。一天一分钟回收八百次得气死。。其实 k8s 的场景下 asg 已经解决了 spot 的优雅关机问题，他本来就是会自动平衡集群。收到事件后 asg 也会 callback 机器关闭调度。所有过程都非常优雅。唯独机器突然没了这种他自己都处理不了。其他场景 asg 足够了。所有间隔时间都可以调，你猜一个每天要赚钱的项目是相信云平台自己的还是一个不那么出名的开源项目？

第二个…按 pod request 啊。我猜你的意思是 hpa 的计算是按 pod request 计算的？不然自动伸缩自动伸缩，啥值会变呢？也只有 cpu 超过了我的阈值或者我需要按其他指标来扩容啊。没明白你说的按 pod request 咋扩容。不专业了。。我说的场景你没碰到过，没办法。野生运维。伸出来的时候所有 pod 刚启动都是 cpu100 。就一直加到最大值。等完事了发现太多了，又缩回去了。得，不够负载的，又加上起来。所谓集群再次重平衡是机器伸缩出来就涉及到 pod 会调度上来。也会有 node 的驱逐。这个过程又涉及到驱逐后的 pod 再次启动可能会挤到原先机器里面去。

k8 集群千奇百怪的…没有银弹

[sampeng]

@cesign 我一直跟你强调的是运维是综合工作。不是只盯着一个集群。sp 是每小时承诺不假啊，但他覆盖所有的机型和 fagrate 。你猜我是不是业务集群在白天，晚上业务集群是不忙了但大数据集群是不是可以干活了呢？

[sampeng]

另外文章底下有这么一句：

Karpenter 开源版本目前只能根据 Pod 的资源 request ，负责节点的选择、创建和删除，未对业务稳定性做深入设计

你犟什么呢？我一直在说 spot 会有稳定性影响。虽然不致命。但要起命来最少我是承担不起这个责任。

[cesign]

@sampeng

> 我一直跟你强调的是运维是综合工作。不是只盯着一个集群。sp 是每小时承诺不假啊，但他覆盖所有的机型和 fagrate 。你猜我是不是业务集群在白天，


你这场景没问题，那你为啥一定要否定我的解决方案呢？为啥一定要证明你的比我好呢？如果我不跑大数据呢？

而且大数据都是 job 类，大多数大数据 job 都有断点重续，跑 spot 完全没问题。


> 其实 k8s 的场景下 asg 已经解决了 spot 的优雅关机问题

我还是没懂你指 cluster autoscaler 还是 aws 的 autoscaling group 。


> 伸出来的时候所有 pod 刚启动都是 cpu100 。就一直加到最大值。等完事了发现太多了，又缩回去了。得，不够负载的，又加上起来。所谓集群再次重平衡是机器伸缩出来就涉及到 pod 会调度上来。


那你有没有想过这种场景不适合用 cpu 作为 HPA 的伸缩指标？这么用，按推理可能会一直扩容。

[cesign]

@sampeng

> 你犟什么呢？我一直在说 spot 会有稳定性影响。虽然不致命。但要起命来最少我是承担不起这个责任。


那不能想办法增强吗？懒得思考？

[cesign]

@sampeng

> 不那么出名的开源项目？

by the way ，AWS 开源的。