Kubernetes节点内存不足时Pod驱逐与调度问题咨询

场景梳理 #

• node1、node2均配备4GB内存
• pod1声明resources.requests.memory=2GB，pod2声明resources.requests.memory=2GB
• 调度器将pod1、pod2调度至node1，二者实际内存占用均为250MB
• 未设置任何资源声明（requests/limits）的pod3被调度至node1
• 当pod3内存占用达2GB时，node1剩余可用内存为1.5GB

核心问题解答 #

1. 当前节点状态下的即时反应 #

此时node1剩余1.5GB可用内存，尚未触发Kubelet的默认驱逐阈值（默认硬驱逐阈值通常为memory.available < 100Mi），所以不会立刻启动驱逐流程。但如果pod3继续占用内存，使节点可用内存跌破驱逐阈值，Kubelet会触发Pod驱逐。

2. 驱逐优先级判定：pod3会被优先驱逐 #

Kubernetes的驱逐逻辑严格按照Pod的QoS等级和资源声明优先级执行：

• pod3属于BestEffort QoS等级（无任何资源声明），这是最低优先级的QoS级别
• pod1、pod2属于Burstable QoS等级（仅声明了requests未声明limits），优先级高于BestEffort
• 资源不足时，Kubelet会优先驱逐BestEffort级别的Pod，也就是pod3，不会先动pod1、pod2

3. pod1、pod2不会被驱逐调度至node2 #

• 首先，当前场景下node1的可用内存还没到必须驱逐高优先级Pod的程度，pod3会被优先处理
• 其次，即使node1后续资源紧张到需要驱逐pod1或pod2，调度器只会在Pod被驱逐后重新调度，而不会主动将它们从node1迁移到node2。且node2的总内存刚好能容纳pod1和pod2的requests总和（4GB），如果pod1/pod2被驱逐，调度器会将它们调度到node2，但这种情况在当前场景下不会发生，因为pod3会先被驱逐释放资源。

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