k8s下docker容器获取cpu核心数不准确导致高负载引发的宕机问题

看了很多书都说docker来部署应用可以隔离系统资源互不影响，直到这段时间出现的一系列问题又颠覆了我的认知。
发现docker并不能隔离真正隔离系统资源。最近k8s中的某一个应用总是被强制重启，由于监控体系没有完善，找了好久都没有找到原因，之前也有其它应用类似的问题是应为metaspace溢出导致的，但是此次事务毫无报错，严重时一天重启三次。有时候又一连好几天个把月没有问题。为了不让五一小长假的美好心情被破坏，觉定把这个问题彻底解决掉，好吧其实放假的第一天就被破坏了，当天重启了3次，为了后续的美好日子，决定把它根因找出来。看k8s日志发现每次重启都是健康检查失败导致重启，于是推断以下几种可能：

• jvm 频繁GC导致进程stw挂起liveless prob探针超时
• 系统cpu负载过高导致处理超时

正对两种情况进行对应排查，有时候排查问题也是有点小麻烦，只能绕着想点其它办法，比如skywalking和arthas的冲突问题，比如docker包只打了jre，好吧就只能打印GC日志来观察情况了，排查过程就不讲了，反正排查半天最后发现内存方面没有问题。

所以就考虑第二种情况，cpu负载问题导致超时，于是先用top观察负载。发现load average值大概在8左右，但是发现这个负载值时机器的总平均负载，没办法查看当前docker容器的情况，但是这也不影响我做出正确的推断，配置的cpu核心数为0.5-1，宿主机和cpu核心数为16，相对16核心数8的负载算正常范围，忽然间又想到这个负载时基于进程级别的，要是我应用的线程数过多，而docker限制了cpu核心数，那么这里会不会出现问题呢？也就是当我进程中的一个线程在使用cpu时其它线程用不了，尽管cpu还有空闲，但是进程内的线程就不断产生上下文切换，导致探针超时，这个也完全有可能，于是按用top -H -p pid 查看线程情况，发现好家伙开了300多个线程，才配置0.5到1核的cpu 这个确实有点过分了。在观察的过程中发现间隔一分钟cpu使用率还会暴涨一次，好吧这个应用是个定时任务，每隔1分钟就会有10几个定时任务同时进来然后开3个线程处理这个10几个定时任务，每个线程进来又开了cpu核心x10个线程去处理子任务，那么如果此时有大量业务数据需要处理就会产生大量的上下文切换，就非常有可能导致探针请求超时。但是按道理说探针超时10秒这个也不太可能吧？
于是接着想到假如cpu又被其它docker容器的进程占用了呢？也就是说当前应用除了跟自己抢占资源外还需要跟其它的进程抢占资源，所以有可能等待更久。也就是这个应用本身是个cpu密集型的应用，给的cpu过少了。看代码的过程中又发现一个坑爹的地方，应用配置的默认线程数是cpu核心数*10，由于docker容器中获取cpu核心数不准确的问题，导致cpu核心数获取到的是宿主机真正核心数16 也就是说实际上是3个线程各自开了160个线程在处理业务，意味着高峰期线程数可能达到480+其它线程的数量，这才导致了探针超时,因为轮半天可能每轮到它执行。
给线程池设置个参数，别开160个线程，外加增加cpu核心数重启完美解决此问题。