[feature request] 原地升级功能实现是否可以优化

[Forget-C]

各位好， 首先我非常喜欢这个项目， 今天在阅读项目源码时有一些思考和建议， 希望和大家交流。 我注意到workload的原地升级与CRR的实现是有重合， 存在区别是， CRR因为要控制原地重启所以需要到node节点上调用cri执行操作， 而原地升级可以通过kubelet本身的机制完成重启。 我在想， 是否可以在CRR中增加image update的功能， 与原地升级“合并”？ 可以是代码上的合并， 也可以是接收到原地升级的请求后创建CRR并利用informer监听的方式在组件间解耦。 如果可以“合并”， 同样可以将NodeImage的功能添加到CRR中， 以预热镜像加快重启速度。

如果建议采纳， 请将开发分配给我， 谢谢～

[zmberg]

@Forget-C 原地升级的话，因为还有ECI（Virtual kubelet） 的场景，这些是没有Daemon组件的，直接合并不太现实。

你想这样优化，想改进的点是什么？ 单纯的代码合并吗？

[Forget-C]

@zmberg

关于合并。

原地升级的流程，我的第一直觉是监听到变化后， 创建CRR对象ownerReferences到目标资源， 后续由CRR流程接管。 我考虑到的合并的好处是整体流程完整了（阅读源码时两处实现对我的干扰比较大）。 但是考虑到您上述的场景，以目前的CRR没法与原地升级的功能合并。 那是否可以新增一个“原地升级”CRD呢？ 因为不了目前的设计原因， 这个算是一个疑问吧。

优化。

我的想法是在原地升级的基础上， 增加一个镜像预热的功能（nodeimage），并可以控制开关， 减少服务不可用时间。 我能想到的实现方式有三种： 与CRR整合？新增"原地升级"CRD？默认尝试预热后再升级？ 如果增加"原地升级"CRD， 那么也可以对原生workload支持原地升级。（原生workload支持原地升级可能会存在较多的限制，可能需要更多思考）

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.