cesign 最近的时间轴更新
cesign

cesign

V2EX 第 607365 号会员,加入于 2022-12-19 21:30:29 +08:00
给昂贵的云降降本
程序员  •  cesign  •  80 天前  •  最后回复来自 cesign
51
NAS 软件:资源自动发现和下载,支持调用迅雷下载
NAS  •  cesign  •  120 天前  •  最后回复来自 krystal9527
18
docker 版迅雷下载 API,欢迎大家二次开发
分享创造  •  cesign  •  346 天前  •  最后回复来自 xinmans
4
新开源项目,各位 v 友来看看
分享创造  •  cesign  •  142 天前  •  最后回复来自 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 最近回复了
80 天前
回复了 cesign 创建的主题 程序员 给昂贵的云降降本
@sampeng

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

by the way ,AWS 开源的。
80 天前
回复了 cesign 创建的主题 程序员 给昂贵的云降降本
@sampeng

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


那不能想办法增强吗?懒得思考?
80 天前
回复了 cesign 创建的主题 程序员 给昂贵的云降降本
@sampeng

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


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

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


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

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


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


那你有没有想过这种场景不适合用 cpu 作为 HPA 的伸缩指标?这么用,按推理可能会一直扩容。
80 天前
回复了 cesign 创建的主题 程序员 给昂贵的云降降本
> 我就不能买 10u ,然后补个 saves plan 么

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

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

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

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

首先,我没强推这个工具,友好交流。降本和提升利用率,本质是一个事物的一体两面。提升钱的利用率难道不是提升利用率吗?
80 天前
回复了 cesign 创建的主题 程序员 给昂贵的云降降本
@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 一直处于不稳定状态” ,能不能专业点。
80 天前
回复了 cesign 创建的主题 程序员 给昂贵的云降降本
@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 的极致弹性。
81 天前
回复了 cesign 创建的主题 程序员 给昂贵的云降降本
@br9852000 看业务类型,我们这种业务加上 od+spot 混合调度,没有端服过。
81 天前
回复了 cesign 创建的主题 程序员 给昂贵的云降降本
@ytmsdy 当然,逐步来,我们也是搞了好久。
81 天前
回复了 cesign 创建的主题 程序员 给昂贵的云降降本
@perfectlife

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

知识盲区,感谢提醒,这个很有用。
81 天前
回复了 cesign 创建的主题 程序员 给昂贵的云降降本
@tabliu

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

确实是这样的。不过拉长时间看,比如 3 个月,大部分时间还是 spot 在跑,少部分时间使用 od 在跑
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   986 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 20ms · UTC 20:21 · PVG 04:21 · LAX 13:21 · JFK 16:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.