备忘

一 背景描述

线上最大的集群增长即将达到社区的最大节点数，团队比较关注, 按照当前线上的使用方式单个集群能支撑到多大规模， 因此安排了这次测试。

二 测试版本及配置信息

kubernetes 1.12.4

硬件配置：

集群由294台M10构成, 单位：台

三 模型简述：

1 社区认为每个node上30个pod是正常负载，因此饱和性测试最终生成8k*30=24w 个pod。 记录24w pod生成时间，计算出调度的吞吐量。这个过程主要是用用于模拟集群大面积故障 ，恢复全部服务的时间。 =》 Scheduling throughput

问题描述

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