diff --git a/content/zh-cn/docs/concepts/workloads/pods/disruptions.md b/content/zh-cn/docs/concepts/workloads/pods/disruptions.md index be0a46dc19..1af0d70bf3 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh-cn/docs/concepts/workloads/pods/disruptions.md @@ -130,15 +130,15 @@ deleting deployments or pods bypasses Pod Disruption Budgets. Here are some ways to mitigate involuntary disruptions: --> -## 处理干扰 +## 处理干扰 {#dealing-with-disruptions} 以下是减轻非自愿干扰的一些方法: +建议在你的 PodDisruptionBudget 中将 +[不健康 Pod 驱逐策略](/zh-cn/docs/tasks/run-application/configure-pdb/#unhealthy-pod-eviction-policy) +设置为 `AlwaysAllow` 以支持在节点腾空期间驱逐行为不当的应用程序。 +默认行为是等待应用程序 Pod 变得 +[健康](/zh-cn/docs/tasks/run-application/configure-pdb/#healthiness-of-a-pod),然后才能继续执行腾空。 + -如果你正使用的 Kubernetes 版本早于 {{< skew currentVersion >}},请参阅对应版本的文档。 -{{< /note >}} - {{< note >}} -`PreemptionByKubeScheduler` +`PreemptionByScheduler` : Pod 将被调度器{{}}, 目的是接受优先级更高的新 Pod。 要了解更多的相关信息,请参阅 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 @@ -543,7 +547,7 @@ and Application Owner as separate roles with limited knowledge of each other. This separation of responsibilities may make sense in these scenarios: --> -## 分离集群所有者和应用所有者角色 +## 分离集群所有者和应用所有者角色 {#separating-cluster-owner-and-application-owner-roles} 通常,将集群管理者和应用所有者视为彼此了解有限的独立角色是很有用的。这种责任分离在下面这些场景下是有意义的: @@ -573,7 +577,7 @@ you may not need to use Pod Disruption Budgets. If you are a Cluster Administrator, and you need to perform a disruptive action on all the nodes in your cluster, such as a node or system software upgrade, here are some options: --> -## 如何在集群上执行干扰性操作 +## 如何在集群上执行干扰性操作 {#how-to-perform-disruptive-actions-on-your-cluster} 如果你是集群管理员,并且需要对集群中的所有节点执行干扰操作,例如节点或系统软件升级,则可以使用以下选项