k8s pod OOMKilled 错误原因

最新推荐文章于 2024-06-11 00:14:18 发布
最新推荐文章于 2024-06-11 00:14:18 发布
阅读量1.5w 收藏 9
点赞数 4
分类专栏： docker&k8s学习之旅 文章标签： docker k8s
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_44843859/article/details/115163996
版权

k8s oomkilled 错误原因：容器使用的内存资源超过了限制。只要节点有足够的内存资源，那容器就可以使用超过其申请的内存，但是不允许容器使用超过其限制的资源。

在yaml文件的resources.limits.memory 下定义了容器使用的内存限制，如果容器中的进程使用内存超过这个限制，就会出现oomkilled错误，容器被终止。

resources:
  limits:
    cpu: '8'
    memory: 32Gi

解决办法：1.优化程序，使之使用内存大小在范围内  2.修改yaml，增大内存的限制大小

小罗tongxue
关注
  • 4
    点赞
  • 踩
  • 9
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
Kubernetes 触发 OOMKilled(内存杀手)如何排除故障
山河已无恙
07-19 1135
简单整一下 k8s 中 Pod 故障OOMKilled的原因以及诊断博文内容涉及:k8sOOMKilled分类: 宿主节点行为 / K8s Cgroups 行为什么是OOMKilledK8s 错误,OOMKiller 机制如何工作？OOMKilledK8s 错误和解决的常见原因理解不足小伙伴帮忙指正对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。
K8s: Java应用OOMKilled的原因与分析
DevOps持续集成的博客
12-12 600
本篇文章是「DevOps云学堂」与你共同进步的第65篇管理 Kubernetes Pod 中运行的 Java 进程的内存使用情况比人们想象的更具挑战性。即使使用正确的 JVM 内存配置，仍然可能会出现OOMKilled问题，您想知道为什么吗？长话短说由于 JVM 仅考虑大小限制，因此无法保证 Java 进程的完整heap内存边界（堆内存）；不是non-heap 内存（非堆内存），这取决于多种因素...
K8s第一章 搭建集群
最新发布
weixin_45309589的博客
06-11 131
三台虚拟机 分别非192.168.110.126 192.168.110.127 192.168.110.128。vi /etc/fstab 把最后一行注释掉。关闭防火墙和swap分区。三台虚拟机相互ping通。
如何诊断 Kubernetes 应用程序中的OOMKilled错误
Kason_iWiki
02-24 5943
OOMKilled错误表示容器或 pod 已被终止，因为它使用的内存多于分配的内存。首字母缩略词 OOM 代表“内存不足”。OOMKilled，通常称为Exit Code 137，是一种源自 Linux 的错误。OOM（Out of Memory Manager）是 Linux 系统上的一种工具，可以按进程跟踪内存使用情况。如果系统即将耗尽内存，OOM Killer将启动并开始杀死进程，以释放内存并避免崩溃。OOM Killer 的目的是通过杀死尽可能少的进程来释放尽可能多的 RAM。 Kubernetes
如何分析K8S中的OOMKilled问题(Exit Code 137)
summer_fish的专栏
10-17 3212
当 Kubernetes 集群中的容器超过其内存限制时，Kubernetes 系统可能会终止该容器并显示“OOMKilled”错误，这表明该进程由于内存不足而被终止。此错误的退出代码是 137。
JVM 内存与 K8s 容器内存不一致引发的 OOMKilled 总结
因上努力，果上随缘。但行好事，莫问前程。
12-02 1855
退出代码0表示特定容器没有附加前台进程该退出代码是所有其他后续退出代码的例外,一般是容器正常退出，程序自动退出。这不一定意味着发生了不好的事情。如果开发人员想要在容器完成其工作后自动停止其容器，则使用此退出代码。比如：kubernetes job 在执行完任务后正常退出码为 0。
kubernetes pod内容器状态OOMKilled和退出码137全流程解析
大叶子不小的博客
02-01 4959
本文研究的都是确定性的问题，好像没有什么意义，话说回来，如果没有学习这些确定性问题的积累，又如何去应对不确定的问题呢？作者：免帅叫哥链接：https://www.jianshu.com/p/0a9718199428来源：简书著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
集群容器频繁OOMKilled的排查经历
CallmeMaybe
01-04 1576
发现日志并无异样，也没有相关异常报错信息排查问题细致！注意分析工具的英文解释，每一个英文都得关注（粗心）日常开发引入jar包一定要深入理解最佳实践后才使用，切勿浅尝辄止能用就行一个已经加载的类被卸载的几率是很小的同时被卸载的时间也是不确定的工具方面mat似乎不太好查看已加载类信息，比较侧重不同类加载器加载同一个类导致的重复类问题visualvm也不太好查看已加载类信息arthas不错 功能全面。
k8s中pod监控看板
12-15
k8s中pod监控看板
kmem问题造成K8S中pod内存溢出
01-20
在Kubernetes(K8S)集群中，当遇到“kmem问题造成K8S中pod内存溢出”的情况，这通常意味着内核内存(kernel memory)的使用超过了预期限制，导致了Pod无法正常运行或者性能下降。内核内存是操作系统用于内部数据结构和...
在k8s中部署prometheus的镜像
03-23
根据实际需求，配置Prometheus以发现k8s中的服务或Pod，如使用KubernetesSD（Kubernetes Service Discovery）。 6. （可选）部署Alertmanager 类似地，创建Alertmanager的Deployment和服务，并配置相应的yaml文件。...
k8s集群pod经常重启问题排查总结.doc
10-29
k8s集群pod经常重启问题排查总结
K8S监控模板，用于k8S集群Pod监控
03-08
- 6417-K8S资源状态监控.json：可能包含了对K8S资源状态的监控配置，包括Pod的运行状态、副本集的状态、服务的状态等，用于跟踪和报警异常情况。 - 9276-主机基础监控.json：可能专注于节点级别的监控，如主机的...
此次部署在k8s集群中的SpringBoot项目OOMKilled问题汇总
weixin_30657541的博客
04-24 1207
现象1：在执行任务时，在页面上发现任务执行失败了（SprintBoot项目） # kubectl get pod |grep podname　　发现有重启的记录 #kubectl describe pod podname　　发现Reason:OOMKilled,Exit Code:137 经过测试发现OOMKill的时候pod占用的内存非常接近上图的Limitsmemor...
k8s oomkilled超出容器的内存限制
weixin_34013044的博客
12-25 8408
超出容器的内存限制 只要节点有足够的内存资源，那容器就可以使用超过其申请的内存，但是不允许容器使用超过其限制的 资源。如果容器分配了超过限制的内存，这个容器将会被优先结束。如果容器持续使用超过限制的内存， 这个容器就会被终结。如果一个结束的容器允许重启，kubelet就会重启他，但是会出现其他类型的运行错误。 本实验，我们创建一个Pod尝试分配超过其限制的内存，下面的这个Pod的配置文档，它申请5...
开源帮助：什么是退出代码 137，你能修复它吗？
开源直播系统源码
06-29 3808
当Kubernetes 环境中的 pod 或容器超过分配给它们的内存量时，将触发退出代码 137 。通常，此退出代码伴随或简称为 OOMKilled。这里描述的killed是指这个错误的结果，它导致一个pod终止。首字母缩略词 OOM 代表内存不足，这是由 pod 超出设置的内存限制引起的。如果您不确定 pod 终止的原因，最简单的找出方法之一是运行“kubectl get pods command”，然后会在特定 pod 上调用状态更新。然后，您会在其中找到 OOMKilled，它会提醒您退出代码 137
java jar killed_我的Java应用程序被OOMKilled了，原因竟是这样？
weixin_35480435的博客
03-03 563
在AWS云上，我们运行并部署容器化应用程序到我们的PaaS管道。像我们这样在Docker中运行Java应用程序的人，可能已经遇到过JVM在容器中运行时无法准确检测可用内存的问题。jvm没有准确地检测Docker容器中可用的内存，而是查看机器的可用内存。这可能导致在容器内运行的应用程序在尝试使用超出Docker容器限制的内存量时被终止的情况。JVM对可用内存的错误检测与Linuxtools/l...
K8S容器OOM killed排查
bruce128的专栏
08-30 1935
docker耗用完内存前，堆内存并没有达到上限，于是没有触发老年代GC，内存没有降下去。如果容器OOM killed，容器里的jvm进程没有Full GC，那么肯定是MaxRAMPercentage参数太高，导致堆内存没有用到上限，无法触发堆内存（老年代）GC。当实例内存超过95%时，对比top显示的的jvm进程内存和ps stats输出的docker实例内存信息，其余进程耗用的内存忽略不计。遂将内存增加到4GB。4 由于堆内存没有的到达上限，但是整个jvm进程内存超出了容器的内存限制。
Kubernetes Pod OOMKilled诊断
Andrew_Chenwq的博客
04-21 935
Container Limit ReachedLimit Overcommit通过kubectl describe pod [name]可以查看pod死亡的具体原因。查看 的最近历史事件，并尝试找出触发 错误的原因，因为只有两个常见原因：
k8s pod pending 原因
09-09
K8s Pod 处于 Pending 状态的原因可能有多种情况。下面是一些可能的原因： 1. 资源不足：K8s 集群中可能没有足够的可用资源来调度 Pod。这可能是因为节点上的 CPU、内存或存储资源已经耗尽。当资源不足时，Pod 将一直处于 Pending 状态，直到有足够的资源可用。 2. 调度问题：如果没有足够的可用节点来调度 Pod，那么 Pod 就会处于 Pending 状态。这可能是因为节点上的标签不满足 Pod 的调度要求，或者有其他调度策略阻止了 Pod 的调度。 3. 持久卷问题：如果 Pod 请求使用一个持久卷，但没有可用的持久卷提供给 Pod，那么 Pod 就会处于 Pending 状态。这可能是因为持久卷的数量不足或持久卷的状态不正确。 4. 网络问题：如果 Pod 需要访问的网络资源无法到达，或者没有可用的网络插件来创建 Pod 的网络，那么 Pod 就会处于 Pending 状态。 5. 初始化容器问题：如果 Pod 中有初始化容器，而初始化容器未能正常启动、运行或完成，则 Pod 将保持在 Pending 状态。 要解决这些问题，可以采取以下措施： 1. 检查集群中资源的使用情况，确保有足够的可用资源。 2. 检查 Pod 的调度要求和节点的标签，确保它们匹配。 3. 检查持久卷供应和状态，确保可供 Pod 使用。 4. 检查网络插件和网络配置，确保网络正常工作。 5. 检查初始化容器的配置和日志，确保其正常运行。 6. 重启相关组件，如 kubelet、kube-proxy 或整个集群，以排除其他可能的问题。 总之，Pending 状态可能是由于各种不同的原因造成的，需要仔细检查和排除各种可能性，才能解决这个问题。
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值