之前可使用kubectl top nodes观察发布时的cpu使用情况

可以登陆node节点主机使用 top H -n 1 查看线程情况

同时并发发布多个项目，导致cpu满了之后，挂掉

导致该node节点的pod全部迁移至其他node节点，而其他node节点的cpu及线程最大限制都无法负载pod，导致node一个个宕机，最终整个集群宕机。

 

经过查看发现是由于pid耗尽，致使docker崩溃，无法驱逐pod，最终触发系统OOM。

 

触发原因: 集群初始node节点较少，启动pod过多，pod request设置的较小，导致大量pod调度到节点上，打满了节点pid，docker崩溃，kubelet无法工作，节点也无法登陆，触发系统OOM后，有多余的pid被释放，此时节点可以登陆，但是docker已经挂掉，问题节点无法恢复正常工作，此时新加节点，会导致原节点上的pod集体迁移到新节点，导致新节点也因同样原因挂掉，造成集群雪崩效应，需要手动重启组件或节点才可恢复。

 

原因1：节点pid限制为32768

原因2：用户container启动了过多的线程

原因3：kubelet未做pid资源限制

 

临时解决方案：

1. 调大pod requests，限制每个节点上的pod总量

2. 减少容器的线程启动量，设置一个最大值

3. 部署服务时尽量提前准备好足够的节点，以使pod能平均调度，减轻各node的pid压力

 

短期解决方案：

1. k8s调大pid限制至65535

2. 改善其他内核限制

3. 去除历史遗留日志

 

长远解决方案：

1. 提供K8S 1.14版本后彻底解决

K8S 1.13版本kubelet有--pod-max-pids feature，是alpha参数，不准备使用

K8S 1.14版本--pod-max-pids是beta参数，将启用限制pod可启的线程数，system-reserved 和kube-reserved 这2个参数也将支持节点pid资源预留，也将启用

https://github.com/kubernetes/kubernetes/pull/73651/commits/2597a1d97ef4d8f54b1ca661453e32794b756909