@
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 一直处于不稳定状态” ,能不能专业点。