cesign 最近的时间轴更新 cesign 最近的时间轴更新 |
cesignV2EX 第 607365 号会员，加入于 2022-12-19 21:30:29 +08:00 |
| raid0，有办法把一个盘(100G，实际只用了 20G)热迁移到另外一块盘(30G)吗？ 程序员 • cesign • 184 天前 • 最后回复来自 dorothyREN | 8 |
| NAS 软件：资源自动发现和下载，支持调用迅雷下载 NAS • cesign • 176 天前 • 最后回复来自 krystal9527 | 18 |
| GitAutomator: 智能 GitHub 开源项目助手，帮你减轻维护压力
1 程序员 • cesign • 270 天前
|
| 使用 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 • 198 天前 • 最后回复来自 windcode | 7 |
| open nas lab：汇聚用户，开发者和厂商，致力打造最好 NAS 软件生态。 NAS • cesign • 2023-10-08 14:45:23 PM • 最后回复来自 evell | 3 |
| 手撸了个 AI zsh shell 智能补全，有 V 友需要吗？ 程序员 • cesign • 2023-09-07 09:50:40 AM • 最后回复来自 wulv | 9 |
| NAS 资源下载项目：有哪位前端大佬能来开源项目贡献一下吗？ NAS • cesign • 2023-09-06 15:01:19 PM • 最后回复来自 libook | 9 |
cesign 最近回复了
2 天前 回复了 Lynnxx 创建的主题 › 云计算 › 在用 Spot 实例的有福了，这个免费工具真的很香！ |
Cool ，不错的工具！
36 天前 回复了 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 一直处于不稳定状态” ，能不能专业点。
@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 的极致弹性。
> 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 当然，逐步来，我们也是搞了好久。
Select Language