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

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

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

這解決了哪些問題?

API 啟動的 Pod 驅逐會遵守 PodDisruptionBudgets (PDB)。這表示透過驅逐對 Pod 請求的自願中斷,不應中斷受保護的應用程式,且 PDB 的 .status.currentHealthy 不應低於 .status.desiredHealthy。處於不健康狀態的執行中 Pod 不會計入 PDB 狀態,但只有在應用程式未中斷的情況下才能驅逐這些 Pod。這有助於中斷或尚未啟動的應用程式盡快實現可用性,而不會因驅逐而造成額外的停機時間。

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

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

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

Kubernetes 1.26 為 PodDisruptionBudget API 引入了一個新的實驗性欄位:.spec.unhealthyPodEvictionPolicy。啟用後,此欄位可讓您同時支援這兩個需求。

它是如何運作的?

API 啟動的驅逐是觸發正常 Pod 終止的過程。此過程可以透過直接呼叫 API、使用 kubectl drain 命令或叢集中的其他參與者來啟動。在此過程中,每次 Pod 移除都會諮詢適當的 PDB,以確保叢集中始終運行足夠數量的 Pod。

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

有兩種策略 IfHealthyBudgetAlwaysAllow 可供選擇。

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

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

我們認為 AlwaysAllow 通常會是更好的選擇,但對於某些關鍵工作負載,您可能仍然希望保護即使是不健康的 Pod 免受節點排空或其他形式的 API 啟動的驅逐。

我該如何使用它?

這是一個 alpha 功能,這表示您必須使用命令列引數 --feature-gates=PDBUnhealthyPodEvictionPolicy=true 為 kube-apiserver 啟用 PDBUnhealthyPodEvictionPolicy 功能閘道

這是一個範例。假設您已在叢集中啟用功能閘道,並且您已定義一個運行純 Web 伺服器的 Deployment。您使用 app: nginx 標記了該 Deployment 的 Pod。您想要限制可避免的中斷,並且您知道盡力而為的可用性對於此應用程式來說已足夠。您決定允許驅逐,即使這些 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