当 Pod 因磁盘问题被 Evicted 时，我发现有两个原因：
[DiskPressure]我找到了的节点条件DiskPressure。
有什么不同？
这两个原因都是由同一个错误引起的——工作节点磁盘空间不足。然而，不同之处在于它们确切发生的时间。
为了回答这个问题我决定深入挖掘Kubernetes 源代码。
从...开始The node had condition: [DiskPressure]。
我们可以发现它被用在pkg/kubelet/eviction/helpers.go文件第44行：
nodeConditionMessageFmt = "The node had condition: %v. "
该变量由文件第 137 行Admit中的函数使用pkg/kubelet/eviction/eviction_manager.go。
Admit函数被文件canAdmitPod中的函数使用pkg/kubelet/kubelet.go， 第 1932 行：
canAdmitPodfunction 由函数使用HandlePodAdditions，也在kubelet.go文件中，第 2195 行中。
Admit和函数中代码中的注释canAdmitPod：
canAdmitPod 确定 pod 是否可以被接纳，如果不能则给出原因。“pod”是新的 pod，而“pod”是所有已接纳的 pod。该函数返回一个布尔值，指示该 pod 是否可以被接纳，一个简短的单字原因以及一条解释该 pod 为何不能被接纳的消息。
和
检查我们是否可以接纳该 Pod；如果没有，请拒绝。
因此，根据此分析，我们可以得出结论，The node had condition: [DiskPressure]当 kubelet 代理不接受节点上的新pod 时，会出现错误消息，这意味着它们不会启动。
现在继续第二个错误 -The node was low on resource: ephemeral-storage. Container NAME was using 16658224Ki, which exceeds its request of 0
和之前类似，我们可以在pkg/kubelet/eviction/helpers.go文件第 42 行找到它：
nodeLowMessageFmt = "The node was low on resource: %v. "
该变量在同一文件中由函数使用evictionMessage，第 1003 行。
evictionMessage函数被文件synchronize中的函数使用pkg/kubelet/eviction/eviction_manager.go，第 231 行
synchronizefunction 由函数使用start，在同一文件中，第 177 行。
synchronize和函数中代码中的注释start：
同步是强制驱逐阈值的主控制循环。返回被杀死的 pod，如果没有 pod 被杀死则返回 nil。
Start 启动控制循环来观察和响应低计算资源。
因此，我们可以认为，The node was low on resource:当 kubelet 代理决定终止节点上当前正在运行的pod 时，会发生错误消息。
值得强调的是，这两条错误消息都来自节点条件（在函数第 308 行中设置synchronize为逐出管理器检测到的值）。然后 kubelet 的代理做出的决定会导致这两条错误消息。
总结：
这两个错误都是由于磁盘空间不足造成的，但是：
The node had condition:错误与即将启动的Pod 有关，但它们无法启动The node was low on resource:错误与当前正在运行的 pod相关，必须终止| 归档时间： |
|
| 查看次数： |
5472 次 |
| 最近记录： |