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