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

相关推荐
isNotNullX32 分钟前
什么是数据分析?常见方法全解析
大数据·数据库·数据仓库·人工智能·数据分析
小袁拒绝摆烂43 分钟前
ElasticSearch快速入门-1
大数据·elasticsearch·搜索引擎
weixin_399380691 小时前
k8s一键部署tongweb企业版7049m6(by why+lqw)
java·linux·运维·服务器·云原生·容器·kubernetes
IT成长日记2 小时前
【Docker基础】Docker数据卷管理:docker volume ls及其参数详解
运维·docker·容器·volume ls
偷萧逸苦茶2 小时前
docker常见命令
docker·容器·eureka
点控云2 小时前
智能私域运营中枢:从客户视角看 SCRM 的体验革新与价值重构
大数据·人工智能·科技·重构·外呼系统·呼叫中心
zkmall3 小时前
企业电商解决方案哪家好?ZKmall模块商城全渠道支持 + 定制化服务更省心
大数据·运维·重构·架构·开源
随缘而动,随遇而安7 小时前
第八十八篇 大数据中的递归算法:从俄罗斯套娃到分布式计算的奇妙之旅
大数据·数据结构·算法
GISer_Jing8 小时前
Git协作开发:feature分支、拉取最新并合并
大数据·git·elasticsearch
IT_10249 小时前
Spring Boot项目开发实战销售管理系统——系统设计!
大数据·spring boot·后端