本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

StatefulSets 的最小就緒秒數

此部落格描述 StatefulSet 工作負載的可用性概念,以及 Kubernetes 1.22 中的新 alpha 功能,該功能為 StatefulSet 新增了 minReadySeconds 組態。

這解決了哪些問題?

在 Kubernetes 1.22 版本之前,一旦 StatefulSet Pod 處於 Ready 狀態,即被視為 Available 以接收流量。對於某些 StatefulSet 工作負載,情況可能並非如此。例如,像 Prometheus 這樣具有多個 Alertmanager 實例的工作負載,只有在 Alertmanager 的狀態傳輸完成時才應被視為 Available,而不是在 Pod 處於 Ready 狀態時。由於 minReadySeconds 新增了緩衝時間,因此狀態傳輸可能會在 Pod 變成 Available 之前完成。雖然這不是識別狀態傳輸是否完成的萬無一失的方法,但它為最終使用者提供了一種表達其意圖的方式,即在 Pod 被視為 Available 且準備好服務請求之前等待一段時間。

另一個 minReadySeconds 有幫助的情況是搭配雲端供應商使用 LoadBalancer Services。由於 minReadySecondsPod Ready 之後新增了延遲,因此它提供了緩衝時間,以防止在新 Pod 出現之前輪換中終止 Pod。想像一下,負載平衡器在不正常路徑中需要 10-15 秒才能傳播。如果您有 2 個副本,那麼您只會在第一個副本啟動後才終止第二個副本,但實際上,第一個副本是看不到的,因為它尚未準備好服務請求。

因此,總體而言,StatefulSetsAvailability 的概念非常有用,此功能有助於解決上述問題。這是一個已經存在於 DeploymentsDaemonSets 的功能,我們現在也為 StatefulSets 提供了此功能,以便為使用者提供一致的工作負載體驗。

它是如何運作的?

statefulSet 控制器監看 StatefulSets 和與它們關聯的 Pods。當與此功能關聯的功能閘道啟用時,statefulSet 控制器會識別與 StatefulSet 關聯的特定 Pod 處於 Running 狀態的時間長度。

如果此值大於或等於最終使用者在 .spec.minReadySeconds 欄位中指定的時間,則 statefulSet 控制器會更新 StatefulSet 狀態子資源中名為 availableReplicas 的欄位,以包含此 PodStatefulSet 狀態中的 status.availableReplicas 是一個整數欄位,用於追蹤 Available 的 Pod 數量。

我該如何使用它?

您需要準備以下事項才能試用此功能

  • 下載並安裝大於 v1.22.0 版本的 kubectl
  • kube-apiserverkube-controller-manager 上使用命令列旗標 --feature-gates=StatefulSetMinReadySeconds=true 開啟功能閘道

成功啟動 kube-apiserverkube-controller-manager 後,您將在狀態中看到 AvailableReplicas,並在 spec 中看到 minReadySeconds(預設值為 0)。

為任何 StatefulSet 指定 minReadySeconds 的值,您可以使用以下命令檢查 Pods 是否可用:kubectl get statefulset/<statefulset 名稱> -o yaml

我如何瞭解更多資訊?

我該如何參與?

請透過 Slack 上的 #sig-apps 頻道與我們聯絡(如果您需要邀請,請造訪 https://slack.k8s.io/),或透過 SIG Apps 郵寄清單:kubernetes-sig-apps@googlegroups.com