kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #37087 from windsonsea/pfpyhf 

[zh] Sync job/pod-failure-policy.md
pull/37096/head
Kubernetes Prow Robot 2022-09-29 19:28:28 -07:00 committed by GitHub
parent 27a79cdebe 14d51fef39
commit c5ada83c9a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
content/zh-cn/docs/tasks/job/pod-failure-policy.md
View File

@ -55,11 +55,11 @@ You should already be familiar with the basic use of [Job](/docs/concepts/worklo
<!-- <!--
As the features are in Alpha, prepare the Kubernetes cluster with the two As the features are in Alpha, prepare the Kubernetes cluster with the two
[feature gates](/docs/reference/command-line-tools-reference/feature-gates/) [feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
enabled: `JobPodFailurePolicy` and `PodDisruptionsCondition`. enabled: `JobPodFailurePolicy` and `PodDisruptionConditions`.
--> -->
因为这些特性还处于 Alpha 阶段，所以在准备 Kubernetes 因为这些特性还处于 Alpha 阶段，所以在准备 Kubernetes
集群时要启用两个[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)： 集群时要启用两个[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)：
`JobPodFailurePolicy` 和 `PodDisruptionsCondition`。 `JobPodFailurePolicy` 和 `PodDisruptionConditions`。
{{< /note >}} {{< /note >}}
<!-- <!--
@ -237,7 +237,7 @@ The cluster automatically cleans up the Pods.
You could rely solely on the You could rely solely on the
[Pod backoff failure policy](/docs/concepts/workloads/controllers/job#pod-backoff-failure-policy), [Pod backoff failure policy](/docs/concepts/workloads/controllers/job#pod-backoff-failure-policy),
by specifying the Job's `.spec.backoffLimit` field. However, in many situations by specifying the Job's `.spec.backoffLimit` field. However, in many situations
it is problematic to find a balance between setting the a low value for `.spec.backoffLimit` it is problematic to find a balance between setting a low value for `.spec.backoffLimit`
to avoid unnecessary Pod retries, yet high enough to make sure the Job would to avoid unnecessary Pod retries, yet high enough to make sure the Job would
not be terminated by Pod disruptions. not be terminated by Pod disruptions.
--> -->