Extreme

If you think this is a bug or feature, please assign it to me

> The killed Pod's name is different, so from the perspective of `chaoskube` I don't think it's a bug. > > The second Pod shouldn't be killed before it's in...

I believe we understand each other. It was my negligence that I didn't notice the "running" status judgment. As you said "it can get killed right after it switches to...

@zmberg ## 关于合并。 原地升级的流程，我的第一直觉是监听到变化后， 创建CRR对象ownerReferences到目标资源， 后续由CRR流程接管。 我考虑到的合并的好处是整体流程完整了（阅读源码时两处实现对我的干扰比较大）。 但是考虑到您上述的场景，以目前的CRR没法与原地升级的功能合并。 那是否可以新增一个“原地升级”CRD呢？ 因为不了目前的设计原因， 这个算是一个疑问吧。 ## 优化。 我的想法是在原地升级的基础上， 增加一个镜像预热的功能（nodeimage），并可以控制开关， 减少服务不可用时间。 我能想到的实现方式有三种： 与CRR整合？新增"原地升级"CRD？默认尝试预热后再升级？ 如果增加"原地升级"CRD， 那么也可以对原生workload支持原地升级。（原生workload支持原地升级可能会存在较多的限制，可能需要更多思考）

and i have a question, why not use `client.ServerPreferredResources()`?