发生了什么？

KCM会逐渐积累内存，如果节点资源更新速度高于processVolumesInUse函数，最终会导致oom。
在我们的案例中，我们有一个超过5000个节点的集群，频繁地创建和删除pod。许多pod携带卷，因此大量的卷信息嵌入在节点状态中。我们还设置了自定义的节点状态更新周期，因此单个节点的更新频率略高于默认值。
所有这些因素共同导致节点更新频率高于processVolumesInUse函数(O(n*m),其中n表示节点卷，m表示所有卷)可以处理的范围。由于处理速度较慢，节点资源在父informer更新事件中累积，导致不可避免的oom。以下是我们在多个oom情况下的kcm资源使用指标。
oom期间kcm的内存使用情况

oom期间kcm的cpu使用情况

你期望发生什么？

更快的processVolumesInUse处理过程，不会出现内存累积

我们如何尽可能最小精确地重现它？

高节点资源更新频率，在我的情况下为每秒500次。

我们需要了解的其他信息吗？

• 无响应*

Kubernetes版本

$ kubectl version
# paste output here

云提供商

OS版本

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

安装工具

容器运行时(CRI)和版本(如适用)

相关插件(CNI,CSI等)和版本(如适用)