我们目前稳定使用 2 个月（ 3 人共享 2 账号），没啥问题；
推荐我们自己的项目，多个账号团队池化： https://github.com/gesta-run/subpool

@bowencool hello ，感谢关注，我马上搞一下

@Mandyer ws 已支持，gpt 指纹还在支持中

@deqiying 已支持

看我看我，https://github.com/gesta-run/subpool
相比 sub2api 更轻量化，易管理；

@crackhopper 还是各种实验中，看怎么最稳定，后续更新

@Kinnice 是的，目前是通过每个账号不超过 3 人共享，目前稳定运行 2 个月

@gyl1989113 是的是的

@paynezhuang 已点

@linuxsuren 已点

@fibroblast 感谢！

Cool ，不错的工具！

👍👍👍

@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 的极致弹性。