在k8s节点上，如何在节点加电时管理Pod磁盘IO登陆？

Question

问题

当我们在本地托管的裸机k8（1.18）节点之一上电时，将安排Pod的运行时间，但很难达到“就绪”状态-几乎完全是由于磁盘IO从30-40涌入在节点上同时调度Pod。

这通常会导致一系列的部署失败：

• 随着Pod的部署，节点上的IO请求以IOWait状态堆叠。
• Pod启动时间从（正常）10-20秒猛增至分钟。
• livenessProbes失败。
• 重新安排了豆荚，随着更多的IO，问题变得更加复杂 请求堆积。
• 重复。

FWIW内存和CPU在节点上的配置过多，即使处于开机状态（使用率不到10％）。

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

尝试的解决方案

作为disk IO is not a limitable resource，我们正在努力寻找解决方案。我们已经调整了docker映像，以便在启动时尽可能少地将其写入磁盘，这对某些人有所帮助。

一种基本解决方案涉及通过增加集群中的节点数来减少每个节点调度的Pod数。对于我们来说，这不是理想的选择，因为它们是物理机器，并且一旦节点确实启动，群集的资源就会明显过多。

由于我们是裸机/本地机，我们没有自动的方法来在启动情况下自动设置节点并在群集稳定时降低它们。

乍一看应用优先级类似乎是一种解决方案。我们已经创建了priorityClasses并相应地应用了它们，如documentation中所述：

荚可以具有优先权。优先级表示Pod的重要性 相对于其他Pod。如果无法安排Pod，则调度程序 尝试抢占（逐出）较低优先级的Pod，以安排 暂挂Pod。

tldr：由于未超出可配置的资源限制，上电后仍可同时对所有Pod进行“调度”。

问题

• 是否有一种方法可以根据节点当前未就绪的吊舱数限制节点上的调度吊舱？这将允许优先级类别逐出非优先级Pod，并优先安排较高优先级。
• 除了增加数量 群集节点，是否有我们没有想到过的方法来管理此磁盘IO混乱？

Answer 1

虽然我也有兴趣看到 smart 人回答这个问题，但这是我可能的“正好”的想法：

1. 用Taint配置新节点，以防止安排您的“常规”吊舱。
2. 使用以下方法创建无所事事的容器的部署：
   • “相当大”的内存请求，例如：1GB。
   • 大量副本足以“填充”节点。
   • 对上述污染的容忍。
3. 从现在的“已满”节点移除污染。
4. 以您认为合适的速度缩减无所事事的部署规模，以避免“抢地”。

这是我用于测试/故障排除的“无用”映像的Dockerfile：

FROM alpine:3.9

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