如何分析K8S中的OOMKilled问题(Exit Code 137)

这篇具有很好参考价值的文章主要介绍了如何分析K8S中的OOMKilled问题(Exit Code 137)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

什么是 OOMKilled Kubernetes 错误(Exit Code 137)

当 Kubernetes 集群中的容器超过其内存限制时,Kubernetes 系统可能会终止该容器并显示“OOMKilled”错误,这表明该进程由于内存不足而被终止。此错误的退出代码是 137。

如果遇到错误,Pod 的状态将显示“OOMKilled”,您可以使用以下命令查看该错误:

kubectl get pods

OOMKiller 机制如何工作?

Out-Of-Memory Killer (OOMKiller) 是 Linux 内核(不是本机 Kubernetes)中的一种机制,负责通过杀死消耗过多内存的进程来防止系统内存不足。当系统内存不足时,内核会调用 OOMKiller 选择一个进程来杀死,以释放内存并保持系统运行。

OOMKiller 的工作方式是选择消耗最多内存且也被认为对系统操作最不重要的进程。此选择过程基于多个因素,包括进程的内存使用情况、优先级以及已运行的时间量。

一旦 OOMKiller 选择要终止的进程,它就会向该进程发送信号,要求其正常终止。如果进程没有响应该信号,内核将强制终止该进程并释放其内存。请注意,如果节点上的重启策略设置为“始终”,则由于内存问题而被杀死的 Pod 不一定会从节点中逐出,而是会尝试重新启动 Pod。

OOMKiller 是最后手段,仅当系统面临内存不足的危险时才会调用。虽然它可以帮助防止系统因内存耗尽而崩溃,但值得注意的是,终止进程可能会导致数据丢失和系统不稳定。因此,建议配置您的系统以避免 OOM 情况,例如,通过监视内存使用情况、设置资源限制以及优化应用程序中的内存使用情况。

在底层,Linux 内核为主机上运行的每个进程维护一个 oom_score。该分数越高,进程被杀死的机会就越大。另一个值称为 oom_score_adj,允许用户自定义 OOM 进程并定义何时应终止进程。

Kubernetes 在为 Pod 定义服务质量 (QoS) 类时使用 oom_score_adj 值。可以将三个 QoS 类别分配给 pod,每个类别都有一个匹配的 oom_score_adj 值:

  • Guaranteed: -997

  • BestEffort: 1000

  • Burstable: min(max(2, 1000 — (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

由于 Qos 值为Guaranteed 的 Pod 的值较低,为 -997,因此它们是内存不足的节点上最后被杀死的。BestEffort pod 是最先被杀死的,因为它们的值最高为 1000。

要查看 Pod 的 QoS 类别,请运行以下命令:

kubectl describe pod <POD_NAME> | grep "QoS Class"


kubectl describe pod busybox-busybox-854bfd7f4d-cwr8s -n dep-xxx-uat | grep "QoS Class"
QoS Class:       Burstable

查看Pod的oom_score:

kubectl exec -it <POD_NAME> /bin/bash


kubectl exec -it dep-redis-deployment-587bdcbc99-4bhsz -n dep-xxx-uat /bin/bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
bash-5.0# cat /proc/1/oom_score
1312

OOMKilled诊断 

检查 pod 日志:诊断 OOMKilled 错误的第一步是检查 pod 日志,看看是否有任何指示内存问题的错误消息。描述命令的事件部分将给出进一步的确认以及错误发生的时间/日期。 

kubectl describe pod <podname>
State:          Running
  Started:      Fri, 12 May 2023 11:14:13 +0200
  Last State:   Terminated
  Reason:       OOMKilled
  Exit Code:    137
  ...

您还可以通过进入该pod运行的主机后台方式查询 pod 日志:

cat /var/log/pods/<podname>


cd /var/log/pods/dep-xxx-uat_dep-redis-deployment-587bdcbc99-b5pfc_e97776e7-7e4c-4632-b1e6-fc15dd88ed15

ls
dep-redis-deployment

cd dep-redis-deployment/
ls
0.log


ls -l
lrwxrwxrwx 1 root root 176 Oct  9 23:41 0.log -> /var/lib/containers/docker/containers/aa87d2a7abcf92acbe4a9a47119d0d806236c78de65519969f64e1b93f90bf50/aa87d2a7abcf92acbe4a9a47119d0d806236c78de65519969f64e1b93f90bf50-json.log

监控内存使用情况:使用 Prometheus 或 Grafana 等 Kubernetes 监控工具来监控 Pod 和容器中的内存使用情况。这可以帮助您识别哪些容器消耗过多内存并触发 OOMKilled 错误。

使用内存分析器:使用内存分析器(例如 pprof)来识别内存泄漏或可能导致内存使用过多的低效代码。

  

Kubernetes OOMKilled 错误的常见原因及解决方法 

1、已达到容器内存限制。这可能是由于在容器清单中指定的内存限制值上设置了不适当的值,这是允许容器使用的最大内存量。这也可能是由于应用程序的负载高于正常负载。解决方案是增加内存限制的值或调查负载增加的根本原因并进行修复。造成这种情况的常见原因包括大文件上传,因为上传大文件会消耗大量内存资源,尤其是当一个 Pod 中运行多个容器时,以及流量突然增加导致的高流量。

2、由于应用程序遇到内存泄漏,因此已达到容器内存限制。需要调试应用程序以解决内存泄漏的原因。

3、节点过度使用——这意味着 Pod 使用的总内存大于可用的节点总内存。通过扩展来增加节点可用的内存,或者将 Pod 移动到具有更多可用内存的节点。您还可以调整在过度使用的节点上运行的 Pod 的内存限制,使它们符合可用边界,请注意,您还应该注意内存请求设置,该设置指定 Pod 应使用的最小内存量。如果设置得太高,可能无法有效利用可用内存。在调整内存请求和限制时,请记住,当节点过度使用时,Kubernetes 将根据以下优先级顺序杀死 pod:

  • 没有请求或限制的 Pod

  • 有请求但没有限制的 Pod

  • 使用超过其内存请求值(指定的最小内存)但低于其内存限制的 Pod

  • 使用超过内存限制的 Pod文章来源地址https://www.toymoban.com/news/detail-770120.html

到了这里,关于如何分析K8S中的OOMKilled问题(Exit Code 137)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 如何批量删除k8s中的异常pod信息

    kubectl get pods 发现有很多pod出问题了 Evicted可使用kubectl中的强制删除命令 批量删除所有“Evicted”状态的pod即可 OutOfCpu可使用kubectl中的强制删除命令 批量删除所有“OutOfcpu ”状态的pod即可 Terminating可使用kubectl中的强制删除命令

    2024年02月12日
    浏览(37)
  • k8s中的服务发现机制是如何实现的

    Kubernetes的服务发现机制是Kubernetes集群中一个非常核心的功能,它允许集群内的Pod、Service以及其他网络实体相互发现和通信。这种机制对于构建微服务架构的应用程序尤为重要,因为它可以消除硬编码的网络地址和端口号,提供动态的、可扩展的服务访问方式。 在Kubernetes中

    2024年03月28日
    浏览(47)
  • K8s出现问题时,如何排查解决!

    K8s问题的排查 1、POD启动异常、部分节点无法启动pod 容器里管理应用 pod出现异常的原因: 2. 审视集群状态 审视集群状态 K8S的集群状态是排查故障的关键起点。使用kubectl get nodes命令来检查节点状态。如果有节点未能就绪或出现异常状态,可能会对应用程序造成故障。确保基

    2024年02月02日
    浏览(52)
  • k8s中的pod不停的重启,定位问题原因与解决方法

    现象: running的pod,短时间内重启次数太多   定位问题方法: 查看pod日志 本次使用以下命令,解决了问题 问题原因: OOM,pod被kill掉,重启了( 内存不够用 )   查看该服务的deployment.yaml文件 发现我们deployment.yaml对服务的内存使用,做了限制 解决方法: 将limit的memory数值提高,然后

    2024年02月15日
    浏览(66)
  • 【Azure K8S】AKS升级 Kubernetes version 失败问题的分析与解决

    创建Azure Kubernetes Service服务后,需要升级AKS集群的 kubernetes version。在AKS页面的 Cluster configuration 页面中,选择新的版本 1.25.5,确认升级。等待50分钟左右,却等到了升级失败的消息: Failed to save Kubernetes service \\\'xxxx-aks3\\\'. Error: Drain of aks-agentpool-xxxxxxxx-vmss00000j did not complete: Too

    2024年02月08日
    浏览(39)
  • 关于k8s中的node_exporter异常write: broken pipe问题排查

    公司网络更改重启服务器后,发现Prometheus监控中node节点三个挂掉了,实际上节点服务器是正常的,但是监控的node_exporter请求http://IP:9100/metrics超过10秒没有获取返回数据则认为服务挂掉。 到各个节点服务器用curl命令检测多久返回数据 time_connect :连接时间,从开始到TCP三次握

    2024年02月10日
    浏览(44)
  • k8s故障排查个案:当Pod内存持续增长,OOM问题如何解决?

    pod 运行一段时间后,内存持续增长,甚至 oom 的情况. 容器化过程中,我们经常会发现 kubernetes 集群内 pod 的内存使用率会不停持续增长,加多少内存吃多少内存,如果对 cgroup 内存的构成不是很清楚的情况下,单纯看监控看不出什么问题。 经过一番查阅,目前总结出大致有

    2024年02月22日
    浏览(59)
  • 【K8S源码之Pod漂移】整体概况分析 controller-manager 中的 nodelifecycle controller(Pod的驱逐)

    k8s 污点驱逐详解-源码分析 - 掘金 k8s驱逐篇(5)-kube-controller-manager驱逐 - 良凯尔 - 博客园 k8s驱逐篇(6)-kube-controller-manager驱逐-NodeLifecycleController源码分析 - 良凯尔 - 博客园 k8s驱逐篇(7)-kube-controller-manager驱逐-taintManager源码分析 - 良凯尔 - 博客园 基于 k8s 1.19 版本分析 TaintManager 与

    2024年02月12日
    浏览(42)
  • kubebuilder+code-generator开发k8s的controller

    本文记录用kubebuilder和code-generator开发k8s的crd控制器。 和k8s.io/code-generator类似,是一个码生成工具,用于为你的CRD生成kubernetes-style API实现。区别在于: Kubebuilder不会生成informers、listers、clientsets,而code-generator会。 Kubebuilder会生成Controller、Admission Webhooks,而code-generator不会。

    2024年01月17日
    浏览(32)
  • K8S | 核心原理分析

    目录 一、背景 二、持续集成 三、K8S架构 1、核心组件 2、分层结构 3、核心能力 3.1 发现与负载 3.2 调度 3.3 自动伸缩 四、应用案例 1、服务部署 2、交互流程 五、参考源码 整体上理解流程和原理; 基于分布式的架构中,需要管理的服务是非常多的,无论是服务的数量还是体

    2024年02月08日
    浏览(63)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包