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

最初认为 oom（内存溢出）只是一个常见的问题，不会造成太大影响，因为 kubernetes（k8s）集群会自动调度。但实际上，它引发的连锁反应是相当可怕的。

问题描述：当一台机器发生 OOM 时，对应的 Pod 会被调度到其他节点上，导致这些节点也出现 OOM。然后，节点开始疯狂输出日志信息，导致 Master 节点的磁盘空间不足，进而开始清理和驱逐 Pod。被驱逐的 Pod 再次被调度到其他节点上，引发连锁反应，最终导致大量服务不可用。

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

总的来说，一个应用的 OOM 导致 Pod 不断被调度，日志信息疯狂输出，最终导致磁盘空间不足。

解决方案：

1. 设置合适的内存请求和限制：限制单个应用的内存使用是非常必要的，避免出现意外情况。

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

2. 修复应用 bug：导致问题的主要原因是代码中的 bug，必须修复。

3. 升级 ECS 的内存：当前集群中的内存不足以满足应用需求，容易引发问题。

4. 定时清理 Master 和 Worker 上的系统日志：之前没有清理过 k8s 的日志文件，长期堆积也是导致此次问题的原因之一。因此，需要编写脚本定时清理日志。

5. 添加磁盘监控：由于没有高存储类型的应用，以前没有考虑到磁盘问题，因此需要添加磁盘监控。