👍👍👍

@sampeng

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

by the way ，AWS 开源的。

@sampeng

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


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

@sampeng

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


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

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


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

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


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


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

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

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

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

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

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

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

@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

> spot 回收哪怕你 3 年没出问题，出一次问题。就是一个锅。

K8s 节点都有挂的可能性，照你这么说，用啥 K8s ，用回物理机算了，spot 确实会回收，但是做好回收后的业务连续性问题（提前回滚）就行。

就算是 on-demand ec2 的可用性保证也只有 99.99%，那按你意思，用啥用。

> 一个是要做一个程序去控制，如果 spot 回收还要想办法加回来。这个程序要不要维护？有 bug 怎么办？ api 升级了怎么办？集群升级了怎么办？是不是都是运维管理成本？第二种，哪有什么成本，年初买个 RI ，云平台设置一下定时关机。几年都不用去管他。甚至忘了的存在。

这个程序就是相关产品的价值。RI 没有弹性，我阐述好多遍了，白天要 100U ，晚上 10U ，我得买 100U RI 的钱，那如果我买 10U RI ，90U 的 OD ，这难道不贵吗？




> fargate 就不是这么节省成本的，你这个算法就跟我入现在这个公司发现所有服务都跑在 eci 上一样。fargate 哪能这么用，

那你知不知到有相关 eks+ec2 的解决方案，也可以做极致弹性，有 pod 就扩，没 Pod 就缩，这个和 farget 体验是一样的，而且还便宜。谁跟你说 eks+ec2 不能做到类似 farget 的极致弹性。

@br9852000 看业务类型，我们这种业务加上 od+spot 混合调度，没有端服过。

@ytmsdy 当然，逐步来，我们也是搞了好久。

@perfectlife

> 国内直接就支持啊，阿里云的 axk 好早就支持抢占实例作为 ack 节点，还支持节点被释放前自动拉起一个新抢占实例补上，抢占实例池没资源还能申请按量付费的

知识盲区，感谢提醒，这个很有用。

@tabliu

> 遇到过一个 region 突然回收几百台 spot 机器的，如果没有预先购买 RI 和 SP 用 OD 代替跑几天成本就哭死

确实是这样的。不过拉长时间看，比如 3 个月，大部分时间还是 spot 在跑，少部分时间使用 od 在跑

@sampeng
而且我不觉得你方案一和方案二维护成本差多少，接近一样。都需要更具 AWS 的 spot 通知，迁移 spot 节点的业务

@sampeng

> 尽可能通知你，但有可能不通知你，自己负责。

还是看你怎么用，我们目前用下来，提前通知都受到了。没有遗失的。

> 而且还要分业务和环境。我做过两种方案，第一种方案呢，开发测试环境白天开 spot ，晚上关机。第二种方案就是直接 RI 覆盖 50%。晚上自动把多余的机器关了，再自动根据流量伸缩一些 spot 机器出来临时用用。看着是前者省钱了，但是一顿操作猛如虎，一看就省 2 毛五。

算算，假设 100 台 m5.xlarge ，弹性的为 50 台
所以第二方案的成本为：(50*0.121+50*0.0588)*1 个月=6562.7$
第一方案成本：(50*0.121+50*0.0588)*1 个月=4292.4$

所以 1 年 2w$属于 2 毛 5 的范畴？如果识别出来业务适合 spot ，为啥不用？


> 现在 fargate 其实是个不错的节省成本方案，如果无状态的，临时调度的扔 fargate 里面，跑完就关了。比开机器舒服多了。

给你看看 farget 成本：以一个程序(2Core/2GiB)运行一小时为例：
EKS Fargate=0.0896$
EKS/EC2=0.077$，使用 c5a.large(2Core/4GiB)，还有 2GiB 的剩余

如果有一种手段既能享受到 farget 弹性，还能稳定使用 spot ，为啥不用？

@fredcc
> spot 实例的中断管理本来也不应该 asg 管啊

那什么来管 spot 上用例的稳定性呢？依靠应用不显示，毕竟正在处理的请求，中断后就丢失了

> eks 不能做么

当然可以，主要是细粒度的应用调度级别的控制

> 楼主的回答只考虑有利于自己的一方。。。这没法聊。。我也能反过来反驳

当然，根据我们的业务场景，这解决方案也有局限性。

关于第 2 点：spot 中断后，正在处理的请求会失败，需要一个机制去提前驱逐节点。这个 autoS 是肯定没有的
关于第 4 点：确实没考虑到。

RI 在我们场景下，并不能省多少，还有很强的绑定，后续我没用这么多资源了，也要求付钱。

@sampeng

> spot 要根据业务特征来定制

完全赞同，还是要识别一些东西。

> 看见太多集群 10%的利用率了。看见太多数据库上来就是一个 8c32G 的了。也看见太多不管三七二十一微服务几十个还不如一个单体跑 2-3 台机器

+++100 ，Karpenter 也有根据资源，自动替换更小节点的能力。

@Frankcox

> 这个是 aws 的节点弹性扩缩的那个服务吧？
指 managed node group 还是 cluster autoscaler? 和着两个区别挺大的。文章里面有描述

@salmon5 这个负责人风险其实挺大的

这个看阶段，增长期的公司，基本不咋关注成本，野蛮生长。

@salmon5

> 花里胡哨的，没参考价值。一个 AWS RI 就搞定的事情。

表示怀疑，以 m5.xlarge 为例(us-east-2)，按需价格为$0.1920/hour ，RI 价格为$0.121/hour ，Spot 价格为 0.0588$/Hour,
简单的购买 RI 只是无脑做法，并不是最优做法。

而且 RI 有个缺陷是，如果我业务改革，导致机器没必要用这么多了，RI 的钱我还是要付（就算我把机器释放），绑定非常严重。

当然，如果有钱，随便造。