k8s pod OOMKilled 错误原因

最新推荐文章于 2024-05-09 22:08:12 发布
最新推荐文章于 2024-05-09 22:08:12 发布
阅读量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 1106
简单整一下 k8s 中 Pod 故障OOMKilled的原因以及诊断博文内容涉及:k8sOOMKilled分类: 宿主节点行为 / K8s Cgroups 行为什么是OOMKilledK8s 错误,OOMKiller 机制如何工作？OOMKilledK8s 错误和解决的常见原因理解不足小伙伴帮忙指正对每个人而言，真正的职责只有一个：找到自我。然后在心中坚守其一生，全心全意，永不停息。
JVM 内存与 K8s 容器内存不一致引发的 OOMKilled 总结
因上努力，果上随缘。但行好事，莫问前程。
12-02 1822
退出代码0表示特定容器没有附加前台进程该退出代码是所有其他后续退出代码的例外,一般是容器正常退出，程序自动退出。这不一定意味着发生了不好的事情。如果开发人员想要在容器完成其工作后自动停止其容器，则使用此退出代码。比如：kubernetes job 在执行完任务后正常退出码为 0。
Kubernetes（K8s）的基础概念
最新发布
rmh0713的博客
05-09 827
kubernetes是一个可移植，可扩展的开源平台，用于管理容器化工作负载和服务，有助于声明式配置和自动化。它拥有庞大且快速发展的生态系统。kubernetes服务，支持和工具随处可见。作用：用于自动部署，扩展和管理“容器化应用程序”的开源系统。可以理解成k8s是负责自动化运维管理多个容器化程序（比如docker）的集群，是一个生态及其丰富的容器编排框架工具。
集群容器频繁OOMKilled的排查经历
CallmeMaybe
01-04 1534
发现日志并无异样，也没有相关异常报错信息排查问题细致！注意分析工具的英文解释，每一个英文都得关注（粗心）日常开发引入jar包一定要深入理解最佳实践后才使用，切勿浅尝辄止能用就行一个已经加载的类被卸载的几率是很小的同时被卸载的时间也是不确定的工具方面mat似乎不太好查看已加载类信息，比较侧重不同类加载器加载同一个类导致的重复类问题visualvm也不太好查看已加载类信息arthas不错 功能全面。
java jar killed_我的Java应用程序被OOMKilled了，原因竟是这样？
weixin_35480435的博客
03-03 556
在AWS云上，我们运行并部署容器化应用程序到我们的PaaS管道。像我们这样在Docker中运行Java应用程序的人，可能已经遇到过JVM在容器中运行时无法准确检测可用内存的问题。jvm没有准确地检测Docker容器中可用的内存，而是查看机器的可用内存。这可能导致在容器内运行的应用程序在尝试使用超出Docker容器限制的内存量时被终止的情况。JVM对可用内存的错误检测与Linuxtools/l...
k8s 详解之资源管理
qq_49832677的博客
03-22 975
k8s 详解之资源管理。
容器中Java 程序OOMKilled原因浅析
weixin_30361753的博客
06-16 2672
背景： 业务的容器化刚刚搞完，线上开始告警，容器重启，容器重启。describe pod 查看原因是OOMKilled 分析： OOMKilled 是pod 中的进程使用的内存超过了.spec.containers[*].resources.limits.memory中定义的内存限制，在超出限制后， kubernetes 会向容器中的进程(pid=1)发送kill -9 信号。kill ...
k8s中pod监控看板
12-15
k8s中pod监控看板
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 上都将...
k8s集群pod经常重启问题排查总结.doc
10-29
k8s集群pod经常重启问题排查总结
K8S监控模板，用于k8S集群Pod监控
03-08
- 6417-K8S资源状态监控.json：可能包含了对K8S资源状态的监控配置，包括Pod的运行状态、副本集的状态、服务的状态等，用于跟踪和报警异常情况。 - 9276-主机基础监控.json：可能专注于节点级别的监控，如主机的...
k8s pod-infrastructure.tgz 软件包，用于 k8s部署基础包
03-26
《K8s Pod基础设施软件包详解》 在现代云计算领域，Kubernetes（简称K8s）作为容器编排的领头羊，已经成为管理和部署应用程序的标准工具。本文将深入探讨"K8s pod-infrastructure.tgz"软件包，它是构建K8s集群的...
k8s容器 pod OOM, exit code:137
feichen2016的博客
11-02 1万+
某天查看线上服务，发现有个服务平均每天重启一次，通过k8s descripe pod podName 命令发现exit code： 137 reason: OOM Killed. 提示比较明显OOM（当时查了失败的容器内服务日志，发现没有异常信息，有点疑惑的）,然后果断在jvm配置里添加OOM自动dump日志参数，-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof，等着问题后分析日志原因（我们体量不大，同时又是多节点，所.
k8s OOMkilled超出内存限制的容器
学亮编程手记
08-27 699
privileged启动的容器，可以看到很多host上的设备，并且可以执行mount。docker解决方法：在docker run启动容器时加上–privileged 如：docker run -v /home/liurizhou/temp:/home/liurizhou/temp –privileged my_images:latest /bin.bash k8s解决方法：在containers:加上 securityContext: privileged: true runAsUser: 0。...
k8s报错整理集合---持续更新
weixin_43273856的博客
03-14 983
个人整理kubernetes各种常见问题，该文章持续更新...
k8s 实战 常见异常事件 event 及解决方案分享
热门推荐
LoveSummer
01-06 6万+
重启集群中的coredns组件发生重启(重新创建)，一般是由于coredns组件压力较大导致oom，请检查业务是否异常，是否存在应用容器无法解析域名的异常。如果是local-dns重启，说明local-dns的性能也不够了，需要优化。
记录一次k8s的oom问题定位
成长之路
11-10 1593
记录一次k8s的oom问题定位
k8s中java内存泄漏,docker – Kubernetes OOM pod被杀死,因为内核内存增长很多
weixin_39949297的博客
03-16 1407
我正在开发一个java服务,它基本上在网络文件系统中创建文件来存储数据.它运行在Ubuntu 18.04 LTS中的k8s集群中.当我们开始限制kubernetes(限制：内存：3Gi)的内存时,pod开始被kubernetes OOMKILL.一开始我们认为这是java进程中的内存泄漏,但更深入地分析我们注意到问题是内核的内存.我们验证了查看文件/sys/fs/cgroup/memory/mem...
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、付费专栏及课程。

余额充值