K8S异常诊断之俺的内存呢

作者：牧原

69 次浏览

5 次

2025-2-20

编辑推荐:

本文讲述作者如何解决客户集群中出现的OOM（Out of Memory）和Pod驱逐问题。文章不仅详细记录了问题的发生背景、现象特征，还深入探讨了排查过程中的关键步骤和技术细节。希望对你的学习有帮助。
本文来自于微信公众号阿里云开发者，由Linda编辑、推荐。

阿里妹导读

本文讲述作者如何解决客户集群中出现的OOM（Out of Memory）和Pod驱逐问题。文章不仅详细记录了问题的发生背景、现象特征，还深入探讨了排查过程中的关键步骤和技术细节。

人在工位坐，锅又双叒叕从天上来：

某日下午，正当我在工位勤恳工作时，我沉寂已久的电话铃声突然响起，刚接起来就听见对面哭喊着：“牧原老哥，救救我啊！”。原来某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的相关信息，且会输出具体的进程占用的内存开销，我们来一起看看系统日志吧。

OOM日志分析必备小知识之看图说话：

OOM日志之开始：

ranker_service进程申请1个page（4kb）的内存时，由于内存不足触发OOM（order=0 2的0次方=1），下图来自网络：

cgroup memcg这两个字样很重要，说明oom是在cgroup里面触发的。

OOM日志之关键信息：

触发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它不正经啊，兄弟：

是的，你的感觉没有错，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被设置为了正确值。