Kubernetes节点内存占用超配置上限问题排查咨询

一、为什么节点内存占用会超出预设的Pod总限制？ #

你遇到的核心问题，本质是对Kubernetes内存限制的几个关键逻辑理解有偏差，主要原因包括：

1. 节点系统进程的内存占用未被计入Pod限制
   Kubernetes的Pod内存限制只统计容器内的进程，但节点本身的系统进程（比如操作系统的init进程、sshd、containerd/docker守护进程、kubelet服务等）都会占用节点内存，这部分内存完全不在你计算的Pod总限制范围内。比如你算的69%是所有Pod的limits总和，但加上系统进程的占用，节点总使用率自然会更高。
2. 部分内置Pod未设置内存限制
   你的猜测是对的：kube-system命名空间里的很多内置组件（比如早期版本的coredns、kube-proxy，或者云厂商提供的节点专属组件）默认可能没有设置内存limits。这类Pod如果遇到流量波动或内存泄漏，会无限制地占用节点内存，直接导致节点总使用率飙升。
3. LimitRange的作用被误解
   你给命名空间设置的LimitRange是容器级的默认限制，不是命名空间的总资源上限。它只会给那些没有显式声明内存limits的容器自动设置默认值，但不会限制整个命名空间的总内存使用。比如如果kube-system里有3个无限制的容器，每个都会被设为1000Mi，那这个命名空间的总limits就会达到3GB，远超你预期的1000Mi。

二、为什么设置LimitRange后总占用达到106%？ #

这完全是因为你混淆了LimitRange和ResourceQuota的作用：

• LimitRange：给单个容器设置默认的requests/limits，或者限制容器的最小/最大资源值，不限制命名空间的总资源。
• ResourceQuota：才是用来限制整个命名空间的总资源使用（比如总内存、总CPU）的工具。

你当前的配置只是给每个无限制的容器设了1000Mi的上限，但没有限制命名空间的总内存，所以当多个容器运行时，总占用很容易超出你预期的2GB。

三、如何避免节点内存超100%导致Pod报错？ #

针对你的场景，给出以下具体解决方案：

1. 给所有Pod（包括kube-system）设置明确的内存requests和limits

• 检查kube-system里的所有Pod，给没有设置limits的组件添加合理的内存限制。比如coredns可以设置limits: memory: 256Mi，kube-proxy设置limits: memory: 128Mi，根据组件的实际运行情况调整。
• 确保你的业务Pod的requests和limits设置合理，requests要反映Pod的实际内存需求，limits要留好缓冲但不要过大。

2. 使用ResourceQuota限制命名空间的总资源

替换（或补充）你的LimitRange配置，给kube-system和test-ns添加ResourceQuota，限制命名空间的总内存使用：

# test-ns的ResourceQuota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: ns-mem-quota
  namespace: test-ns
spec:
  hard:
    memory: 1000Mi
    pods: "2" # 限制Pod数量，和你的Deployment replicas对应
---
# kube-system的ResourceQuota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: kube-system-mem-quota
  namespace: kube-system
spec:
  hard:
    memory: 1000Mi

这样就能确保每个命名空间的总内存占用不超过你设定的上限。

3. 给节点预留足够的系统内存

Kubernetes默认会给节点系统进程预留一部分内存，但你可以手动调整kubelet的配置（比如通过--kube-reserved和--system-reserved参数），确保节点的系统进程和K8s组件有足够的内存可用。比如2GB内存的节点，可以预留300MB给系统，100MB给kubelet：

--kube-reserved=memory=100Mi
--system-reserved=memory=300Mi

这样Kubernetes调度Pod时会自动扣除这部分预留内存，不会把Pod调度到内存不足的节点。

4. 配置kubelet的内存驱逐策略

调整kubelet的驱逐阈值，让kubelet在节点内存快要耗尽时，主动驱逐低优先级的Pod，避免节点OOM导致你的业务Pod报错。比如设置当可用内存低于10%时开始驱逐：

--eviction-hard=memory.available<10%
--eviction-soft=memory.available<15%
--eviction-soft-grace-period=1m

这样kubelet会在内存紧张时先清理不重要的Pod，保障你的业务Pod运行。

验证方法 #

你可以通过以下命令验证配置效果：

• 查看命名空间的资源使用情况：kubectl describe quota -n test-ns
• 实时监控节点和Pod内存：kubectl top nodes、kubectl top pods -A
• 查看节点的预留资源和驱逐配置：kubectl describe node <node-name>

内容的提问来源于stack exchange，提问作者DaiKeung