我对KruiseRollout测试时发现这样个情况:
同样的发布镜像,同样的maxSurge(25%)和maxUnavailable(25%),更新100个工作负载(2pod)。工作负载内部设有延时60s就绪。KruiseRollout资源limit是4C8G,4个控制器的并行数都是100
原生滚动最坏情况188s, 最好137s
KruiseRollout最坏情况348s, 最好情况273s
请问有大佬测过KruiseRollout相关性能吗,有没有优化的方向指点呢?
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
如果有流量慢是正常的,因为涉及到 两个 controller 的协调,watch机制的延迟,我们在流量的时候,确实是特意慢的。但是,如果单纯的是分批发布的话,不应该慢太多。。rollout 的每个step是要暂停做业务观察的, 如果你们只用第一批观察, step只设置第一个就行了,后面就不设置好了, 这样后面就是完全deployment滚动下去了,如果pause duration是0, 感觉你都没必要用rollout,直接发deployment就行, rollout是要你能控制流量,或者控制批次暂停观察, 啥都不观察的化用rollout意义不大了,此回答整理自钉群“OpenKruise 社区交流群”