我们领导的想法是，他们线程创建过多了，并且是不应该创建这么多的（也得到了对方的认可），这是直接原因，我们设置 pid_max 较低（约 10 万），是间接原因。开会讨论我们要补齐相关告警，优化 pid_max 的配置，并从 kubelet 维度限制 Pod 的线程数。但是开发的领导说，这次是 pid_max 导致的，如果下次是别的内核参数不对出问题怎么办？我的领导说让我参考一下其他集群的相似的机器的内核参数（有多个生产集群，但是硬件配置，操作系统，内核，k8s 版本都不完全相同），修改出问题的机器的配置。
我部分赞同领导的想法，但是我也不能确保没出过问题的机器的内核参数配置就一定对，而且同步过来参数是不是一定适合这台机器，这也不好说。
我现在有疑虑的点就是，在我们的技术有限（运维经验都在 3 年以内），人力有限（ 3 个人运维 300 开发团队的应用）的条件下，如何能解决这种认知范围之外的问题（之前没有线程数监控，甚至排查的时候也花了较多时间才看到），因为操作系统实在是比较复杂，各类的内核参数、system service 配置等等实在是难以完全掌握，确实没有办法保证不会再出类似的问题。而且，为了控制成本，领导也不打算社招一些丰富经验的老运维去带带我们。
