k8s集群内prometheus频繁oomkilled问题解决

最新推荐文章于 2025-11-06 13:28:56 发布
原创 最新推荐文章于 2025-11-06 13:28:56 发布 · 1.8w 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#docker #运维 #devops

随着k8s集群规模扩大，Prometheus面临OOM问题。本文分享了解决方案：拆分抓取任务、过滤指标、调整数据落盘时间，采用联邦模式汇总监控数据。

背景

通过在k8s集群内搭建prometheus对k8s集群进行监控，主要包括以下模块

  • node-exporter监控物理机资源
  • cadavisor、kube-state-metrics监控容器资源
  • kubelete
  • apiserver
  • etcd
  • controller manager
  • kube-proxy
  • 应用程序容器自身暴露的metrics

但随着集群规模的增大，抓取的监控指标越来越多，prometheus容器开始经常出现oomkilled的问题，导致prometheus几乎不可用，无限增大分配给prometheus容器的内存终究不是最终的解决方案，现将自己解决这个问题的思路给大家分享一下，希望能够对你有所帮助！

解决方案

  • 拆分抓取任务

最初数据抓取量不大时，单个prometheus就可以完成对背景介绍中几个模块的数据的抓取，即所有的job都在一个prometheus中进行配置，但随着集群规模的增大，个别job的数据抓取量变得非常庞大，导致oomkilled之后所有的任务都会受到影响，所以可以通过查询每个job的数据量，对抓取任务进行拆分，将他们分散到多个prometheus中去完成任务的抓取

# 查看job数据抓取量
sort_desc(sum(scrape_samples_scraped) by (job))
  • 过滤抓取指标

将prometheus拆分成多个之后，监控数据分散在了多个不同的位置，如何方便的查询就又成了一个新的问题，这个就可以使用prometheus的联邦模式（FEDERATION）将多个Prometheus中的监控数据归集到一起，但是需要注意的是，归集时只去抓取需要的监控指标，尽量的精简，全量抓取同样会导致之前的问题，而且这对抓取端与被抓取端来说，都是很大的压力

<
最低0.47元/天 解锁文章
糟了，线上服务出现OOM了
10-10 2700
前一段时间，公司同事的一个线上服务OOM的问题，我觉得挺有意思的，在这里跟大家一起分享一下。我当时其实也参与了一部分问题的定位。如果这篇文章对您有所帮助，或者有所启发的话，帮忙扫描下发二维码关注一下，您的支持是我坚持写作最大的动力。关注公众号：【苏三说技术】，在公众号中回复：面试、代码神器、开发手册、时间管理有超赞的粉丝福利，另外回复：加群，可以跟很多BAT大厂的前辈交流和学习。
【Prometheus】k8s集群内部署的prometheus如何监控kubernetes集群
热门推荐
景天科技苑
03-06 6万+
在前面的章节中，我们已经介绍了 Prometheus 的核心功能，并展示了如何使用二进制部署的Prometheus来监控 Kubernetes 的 APIServer。 但在实际的生产环境中，我们通常是将 Prometheus 部署在 Kubernetes 集群内部，来监控整个集群的资源及状态。
K8s中内置的Prometheus 异常，不断重启的解决方案
是我的温柔啊
04-23 2926
如果Prometheus-k8s-0一直重启，则不光需要操作Prometheus-k8s-0，也需要对它的另一个实例Prometheus-k8s-1进行处理。执行命令： kubectl get pv pvc-cb0b2232-0ddb-4828-ac5b-706916d8de63 -o yaml。注意命令最后的k8s-system ，是根据需要(不断重启的pod)选择k8s 或 k8s-system。注意命令最后的k8s-system ，是根据需要(不断重启的pod)选择k8s 或 k8s-system。
为什么你的Dify在K8s上频繁OOMKilled？（深度解析资源配置陷阱）
最新发布
PixelFlow的博客
11-06 759
解决Dify在K8s上频繁OOMKilled问题，深入剖析Dify部署在Kubernetes的资源配置陷阱。涵盖内存限制、请求配额与实际负载匹配技巧，提升服务稳定性。运维与开发必备调优指南，值得收藏。
一文理清 K8S OOM 和 CPU 节流机制
力哥讲技术
05-04 1599
使用 Kubernetes 时，内存不足 (OOM) 错误和 CPU 节流是云应用程序中资源处理的主要难题。这是为什么？云应用程序中的 CPU 和内存要求变得越来越重要，因为它们与您的云成本直接相关。通过 limits 和 requests ，您可以配置 pod 应如何分配内存和 CPU 资源，以防止资源匮乏并调整云成本。如果节点没有足够的资源， Pod 可能会通过抢占或节点压力被驱逐。当一个进程运行内存不足 (OOM) 时，它会被终止，因为它没有所需的资源。
k8s oomkilled超出容器的内存限制
weixin_34013044的博客
12-25 8624
超出容器的内存限制 只要节点有足够的内存资源，那容器就可以使用超过其申请的内存，但是不允许容器使用超过其限制的 资源。如果容器分配了超过限制的内存，这个容器将会被优先结束。如果容器持续使用超过限制的内存， 这个容器就会被终结。如果一个结束的容器允许重启，kubelet就会重启他，但是会出现其他类型的运行错误。 本实验，我们创建一个Pod尝试分配超过其限制的内存，下面的这个Pod的配置文档，它申请5...
K8S在部署应用时，总提示OOMkilled
冰川的博客
08-14 1674
问题原因： Linux内核限制过线 解决方法 cat /etc/sysctl.conf修改内核参数 下班先写到这，有空再补
面试中询问k8s搭建prometheus过程中可能会出现的问题，并且是如何解决的
06-03
- **问题现象**：Prometheus Pod 频繁重启或被 OOMKilled。 - **原因**：未合理设置内存/CPU 资源限制，或监控目标过多导致内存溢出。 - **解决方案**： - 在 Helm Chart 中调整资源限制（示例）： ```yaml # ...
容器化环境中内存泄漏的监控挑战：K8s + Prometheus解决方案（云原生必备技能）
[容器化环境中内存泄漏的监控挑战：K8s + Prometheus解决方案（云原生必备技能）](https://user-images.githubusercontent.com/1628340/98347858-4989be80-2018-11eb-992c-438fb6b80405.png) # 1. 容器化环境中内存...
【网络与爬虫 52】Scrapyd-k8s集群化爬虫部署：Kubernetes原生分布式爬虫管理平台实战指南
熵数实验室
08-09 1470
本文深入解析Scrapyd-k8s这一革命性的Kubernetes原生爬虫管理平台，通过费曼学习法从传统部署痛点出发，详细讲解如何利用容器编排技术实现爬虫的自动化部署、弹性扩缩容和高可用集群管理。涵盖从基础概念到生产实战的完整指南，帮助开发者构建现代化、可扩展的分布式爬虫系统。
K8S容器OOM killed排查
bruce128的专栏
08-30 3229
docker耗用完内存前，堆内存并没有达到上限，于是没有触发老年代GC，内存没有降下去。如果容器OOM killed，容器里的jvm进程没有Full GC，那么肯定是MaxRAMPercentage参数太高，导致堆内存没有用到上限，无法触发堆内存（老年代）GC。当实例内存超过95%时，对比top显示的的jvm进程内存和ps stats输出的docker实例内存信息，其余进程耗用的内存忽略不计。遂将内存增加到4GB。4 由于堆内存没有的到达上限，但是整个jvm进程内存超出了容器的内存限制。
kubernetes-oom-event-generator：当Pod的容器被OOMKilled后，生成Kubernetes事件
02-03
kubernetes-oom-event-generator 容器启动时生成Kubernetes事件，并指示该容器先前已被杀死。 设计 控制器侦听Kubernetes API中的新事件和事件更改。 每次收到有关事件的通知时，它都会根据事件的Reason和所涉及对象的Kind ，检查此事件是否引用“ ContainerStarted”事件。 如果是这种情况，并且Event构成了更改（意味着它不是不变的更新，则在每两分钟执行一次重新同步时会发生这种情况），它将检查基础Pod资源。 如果Pod的LastTerminationState引用OOM，则控制器将发出Kubernetes事件，该事件的级别为Warning ，原因为PreviousContainerWasOOMKilled 。 用法 Usage: kubernetes-oom-event-generator [OPTIONS] Application Options: -v, --verbose= Show verbose debug information [$VERBOSE] --version Print
k8s重启Exit Code: 137；Reason: OOMKilled
AXingSong的博客
04-27 1884
发现原因：红框里的信息OOMKilled，退出的提示码是137，经过查询发现是部署服务时的yaml文件里的限制内存写的有点小，简单来说就是：你运行项目需要的内存比你设置的内存大，在你运行项目的时候申请内存超过了你限制的内存就会报错退出，然后重启。一开始以为是程序中下载的训练模型太大了，每天都下载一遍模型并且不会删除，导致内存溢出服务挂掉然后重启。在自己文件中把这个改大了一些，观察了一段时间，暂时还没有遇到重启。网上看到有人说可能是服务部署设置的问题，使用命令。问题：发现部署到k8s上的服务一直在自动重启。
K8s: Java应用OOMKilled的原因与分析
DevOps持续集成的博客
12-12 1326
本篇文章是「DevOps云学堂」与你共同进步的第65篇管理 Kubernetes Pod 中运行的 Java 进程的内存使用情况比人们想象的更具挑战性。即使使用正确的 JVM 内存配置，仍然可能会出现OOMKilled问题，您想知道为什么吗？长话短说由于 JVM 仅考虑大小限制，因此无法保证 Java 进程的完整heap内存边界（堆内存）；不是non-heap 内存（非堆内存），这取决于多种因素...
此次部署在k8s集群中的SpringBoot项目OOMKilled问题汇总
weixin_30657541的博客
04-24 1306
现象1：在执行任务时，在页面上发现任务执行失败了（SprintBoot项目） # kubectl get pod |grep podname　　发现有重启的记录 #kubectl describe pod podname　　发现Reason:OOMKilled,Exit Code:137 经过测试发现OOMKill的时候pod占用的内存非常接近上图的Limitsmemor...
k8s搭建问题（1）--OOMKilled
大JAVA解决方案
05-20 4025
kubectl describe pods ****** --namespace=****** 现象 Host Port: 0/TCP State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: OOMKilled 解决 resources: limits: cpu: 1 ...
如何分析K8S中的OOMKilled问题(Exit Code 137)
summer_fish的专栏
10-17 7082
当 Kubernetes 集群中的容器超过其内存限制时，Kubernetes 系统可能会终止该容器并显示“OOMKilled”错误，这表明该进程由于内存不足而被终止。此错误的退出代码是 137。
k8s Pod 常见的状态之OOMKilled状态详解
abcy071213的博客
06-12 769
在 Kubernetes (k8s) 中，OOMKilled状态指的是一个 Pod 由于内存不足（Out of Memory，简称 OOM）而被系统杀死。当容器在 Kubernetes 节点上运行时，它可能会消耗过多的内存，导致节点上的内核检测到内存不足，进而杀死该容器以保护系统的稳定性。下面将详细解释OOMKilled状态以及如何处理和避免这种情况。
k8s-kublulet-OOM-kill ，容器 OOM ， jvm oom故障分析
yuezhilangniao的博客
04-21 5477
# 排查参考文章： https://blog.youkuaiyun.com/fly910905/article/details/90179225 # 理解Linux oom https://blog.youkuaiyun.com/run_for_belief/article/details/83446344 # 理解 java oom https://www.cnblogs.com/bhlsheji/p/5330045.html 省略比較小的区域，能够总结JVM占用的内存： JVM内存 ≈ Java永久代 ＋...
k8s的pod突然出现问题解决方案
08-20
在 Kubernetes 中，Pod 突然出现异常状态可能是由多种原因引起的，包括节点问题、容器崩溃、资源限制、网络中断、存储问题等。以下是针对此类问题的排查和解决方案： ### 1. 查看 Pod 状态和事件日志 首先使用 `kubectl describe pod <pod-name>` 命令查看 Pod 的当前状态和最近事件。事件日志通常会提供关键线索，例如容器崩溃、镜像拉取失败、资源不足等。 示例命令： ```bash kubectl describe pod my-pod -n default ``` 通过事件日志可以判断问题是否与调度、容器启动、健康检查失败等有关[^1]。 ### 2. 检查容器日志 使用 `kubectl logs <pod-name>` 查看容器的标准输出日志，识别是否有异常堆栈或错误信息。 如果容器曾发生崩溃并重启，可以使用 `--previous` 参数查看上一次容器的日志： ```bash kubectl logs my-pod -n default --previous ``` ### 3. 检查节点状态 Pod 所在节点可能出现问题，例如节点宕机、资源耗尽或 Kubelet 异常。使用以下命令检查节点状态： ```bash kubectl describe node <node-name> ``` 关注节点的 `Conditions` 字段，查看是否有 `NotReady`、`DiskPressure`、`MemoryPressure` 等异常状态。如果节点状态为 `Unknown`，则可能是由于 Kubelet 失联或网络中断导致[^1]。 ### 4. 检查 Pod 的健康检查配置 Kubernetes 使用 `livenessProbe` 和 `readinessProbe` 来监控容器健康状态。如果探针配置不当或服务响应超时，可能导致容器被重启或标记为不可用。 检查 Pod 的 YAML 配置中探针设置是否合理，例如： ```yaml livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 ``` 若探针频繁失败，可适当调整 `initialDelaySeconds` 和 `failureThreshold` 参数，避免误杀正在启动的容器[^1]。 ### 5. 检查资源限制和配额 Pod 可能因为资源请求过高或集群资源不足而无法调度或被 OOMKilled。检查 Pod 的资源请求和限制是否合理： ```yaml resources: requests: memory: "256Mi" cpu: "100m" limits: memory: "512Mi" cpu: "500m" ``` 使用以下命令查看是否有因资源不足导致的调度失败或 Pod 被驱逐： ```bash kubectl describe node <node-name> | grep -i "evicted" ``` ### 6. 检查网络和存储卷配置 Pod 异常也可能是由于网络策略限制、服务发现失败或存储卷挂载失败引起。检查 Pod 的 `volumes` 和 `volumeMounts` 是否配置正确，以及网络策略是否限制了容器间的通信。 ### 7. 使用监控和告警系统 建议集成 Prometheus、Grafana 或 Kubernetes 内置的 Metrics Server，实时监控 Pod 的 CPU、内存、网络等指标。通过设置告警规则（如 CPU 使用率超过阈值、Pod 重启次数过多等），可以在问题发生前及时响应。 ### 8. 定期维护和健康检查 定期执行节点巡检、清理无效 Pod 和镜像、更新 Kubernetes 版本，并配置 Pod 的自动重启策略（如 `restartPolicy: Always`），有助于提升集群的稳定性和容错能力。 ---
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值