一开始觉得 oom 是一个常见问题,应该没有什么大问题,反正 k8s 集群会调度的,但其实它造成的连锁反应很恐怖。

问题描述

具体简单描述过程:一台机器 OMM, 导致将对应的pod调度到了其他节点上,导致其他节点 OOM 然后开始疯狂输出日志信息,然后导致 master 磁盘不足开始清理并驱逐,然后导致驱逐(Evicted)的应用再次调度到其他节点,然后连锁反应,最终相关大量服务不可用….

pod 出现告警信息 The node had condition: [DiskPressure].

oom-master-df-lh

总的来说就是一个 应用的 oom 不停的被调度来调度去,导致日志疯狂的输出,导致磁盘不足了。

问题解决

设置合适的内存请求和限制条件

限制单个应用的使用内存还是非常有必要的,免得出现很多意外的情况

1
2
3
4
5
6
7
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 200m
memory: 256Mi

应用 bug 修复

代码 bug 肯定要修复的,这个毕竟是导致问题的主要原因

升级 ECS 的内存

确实当前的集群中的内存不够应用使用了(主要是非常容易出现问题)

定时清理 master 和 work 上的系统日志

之前都没有清理过 k8s 的日志文件,运行了很久,一直堆积也没有去管它,从而也是导致这次问题的一个原因之一,所以搞个脚本定时清理还是非常有必要的

添加磁盘监控

因为没有高存储类型的应用,之前完全就没有想到磁盘会出问题,所以添加磁盘的监控