K8s Pod OOMKilled,监控却显示内存资源并未打满

1. 问题现象

pod一直重启,通过grafana查看,发现内存使用率并没有100%。

2. 排查过程

2.1 describe查看pod最新一次的状态

可以明显看到,最近一次的重启就是因为内存不足导致的。

2.2 describe 查看node节点状态

找到原因了,原来是触发了节点压力驱逐。

这就是为啥pod是因为oom被杀死的,而监控上却显示内存并没有达到上限。

3. 原因分析

3.1 kubelet工作原理回顾

3.1.1 面向容器

官方文档:kubelet | Kubernetes

kubelet 是基于 PodSpec 来工作的。每个 PodSpec 是一个描述 Pod 的 YAML 或 JSON 对象。 kubelet 接受通过各种机制(主要是通过 apiserver)提供的一组 PodSpec,并确保这些 PodSpec 中描述的容器处于运行状态且运行状况良好。

简单点说:你给我yaml,我按照你的要求创建pod并监测它们是running的。

3.1.2 面向node节点

官方文档:节点压力驱逐 | Kubernetes

kubelet 监控集群节点的内存、磁盘空间和文件系统的 inode 等资源。 当这些资源中的一个或者多个达到特定的消耗水平, kubelet 可以主动地使节点上一个或者多个 Pod 失效,以回收资源防止饥饿。

这个过程,被称为"节点压力驱逐",在节点压力驱逐期间,kubelet 将所选 Pod 的阶段 设置为 Failed 并终止 Pod。

但我们常见的驱逐状态不是"Eviction"吗,为什么我次的场景中并没有看到该状态呢?继续往下看。

3.2 驱逐

首先系统学习过k8s的铁子们肯定都知道,kubelet启动时,是可以配置系统资源预留的,通过--eviction相关的参数,可以配置给系统预留多少资源。如下:

imagefs.available<15%,memory.available<100Mi,nodefs.available<10%

一旦达到预留的阈值,就会触发"驱逐"。pod状态如下图:

但还是有一种情况,pod不会出现这个驱逐状态,而是反复的被kubelet 直接杀死对应的进程,那就是"节点内存不足行为"。

3.3 节点内存不足行为

如果 kubelet 在节点遇到 OOM 之前无法回收内存, 则 oom_killer 根据它在节点上使用的内存百分比计算 oom_score, 然后加上 oom_score_adj 得到每个容器有效的 oom_score。 然后它会杀死得分最高的容器。

这意味着低 QoS Pod 中相对于其调度请求消耗内存较多的容器,将首先被杀死。

与 Pod 驱逐不同,如果容器被 OOM 杀死, kubelet 可以根据其 restartPolicy 重新启动它。

相关推荐
武子康10 小时前
大数据-98 Spark 从 DStream 到 Structured Streaming:Spark 实时计算的演进
大数据·后端·spark
阿里云大数据AI技术10 小时前
2025云栖大会·大数据AI参会攻略请查收!
大数据·人工智能
代码匠心13 小时前
从零开始学Flink:数据源
java·大数据·后端·flink
Lx35215 小时前
复杂MapReduce作业设计:多阶段处理的最佳实践
大数据·hadoop
武子康18 小时前
大数据-100 Spark DStream 转换操作全面总结:map、reduceByKey 到 transform 的实战案例
大数据·后端·spark
expect7g19 小时前
Flink KeySelector
大数据·后端·flink
阿里云大数据AI技术1 天前
StarRocks 助力数禾科技构建实时数仓:从数据孤岛到智能决策
大数据
Lx3522 天前
Hadoop数据处理优化:减少Shuffle阶段的性能损耗
大数据·hadoop
武子康2 天前
大数据-99 Spark Streaming 数据源全面总结:原理、应用 文件流、Socket、RDD队列流
大数据·后端·spark
阿里云大数据AI技术2 天前
大数据公有云市场第一,阿里云占比47%!
大数据