Kube.netes Stateful set、AZ 和 Volume 聲明：AZ 失敗時會發生什么

Question

考慮跨 3 個可用區的 Statefulset（Cassandra 使用官方 K8S 示例）：

• cassandra-0 -> 區域 a
• cassandra-1 -> b 區
• cassandra-2 -> 區域 c

每個 Cassandra pod 使用一個 EBS 卷。 所以會自動產生親和力。 例如，cassandra-0 不能移動到“zone-b”，因為它的卷在“zone-a”中。 都好。

如果一些 Kube.netes 節點/workers 發生故障，它們將被替換。 Pod 將在新節點上重新啟動並重新連接到它們的 EBS 卷。 看起來什么都沒發生過。

現在，如果整個 AZ“zone-a”出現故障並且在一段時間內不可用（意味着 cassandra-0 由於對同一區域中的 EBS 的親和力而無法再啟動）。 你還剩下：

• cassandra-1 -> b 區
• cassandra-2 -> 區域 c

只要“zone-a”不可用，Kube.netes 就永遠無法啟動 cassandra-0。 這一切都很好，因為 cassandra-1 和 cassandra-2 可以處理請求。

現在，如果最重要的是，另一個 K8S 節點出現故障，或者您已經設置了基礎設施的自動縮放，您最終可能需要 cassandra-1 或 cassandra-2 才能移動到另一個 K8S 節點。 這應該不是問題。

但是根據我的測試，K8S 不會這樣做，因為 pod cassandra-0 處於離線狀態。 它永遠不會自我修復 cassandra-1 或 cassandra-2（或任何 cassandra-X），因為它希望 cassandra-0 先回來。 而 cassandra-0 無法啟動，因為它的卷位於一個已關閉且未恢復的區域中。

因此，如果您跨區域使用 Statefulset + VolumeClaim +並且您遇到整個 AZ 故障並且您在另一個 AZ 中遇到 EC2 故障或者您的基礎設施具有自動擴展

=> 那么您將丟失所有 Cassandra 吊艙。 直到 zone-a 重新上線

這似乎是一個危險的情況。 有沒有辦法讓有狀態集不關心順序並仍然自我修復或在 cassandra-3、4、5、X 上啟動更多 pod？

Answer 1

從Kubernetes 1.7開始，您可以告訴Kubernetes使用podManagementPolicy選項（ 文檔 ）放松StatefulSet排序保證。 通過將該選項設置為Parallel Kubernetes將不再保證在啟動或停止pod並且並行啟動pod時的任何順序。 這可能會對您的服務發現產生影響，但應該解決您正在討論的問題。

Answer 2

兩種選擇：

選項1： 使用podManagementPolicy並將其設置為Parallel。 pod-1和pod-2將崩潰幾次，直到種子節點（pod-0）可用。 第一次創建statefulset時會發生這種情況。 另請注意，Cassandra文檔過去建議不要並行創建多個節點，但似乎最近的更新使這不正確。 可以同時向群集添加多個節點

發現問題：如果使用2個種子節點，您將獲得裂腦情景。 將同時創建每個種子節點，並創建2個單獨的邏輯Cassandra集群

選項1b： 使用podManagementPolicy並將其設置為Parallel並使用ContainerInit。 與選項1相同，但使用initContainer https://kubernetes.io/docs/concepts/workloads/pods/init-containers/ 。 init容器是一個短期容器，用於在啟動實際容器之前檢查種子節點是否可用。 如果我們很高興pod會崩潰直到種子節點再次可用，那么這不是必需的。問題是Init Container將始終運行，這不是必需的。 我們希望確保Cassandra集群在第一次創建時形成良好。 之后無所謂

選項2： 創建3個不同的狀態填充 。

每個AZ / Rack有1個狀態。 每個statefulset都有約束，因此它只能在特定AZ中的節點上運行。 我還有3個存儲類（再次約束到特定區域），以確保statefulset不在錯誤的區域中提供EBS（statefulset還沒有動態處理它）在每個statefulset中我都有一個Cassandra種子節點（定義為環境變量CASSANDRA_SEEDS，它在運行時填充SEED_PROVIDER）。 這使3個種子充足。 由於復制因子= 3，我的設置可以在完整的區域中斷后繼續存在

提示：

• 種子節點列表包含用逗號分隔的所有3個節點：“cassandra-a-0.cassandra.MYNAMESPACE.svc.cluster.local，cassandra-b-0.cassandra.MYNAMESPACE.svc.cluster.local，cassandra-c- 0.cassandra.MYNAMESPACE.svc.cluster.local”
• 等到第一個種子（cassandra-a-0）准備就緒，然后再創建其他2個狀態集。 否則你會得到一個裂腦。 這只是創建群集時的問題。 之后，您可以松散一個或兩個種子節點而不會產生影響，因為第三個節點知道所有其他節點。

Answer 3

我認為，如果您可以控制每個 pod 的部署（cassandra-0、cassandra-1、cassandra-2 具有三個不同的 yaml 部署文件），則可以將 podAffinity 設置為每個 pod 的特定區域。

一旦區域上的節點發生故障並且必須重新安排在該服務器內運行的 pod，親和力將強制 Kube.netes 將 pod 部署在同一區域的不同節點上，如果同一區域上沒有節點可用， Kube.netes 應該無限期地關閉那個 pod。

例如，您可以創建一個具有三個不同 managedNodeGroup 的 Kube.netes 集群，每個區域一個（標簽“zone”：每個組的“a”、“b”、“c”），每個組至少有兩個節點，並使用 podAffinity。

注意：不要為節點使用 x1.32xlarge 機器:-)