跨 Kubernetes 分散工作負載
我創建了一個 Deployment，它可以包含 2 到 25 個容器，它們都在一個更大的單個邏輯工作單元的一個切片上工作。容器將使用 700MB-4GB 的峰值記憶體，我最初的方法是請求 1G，限制 4G。在最壞的情況下（4GB 多於 700MB），即使在其他地方有 3% 或 400% 的免費聚合資源可用，這也會導致節點停機（或不會安排開始）。
看著一個或兩個容器在 RAM 中慢慢爬升並 OOM 節點關閉，而不是讓調度程序將容器拔出並重新定位，這似乎是一個非常明顯的穩定性問題。
經過多年的 git 辯論、文件和程式碼本身的探勘。目前尚不清楚調度程序在抽象的哪個抽象級別上甚至在啟動時傳播容器，或者一旦部署工作，K8S 是否有任何主動步驟。
如果一個 ReplicaSet（我相信那是新的、改進的 ReplicationController）只會在殺死主機之前重新啟動容器，那麼您必須在其職權範圍內為每個 pod 創建最壞情況的硬性請求。對於我們作為部署執行的較大的作業，這會引入50% 以上的 RAM 浪費，因為“以防萬一”過度配置。
保持過度配置的資源不是我們在這裡試圖解決的問題之一嗎？
多年來，我使用了很多調度程序/資源管理器，並且不記得一個作業步驟 - 容器 - 無論是什麼類比都會被允許損害主機本身，而不是被強制遷移或直接標記沒有資格安排..
儘管文件告誡這個想法，但裸 pod 或 1 pod:1 ReplicaSet似乎是保持工作分佈式的唯一方法（假設容器檢查點和自殺經常足以重新考慮整體資源圖）。
我還應該提到，這是託管的 Google Container Engine (v1.2.2)，並且考慮到看起來可以啟動 K8S 的幾頁標誌，不清楚這是一個固有問題、使用者錯誤還是 GCE 的配置方式K8S。我真的希望這個使用者錯誤。
根據 Kubernetes slack 頻道上一些非常有幫助的人來回答我自己的問題。
– 我的節點由於容器的OOM’ing 而失敗的經歷可能是由於資源管理器旨在防止這種情況的次要影響。建議的罪魁禍首實際上是 I/O 子系統過載到節點不穩定的程度，經過一些測量，這看起來很可能。
在 GKE 中，作業系統、Docker、K8S 以及 pod 請求的任何臨時目錄都位於一個非本地 100GB（我相信預設情況下）ext4 文件系統上。
我們創建的大多數 pod 都在請求並寫入臨時目錄，而集體 I/O 使系統不堪重負，以至於系統變得無響應，在我們的例子中鎖定了作業系統本身。
– 一個初步測試，在自己的 ext4 驅動器上設置我自己的 K8S 作業系統，docker 和在他們自己的 ZFS 池中的臨時空間，並且相同的部署清單確實有壓力，但不會接近崩潰作業系統。
- 一個已經提出但尚未測試的解決方法是使用 Jobs 並通過一些協調過程管理它們之間的依賴關係，大概因為這會將單個容器分佈在集群中。這可能會奏效，但讓我印象深刻，因為它掩蓋了一個潛在的問題。
雖然我還沒有測量為我們使用 emptyDir 的暫存空間分配永久性磁碟，但我假設這也會減輕主磁碟上的負載，並且可能足以掩蓋問題。
不幸的是，預設的 GKE 設置假定 sda 將能夠處理作業系統、K8S 日誌、Docker 和暫存空間的全部負載，這顯然必須為大多數人工作，因為我找不到像我們這樣的另一個問題。
來自裸機，我希望在管理集群時避免一些低級別的細節，但是到目前為止，dataproc 和 GKE 至少讓我非常傾向於自己建構集群。
希望這將有助於那些工作負載適合作業模式或主要使用預置磁碟的人。
我很驚訝任何最佳實踐都會對引導驅動器抱有如此多的期望，並且會在支持下標記這一點，因為即使是“正常”計算引擎也似乎不鼓勵這種情況，因為預設引導驅動器大小。