參考：https://kubernetes.io/zh/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget

本指南針對的是希望構建高可用性應用程式的應用所有者，他們有必要了解可能發生在 Pod 上的干擾型別。

文件同樣適用於想要執行自動化叢集操作（例如升級和自動擴充套件叢集）的叢集管理員。

自願干擾和非自願干擾

Pod 不會消失，除非有人（使用者或控制器）將其銷燬，或者出現了不可避免的硬體或軟體系統錯誤。

我們把這些不可避免的情況稱為應用的非自願干擾（Involuntary Disruptions）。例如：

節點下層物理機的硬體故障
叢集管理員錯誤地刪除虛擬機器（例項）
雲提供商或虛擬機器管理程式中的故障導致的虛擬機器消失
核心錯誤
節點由於叢集網路隔離從叢集中消失
由於節點資源不足導致 pod 被驅逐。
 

除了資源不足的情況，大多數使用者應該都熟悉這些情況；它們不是特定於 Kubernetes 的。

我們稱其他情況為自願干擾（Voluntary Disruptions）。 包括由應用程式所有者發起的操作和由叢集管理員發起的操作。典型的應用程式所有者的操 作包括：

刪除 Deployment 或其他管理 Pod 的控制器
更新了 Deployment 的 Pod 模板導致 Pod 重啟
直接刪除 Pod（例如，因為誤操作）

叢集管理員操作包括：

排空（drain）節點進行修復或升級。
從叢集中排空節點以縮小叢集（瞭解叢集自動擴縮）。
從節點中移除一個 Pod，以允許其他 Pod 使用該節點。
 

這些操作可能由叢集管理員直接執行，也可能由叢集管理員所使用的自動化工具執行，或者由叢集託管提供商自動執行。

諮詢叢集管理員或聯絡雲提供商，或者查詢釋出文件，以確定是否為叢集啟用了任何資源干擾源。 如果沒有啟用，可以不用建立 Pod Disruption Budgets（Pod 干擾預算）

注意： 並非所有的自願干擾都會受到 Pod 干擾預算的限制。 例如，刪除 Deployment 或 Pod 的刪除操作就會跳過 Pod 干擾預算檢查。

處理干擾

以下是減輕非自願干擾的一些方法：

確保 Pod 在請求中給出所需資源。
如果需要更高的可用性，請複製應用程式。 （瞭解有關執行多副本的無狀態 和有狀態應用程式的資訊。）
為了在運行復制應用程式時獲得更高的可用性，請跨機架（使用 反親和性 或跨區域（如果使用多區域叢集）擴充套件應用程式。
 

自願干擾的頻率各不相同。在一個基本的 Kubernetes 叢集中，沒有自願干擾（只有使用者觸發的干擾）。 然而，叢集管理員或託管提供商可能執行一些可能導致自願干擾的額外服務。例如，節點軟 更新可能導致自願干擾。另外，叢集（節點）自動縮放的某些 實現可能導致碎片整理和緊縮節點的自願干擾。叢集 管理員或託管提供商應該已經記錄了各級別的自願干擾（如果有的話）。 有些配置選項，例如在 pod spec 中 使用 PriorityClasses 也會產生自願（和非自願）的干擾。

Kubernetes 提供特性來滿足在出現頻繁自願干擾的同時執行高可用的應用程式。我們稱這些特性為 干擾預算（Disruption Budget）。

干擾預算

FEATURE STATE: Kubernetes v1.21 [stable]

即使你會經常引入自願性干擾，Kubernetes 也能夠支援你執行高度可用的應用。

應用程式所有者可以為每個應用程式建立 PodDisruptionBudget 物件（PDB）。 PDB 將限制在同一時間因自願干擾導致的複製應用程式中宕機的 pod 數量。 例如，基於票選機制的應用程式希望確保執行的副本數永遠不會低於仲裁所需的數量。 Web 前端可能希望確保提供負載的副本數量永遠不會低於總數的某個百分比。

叢集管理員和託管提供商應該使用遵循 PodDisruptionBudgets 的介面 （通過呼叫Eviction API）， 而不是直接刪除 Pod 或 Deployment。

例如，kubectl drain 命令可以用來標記某個節點即將停止服務。 執行 kubectl drain 命令時，工具會嘗試驅逐機器上的所有 Pod。 kubectl 所提交的驅逐請求可能會暫時被拒絕，所以該工具會定時重試失敗的請求， 直到所有的 Pod 都被終止，或者達到配置的超時時間。

PDB 指定應用程式可以容忍的副本數量（相當於應該有多少副本）。 例如，具有 .spec.replicas: 5 的 Deployment 在任何時間都應該有 5 個 Pod。 如果 PDB 允許其在某一時刻有 4 個副本，那麼驅逐 API 將允許同一時刻僅有一個而不是兩個 Pod 自願干擾。

使用標籤選擇器來指定構成應用程式的一組 Pod，這與應用程式的控制器（Deployment，StatefulSet 等） 選擇 Pod 的邏輯一樣。

Pod 控制器的 .spec.replicas 計算“預期的” Pod 數量。 根據 Pod 物件的 .metadata.ownerReferences 欄位來發現控制器。

PDB 不能阻止非自願干擾的發生，但是確實會計入 預算。

由於應用程式的滾動升級而被刪除或不可用的 Pod 確實會計入干擾預算， 但是控制器（如 Deployment 和 StatefulSet）在進行滾動升級時不受 PDB 的限制。應用程式更新期間的故障處理方式是在對應的工作負載資源的 spec 中配置的。

當使用驅逐 API 驅逐 Pod 時，Pod 會被體面地 終止，期間會 參考 PodSpec 中的 terminationGracePeriodSeconds 配置值。

PDB 例子

假設叢集有 3 個節點，node-1 到 node-3。叢集上運行了一些應用。 其中一個應用有 3 個副本，分別是 pod-a，pod-b 和 pod-c。 另外，還有一個不帶 PDB 的無關 pod pod-x 也同樣顯示出來。 最初，所有的 Pod 分佈如下：

3 個 Pod 都是 deployment 的一部分，並且共同擁有同一個 PDB，要求 3 個 Pod 中至少有 2 個 Pod 始終處於可用狀態。

例如，假設叢集管理員想要重啟系統，升級核心版本來修復核心中的許可權。 叢集管理員首先使用 kubectl drain 命令嘗試排空 node-1 節點。 命令嘗試驅逐 pod-a 和 pod-x。操作立即就成功了。 兩個 Pod 同時進入 terminating 狀態。這時的叢集處於下面的狀態：

Deployment 控制器觀察到其中一個 Pod 正在終止，因此它建立了一個替代 Pod pod-d。 由於 node-1 被封鎖（cordon），pod-d 落在另一個節點上。 同樣其他控制器也建立了 pod-y 作為 pod-x 的替代品。

（注意：對於 StatefulSet 來說，pod-a（也稱為 pod-0）需要在替換 Pod 建立之前完全終止， 替代它的也稱為 pod-0，但是具有不同的 UID。除此之外，此示例也適用於 StatefulSet。）

當前叢集的狀態如下：

此時，如果一個急躁的叢集管理員試圖排空（drain）node-2 或 node-3，drain 命令將被阻塞， 因為對於 Deployment 來說只有 2 個可用的 Pod，並且它的 PDB 至少需要 2 個。 經過一段時間，pod-d 變得可用。

叢集狀態如下所示：

現在，叢集管理員試圖排空（drain）node-2。 drain 命令將嘗試按照某種順序驅逐兩個 Pod，假設先是 pod-b，然後是 pod-d。 命令成功驅逐 pod-b，但是當它嘗試驅逐 pod-d時將被拒絕，因為對於 Deployment 來說只剩一個可用的 Pod 了。

Deployment 建立 pod-b 的替代 Pod pod-e。 因為叢集中沒有足夠的資源來排程 pod-e，drain 命令再次阻塞。叢集最終將是下面這種狀態：

此時，叢集管理員需要增加一個節點到叢集中以繼續升級操作。

可以看到 Kubernetes 如何改變干擾發生的速率，根據：

應用程式需要多少個副本
優雅關閉應用例項需要多長時間
啟動應用新例項需要多長時間
控制器的型別
叢集的資源能力

分離叢集所有者和應用所有者角色

通常，將叢集管理者和應用所有者視為彼此瞭解有限的獨立角色是很有用的。這種責任分離在下面這些場景下是有意義的：

當有許多應用程式團隊共用一個 Kubernetes 叢集，並且有自然的專業角色
當第三方工具或服務用於叢集自動化管理

Pod 干擾預算通過在角色之間提供介面來支援這種分離。

如果你的組織中沒有這樣的責任分離，則可能不需要使用 Pod 干擾預算。

如何在叢集上執行干擾性操作

如果你是叢集管理員，並且需要對叢集中的所有節點執行干擾操作，例如節點或系統軟體升級，則可以使用以下選項

接受升級期間的停機時間。
故障轉移到另一個完整的副本叢集。
    沒有停機時間，但是對於重複的節點和人工協調成本可能是昂貴的。
編寫可容忍干擾的應用程式和使用 PDB。
    不停機。
    最小的資源重複。
    允許更多的叢集管理自動化。
    編寫可容忍干擾的應用程式是棘手的，但對於支援容忍自願干擾所做的工作，和支援自動擴縮和容忍非 自願干擾所做工作相比，有大量的重疊