之前可使用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

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐