cesign 最近的时间轴更新 cesign 最近的时间轴更新 | cesignV2EX 第 607365 号会员，加入于 2022-12-19 21:30:29 +08:00今日活跃度排名 16732 |
| 不止 AWS！ Karpenter 也能在 GCP 上智能扩缩容了 程序员 cesign 63 天前 最后回复来自 qqqyh | 2 |
| 各位 v 友，求个 star 1 程序员 cesign 226 天前 最后回复来自 AmaQuinton | 8 |
| raid0，有办法把一个盘(100G，实际只用了 20G)热迁移到另外一块盘(30G)吗？ 程序员 cesign 2024-06-28 03:54:09 AM 最后回复来自 dorothyREN | 8 |
| NAS 软件：资源自动发现和下载，支持调用迅雷下载 NAS cesign 2024-07-05 22:03:59 PM 最后回复来自 krystal9527 | 18 |
| GitAutomator: 智能 GitHub 开源项目助手，帮你减轻维护压力 1 程序员 cesign 2024-04-02 14:39:40 PM |
| 使用 yutto，自动下载博主更新的视频，再用不怕视频忽然被和谐啦（狗头） NAS cesign 2023-12-22 14:01:42 PM 最后回复来自 TNOK | 6 |
| docker 版迅雷下载 API，欢迎大家二次开发 分享创造 cesign 2023-11-22 23:19:35 PM 最后回复来自 xinmans | 4 |
| 新开源项目，各位 v 友来看看 分享创造 cesign span title="2024-06-13 15:02:08 +08:00">2024-06-13 15:02:08 PM 最后回复来自 windcode | 7 |
| open nas lab：汇聚用户，开发者和厂商，致力打造最好 NAS 软件生态。 NAS cesign 2023-10-08 14:45:23 PM 最后回复来自 evell | 3 |
cesign 最近回复了
226 天前 回复了 cesign 创建的主题 程序员 各位 v 友，求个 star |
@paynezhuang 已点
227 天前 回复了 cesign 创建的主题 程序员 各位 v 友，求个 star |
@linuxsuren 已点
227 天前 回复了 cesign 创建的主题 程序员 各位 v 友，求个 star |
@fibroblast 感谢！
290 天前 回复了 Lynnxx 创建的主题 云计算 在用 Spot 实例的有福了，这个免费工具真的很香！ |
Cool ，不错的工具！
@sampeng
> 我一直跟你强调的是运维是综合工作。不是只盯着一个集群。sp 是每小时承诺不假啊，但他覆盖所有的机型和 fagrate 。你猜我是不是业务集群在白天，
你这场景没问题，那你为啥一定要否定我的解决方案呢？为啥一定要证明你的比我好呢？如果我不跑大数据呢？
而且大数据都是 job 类，大多数大数据 job 都有断点重续，跑 spot 完全没问题。
> 其实 k8s 的场景下 asg 已经解决了 spot 的优雅关机问题
我还是没懂你指 cluster autoscaler 还是 aws 的 autoscaling group 。
> 伸出来的时候所有 pod 刚启动都是 cpu100 。就一直加到最大值。等完事了发现太多了，又缩回去了。得，不够负载的，又加上起来。所谓集群再次重平衡是机器伸缩出来就涉及到 pod 会调度上来。
那你有没有想过这种场景不适合用 cpu 作为 HPA 的伸缩指标？这么用，按推理可能会一直扩容。
> 我一直跟你强调的是运维是综合工作。不是只盯着一个集群。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 就是白白浪费的钱。他不是算你每天平均值去覆盖的。
> 要么就是之前浪费太多了，集群平均利用率水位压根不达标。
我承认之前浪费非常严重，
> 工具只是提高管理效率，用一个工具就省钱就是本末倒置了
首先，我没强推这个工具，友好交流。降本和提升利用率，本质是一个事物的一体两面。提升钱的利用率难道不是提升利用率吗？
你知道 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 一直处于不稳定状态” ，能不能专业点。
> 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 一直处于不稳定状态” ，能不能专业点。
Select Language