[feature request] 在virtual-kubelet节点中，优化原地升级支持

[ftpilot]

在InPlaceUpdateEnvFromMetadata特性打开的情况下，由于virtual-kubelet节点不支持安装kruise daemon，会导致原地更新卡住，希望可以优化该场景:
场景：在virtual-kubelet节点上打开InPlaceUpdateEnvFromMetadata特性，修改镜像版本，pod会进入原地升级，InPlaceUpdateReady condition会从true变为false，但在Container重启Ready后，InPlaceUpdateReady condition不会恢复成true。
原因分析：通过追踪源码和数据，发现是进了下图中的代码分支：

pod上的annotation如下：

这里因为将InPlaceUpdateEnvFromMetadata打开，所以updateEnvFromMetadata为true，但又没有kruise daemon来通过annotation来上报状态，所以这里的runtimeContainerMetaSet 为空，导致原地升级流程卡住。

[zmberg]

@ftpilot 是的，如果Pod是在VK节点 确实没有必要 执行这个逻辑。你这边 方便修复这个问题吗？

[ftpilot]

可以 可能需要提供一些帮助

[zmberg]

@ftpilot 前段时间一直没太关注，如果你还在关注这个 issue ，可以回复一下，一起看看如何修复？

[chengjoey]

vk节点通常有这些特征，是否可以通过这些来判断pod运行的几点是否为vk节点

[zmberg]

这个地方可能没有这么简单，情况复杂一些。其实只有 InPlaceUpdateEnvFromMetadata 特性打开，并且只利用这种特性的方式，才不能原地升级成功。其它的情况，还是可以原地升级成功的。

[a932846905]

那我理解 vk节点上pod的原地升级，要等同于InPlaceUpdateEnvFromMetadata=false，也就只能是修改image通过kubelet来原地升级，所以是不是可以在判断条件上 && isVkNode 这样

[a932846905]

@ftpilot 前段时间一直没太关注，如果你还在关注这个 issue ，可以回复一下，一起看看如何修复？

提issue的账号ftpilot是公司账号，我用个人账号来沟通吧 这里现在有进度了吗