@@ -130,15 +130,15 @@ deleting deployments or pods bypasses Pod Disruption Budgets.
130
130
131
131
Here are some ways to mitigate involuntary disruptions:
132
132
-->
133
- ## 处理干扰
133
+ ## 处理干扰 {#dealing-with-disruptions}
134
134
135
135
以下是减轻非自愿干扰的一些方法:
136
136
137
137
<!--
138
138
- Ensure your pod [requests the resources](/docs/tasks/configure-pod-container/assign-memory-resource) it needs.
139
139
- 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.)
142
142
- For even higher availability when running replicated applications,
143
143
spread applications across racks (using
144
144
[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
266
266
在进行滚动升级时不受 PDB 的限制。
267
267
应用更新期间的故障处理方式是在对应的工作负载资源的 ` spec ` 中配置的。
268
268
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
+
269
281
<!--
270
282
When a pod is evicted using the eviction API, it is gracefully
271
283
[terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination), honoring the
@@ -434,14 +446,6 @@ can happen, according to:
434
446
435
447
{{< feature-state for_k8s_version="v1.26" state="beta" >}}
436
448
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
-
445
449
{{< note >}}
446
450
<!--
447
451
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:
464
468
状况中的 ` reason ` 字段进一步给出 Pod 终止的原因,如下:
465
469
466
470
<!--
467
- `PreemptionByKubeScheduler `
471
+ `PreemptionByScheduler `
468
472
: 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/).
469
473
-->
470
- ` PreemptionByKubeScheduler `
474
+ ` PreemptionByScheduler `
471
475
: Pod 将被调度器{{<glossary_tooltip term_id="preemption" text="抢占">}},
472
476
目的是接受优先级更高的新 Pod。
473
477
要了解更多的相关信息,请参阅 [ Pod 优先级和抢占] ( /zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/ ) 。
@@ -543,7 +547,7 @@ and Application Owner as separate roles with limited knowledge
543
547
of each other. This separation of responsibilities
544
548
may make sense in these scenarios:
545
549
-->
546
- ## 分离集群所有者和应用所有者角色
550
+ ## 分离集群所有者和应用所有者角色 {#separating-cluster-owner-and-application-owner-roles}
547
551
548
552
通常,将集群管理者和应用所有者视为彼此了解有限的独立角色是很有用的。这种责任分离在下面这些场景下是有意义的:
549
553
@@ -573,7 +577,7 @@ you may not need to use Pod Disruption Budgets.
573
577
If you are a Cluster Administrator, and you need to perform a disruptive action on all
574
578
the nodes in your cluster, such as a node or system software upgrade, here are some options:
575
579
-->
576
- ## 如何在集群上执行干扰性操作
580
+ ## 如何在集群上执行干扰性操作 {#how-to-perform-disruptive-actions-on-your-cluster}
577
581
578
582
如果你是集群管理员,并且需要对集群中的所有节点执行干扰操作,例如节点或系统软件升级,则可以使用以下选项
579
583
0 commit comments