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

Kubernetes 1.26:由 PodDisruptionBudgets 保護的不健康 Pod 的驅逐策略

確保應用程式的中斷不影響其可用性並非易事。上個月釋出的 Kubernetes v1.26 允許你為 PodDisruptionBudgets(PDB)指定一個**不健康 Pod 驅逐策略**,以幫助你在節點管理操作期間保持可用性。在本文中,我們將深入探討對 PDB 引入了哪些修改,以便為應用程式所有者提供更大的靈活性來管理中斷。

這解決了什麼問題?

透過 API 發起的 Pod 驅逐會遵循 PodDisruptionBudgets (PDBs)。這意味著透過驅逐向 Pod 發起的自願性中斷請求,不應中斷受保護的應用程式,並且 PDB 的 .status.currentHealthy 不應低於 .status.desiredHealthy。執行中的不健康 Pod 不計入 PDB 狀態,但只有在應用程式未被中斷的情況下才可能驅逐它們。這有助於已中斷或尚未啟動的應用程式儘快實現可用性,而不會因驅逐造成額外的停機時間。

不幸的是,這給希望在沒有任何手動干預的情況下排空節點的叢集管理員帶來了問題。行為不當的應用程式(由於 bug 或配置錯誤導致 Pod 處於 CrashLoopBackOff 狀態)或根本無法就緒的 Pod 使這項任務變得更加困難。當應用程式的所有 Pod 都不健康時,任何驅逐請求都會因違反 PDB 而失敗。在這種情況下,節點的排空無法取得任何進展。

另一方面,有些使用者依賴於現有行為,以便:

  • 防止因刪除保護底層資源或儲存的 Pod 而導致的資料丟失
  • 為他們的應用程式實現最佳的可用性

Kubernetes 1.26 在 PodDisruptionBudget API 中引入了一個新的實驗性欄位:.spec.unhealthyPodEvictionPolicy。啟用後,該欄位可以讓你同時支援這兩種需求。

它是如何工作的?

透過 API 發起的驅逐是觸發 Pod 優雅終止的過程。該過程可以透過直接呼叫 API、使用 kubectl drain 命令或叢集中的其他角色來啟動。在此過程中,每次移除 Pod 都會與適當的 PDBs 進行協商,以確保叢集中始終有足夠數量的 Pod 在執行。

以下策略允許 PDB 作者更好地控制該過程如何處理不健康的 Pod。

有兩種策略可供選擇:IfHealthyBudgetAlwaysAllow

前者,IfHealthyBudget,遵循現有行為以實現你預設獲得的最佳可用性。只有當應用程式具有最小可用 .status.desiredHealthy 數量的 Pod 時,才能中斷不健康的 Pod。

透過將 PDB 的 spec.unhealthyPodEvictionPolicy 欄位設定為 AlwaysAllow,你是在為你的應用程式選擇盡力而為的可用性。使用此策略,始終可以驅逐不健康的 Pod。這將使維護和升級你的叢集變得更加容易。

我們認為 AlwaysAllow 通常會是一個更好的選擇,但對於某些關鍵工作負載,你可能仍希望保護甚至不健康的 Pod 免受節點排空或其他形式的 API 發起驅逐的影響。

我該如何使用它?

這是一個 Alpha 功能,這意味著你必須透過向 kube-apiserver 新增命令列引數 --feature-gates=PDBUnhealthyPodEvictionPolicy=true 來啟用 PDBUnhealthyPodEvictionPolicy 特性門控

這裡有一個例子。假設你已經在叢集中啟用了該特性門控,並且已經定義了一個執行普通 Web 伺服器的 Deployment。你為該 Deployment 的 Pod 添加了標籤 app: nginx。你希望限制可避免的中斷,並且你知道盡力而為的可用性對於此應用已經足夠。你決定即使這些 Web 伺服器 Pod 不健康也允許驅逐。你建立一個 PDB 來保護此應用程式,併為驅逐不健康的 Pod 設定 AlwaysAllow 策略。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  selector:
    matchLabels:
      app: nginx
  maxUnavailable: 1
  unhealthyPodEvictionPolicy: AlwaysAllow

我如何瞭解更多資訊?

我如何參與?

如果你有任何反饋,請透過 Slack 的 #sig-apps 頻道聯絡我們(如果需要邀請,請訪問 https://slack.k8s.io/),或透過 SIG Apps 郵件列表:kubernetes-sig-apps@googlegroups.com