最初认为 %ignore_a_1%om（内存溢出）只是一个常见的问题，不会造成太大影响，因为 kubernetes（k8s）集群会自动调度。但实际上，它引发的连锁反应是相当可怕的。
问题描述：当一台机器发生 OOM 时，对应的 Pod 会被调度到其他节点上，导致这些节点也出现 OOM。然后，节点开始疯狂输出日志信息，导致 Master 节点的磁盘空间不足，进而开始清理和驱逐 Pod。被驱逐的 Pod 再次被调度到其他节点上，引发连锁反应，最终导致大量服务不可用。
Pod 出现告警信息 The node had condition: [DiskPressure].
总的来说，一个应用的 OOM 导致 Pod 不断被调度，日志信息疯狂输出，最终导致磁盘空间不足。
解决方案：
设置合适的内存请求和限制：限制单个应用的内存使用是非常必要的，避免出现意外情况。
resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi
修复应用 bug：导致问题的主要原因是代码中的 bug，必须修复。
升级 ECS 的内存：当前集群中的内存不足以满足应用需求，容易引发问题。
定时清理 Master 和 Worker 上的系统日志：之前没有清理过 k8s 的日志文件，长期堆积也是导致此次问题的原因之一。因此，需要编写脚本定时清理日志。
添加磁盘监控：由于没有高存储类型的应用，以前没有考虑到磁盘问题，因此需要添加磁盘监控。
以上就是k8s 意外集锦 – oom 的连锁反应的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/32217.html
微信扫一扫 
支付宝扫一扫 
