Skip to content

Commit ed214ed

Browse files
jzhupupjzhupup
committed
[zh-cn] sync1.25 job.md
Signed-off-by: jzhupup <[email protected]>
1 parent ec18dbf commit ed214ed

File tree

2 files changed

+187
-0
lines changed

2 files changed

+187
-0
lines changed

‎content/zh-cn/docs/concepts/workloads/controllers/job.md

Lines changed: 159 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1081,6 +1081,165 @@ mismatch.
10811081
设置 `manualSelector: true`
10821082
是在告诉系统你知道自己在干什么并要求系统允许这种不匹配的存在。
10831083

1084+
<!--
1085+
### Pod failure policy {#pod-failure-policy}
1086+
-->
1087+
### Pod 失效策略 {#pod-failure-policy}
1088+
1089+
{{< feature-state for_k8s_version="v1.25" state="alpha" >}}
1090+
1091+
{{< note >}}
1092+
<!--
1093+
You can only configure a Pod failure policy for a Job if you have the
1094+
`JobPodFailurePolicy` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
1095+
enabled in your cluster. Additionally, it is recommended
1096+
to enable the `PodDisruptionsCondition` feature gate in order to be able to detect and handle
1097+
Pod disruption conditions in the Pod failure policy (see also:
1098+
[Pod disruption conditions](/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions)). Both feature gates are
1099+
available in Kubernetes v1.25.
1100+
-->
1101+
只有你在集群中启用了
1102+
`JobPodFailurePolicy` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
1103+
你才能为某个 Job 配置 Pod 失效策略。
1104+
此外，建议启用 `PodDisruptionsCondition` 特性门控以便在 Pod 失效策略中检测和处理 Pod 干扰状况
1105+
（参考：[Pod 干扰状况](/zh-cn/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions)）。
1106+
这两个特性门控都是在 Kubernetes v1.25 中提供的。
1107+
{{< /note >}}
1108+
1109+
<!--
1110+
A Pod failure policy, defined with the `.spec.podFailurePolicy` field, enables
1111+
your cluster to handle Pod failures based on the container exit codes and the
1112+
Pod conditions.
1113+
-->
1114+
Pod 失效策略使用 `.spec.podFailurePolicy` 字段来定义，
1115+
它能让你的集群根据容器的退出码和 Pod 状况来处理 Pod 失效事件。
1116+
1117+
<!--
1118+
In some situations, you may want to have a better control when handling Pod
1119+
failures than the control provided by the [Pod backoff failure policy](#pod-backoff-failure-policy),
1120+
which is based on the Job's `.spec.backoffLimit`. These are some examples of use cases:
1121+
-->
1122+
在某些情况下，你可能希望更好地控制 Pod 失效的处理方式，
1123+
而不是仅限于 [Pod 回退失效策略](#pod-backoff-failure-policy)所提供的控制能力，
1124+
后者是基于 Job 的 `.spec.backoffLimit` 实现的。以下是一些使用场景：
1125+
<!--
1126+
* To optimize costs of running workloads by avoiding unnecessary Pod restarts,
1127+
you can terminate a Job as soon as one of its Pods fails with an exit code
1128+
indicating a software bug.
1129+
* To guarantee that your Job finishes even if there are disruptions, you can
1130+
ignore Pod failures caused by disruptions (such {{< glossary_tooltip text="preemption" term_id="preemption" >}},
1131+
{{< glossary_tooltip text="API-initiated eviction" term_id="api-eviction" >}}
1132+
or {{< glossary_tooltip text="taint" term_id="taint" >}}-based eviction) so
1133+
that they don't count towards the `.spec.backoffLimit` limit of retries.
1134+
-->
1135+
* 通过避免不必要的 Pod 重启来优化工作负载的运行成本，
1136+
你可以在某 Job 中一个 Pod 失效且其退出码表明存在软件错误时立即终止该 Job。
1137+
* 为了保证即使有干扰也能完成 Job，你可以忽略由干扰导致的 Pod 失效
1138+
（例如{{< glossary_tooltip text="抢占" term_id="preemption" >}}、
1139+
{{< glossary_tooltip text="通过 API 发起的驱逐" term_id="api-eviction" >}}
1140+
或基于{{< glossary_tooltip text="污点" term_id="taint" >}}的驱逐），
1141+
这样这些失效就不会被计入 `.spec.backoffLimit` 的重试限制中。
1142+
1143+
<!--
1144+
You can configure a Pod failure policy, in the `.spec.podFailurePolicy` field,
1145+
to meet the above use cases. This policy can handle Pod failures based on the
1146+
container exit codes and the Pod conditions.
1147+
-->
1148+
你可以在 `.spec.podFailurePolicy` 字段中配置 Pod 失效策略，以满足上述使用场景。
1149+
该策略可以根据容器退出码和 Pod 状况来处理 Pod 失效。
1150+
1151+
<!--
1152+
Here is a manifest for a Job that defines a `podFailurePolicy`:
1153+
-->
1154+
下面是一个定义了 `podFailurePolicy` 的 Job 的清单：
1155+
1156+
{{< codenew file="controllers/job-pod-failure-policy-example.yaml" >}}
1157+
1158+
<!--
1159+
In the example above, the first rule of the Pod failure policy specifies that
1160+
the Job should be marked failed if the `main` container fails with the 42 exit
1161+
code. The following are the rules for the `main` container specifically:
1162+
-->
1163+
在上面的示例中，Pod 失效策略的第一条规则规定如果 `main` 容器失败并且退出码为 42，
1164+
Job 将被标记为失败。以下是 `main` 容器的具体规则：
1165+
1166+
<!--
1167+
- an exit code of 0 means that the container succeeded
1168+
- an exit code of 42 means that the **entire Job** failed
1169+
- any other exit code represents that the container failed, and hence the entire
1170+
Pod. The Pod will be re-created if the total number of restarts is
1171+
below `backoffLimit`. If the `backoffLimit` is reached the **entire Job** failed.
1172+
-->
1173+
- 退出码 0 代表容器成功
1174+
- 退出码 42 代表 **整个 Job** 失败
1175+
- 所有其他退出码都代表容器失败，同时也代表着整个 Pod 失效。
1176+
如果重启总次数低于 `backoffLimit` 定义的次数，则会重新启动 Pod，
1177+
如果等于 `backoffLimit` 所设置的次数，则代表 **整个 Job** 失效。
1178+
1179+
{{< note >}}
1180+
<!--
1181+
Because the Pod template specifies a `restartPolicy: Never`,
1182+
the kubelet does not restart the `main` container in that particular Pod.
1183+
-->
1184+
因为 Pod 模板中指定了 `restartPolicy: Never`，
1185+
所以 kubelet 将不会重启 Pod 中的 `main` 容器。
1186+
{{< /note >}}
1187+
1188+
<!--
1189+
The second rule of the Pod failure policy, specifying the `Ignore` action for
1190+
failed Pods with condition `DisruptionTarget` excludes Pod disruptions from
1191+
being counted towards the `.spec.backoffLimit` limit of retries.
1192+
-->
1193+
Pod 失效策略的第二条规则，
1194+
指定对于状况为 `DisruptionTarget` 的失效 Pod 采取 `Ignore` 操作，
1195+
统计 `.spec.backoffLimit` 重试次数限制时不考虑 Pod 因干扰而发生的异常。
1196+
{{< note >}}
1197+
<!--
1198+
If the Job failed, either by the Pod failure policy or Pod backoff
1199+
failure policy, and the Job is running multiple Pods, Kubernetes terminates all
1200+
the Pods in that Job that are still Pending or Running.
1201+
-->
1202+
如果根据 Pod 失效策略或 Pod 回退失效策略判定 Pod 已经失效，
1203+
并且 Job 正在运行多个 Pod，Kubernetes 将终止该 Job 中仍处于 Pending 或 Running 的所有 Pod。
1204+
{{< /note >}}
1205+
1206+
<!--
1207+
These are some requirements and semantics of the API:
1208+
- if you want to use a `.spec.podFailurePolicy` field for a Job, you must
1209+
also define that Job's pod template with `.spec.restartPolicy` set to `Never`.
1210+
- the Pod failure policy rules you specify under `spec.podFailurePolicy.rules`
1211+
are evaluated in order. Once a rule matches a Pod failure, the remaining rules
1212+
are ignored. When no rule matches the Pod failure, the default
1213+
handling applies.
1214+
- you may want to restrict a rule to a specific container by specifing its name
1215+
in`spec.podFailurePolicy.rules[*].containerName`. When not specified the rule
1216+
applies to all containers. When specified, it should match one the container
1217+
or `initContainer` names in the Pod template.
1218+
- you may specify the action taken when a Pod failure policy is matched by
1219+
`spec.podFailurePolicy.rules[*].action`. Possible values are:
1220+
- `FailJob`: use to indicate that the Pod's job should be marked as Failed and
1221+
all running Pods should be terminated.
1222+
- `Ignore`: use to indicate that the counter towards the `.spec.backoffLimit`
1223+
should not be incremented and a replacement Pod should be created.
1224+
- `Count`: use to indicate that the Pod should be handled in the default way.
1225+
The counter towards the `.spec.backoffLimit` should be incremented.
1226+
-->
1227+
下面是此 API 的一些要求和语义：
1228+
- 如果你想在 Job 中使用 `.spec.podFailurePolicy` 字段，
1229+
你必须将 Job 的 Pod 模板中的 `.spec.restartPolicy` 设置为 `Never`。
1230+
- 在 `spec.podFailurePolicy.rules` 中设定的 Pod 失效策略规则将按序评估。
1231+
一旦某个规则与 Pod 失效策略匹配，其余规则将被忽略。
1232+
当没有规则匹配 Pod 失效策略时，将会采用默认的处理方式。
1233+
- 你可能希望在 `spec.podFailurePolicy.rules[*].containerName`
1234+
中通过指定的名称将规则限制到特定容器。
1235+
如果不设置，规则将适用于所有容器。
1236+
如果指定了容器名称，它应该匹配 Pod 模板中的一个普通容器或一个初始容器（Init Container）。
1237+
- 你可以在 `spec.podFailurePolicy.rules[*].action` 指定当 Pod 失效策略发生匹配时要采取的操作。
1238+
可能的值为：
1239+
- `FailJob`：表示 Pod 的任务应标记为 Failed，并且所有正在运行的 Pod 应被终止。
1240+
- `Ignore`：表示 `.spec.backoffLimit` 的计数器不应该增加，应该创建一个替换的 Pod。
1241+
- `Count`：表示 Pod 应该以默认方式处理。`.spec.backoffLimit` 的计数器应该增加。
1242+
10841243
<!--
10851244
### Job tracking with finalizers
10861245
-->

‎content/zh-cn/examples/controllers/job-pod-failure-policy-example.yaml

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
apiVersion: batch/v1
2+
kind: Job
3+
metadata:
4+
name: job-pod-failure-policy-example
5+
spec:
6+
completions: 12
7+
parallelism: 3
8+
template:
9+
spec:
10+
restartPolicy: Never
11+
containers:
12+
- name: main
13+
image: docker.io/library/bash:5
14+
command: ["bash"] # 模拟一个触发 FailJob 动作的错误的示例命令
15+
args:
16+
- -c
17+
- echo "Hello world!" && sleep 5 && exit 42
18+
backoffLimit: 6
19+
podFailurePolicy:
20+
rules:
21+
- action: FailJob
22+
onExitCodes:
23+
containerName: main # 可选
24+
operator: In # In 和 NotIn 二选一
25+
values: [42]
26+
- action: Ignore # Ignore、FailJob、Count 其中之一
27+
onPodConditions:
28+
- type: DisruptionTarget # 表示 Pod 失效

0 commit comments

Comments
 (0)