K8s集群OOM和Pod驱逐问题排查，发现kubelet修改保留内存后未同步更新systemd配置导致。
原文标题：K8S异常诊断之俺的内存呢
原文作者：阿里云开发者
冷月清谈：
排查过程中，首先查看了Pod驱逐原因、Pod的YAML配置、节点资源使用情况及kubelet参数。通过分析OOM日志，发现cgroup的limit小于节点的Allocatable，与预期不符。进一步排查发现，kubelet修改保留内存后，cgroup的limit没有同步更新，导致OOM。
最终，通过查看kubelet和systemd日志，以及相关代码和GitHub issue，确定问题原因是kubelet修改保留内存后未更新systemd的memory.limit，导致systemd在daemon-reload时覆盖了kubelet的设置。根本解法是升级到1.22及以上版本的集群，临时方案是手动修改systemd的memory.limit值并重启kubelet。
怜星夜思：
2、如何避免systemd和kubelet配置冲突的问题？除了升级k8s版本，还有什么最佳实践？
3、除了文中提到的排查方法，还有哪些工具或技术可以帮助快速诊断K8s的OOM问题？
原文内容
人在工位坐，锅又双叒叕从天上来：
某日下午，正当我在工位勤恳工作时，我沉寂已久的电话铃声突然响起，刚接起来就听见对面哭喊着：“牧原老哥，救救我啊！”。原来某TAM同学拜访客户，恰逢客户集群多个节点和业务出现OOM以及驱逐pod的情况，需要我们快速救援，那咱必须救兄弟姐妹于金木水火土之中啊
问题特征有几个....：
-
多集群，多业务，多节点出现驱逐
-
不同的业务pod的内存都相当大，独占节点（节点16c32G ，pod limit 15c 31G-主业务container）
-
既有podOOM又有节点内存不足的驱逐 "reason":"Evicted","message":"The node was low on resource: memory
-
调小kubelet保留内存（调整前可用26G，调整后29G），依然约26G触发OOM
闻弦歌而知雅意，这个问题不高级~：
这现象看起来就是业务正常的增长导致内存用完了，还要啥自行车啊？
用户表示，我业务实际没有使用那么多内存，并提供了内存使用的监控截图。
对于这类问题，如果我们想要细致的分析，是需要采集一些关键信息来佐证和分析。
a) 找到驱逐状态的pod查看下驱逐的原因，可以看到这个pod的驱逐原因是节点内存不足，同时输出了这个container使用了约27G的内存，初始的request内存是24G。
b) 我们看下pod的yaml对资源这块的设置，主业务确实是31G，以及当前是否有大内存使用的pod，发现多个25G左右的内存使用率pod。
c) 查看节点如top node，节点的可分配资源，以及运行的pod，超卖信息等，这里面满满都是信息啊。
d) 客户反馈调小过系统的资源保留，因此我们也要看下kubelet的参数是否生效，可以看到，reserved的内存已经降低到了100m，说明调整已经生效了。
既然基础信息采集完毕，开始整活：
触发了OOM，那么系统会输出oom的相关信息，且会输出具体的进程占用的内存开销，我们来一起看看系统日志吧。
-
ranker_service进程申请1个page（4kb）的内存时，由于内存不足触发OOM（order=0 2的0次方=1），下图来自网络：
-
cgroup memcg这两个字样很重要，说明oom是在cgroup里面触发的。
-
触发OOM的task是在这个cgroup路径里面。
-
当前的内存使用以及limit上限，failecnt代表申请失败的次数（申请失败不会立刻oom，会先尝试回收内存 ）。
-
同时输出了很多cgroup的统计信息，每个cgroup使用的内存统计，可以先忽略。
-
OOM时统计到的进程内存开销信息，开销最大就是客户的ranker_service，并且最终这个进程被kill了。
这里有个知识点，rss是page数，因此计算进程的内存开销应该用rss*4kb去计算。
通过计算rss的page值得出，内存还远远没达到系统的最大内存：
echo "scale=2; 6901788 * 4 / 1024/1024" |bc 26.32G
少年，有没有感觉哪里不对劲？
是的，你的感觉没有错，cgroup的limit是 27968328 kB。
节点的Allocatable: 31273800 Ki，
按理说cgroup的limit应该是Allocatable差不多的值，这里偏差有点大，拿出我当年尝试论证「哥德巴赫猜想」的数学能力，经过一番缜密的计算得出，cgroup的limit小于节点的Allocatable，这个cgroup它不正经啊，兄弟
。
cgroup limit: % echo "scale=2; 27968328 / 1024/1024" |bc 26.67 node Allocatable: % echo "scale=2; 31273800 / 1024/1024" |bc 29.82
cgroup设置的总得limit在这个文件中设置，它是kubelet初始化的时候设置的。
我们看下ack的初始化日志，读取自定义配置文件，计算要保留的内存。
可以看下大概的时间点，在17:34:26分的时候完成的计算。
客户通过自定义kubelet参数修改了保留内存，那我们得看下文件/etc/kubernetes/kubelet-customized-args.conf 的变动时间，以及kubelet加载的时间，文件是17:35:18左右修改的，难道是文件修改的延迟太大，导致没有覆盖？
不然，kubelet监测到配置文件变更会有一次reload的行为，因此我们可以继续看下日志，是否有重新加载。
可以看到kubelet的参数被配置成了100m。
配置难道不成功？
kubelet刷新cgroup的配置也是有日志记录的，我们可以通过关键词“Updated Node Allocatable limit across pods”看下同步的时间。
17:35:18是有刷新的日志的，且该日志表明强制配置cgroup成功后返回，兜兜转转又双叒叕来到了我最不喜欢的翻代码环节。
此处省略一万字
// If Node Allocatable is enforced on a node that has not been drained or is updated on an existing node to a lower value, // existing memory usage across pods might be higher than current Node Allocatable Memory Limits. // Pod Evictions are expected to bring down memory usage to below Node Allocatable limits. // Until evictions happen retry cgroup updates. // Update limits on non root cgroup-root to be safe since the default limits for CPU can be too low. // Check if cgroupRoot is set to a non-empty value (empty would be the root container) if len(cm.cgroupRoot) > 0 { go func() { for { err := cm.cgroupManager.Update(cgroupConfig) if err == nil { cm.recorder.Event(nodeRef, v1.EventTypeNormal, events.SuccessfulNodeAllocatableEnforcement, "Updated Node Allocatable limit across pods") return } message := fmt.Sprintf("Failed to update Node Allocatable Limits %q: %v", cm.cgroupRoot, err) cm.recorder.Event(nodeRef, v1.EventTypeWarning, events.FailedNodeAllocatableEnforcement, message) time.Sleep(time.Minute) } }() } // Now apply kube reserved and system reserved limits if required. if nc.EnforceNodeAllocatable.Has(kubetypes.SystemReservedEnforcementKey) { klog.V(2).Infof("Enforcing System reserved on cgroup %q with limits: %+v", nc.SystemReservedCgroupName, nc.SystemReserved) if err := enforceExistingCgroup(cm.cgroupManager, cm.cgroupManager.CgroupName(nc.SystemReservedCgroupName), nc.SystemReserved); err != nil { message := fmt.Sprintf("Failed to enforce System Reserved Cgroup Limits on %q: %v", nc.SystemReservedCgroupName, err) cm.recorder.Event(nodeRef, v1.EventTypeWarning, events.FailedNodeAllocatableEnforcement, message) return fmt.Errorf(message) } cm.recorder.Eventf(nodeRef, v1.EventTypeNormal, events.SuccessfulNodeAllocatableEnforcement, "Updated limits on system reserved cgroup %v", nc.SystemReservedCgroupName) } if nc.EnforceNodeAllocatable.Has(kubetypes.KubeReservedEnforcementKey) { klog.V(2).Infof("Enforcing kube reserved on cgroup %q with limits: %+v", nc.KubeReservedCgroupName, nc.KubeReserved) if err := enforceExistingCgroup(cm.cgroupManager, cm.cgroupManager.CgroupName(nc.KubeReservedCgroupName), nc.KubeReserved); err != nil { message := fmt.Sprintf("Failed to enforce Kube Reserved Cgroup Limits on %q: %v", nc.KubeReservedCgroupName, err) cm.recorder.Event(nodeRef, v1.EventTypeWarning, events.FailedNodeAllocatableEnforcement, message) return fmt.Errorf(message) } cm.recorder.Eventf(nodeRef, v1.EventTypeNormal, events.SuccessfulNodeAllocatableEnforcement, "Updated limits on kube reserved cgroup %v", nc.KubeReservedCgroupName) }
为了验证kubelet设置的值是否正确，祭出运维三宝之重启下kubelet试试，重启kubelet后memory.limit_in_bytes被设置为了正确值。
so，谁改了我的memory.limit 呢？
云上ACK集群默认使用的cgroup驱动是systemd，会不会是systemd在搞鬼呢？
systemctl cat kubepods.slice systemctl show kubepods.slice
可以看到，systemd记录到的memory_limit是初始值（kubelet加载自定义配置之前的初始值）。
重启kubelet后会覆盖成新值，但是触发daemon-reload的话会再次覆盖回去。
daemon-reload跟kubelet分开运行，互相覆盖对方的值，从issue来看，systemd覆盖了cgroup的limit值，而systemd记录的memory.limit是kubelet第一次计算的值，不是重新加载客户自定义配置的值，因此当daemon-reload时会导致覆盖。
https://github.com/kubernetes/kubernetes/issues/104289
所以这个问题我们主要考虑的点在 kubelet计算完保留值，写入systemd的memory.limit后，再加载客户自定义配置重新计算limit的逻辑，是不是没有再次更新systemd的memory.limit的值呢？
难道又双叒叕到了最“喜欢”的翻代码环节？
再次拿出媲美我小学三年级儿子的英文水平。
https://github.com/kubernetes/kubernetes/issues/88197
kubelet计算自定义的预留值后，没有update systemd的配置文件导致。
根本解法：1.20的集群升级到1.22及以上版本的集群，修复了覆盖systemd的问题。
临时方案：手动修改systemd记录的memory.limit值，然后重启，不然直接重启kubelet的话还是会被覆盖，极度不推荐。
收工，又是快乐的一天~
如果想了解K8S 集群中更多常见的故障类型及其成因，点击阅读原文，免费阅读《云运维工程师系列之云容器 K8S 异常诊断》。不仅能够加深对 Kubernetes 工作原理的理解，还能掌握一系列实用技巧来提升自己在面对突发状况时的应变能力。