k8s 意外集锦 - oom 的连锁反应
前言
一开始觉得 oom 是一个常见问题,应该没有什么大问题,反正 k8s 集群会调度的,但其实它造成的连锁反应很恐怖。
问题描述
具体简单描述过程:一台机器 OMM, 导致将对应的pod调度到了其他节点上,导致其他节点 OOM 然后开始疯狂输出日志信息,然后导致 master 磁盘不足开始清理并驱逐,然后导致驱逐(Evicted)的应用再次调度到其他节点,然后连锁反应,最终相关大量服务不可用....
pod 出现告警信息 The node had condition: [DiskPressure].
总的来说就是一个 应用的 oom 不停的被调度来调度去,导致日志疯狂的输出,导致磁盘不足了。
问题解决
设置合适的内存请求和限制条件
限制单个应用的使用内存还是非常有必要的,免得出现很多意外的情况
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 200m
memory: 256Mi
应用 bug 修复
代码 bug 肯定要修复的,这个毕竟是导致问题的主要原因
升级 ECS 的内存
确实当前的集群中的内存不够应用使用了(主要是非常容易出现问题)
定时清理 master 和 work 上的系统日志
之前都没有清理过 k8s 的日志文件,运行了很久,一直堆积也没有去管它,从而也是导致这次问题的一个原因之一,所以搞个脚本定时清理还是非常有必要的
添加磁盘监控
因为没有高存储类型的应用,之前完全就没有想到磁盘会出问题,所以添加磁盘的监控
网友评论