cesign's recent timeline updates cesign's recent timeline updates |
cesignV2EX member #607365, joined on 2022-12-19 21:30:29 +08:00 |
| 不止 AWS！ Karpenter 也能在 GCP 上智能扩缩容了 程序员 • cesign • Aug 10, 2025 • Lastly replied by qqqyh | 2 |
| 各位 v 友，求个 star 🙏
1 程序员 • cesign • Feb 28, 2025 • Lastly replied by AmaQuinton
|
8 |
| raid0，有办法把一个盘(100G，实际只用了 20G)热迁移到另外一块盘(30G)吗？ 程序员 • cesign • Jun 28, 2024 • Lastly replied by dorothyREN | 8 |
| NAS 软件：资源自动发现和下载，支持调用迅雷下载 NAS • cesign • Jul 5, 2024 • Lastly replied by krystal9527 | 18 |
| GitAutomator: 智能 GitHub 开源项目助手，帮你减轻维护压力
1 程序员 • cesign • Apr 2, 2024
|
| 使用 yutto，自动下载博主更新的视频，再用不怕视频忽然被和谐啦（狗头） NAS • cesign • Dec 22, 2023 • Lastly replied by TNOK | 6 |
| docker 版迅雷下载 API，欢迎大家二次开发 分享创造 • cesign • Nov 22, 2023 • Lastly replied by xinmans | 4 |
| 新开源项目，各位 v 友来看看 分享创造 • cesign • Jun 13, 2024 • Lastly replied by windcode | 7 |
| open nas lab：汇聚用户，开发者和厂商，致力打造最好 NAS 软件生态。 NAS • cesign • Oct 8, 2023 • Lastly replied by evell | 3 |
cesign's recent replies
Feb 28, 2025 Replied to a topic by cesign › 程序员 › 各位 v 友，求个 star 🙏 |
@paynezhuang 已点
Feb 27, 2025 Replied to a topic by cesign › 程序员 › 各位 v 友，求个 star 🙏 |
@linuxsuren 已点
Feb 27, 2025 Replied to a topic by cesign › 程序员 › 各位 v 友，求个 star 🙏 |
@fibroblast 感谢！
Dec 26, 2024 Replied to a topic by Lynnxx › 云计算 › 在用 Spot 实例的有福了，这个免费工具真的很香！ |
Cool ，不错的工具！
Nov 22, 2024 Replied to a topic by helenfrank › 分享创造 › 自荐我负责参与开发的开源项目 karpenter-provider-alibabacloud, 今天 release 了 0.1.0 |
👍👍👍
@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