kubernetes 软驱逐具有较长宽限期的pods,在资源压力下阻止硬驱逐

v64noz0r 于 5个月前发布在 Kubernetes

关注(0)|答案(8)|浏览(77)

发生了什么？
当kubelet检测到资源压力时，它首先尝试进行软驱逐，直到达到硬驱逐阈值。当一个pod被软驱逐时，它会尊重配置的最大pod宽限期秒数，直到pod关闭，kubelet将不会尝试软或硬驱逐另一个pod,即使达到了硬驱逐阈值。
结果是，一个花费很长时间关闭的pod可能导致kubelet耗尽资源。从这条评论和这条评论来看，这种行为似乎是有意为之。
在我们的情况下，我们看到一个软驱逐花了7个小时才完成，与此同时，资源使用量不断攀升，没有任何自动化尝试来节省节点。如果在pod关闭的同时有其他pod被软驱逐，这就不会成为问题。手动干预阻止了它达到硬驱逐阈值，但如果没有发生这种情况，这将完全耗尽节点，而没有任何自动化操作。
你期望会发生什么？
我期望kubelet会在一个pod花费很长时间关闭时继续尝试软驱逐其他pod。或者至少，在达到硬驱逐阈值时开始硬驱逐pod。它还可以硬驱逐被软驱逐但花费很长时间关闭的pod。
我们如何尽可能精确地重现它？

创建两个调度到同一个节点上的pod,它们具有emptyDir卷和一个预停止钩子，该钩子只是永远睡眠
用dd填充这些emptyDir卷，直到达到软驱逐阈值
观察kubelet软驱逐一个pod
继续用dd填充emptyDir卷
即使资源完全耗尽，kubelet也不会驱逐(硬或软)

我们需要了解其他任何信息吗？

无响应*

Kubernetes版本：

$ kubectl version
Client Version: v1.27.11
Kustomize Version: v5.0.1
Server Version: v1.27.11

云提供商：aws
操作系统版本：AlmaLinux9/CentOS Stream 8
安装工具：
容器运行时(CRI)和版本(如适用)
cri-o 1.27.0和containerd 1.6.21(我们同时使用两者)
相关插件(CNI、CSI等)和版本(如适用)

kubernetes

来源：https://github.com/kubernetes/kubernetes/issues/123872

8条答案

按热度按时间

aiazj4mn1#

/sig node

赞(0）回复(0）举报 5个月前

e4yzc0pl2#

/priority important-longterm

赞(0）回复(0）举报 5个月前

5ssjco0h3#

看起来像是可以通过kubelet cc中的grace period preemption来解决的问题。

赞(0）回复(0）举报 6个月前

dluptydi4#

@olyazavr 你能提供更多关于运行时(crio,containerd)和版本信息的详细信息吗？

赞(0）回复(0）举报 6个月前

yqkkidmi5#

一般来说 - 我觉得你描述的使用场景是有效的 - 让一个pod有足够的时间来关闭，除非出现紧急情况。
另一个我想到的想法是，如果在一个受压力的节点上配置了高宽限期的pod数量占大多数，那么可能会影响到那些无法被驱逐、一直等待pod关闭的节点(据我所知，没有管理员级别的方法可以在不使用webhook的情况下控制pod的宽限期)。
kubelet不会尝试软或硬驱逐另一个pod,即使达到了硬驱逐阈值。
乍一看这对我来说听起来很奇怪。
如果达到了硬驱逐阈值，强制驱逐pod是否有意义？

赞(0）回复(0）举报 6个月前

nkhmeac66#

看起来像是可以通过kubelet cc中的grace period preemption来解决的问题。
请问您对此有何解释？

赞(0）回复(0）举报 6个月前

h22fl7wq7#

@iholder101 目前已经有一个软硬驱逐阈值，所以如果达到硬驱逐阈值，它将使用一个被重置为1的宽限期来驱逐pods(当然我们需要#124063才能使其生效):
kubernetes/pkg/kubelet/eviction/eviction_manager.go
第408行到第409行
| | gracePeriodOverride:=int64(0) |
| | if!isHardEvictionThreshold(thresholdToReclaim) { |
因此，即使软驱逐的宽限期设置为较大的值，这也保护了节点。

赞(0）回复(0）举报 6个月前

pbwdgjma8#

/triage accepted

赞(0）回复(0）举报 6个月前