我们是公司的 K8s SRE 运维团队,近期发生了一次生产故障,一台机器上某 2 个 Pod 里面创建了很多线程,达到了宿主机的 pid_max 的阈值,机器上所有进程在某些达到阈值的时刻都无法创建新线程( Pod 正常),导致了故障。
我们领导的想法是,他们线程创建过多了,并且是不应该创建这么多的(也得到了对方的认可),这是直接原因,我们设置 pid_max 较低(约 10 万),是间接原因。开会讨论我们要补齐相关告警,优化 pid_max 的配置,并从 kubelet 维度限制 Pod 的线程数。但是开发的领导说,这次是 pid_max 导致的,如果下次是别的内核参数不对出问题怎么办?我的领导说让我参考一下其他集群的相似的机器的内核参数(有多个生产集群,但是硬件配置,操作系统,内核,k8s 版本都不完全相同),修改出问题的机器的配置。
我部分赞同领导的想法,但是我也不能确保没出过问题的机器的内核参数配置就一定对,而且同步过来参数是不是一定适合这台机器,这也不好说。
我现在有疑虑的点就是,在我们的技术有限(运维经验都在 3 年以内),人力有限( 3 个人运维 300 开发团队的应用)的条件下,如何能解决这种认知范围之外的问题(之前没有线程数监控,甚至排查的时候也花了较多时间才看到),因为操作系统实在是比较复杂,各类的内核参数、system service 配置等等实在是难以完全掌握,确实没有办法保证不会再出类似的问题。而且,为了控制成本,领导也不打算社招一些丰富经验的老运维去带带我们。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
https://www.v2ex.com/t/1054840
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.