k8s 意外集锦 - oom 的连锁反应

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

问题描述

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

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

oom-master-df-lh

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

问题解决

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

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

resources:
   requests:
     cpu: 100m
     memory: 128Mi
   limits:
     cpu: 200m
     memory: 256Mi

应用 bug 修复

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

升级 ECS 的内存

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

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

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

添加磁盘监控

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