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 重新启动它。

相关推荐
请提交用户昵称22 分钟前
大数据各组件flume,datax,presto,DolphinScheduler,findBI在大数据数仓架构中的作用和功能。
大数据·flume·datax·dolphin·presto·findbi·大数据组件
IT果果日记29 分钟前
详解DataX开发达梦数据库插件
大数据·数据库·后端
用户Taobaoapi20141 小时前
微店API秘籍!轻松获取商品详情数据
大数据·数据挖掘·数据分析
chimchim662 小时前
StarRocks导入数据-使用 Broker Load 进行异步导入
大数据·sql
iGarment3 小时前
服装采购跟单系统的高效管理实践
大数据·经验分享·云计算
闯闯桑3 小时前
Spark 中spark.implicits._ 中的 toDF和DataFrame 类本身的 toDF 方法
大数据·ajax·spark·scala
阿里云大数据AI技术4 小时前
【跨国数仓迁移实践9】dbt‑maxcompute 在 GoTerra 迁移过程中的落地与技术贡献
大数据
的小姐姐4 小时前
RMS设备检修管理系统_HawkEye智能运维平台_璞华大数据
大数据·运维
时空自由民.4 小时前
repo 学习教程
大数据·学习·elasticsearch
刘一说4 小时前
Elasticsearch HTTPS访问错误解决指南
大数据·elasticsearch·https