请问KubeVela中，这几天我在操作 poc，感觉用 kruise-rollout 扩缩容相关操作
"问题1：请问KubeVela中，这几天我在操作 poc，感觉用 kruise-rollout 扩缩容相关操作是比较别扭，不变容量的部分感觉很杰出了，或者说 kruise-rollout 其实不想自己去操刀做容量的事情。我是比较需要理解 kruise 类似这样的态度，比如 kruise 想让用户自己去改 replicas，那我后面的方向就会自己开发一些扩缩容的 vela step 专门去做这个事，不强求 kruise ，之前是别的同事在试验同时修改工作负载内容和容量，但是没法保障顺利执行 kruise rollout 里的分批计划。 请问是什么原因呢？ 问题2：用百分比分批也不行吗？我没法强制用什么方式，不过也不一定会遇到发布中复本又变化的情况。扩缩容看起来是几个情况 1. 只调整复本数的话，不会走分批计划，会直接一步到位 2. 镜像有变化的话，有一些看起来尽量合理化的比例变更逻辑
不过确实你的提法更合理，先变水位后 rollout 的行为干净明确…… 所以现在我的倾向是，之前我习惯 vela-rollout 那种蓝绿对滚了，现在要重新考虑下；很可能扩缩容要单独做工作流步骤，不搞看似一步到位实则含混不清的事情了"
写回答
-
意中人就是我呀！"回答1：kruise-rollout更多还是关注deployment的template spec内容，我们目前是通过vela的scaler trait来做的扩容和缩容，不过后面对于超大规模的扩容和缩容，就得自己开发step或者trait。在副本变化比较频繁的场景，还是推荐使用百分比来设置分批梯度。 回答2：这种可能适合通过工作流来做，比如先改变副本，人工确认之后，再去做升级变更。目前对于问题 1. 是因为确实没有看到扩容需要分批的场景；就我们内部的场景而言，我接触到的一些 PaaS，发布与扩缩容是两条独立的链路，不过 kruise rollout 目前确实也考虑两者并发的场景，会按照用户 steps 的描述来发布，且中间不会出现卡住的情况。 此回答整理至钉群“OAM/KubeVela 社区交流群”"
2023-06-01 10:31:05赞同 展开评论 打赏
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践，通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式，助力制造业企业高效上云，实现系统稳定、应用敏捷智能。拥抱云原生，让创新无处不在。
