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

請查看我的建議，如果它們有幫助，請告訴我。