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