这是一个创建于 143 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们是公司的 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 配置等等实在是难以完全掌握，确实没有办法保证不会再出类似的问题。而且，为了控制成本，领导也不打算社招一些丰富经验的老运维去带带我们。
第 1 条附言 · 143 天前
其实我们注意过内核参数里有个threads-max，当时也调了，但是想当然以为这个是限制线程的
22 条回复 • 2024-07-05 11:26:31 +08:00
 |
1
Aliencn 143 天前
团队技术能力不够，又无法扩招团队，那就通过外包形式来解决吧，比如买一些云的 K8S 服务
|
 |
3
qq135449773 143 天前
经典决策层之又不想花钱又想办事儿
|
 |
4
EastLord 143 天前
只能不断学习，比如 k8s/docker 官方文档，尝试问问 chatGPT ，当个参考不能全信，遇到问题来 v 站问问老哥
|
 |
5
zsc8917zsc 143 天前  1
国企的话，资源有限，那就发挥不怕苦不怕累的精神，一个参数一个参数的啃，没日没夜的反复验证，创造一个又一个可歌可泣的故事......
|
 |
6
defunct9 143 天前
你怎么可能提前预知哪些指标会超出阈值呢，只有出了事补足，补足，补足，3 年后，自然没啥大毛病了
|
 |
7
FrankAdler 143 天前 via Android
k8s 能限制 pod 资源除了 cpu 内存也没几项了，全部过一遍，设置下合理的值应该工作量不大，用的应该是 cgroups 能力？
|
|
8
Aliencn 143 天前
|
 |
9
Makabaka01 143 天前
@zhoudaiyu 要么扛住压力，用公司的资源让自己进步，反正自己不是老板出问题亏的也不是自己；要么跑路
|
 |
10
opengps 143 天前
既然是能力之外的，那么这类故障有了这次也会有下次，只能减少不会杜绝。
你有的监控的参数再多，也架不住有你不懂得地方，所以能做的就是多参考市面上的监控指标，有什么抄什么，等自身能力到一定数值之后可能就是你有什么市面上抄你什么。 举个我的例子：当年我人肉运维时候，就怕服务器端 socket 死掉，所以就自己写了个检测端口能否连上的程序，一个放在局域网，一个放在公网，当时真的出现了光纤被挖断的事故，两个报警都有效但内网的显然发不出来，幸好有放在外网的这一份报警程序凌晨 3 点把我吵醒起来运维，一个电话打给联通到凌晨 4 点就反馈说给解决了。然后过了几年，我听到了脉脉故障的故事（只有内网的监控，以至于官方自己没有第一时间发现故障，反倒通过市场客户反馈得知故障） |
 |
11
xueling 143 天前 1
这种容器服务，如果没有太多经验，不踩坑是不可能的。可以用我的开源项目： https://github.com/xl-xueling/xl-lighthouse 。网络上搜集所有可能导致宿主节点宕机/故障的配置参数，然后开发一些数据上报脚本，建立全方位的统计监控体系。我的项目可以任意创建自定义统计监控指标，实现任意维度的数据监控，使用非常灵活，统计监控方面的功能比 Prometheus 那一类工具要强大的多。
|
 |
13
zhoudaiyu OP @qq135449773
@EastLord @zsc8917zsc @defunct9 @FrankAdler @Aliencn @willx12123 @opengps @xueling 我在想要不要鼓弄领导买一套阿里云/腾讯云的服务（纯测试用不跑实际业务），然后把监控告警也买了，然后对着补齐？ |
 |
14
RainCats 143 天前
@zsc8917zsc 是不是还得来点什么重病奋战、什么老婆生孩子仍旧坚守岗位、什么家里人去世强忍悲痛奋战之类的
|
 |
15
isno 143 天前
如果下次是别的内核参数不对出问题怎么办？事实的做法是出了问题就修，没别的办法。
说点我的建议 1. 搞全链路测试、压测，提前找出问题。 2. 让开发也参与报警的设置，这次是线程数故障，下次如果是内存不够、带宽不够、业务接口不通呢？难道全你们设置 3. 买技术支持，参考 B 站大故障。。。 |
|
16
isno 143 天前 1
[如何能解决这种认知范围之外的问题？]
来看看我写这篇文章。 https://www.thebyte.com.cn/Observability/Observability-vs-Monitoring.html |
 |
17
yyttrr 143 天前
这种指标太多了，连接数，rss 内存，wss 内存，cpu throttled 啥的
遇到一次问题下次别再出就行 |
 |
18
Hopetree 143 天前
监控告警搞上去，Prometheus 有没有利用上
|
 |
19
mango88 143 天前
补齐监控指标，调低告警阈值，让业务开发团队配合压测，分配资源的时候多预留一些
|
 |
20
coderzhangsan 143 天前
又想马儿跑，又不想给马儿吃草。
|
|
21
xueling 143 天前 2
@zhoudaiyu 光测试我倒觉得用处不大，很多线上环境中的问题，测试服务暴漏不出来。不要觉得云服务多么完善似的，人家只分配给你固定资源，不要想当然以为出了问题这些云服务厂商会一直给你排查。他们只处理整个集群层面的问题，如果只有你自己的服务出了问题，主要还得自己处理。就像你说的线上故障，本身定位到 pid_max 的故障原因都花了很多时间。线上问题的排查需要逐一排除各种可能的原因，云服务厂商有可能给你提供全方位的服务吗，毕竟对于云服务厂商来说，这里面涉及太多比如用户数据隐私、人力成本等等因素了。你说的监控告警指标，网络搜集就足够了，比如： https://cloud.tencent.com/document/product/457/39820 你自己网上找找，把这些云服务的监控指标汇总一下就 ok 了。
|
 |
22
guanzhangzhang 142 天前
每次发生生产故障，监控也很重要，有没有监控，没有就部署上，有监控没监控到，如何监控上。后续在考虑看看怎么限制
|
Select Language