Kubernetes Pods Disruptions

此頁面介紹如何限制您的應用程式所經歷的同時中斷次數，從而在允許叢集管理員管理叢集節點的同時提高應用程式的可用性。

Voluntary and involuntary disruptions

Pod 不會自行消失，除非有人（例如某人或控制器）將其銷毀，或者發生了無法避免的硬體或系統軟體錯誤。

我們稱這些無法避免的情況為應用程式的非自願中斷，以下是一些例子：

• 支援節點的實體機器發生硬體故障
• 叢集管理員誤刪了虛擬機 (instance)
• 雲提供商或虛擬化管理程式故障使虛擬機消失
• 核心崩潰（kernel panic）
• 因叢集網路分區，節點從叢集中消失
• 因節點資源耗盡而逐出 Pod

除了資源耗盡的情況外，這些情況對大多數用戶來說都應該是熟悉的，它們並不是 Kubernetes 特有的。

我們將其他情況稱為自願中斷，這包括由應用程式所有者或叢集管理員發起的動作。典型的應用程式所有者行為包括：

• 刪除管理 Pod 的 deployment 或其他 controller
• 更新 deployment’s Pod template 導致重啟
• 直接刪除 Pod（例如誤操作）

叢集管理員的行為包括：

• 排空節點以進行維修或升級
• 從叢集中排空節點以縮小叢集規模（了解 Cluster Autoscaling）
• 將 Pod 從節點上移除以便讓其他 workload 適配該節點

這些動作可能由叢集管理員直接執行，或由叢集管理員運行的自動化工具執行，或由您的叢集託管提供商執行。

詢問您的叢集管理員，或查閱雲提供商或發行版的文檔，確定您的叢集是否啟用了任何自願中斷的來源。如果未啟用，您可以跳過創建 Pod 中斷預算（Pod Disruption Budgets）。

:::info

Note:

並非所有的自願中斷都受 Pod Disruption Budgets 的限制。例如，刪除 deployments 或 Pod 將繞過 Pod 中斷預算的限制。

:::

Dealing with disruptions

https://kubernetes.io/docs/concepts/workloads/pods/disruptions/