在k8s节点上，如何管理节点开机时的pod盘IO land-rush？

Question

问题

当我们本地托管的裸机 k8s (1.18) 节点开机时，会安排 pods，但很难达到 "就绪 "状态--这几乎完全是由于该节点上同时安排了 30-40 个 pods，导致磁盘 IO 急剧增加。

这通常会导致一连串的部署失败。

• 节点上的IO请求随着pods的部署而堆积在IOWait状态。
• Pod启动时间从（正常的）10-20秒飙升到几分钟。
• livenessProbes失败。
• Pods被重新调度，随着更多IOrequests的堆积，问题更加复杂。
• 重复。

FWIW内存和CPU在节点上大大超额供给，即使在开机状态下（<10%的使用率）。

虽然我们确实有应用NFS卷挂载（通常会怀疑WRT IO问题），但pod启动时的磁盘活动和限制几乎完全在本地docker容器文件系统中。

尝试的解决方案

作为 磁盘IO不是一个可限制的资源我们正在努力寻找解决这个问题的方法。我们已经调整了我们的docker镜像，使其在启动时尽可能少地写入磁盘，这有一些帮助。

一个基本的解决方案是通过增加集群中的节点数量来降低每个节点计划的pods数量。这对我们来说并不理想，因为它们是物理机器，一旦节点启动，集群的资源就会明显过剩。

由于我们是裸机本地，我们没有一个自动的方法在启动情况下自动提供节点，并在集群稳定后降低节点数量。

应用优先级Classes乍一看似乎是一个解决方案。我们已经创建了priorityClasses，并相应地应用了它们，然而，正如在? 文件:

Pods可以有优先权。优先级表示一个Pod相对于其他Pod的重要性。如果一个Pod不能被调度，调度器会尝试抢占（驱逐）优先级较低的Pod，使待定Pod的调度成为可能。

tldr：在开机时，所有的花苞仍将同时 "可调度"，因为没有超过可配置的资源限制。

问题

• 有没有一种方法可以根据节点当前的非Ready豆荚数量来限制其调度豆荚？这样可以让优先级驱逐非优先级的豆荚，先调度优先级较高的豆荚。
• 除了增加cluster节点的数量，有没有我们没有想到的方法来管理这个磁盘IO landrush，否则？

Answer 1

虽然我也很想看看 聪明的 人们回答这个问题，这里是我的可能 "刚刚好 "的想法。

1. 配置新的节点与污点 这将防止你的 "正常" pods被安排到它。
2. 创建一个无所事事的pods部署。
   • 一个 "合理的大 "内存请求，例如： 1GB。
   • 一个足够 "填满 "节点的复制数量。
   • 一个对上述Taint的容忍度。
3. 从现在 "满了 "的节点中移除Taint。
4. 以任何你觉得合适的速度缩减do-nothing部署，以避免 "抢地盘"。

这里是我用来测试troubleshooting的do-nothing "noop "镜像的Docker文件。

FROM alpine:3.9

CMD sh -c 'while true; do sleep 5; done'