Kubernetes在節點變爲無法訪問後重新調度Pod的方法

Question

running ZooKeeper in Kubernetes的示例顯示了在節點從連接耗盡之後，Pod可以在不同節點上重新安排時間，通常是因爲必須對其執行維護。

豆莢與相同的身份重新安排他們有之前，在這種情況下，myid動物園管理員服務器，對應於每個莢zk-0，zk-1等的增量數。

如果節點沒有響應（可能是由於過載或網絡問題），Kubernetes是否可以在原始Pod仍在運行時重新安排另一個節點上的Pod？

它似乎some of this behavior has been specified explicitly，但我不知道如何驗證它缺少在雲提供商上設置多個節點並嘗試它。

Answer 1

如果節點沒有響應，Kubernetes> = 1.5將而不是重新安排具有相同身份的吊艙，直到確認它已被終止。有關StatefulSet的行爲詳見here。

只因爲 節點無法訪問，Kubernetes（版本1.5或更新版本）不會刪除Pod。在無法訪問的節點上運行的Pod在超時後輸入 「終止」或「未知」狀態。當用戶試圖在 無法訪問的節點上嘗試正常刪除Pod時，Pods也可能會輸入這些狀態 。是其中一個波德在這樣的狀態可以是 從API服務器移除的唯一途徑如下：

• 節點對象是 刪除（通過你，或由節點控制器）。
• korelet on 無響應節點開始響應，殺死Pod並從apiserver中刪除 條目。
• 強制用戶刪除Pod。

由於吊艙的名稱是一把鎖，我們從來沒有創建兩個吊艙具有相同的身份，「在最一」語義StatefulSets給我們。用戶可以通過執行強制刪除來重寫此行爲（並手動確保該吊艙被圍起來），但沒有自動操作可導致具有相同身份的兩個吊艙。

Kubernetes 1.5的變化確保我們優先處理StatefulSets的安全性。 Node Controller documentation有關於變化的一些細節。你可以閱讀完整的建議here。