kuscia部署在k8s上， 节点pod飘逸后如何清理掉无效的instance

[chenweiw09]

Issue Type

Document

Search for existing issues similar to yours

Yes

Kuscia Version

kuscia 0.14.0bo

Link to Relevant Documentation

No response

Question Details

问题：kuscia部署在k8s上，节点重启后pod飘逸，从API接口查询出来有not ready 的实列。
限制：生产环境，无法在k8s上操作命令；
诉求：有什么方式能清理掉无效的instance

[YiAng603]

您好，若可以通过API接口进行查询，是否有权限通过API删除？ 作为生产环境，操作要谨慎，对于not ready node是否可容忍呢？已经not ready的node，对kuscia、dp、sf等暂无影响。

[chenweiw09]

您好，若可以通过API接口进行查询，是否有权限通过API删除？ 作为生产环境，操作要谨慎，对于not ready node是否可容忍呢？已经not ready的node，对kuscia、dp、sf等暂无影响。

kuscia会自动调度到ready的instance上，对于not ready 的实例，仅仅是一个list显示，是吧。

[YiAng603]

是的，这是k8s的机制，对于not ready状态的机器，pod不会调度上去。 对于kuscia内的k8s来说，取的 Kuscia 的 hostname 作为 K3s 的节点名，kuscia重启后，podname发生了变化，所以老的kuscia node就会显示not ready，同时新的dp会调度在新的kuscia node，执行sf、scql等任务时，也会调度在新的kuscia node。