记录一次k8s的oom问题定位

最新推荐文章于 2023-08-30 09:20:09 发布
最新推荐文章于 2023-08-30 09:20:09 发布
阅读量1.7k 收藏 3
点赞数
文章标签： kubernetes devops docker
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_41685990/article/details/127790375
版权
博客讲述了在项目上线后遇到的服务偶现调用接口报错问题，通过查看Kubernetes pod日志和node节点日志，发现是由于程序占用内存超出限制导致OOM，从而触发了pod的重启。解决方案是调整limit.memory值或减小项目的XMX设置。
摘要由CSDN通过智能技术生成
背景介绍

在一次项目上线之后，发现环境偶现调用接口报错的情况，排查发现是k8s服务偶尔重启导致过程中服务不可用，这样开始了本次问题的定位

步骤一

查看pod的日志信息

# -n 命名空间
# po -l 根据label参数过滤
kubectl describe -n cdp po -l app=cdp-version

pod日志信息如下：
在这里插入图片描述

第二个框是重启的原因，oom导致被kill掉

第三个框是参数的设置，先记录一下

步骤二

去对应的node节点查看日志信息，从上图中可以看到oom的时间点，大概是在11月10号的9:28:04之前，并且可以看到对应的node名称是devops-2节点

切换节点

kubectl describe nodes devops-2

查看devops-2节点的日志信息

那么我们就去查看devops-2节点在11月10号的9:27:30之后的日志

journalctl --since="2022-11-10 09:27:30"

日志信息如下，可以看到是程序占用完了所有可用的内存信息，还记得上个图片展示的内存限制吗（limit-memory-2g），去搜索了一下containers.spec的这个参数的意义，解释如下：如果程序内存超过pod的设置阈值，会触发oom去kill pod里面的容器

在这里插入图片描述

这就是服务重启的原因，那么到这原因就基本找到了，调大limit,memory值或者调小项目的xmx，查看了一下xmx的设置是2048m，果然超过了,把值调小解决了这个问题

vincentwc
关注
k8s报错整理集合---持续更新
weixin_43273856的博客
03-14 1058
个人整理kubernetes各种常见问题，该文章持续更新...
零信任策略下K8s安全监控最佳实践（K+）
阿里云技术
09-19 585
本文重点将围绕监控防护展开，逐层递进地介绍如何在复杂的分布式容器化环境中借助可观测性平台，持续监控K8s集群，及时发现异常的 API 访问事件、异常流量、异常配置、异常日志等行为，并且结合合理的告警策略建立更主动的安全防御体系。
一次OOM问题排查过程实战记录
08-26
主要给大家介绍了一次OOM问题排查过程，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面来一起学习学习吧
kmem问题造成K8S中pod内存溢出
01-20
问题排查 可以通过 $ cat /sys/fs/cgroup/memory/kubepods/burstable/pod//memory.kmem.slabinfo 来查看是否存在bug,如果返回 cat: memory.kmem.slabinfo: Input/output error 则不存在bug 问题解决 需要在 kubelet 和 docker 上都将 kmem account 功能关闭。kubelet 需要重新编译。 kubelet 版本是 v1.14 及以上，则可以通过在编译 kubelet 的时候加上 Build Tags 来关闭 $ git clone --branch
k8s oom
wasd12121212的博客
12-19 1093
这段代码就是讲的如何计算每个容器的oom score的。 首先看这个容器所属的Pod是属于什么级别的，如果是Guaranteed级别的直接返回-998也是最高级最后被Kill掉的，如果是BestEffort级别则直接返回1000是最低级别的，最有可能被杀掉。如果是Burstable则是中间级别需要按照资源的申请量来计算oom score。 oomScoreAdjust := 1000 - (1...
怎么定位K8s容器中运行的JAVA程序OOM异常（一）
计算科学
06-26 2594
一.前置环境 1. 运行在k8s集群上的Pod服务（Java程序） 2. MAT分析工具 二.利用Jmap工具导出Heap Dump 1.执行命令进入pod容器 kubectl exec -itn {namespace} {pod}} sh 2.利用jmap生成java程序的Dump文件 jps | grep {jar} ./jmap -dump:live,format=b,file=haep.hprof 8 3.利用k8s命令导出Dump文件到本地 kubectl cp -n
解决 k8s 限制内存后 还出现 OOM 错误的问题：资源整合
浅抒流年的博客
05-28 1294
解决 k8s 限制内存后 还出现 OOM 错误的问题：资源整合
一文理清 K8S OOM 和 CPU 节流机制
力哥讲技术
05-04 1100
使用 Kubernetes 时，内存不足 (OOM) 错误和 CPU 节流是云应用程序中资源处理的主要难题。这是为什么？云应用程序中的 CPU 和内存要求变得越来越重要，因为它们与您的云成本直接相关。通过 limits 和 requests ，您可以配置 pod 应如何分配内存和 CPU 资源，以防止资源匮乏并调整云成本。如果节点没有足够的资源， Pod 可能会通过抢占或节点压力被驱逐。当一个进程运行内存不足 (OOM) 时，它会被终止，因为它没有所需的资源。
一次线上OOM问题的个人复盘
fm18771120556的博客
04-01 365
java服务上线后，偶尔会发生内存OOM问题，但由于OOM导致服务不响应请求，健康检查多次不通过，最后部署平台kill了java进程，这导致定位这次OOM问题也变得困难起来。
记录xx项目生产oom导致dump，通过jvisualvm排查.hprof文件找出问题根源
andQ的博客
03-29 1515
记录xx项目生产dump排查 1.描述 20200229 6点生产某台机器宕机重启，通过运维拿出dump文件(:java_pid1（2020-02-29）.hprof)，如图 刚开始接收dump文件不知道如何排查，公司同事用jprofile9，用这个看不出什么。故保存dump后续研究 ==================================================================================== 20210329 学习jvm后通过visu
面经 - OpenStack（Docker、Django、K8S、SDN）知识点
RBK的博客
02-24 4272
概述 云计算是一种采用按量付费的模式，基于虚拟化技术，将相应计算资源（如网络、存储等）池化后，提供便捷的、高可用的、高扩展性的、按需的服务（如计算、存储、应用程序和其他 IT 资源）。 云计算基本特征： 自主服务：可按需的获取云端的相应资源（主要指公有云）； 网路访问：可随时随地使用任何联网终端设备接入云端从而使用相应资源。 资源池化： 快速弹性：可方便、快捷地按需获取和释放计算资源。 按量计费： 常见的部署模式 公有云 私有云 社区云 混合云 三种服务模式 IaaS：云服务商将IT系统的基础设施
图解 K8S OOM 和 CPU 节流
LinkSLA的博客
02-17 813
使用 Kubernetes 时，内存不足 (OOM) 错误和 CPU 节流是云应用程序中资源处理的主要难题。这是为什么？云应用程序中的 CPU 和内存要求变得越来越重要，因为它们与您的云成本直接相关。通过 limits 和 requests ，您可以配置 pod 应如何分配内存和 CPU 资源，以防止资源匮乏并调整云成本。如果节点没有足够的资源， Pod 可能会通过抢占或节点压力被驱当一个进程运行内存不足 (OOM) 时，它会被终止，因为它没有所需的资源。
K8S容器OOM killed排查
bruce128的专栏
08-30 2158
docker耗用完内存前，堆内存并没有达到上限，于是没有触发老年代GC，内存没有降下去。如果容器OOM killed，容器里的jvm进程没有Full GC，那么肯定是MaxRAMPercentage参数太高，导致堆内存没有用到上限，无法触发堆内存（老年代）GC。当实例内存超过95%时，对比top显示的的jvm进程内存和ps stats输出的docker实例内存信息，其余进程耗用的内存忽略不计。遂将内存增加到4GB。4 由于堆内存没有的到达上限，但是整个jvm进程内存超出了容器的内存限制。
在k8s下坑人的OOM问题
a807719447的专栏
03-11 3166
最近测试提了个bug，说批量图片上传会返回500错误。然后我弄了两个zip压缩包一个3MB，一个120MB，发现3MB的压缩包每次上传都没问题，而120MB的每次上传都会报500，于是上spring cloud gateway网关查看了下日志，发现网关报了一个莫名奇妙的错误 Connection prematurely closed BEFORE response 意思为连接在响应前过早关闭了。显得莫名奇妙，然后拿着这个报错百度google了一番，没找到答案，于是换个方向。小文件没有问题，而大文件出问题，
k8s-kublulet-OOM-kill ，容器 OOM ， jvm oom故障分析
yuezhilangniao的博客
04-21 4951
# 排查参考文章： https://blog.csdn.net/fly910905/article/details/90179225 # 理解Linux oom https://blog.csdn.net/run_for_belief/article/details/83446344 # 理解 java oom https://www.cnblogs.com/bhlsheji/p/5330045.html 省略比較小的区域，能够总结JVM占用的内存： JVM内存 ≈ Java永久代 ＋...
2023更新，K8S中java程序OOM
hiphop321的博客
11-18 996
记一次oom故障
总结：记一次K8S容器OOM案例
w2009211777的专栏
07-15 4510
JVM OOM -XX:MaxRAMPercentage
K8s node flannel systemoom如何解决
weixin_42601134的博客
01-09 284
好的。在 Kubernetes 中，flannel 是一种用于网络覆盖的工具，可以在集群中的所有节点之间建立一个虚拟网络。systemd 是一种用于管理系统和服务的系统和服务管理器。 如果你遇到了 K8s node 中的 flannel 和 systemoom 问题，那么可以尝试以下解决方案： 检查日志以了解问题的具体原因。使用 journalctl -u flanneld 命令查看 flann...
kafka OOM问题定位
最新发布
09-26
Kafka OOM问题的定位可以通过以下步骤进行： 1. 首先，检查Kafka的内存使用情况。可以通过监控工具（如JMX）或命令行工具（如jstat）来查看Kafka进程的内存使用情况。如果内存使用量接近或超过了可用内存，则可能...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值