kubekey v2.x 安装的 kubesphere 集群启动带有多线程的 java docker应用 OOM 的问题反馈（ kubekey1.x 安装的不会）

[MrYang-Jia]

What is version of KubeKey has the issue?

v2.1.0 & 2.0.0

What is your os environment?

centos6 | centos7 | centos8 | alinyunLinux3 | alinyunLinux2

ks 1.19.x ~ 1.21.4 docker 1.20.8 springboot2.5.3 dockerImages java:openJdk8

KubeKey config file

config配置文件，都是通过 kubekey confgi 创建出来重新制定，都能完美安装好集群环境,所以就不提供了

A clear and concise description of what happend.

使用 kubekey 2.x 版本（2.1.1 的版本还没有测试过），安装完 kubesphere 2.3.1 的集群时，发现原来可以正常运行在 kubesphere 2.1.1 上的java 运用(springboot服务)不能正常访问了，然后我看了下pod的健康状态是 正常 ，然而却不能访问任何http请求服务，登录容器的内部控制台时，提示docker容器拒绝访问的信息

OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: read init-p: connection reset by peer: unknown

然后查看日志，发现报了 oom 错误信息提示

java.lang.OutOfMemoryError: unable to create new native thread

我以为就是一次普通的事件，偶然性的，所以多次重启后，发现确实是该服务会不断创建和销毁线程，健康检查变成健康的小段时间内都是可以正常访问，然后web容器里有一些线程会不断检查自身健康，不断创建线程和销毁线程，然后发现报oom了，此时pod的允许最大内存是8G，才用了1.5G，就直接报 oom 内存溢出不足于构建线程 ？？？

然后我不信邪的用 kubekey 2.0.0 或 2.1.0 重新安装集群还原到 3.1.1 版本，结果发现原来可以在 3.1.1 正常运行的pod也是一样不行了，瞬间一脸懵逼，然后我使用 kubekey 1.1.1 重新安装了下，发现这回重新部署 java 应用，这回等了好几个小时，应用都是正常的，我接着用 kubekey 1.2.1 安装最新版本的 kusphere 3.2.1 发现还是没有问题，java 应用部署后结果一切正常!!!

所以如果是 kubekey 2.x 版本的bug的话，请务必修复，调整发布时docker run 的参数，如果不是，请告知下怎么配置这些参数，以便跟 kubekey 1.x 版本的一样，这个是我的知识盲区，我因此测试不足，导致升级完成后生产停机了整整6个小时，虽然现在用 kubekey 1.2.1 恢复了集群，但还是想反馈下，看看该现象是不是不正常

Relevant log output

docker exec -it 

OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: read init-p: connection reset by peer: unknown

pod/docker log

...
java.lang.OutOfMemoryError: unable to create new native thread
...

### Additional information

_No response_

[24sama]

Hi @MrYang-Jia , thanks for your feedback! I guess it might be caused by: https://github.com/kubesphere/kubekey/blob/b19724c728154af81d5e2daa5e28808e07b877c1/pkg/kubernetes/templates/v1beta2/kubeadm_config.go#L218

It was a kubelet config and will limit the number of pod pid.

You can modify this value and use the makefile to build the kk, then deploy your java app to verify.

Ref: https://github.com/SonarSource/docker-sonarqube/issues/265 https://kubernetes.io/docs/concepts/policy/pid-limiting/

[MrYang-Jia]

@24sama 谢谢你的回复，我会尝试去修改并尝试看看，虽然现在已经恢复了正常，但是还是希望能正常执行在每个大版本里,谢谢

[24sama]

Hi @MrYang-Jia I think this configuration is not necessary and can lead to problems that cannot be easily found out by users. If you're interested in fixing it, you can submit a PR to remove the podPidsLimit and pid.available.

[MrYang-Jia]

Hi @24sama ， thanks for your answer ,this is right

[tanmx]

同样的问题 排查了半天 结果是kubelet限制了

[24sama]

同样的问题 排查了半天 结果是kubelet限制了

Hi @tanmx This PR has been fixed this issue and we will release a new version soon.

[MrYang-Jia]

同样的问题 排查了半天 结果是kubelet限制了

有帮到你就好，我当时为了研究这个问题，我3天没合过眼。 因为测试的时候，没有压测下量，就过了，真是万万没想到.... 但是有时候要做升级的时候，资源很难申请到足够全方位测试的情况，就比较尴尬了，升级还是要有所谨慎，做了第一个吃螃蟹的人了 ~~~