一次生产故障引发的一些思考与问题,请大大们帮忙分析

5次阅读

共计 619 个字符,预计需要花费 2 分钟才能阅读完成。

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