备忘

问题描述

值班同学反馈线上一台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次