问题描述
值班同学反馈线上一台centos7的物理机container层kmem打开了 kubepods层kmem是关闭的。
问题排查
kubelet如果是打开了kmem,从kubepods层就能看到slabinfo的内容,因此排除是kubelet版本低的问题。继续排查18版本的docker-runc代码部分,发现runc中默认是打开kmem的。
13和18版本runc关于kmem部分的代码对比
docker13 runc | docker18 runc |
值班同学反馈线上一台centos7的物理机container层kmem打开了 kubepods层kmem是关闭的。
kubelet如果是打开了kmem,从kubepods层就能看到slabinfo的内容,因此排除是kubelet版本低的问题。继续排查18版本的docker-runc代码部分,发现runc中默认是打开kmem的。
13和18版本runc关于kmem部分的代码对比
docker13 runc | docker18 runc |
物理机时代,业务根据/proc/sys/kernel/threads-max
设置线程池大小。容器(特指docker)该值仍然获取的是物理机上的信息,而容器规格一般比物理机小,再根据这个值获取信息设置容器内线程数就不准确了。物理机上这个值受哪些资源影响,因此有了这篇文章。
内核版本4.18 线程数限制为[20,0x3fffffff]
线上A模块访问B模块,A模块部署在物理机,B模块部署在容器上。早晚高峰A访问B会出现超时报警。
业务方找到我们排查,我首先申请了监控中提示超时的两台机器权限,看一下超时规律 登录10.167.8.25容器所在的宿主机常规排查
dmesg显示如下,联系值班同学和系统部同学硬件报修。
EDAC sbridge MC1: HANDLING MCE MEMORY ERROR
漂移容器10.167.8.252后,10.167.41.18 在两台物理机上小时级别日志中会出现近10次