1

问题

当我们本地托管的裸机 k8s (1.18) 节点之一启动时，pod 已安排好，但难以达到“就绪”状态 - 几乎完全是由于 30 到 40 个正在安排的 pod 的磁盘 IO 涌入同时在节点上。

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

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

FWIW 内存和 CPU 在节点上被过度配置，即使在开机状态下（<10% 的使用率）也是如此。

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

尝试的解决方案

由于磁盘 IO 不是有限资源，我们正在努力寻找解决方案。我们已经调整了我们的 docker 镜像，使其在启动时尽可能少地写入磁盘，这对一些人有所帮助。

一种基本解决方案是通过增加集群中的节点数量来减少每个节点调度的 Pod 数量。这对我们来说并不理想，因为它们是物理机器，一旦节点启动，集群就会严重资源过剩。

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

乍一看，应用priorityClasses 似乎是一个解决方案。但是，我们已经创建了 priorityClasses 并相应地应用了它们，如文档中所列：

Pod 可以有优先权。优先级表示一个 Pod 相对于其他 Pod 的重要性。如果 Pod 无法被调度，调度程序会尝试抢占（驱逐）较低优先级的 Pod，以使挂起的 Pod 的调度成为可能。

tldr：Pod 仍将在开机时同时“可调度”，因为没有超过可配置的资源限制。

问题）

  • 有没有一种方法可以根据节点当前的非就绪 pod 数量来限制节点上的调度 pod？这将允许优先级类驱逐非优先级 pod 并首先安排更高优先级。
  • 除了增加集群节点的数量之外，还有没有其他我们没有想到的方法来管理这个磁盘 IO 风暴？
4

2 回答 2

2

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

  1. 使用 Taint 配置新节点，这将阻止您的“正常” pod 被调度到它。
  2. 使用以下命令创建无操作 pod 部署：
    • “相当大”的内存请求，例如：1GB。
    • 足够高的副本数以“填充”节点。
    • 对上述 Taint 的容忍度。
  3. 从现在的“完整”节点中删除污点。
  4. 以您认为合适的速度缩减无所事事的部署，以避免“土地抢购”。

这是我用于测试/故障排除的无操作“noop”图像的 Dockerfile：

FROM alpine:3.9

CMD sh -c 'while true; do sleep 5; done'
于 2020-06-12T18:51:45.027 回答
0

Kubernetes Startup Probes可能会缓解由于 livenessProbe 超时而导致 Pod 被杀死的问题：https ://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes

如果配置得当，I/O“抢滩”仍然会发生，但 pod 有足够的时间自行解决而不是被杀死。

于 2021-11-18T17:41:44.463 回答