Skip to content

Commit 9a6e46c

Browse files
authored
[zh-cn] Sync disruptions.md (#40662)
Signed-off-by: Guangwen Feng <[email protected]>
1 parent 424f902 commit 9a6e46c

File tree

1 file changed

+19
-15
lines changed

1 file changed

+19
-15
lines changed

content/zh-cn/docs/concepts/workloads/pods/disruptions.md

Lines changed: 19 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -130,15 +130,15 @@ deleting deployments or pods bypasses Pod Disruption Budgets.
130130
131131
Here are some ways to mitigate involuntary disruptions:
132132
-->
133-
## 处理干扰
133+
## 处理干扰 {#dealing-with-disruptions}
134134

135135
以下是减轻非自愿干扰的一些方法:
136136

137137
<!--
138138
- Ensure your pod [requests the resources](/docs/tasks/configure-pod-container/assign-memory-resource) it needs.
139139
- Replicate your application if you need higher availability. (Learn about running replicated
140-
[stateless](/docs/tasks/run-application/run-stateless-application-deployment/)
141-
and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.)
140+
[stateless](/docs/tasks/run-application/run-stateless-application-deployment/)
141+
and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) applications.)
142142
- For even higher availability when running replicated applications,
143143
spread applications across racks (using
144144
[anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity))
@@ -266,6 +266,18 @@ during application updates is configured in the spec for the specific workload r
266266
在进行滚动升级时不受 PDB 的限制。
267267
应用更新期间的故障处理方式是在对应的工作负载资源的 `spec` 中配置的。
268268

269+
<!--
270+
It is recommended to set `AlwaysAllow` [Unhealthy Pod Eviction Policy](/docs/tasks/run-application/configure-pdb/#unhealthy-pod-eviction-policy)
271+
to your PodDisruptionBudgets to support eviction of misbehaving applications during a node drain.
272+
The default behavior is to wait for the application pods to become [healthy](/docs/tasks/run-application/configure-pdb/#healthiness-of-a-pod)
273+
before the drain can proceed.
274+
-->
275+
建议在你的 PodDisruptionBudget 中将
276+
[不健康 Pod 驱逐策略](/zh-cn/docs/tasks/run-application/configure-pdb/#unhealthy-pod-eviction-policy)
277+
设置为 `AlwaysAllow` 以支持在节点腾空期间驱逐行为不当的应用程序。
278+
默认行为是等待应用程序 Pod 变得
279+
[健康](/zh-cn/docs/tasks/run-application/configure-pdb/#healthiness-of-a-pod),然后才能继续执行腾空。
280+
269281
<!--
270282
When a pod is evicted using the eviction API, it is gracefully
271283
[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), honoring the
@@ -434,14 +446,6 @@ can happen, according to:
434446

435447
{{< feature-state for_k8s_version="v1.26" state="beta" >}}
436448

437-
{{< note >}}
438-
<!--
439-
If you are using an older version of Kubernetes than {{< skew currentVersion >}}
440-
please refer to the corresponding version of the documentation.
441-
-->
442-
如果你正使用的 Kubernetes 版本早于 {{< skew currentVersion >}},请参阅对应版本的文档。
443-
{{< /note >}}
444-
445449
{{< note >}}
446450
<!--
447451
In order to use this behavior, you must have the `PodDisruptionConditions`
@@ -464,10 +468,10 @@ indicates one of the following reasons for the Pod termination:
464468
状况中的 `reason` 字段进一步给出 Pod 终止的原因,如下:
465469

466470
<!--
467-
`PreemptionByKubeScheduler`
471+
`PreemptionByScheduler`
468472
: Pod is due to be {{<glossary_tooltip term_id="preemption" text="preempted">}} by a scheduler in order to accommodate a new Pod with a higher priority. For more information, see [Pod priority preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/).
469473
-->
470-
`PreemptionByKubeScheduler`
474+
`PreemptionByScheduler`
471475
: Pod 将被调度器{{<glossary_tooltip term_id="preemption" text="抢占">}},
472476
目的是接受优先级更高的新 Pod。
473477
要了解更多的相关信息,请参阅 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
@@ -543,7 +547,7 @@ and Application Owner as separate roles with limited knowledge
543547
of each other. This separation of responsibilities
544548
may make sense in these scenarios:
545549
-->
546-
## 分离集群所有者和应用所有者角色
550+
## 分离集群所有者和应用所有者角色 {#separating-cluster-owner-and-application-owner-roles}
547551

548552
通常,将集群管理者和应用所有者视为彼此了解有限的独立角色是很有用的。这种责任分离在下面这些场景下是有意义的:
549553

@@ -573,7 +577,7 @@ you may not need to use Pod Disruption Budgets.
573577
If you are a Cluster Administrator, and you need to perform a disruptive action on all
574578
the nodes in your cluster, such as a node or system software upgrade, here are some options:
575579
-->
576-
## 如何在集群上执行干扰性操作
580+
## 如何在集群上执行干扰性操作 {#how-to-perform-disruptive-actions-on-your-cluster}
577581

578582
如果你是集群管理员,并且需要对集群中的所有节点执行干扰操作,例如节点或系统软件升级,则可以使用以下选项
579583

0 commit comments

Comments
 (0)