Kubernetes pod eviction 将被驱逐的 pod 安排到已经在 DiskPressure 下的节点

Question

我们正在运行一个具有 5 个主节点和 20 个工作节点的 kubernetes (1.9.4) 集群。 我们正在此集群中的其他 pod 中运行一个带有复制 3 的 statefulset pod。 最初，statefulset pod 分发到 3 个节点。 然而，由于节点 2 上的磁盘压力，节点 2 上的 pod-2 被逐出。 但是，当 pod-2 被驱逐时，它会转到 node-1，其中 pod-1 已经在运行，而 node-1 已经承受了节点压力。 根据我们的理解，kubernetes-scheduler 不应该将 pod（非关键）调度到已经存在磁盘压力的节点。 这是在磁盘压力下不将 pod 调度到节点的默认行为还是允许的。 原因是，同时我们确实观察到 node-0 没有任何磁盘问题。 因此，我们希望 node-2 上被驱逐的 pod 理想情况下应该出现在 node-0 上，而不是出现在磁盘压力下的 node-1 上。

我们的另一个观察结果是，当 node-2 上的 pod-2 被驱逐时，我们看到同一个 pod 被成功调度并生成并移动到 node-1 中的运行状态。 但是，对于被驱逐的同一个 pod-2，我们仍然在 node-2 中多次看到“无法承认 pod”错误。 这是 kube-scheduler 的任何问题吗？

Answer 1

是的，调度程序不应将新 pod 分配给具有 DiskPressure Condition 的节点。

但是，我认为您可以从几个不同的角度来解决这个问题。

1. 查看调度程序的配置：

   • ./kube-scheduler --write-config-to kube-config.yaml

并检查它是否需要任何调整。 您可以在此处找到有关 kube-scheduler 的其他选项的信息：

2. 您还可以根据需要配置其他调度程序。 可以在这里找到教程

3. 检查日志：

   • kubeclt logs ：kube-scheduler 事件日志
   • journalctl -u kubelet : kubelet 日志
   • /var/log/kube-scheduler.log （在主服务器上）

4. 更仔细地查看 Kubelet 的 Eviction Thresholds（软和硬）以及设置了多少节点内存容量。

5. 请记住：

   • Kubelet 可能无法足够快地观察到资源压力或
   • 由于统计信息收集时间间隔，Kubelet 可能会驱逐比需要更多的 Pod

请查看我的建议，如果它们有帮助，请告诉我。