[zh-cn] sync tasks/job/* configmap-secret/*

Signed-off-by: xin.li <[email protected]>

Author: my-git9

content/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file.md

@@ -147,7 +147,7 @@ parts of that configuration file during your deployment process.
 <!--
 For example, if your application uses the following configuration file:
 -->
-例如，如果你的应用程序使用以下配置文件:
+例如，如果你的应用程序使用以下配置文件：
 
 ```yaml
 apiUrl: "https://my.api.com/api/v1"
@@ -158,7 +158,7 @@ password: "<password>"
 <!--
 You could store this in a Secret using the following definition:
 -->
-你可以使用以下定义将其存储在 Secret 中:
+你可以使用以下定义将其存储在 Secret 中：
 
 ```yaml
 apiVersion: v1
@@ -173,6 +173,13 @@ stringData:
     password: <password>
 ```
 
+{{< note >}}
+<!--
+The `stringData` field for a Secret does not work well with server-side apply.
+-->
+Secret 的 `stringData` 字段不能很好地与服务器端应用配合使用。
+{{< /note >}}
+
 <!-- 
 When you retrieve the Secret data, the command returns the encoded values,
 and not the plaintext values you provided in `stringData`.
@@ -231,6 +238,13 @@ stringData:
   username: administrator
 ```
 
+{{< note >}}
+<!--
+The `stringData` field for a Secret does not work well with server-side apply.
+-->
+Secret 的 `stringData` 字段不能很好地与服务器端应用配合使用。
+{{< /note >}}
+
 <!--
 The `Secret` object is created as follows:
 -->

content/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize.md

@@ -57,9 +57,9 @@ secretGenerator:
 {{% tab name="文件" %}}
 
 <!--
-1.  Store the credentials in files with the values encoded in base64:
+1.  Store the credentials in files. The filenames are the keys of the secret:
 -->
-1. 用 base64 编码的值存储凭据到文件中：
+1. 将凭据存储在文件中。文件名是 Secret 的 key 值：
 
    ```shell
    echo -n 'admin' > ./username.txt

content/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md

@@ -1320,21 +1320,21 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
 -->
 验证规则例子：
 
-| 规则                                                                             | 目的                                                                             |
-| ----------------                                                                 | ------------                                                                     |
-| `self.minReplicas <= self.replicas && self.replicas <= self.maxReplicas`         | 验证定义副本数的三个字段大小顺序是否正确                                             |
-| `'Available' in self.stateCounts`                                                | 验证 map 中是否存在键名为 `Available`的条目                                   |
-| `(size(self.list1) == 0) != (size(self.list2) == 0)`                             | 验证两个 list 之一是非空的，但不是二者都非空                                   |
-| <code>!('MY_KEY' in self.map1) &#124;&#124; self['MY_KEY'].matches('^[a-zA-Z]*$')</code>               | 如果某个特定的 key 在 map 中，验证 map 中这个 key 的 value |
-| `self.envars.filter(e, e.name = 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$')` | 验证一个 listMap 中主键 'name' 为 'MY_ENV' 'value' 的表项，检查其取值 'value'             |
-| `has(self.expired) && self.created + self.ttl < self.expired`    | 验证 'Expired' 日期是否晚于 'Create' 日期加上 'ttl' 持续时间                   |
-| `self.health.startsWith('ok')`                                                   | 验证 'health' 字符串字段有前缀 'ok'             |
-| `self.widgets.exists(w, w.key == 'x' && w.foo < 10)`                             | 验证 key 为 'x' 的 listMap 项的 'foo' 属性是否小于 10                             |
-| `type(self) == string ? self == '100%' : self == 1000`                           | 在 int 型和 string 型两种情况下验证 int-or-string 字段                           |
-| `self.metadata.name.startsWith(self.prefix)`                                     | 验证对象的名称是否具有另一个字段值的前缀                                         |
-| `self.set1.all(e, !(e in self.set2))`                                            | 验证两个 listSet 是否不相交                                                      |
-| `size(self.names) == size(self.details) && self.names.all(n, n in self.details)` | 验证 'details' map 是由 'names' listSet 的项目所决定的。                         |
-| `size(self.clusters.filter(c, c.name == self.primary)) == 1`                     | 验证 'primary' 属性仅在 'clusters' listMap 中出现一次且只有一次           |
+| 规则                                                                                      | 目的                                                                              |
+| ----------------                                                                         | ------------                                                                      |
+| `self.minReplicas <= self.replicas && self.replicas <= self.maxReplicas`                 | 验证定义副本数的三个字段大小顺序是否正确                                                 |
+| `'Available' in self.stateCounts`                                                        | 验证映射中是否存在键名为 `Available`的条目                                             |
+| `(size(self.list1) == 0) != (size(self.list2) == 0)`                                     | 检查两个列表之一是非空的，但不是二者都非空                                               |
+| <code>!('MY_KEY' in self.map1) &#124;&#124; self['MY_KEY'].matches('^[a-zA-Z]*$')</code> | 如果某个特定的键在映射中，验证映射中对应键的取值                                           |
+| `self.envars.filter(e, e.name = 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$')`         | 验证一个 listMap 中主键 'name' 为 'MY_ENV' 的表项的取值                                 |
+| `has(self.expired) && self.created + self.ttl < self.expired`                            | 验证 'Expired' 日期是否晚于 'Create' 日期加上 'ttl' 时长                                |
+| `self.health.startsWith('ok')`                                                           | 验证 'health' 字符串字段有前缀 'ok'                                                   |
+| `self.widgets.exists(w, w.key == 'x' && w.foo < 10)`                                     | 验证键为 'x' 的 listMap 项的 'foo' 属性是否小于 10                                     |
+| `type(self) == string ? self == '100%' : self == 1000`                                   | 在 int 型和 string 型两种情况下验证 int-or-string 字段                                 |
+| `self.metadata.name.startsWith(self.prefix)`                                             | 验证对象的名称是否以另一个字段值为前缀                                                   |
+| `self.set1.all(e, !(e in self.set2))`                                                    | 验证两个 listSet 是否不相交                                                           |
+| `size(self.names) == size(self.details) && self.names.all(n, n in self.details)`         | 验证 'details' 映射中的 'names' 来自于 listSet                                        |
+| `size(self.clusters.filter(c, c.name == self.primary)) == 1`                             | 验证 'primary' 属性在 'clusters' listMap 中出现一次且只有一次                           |
 
 参考：[CEL 中支持的求值](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#evaluation)
 

content/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs.md

@@ -38,7 +38,7 @@ Here is a manifest for a CronJob that runs a simple demonstration task every min
 CronJob 需要一个配置文件。
 以下是针对一个 CronJob 的清单，该 CronJob 每分钟运行一个简单的演示任务：
 
-{{% code file="application/job/cronjob.yaml" %}}
+{{% code_sample file="application/job/cronjob.yaml" %}}
 
 <!--
 Run the example CronJob by using this command:

content/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue.md

@@ -212,11 +212,11 @@ root@temp-loe07:/# export BROKER_URL=amqp://guest:guest@rabbitmq-service:5672
 
 root@temp-loe07:/# /usr/bin/amqp-declare-queue --url=$BROKER_URL -q foo -d foo
 
-# 向它推送一条消息:
+# 向它推送一条消息：
 
 root@temp-loe07:/# /usr/bin/amqp-publish --url=$BROKER_URL -r foo -p -b Hello
 
-# 然后取回它.
+# 然后取回它：
 
 root@temp-loe07:/# /usr/bin/amqp-consume --url=$BROKER_URL -q foo -c 1 cat && echo
 Hello
@@ -225,7 +225,8 @@ root@temp-loe07:/#
 
 <!--
 In the last command, the `amqp-consume` tool takes one message (`-c 1`)
-from the queue, and passes that message to the standard input of an arbitrary command.  In this case, the program `cat` prints out the characters read from standard input, and the echo adds a carriage
+from the queue, and passes that message to the standard input of an arbitrary command.
+In this case, the program `cat` prints out the characters read from standard input, and the echo adds a carriage
 return so the example is readable.
 -->
 
@@ -302,12 +303,12 @@ example program:
 我们将用 `amqp-consume` 实用程序从队列中读取消息并运行实际的程序。
 这里给出一个非常简单的示例程序：
 
-{{% code language="python" file="application/job/rabbitmq/worker.py" %}}
+{{% code_sample language="python" file="application/job/rabbitmq/worker.py" %}}
 
 <!--
 Give the script execution permission:
 -->
-赋予脚本执行权限:
+赋予脚本执行权限：
 
 ```shell
 chmod +x worker.py
@@ -371,7 +372,7 @@ image to match the name you used, and call it `./job.yaml`.
 
 这里给出一个 Job 定义 YAML 文件。你将需要拷贝一份 Job 并编辑该镜像以匹配你使用的名称，保存为 `./job.yaml`。
 
-{{% code file="application/job/rabbitmq/job.yaml" %}}
+{{% code_sample file="application/job/rabbitmq/job.yaml" %}}
 
 <!--
 In this example, each pod works on one item from the queue and then exits.
@@ -520,4 +521,3 @@ Job 也会显示为未完成。Job 将创建 Pod 并阻塞等待消息输入。
 当发生下面两种情况时，即使队列中所有的消息都处理完了，Job 也不会显示为完成状态：
 * 在 amqp-consume 命令拿到消息和容器成功退出之间的时间段内，执行杀死容器操作；
 * 在 kubelet 向 api-server 传回 Pod 成功运行之前，发生节点崩溃。
-

content/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue.md

@@ -106,7 +106,7 @@ Start a temporary interactive pod for running the Redis CLI.
 -->
 ## 使用任务填充队列
 
-现在，让我们往队列里添加一些 “任务”。在这个例子中，我们的任务是一些将被打印出来的字符串。
+现在，让我们往队列里添加一些“任务”。在这个例子中，我们的任务是一些将被打印出来的字符串。
 
 启动一个临时的可交互的 Pod 用于运行 Redis 命令行界面。
 
@@ -192,9 +192,9 @@ called rediswq.py ([Download](/examples/application/job/redis/rediswq.py)).
 The "worker" program in each Pod of the Job uses the work queue
 client library to get work.  Here it is:
 -->
-Job 中每个 Pod 内的 “工作程序” 使用工作队列客户端库获取工作。具体如下：
+Job 中每个 Pod 内的“工作程序” 使用工作队列客户端库获取工作。具体如下：
 
-{{% code language="python" file="application/job/redis/worker.py" %}}
+{{% code_sample language="python" file="application/job/redis/worker.py" %}}
 
 <!--
 You could also download [`worker.py`](/examples/application/job/redis/worker.py),
@@ -241,7 +241,7 @@ your app image with your project ID, and push to GCR. Replace
 `<project>` with your project ID.
 -->
 如果你使用的是 [Google Container Registry](https://cloud.google.com/tools/container-registry/)，
-请先用你的 project ID 给你的镜像打上标签，然后 push 到 GCR 。请将 `<project>` 替换为你自己的 project ID。
+请先用你的 project ID 给你的镜像打上标签，然后 push 到 GCR。请将 `<project>` 替换为你自己的 project ID。
 
 ```shell
 docker tag job-wq-2 gcr.io/<project>/job-wq-2
@@ -257,7 +257,7 @@ Here is the job definition:
 
 这是 Job 定义：
 
-{{% code file="application/job/redis/job.yaml" %}}
+{{% code_sample file="application/job/redis/job.yaml" %}}
 
 <!--
 Be sure to edit the job template to

content/zh-cn/docs/tasks/job/indexed-parallel-processing-static.md

@@ -89,8 +89,7 @@ To access the work item from the worker program, you have a few options:
 要从工作程序访问工作项，你有几个选项：
 
 1. 读取 `JOB_COMPLETION_INDEX` 环境变量。Job
-   {{< glossary_tooltip text="控制器" term_id="controller" >}}
-   自动将此变量链接到包含完成索引的注解。
+   {{< glossary_tooltip text="控制器" term_id="controller" >}}自动将此变量链接到包含完成索引的注解。
 2. 读取包含完整索引的文件。
 3. 假设你无法修改程序，你可以使用脚本包装它，
    该脚本使用上述任意方法读取索引并将其转换为程序可以用作输入的内容。
@@ -138,7 +137,7 @@ Here is a sample Job manifest that uses `Indexed` completion mode:
 
 这是一个使用 `Indexed` 完成模式的示例 Job 清单：
 
-{{% code language="yaml" file="application/job/indexed-job.yaml" %}}
+{{% code_sample language="yaml" file="application/job/indexed-job.yaml" %}}
 
 <!-- 
 In the example above, you use the builtin `JOB_COMPLETION_INDEX` environment
@@ -169,7 +168,7 @@ like shown in the following example:
 [使用 Downward API 将注解值作为卷文件传递](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields)，
 如下例所示：
 
-{{% code language="yaml" file="application/job/indexed-job-vol.yaml" %}}
+{{% code_sample language="yaml" file="application/job/indexed-job-vol.yaml" %}}
 
 <!-- 
 ## Running the Job
@@ -186,9 +185,12 @@ kubectl apply -f https://kubernetes.io/examples/application/job/indexed-job.yaml
 ```
 
 <!-- 
-When you create this Job, the control plane creates a series of Pods, one for each index you specified. The value of `.spec.parallelism` determines how many can run at once whereas `.spec.completions` determines how many Pods the Job creates in total.
+When you create this Job, the control plane creates a series of Pods, one for each index you specified.
+The value of `.spec.parallelism` determines how many can run at once whereas `.spec.completions`
+determines how many Pods the Job creates in total.
 
-Because `.spec.parallelism` is less than `.spec.completions`, the control plane waits for some of the first Pods to complete before starting more of them.
+Because `.spec.parallelism` is less than `.spec.completions`, the control plane waits for some
+of the first Pods to complete before starting more of them.
 -->
 当你创建此 Job 时，控制平面会创建一系列 Pod，你指定的每个索引都会运行一个 Pod。
 `.spec.parallelism` 的值决定了一次可以运行多少个 Pod，
@@ -294,4 +296,4 @@ The output is similar to:
 
 ```
 xuq
-```
+```

content/zh-cn/docs/tasks/job/job-with-pod-to-pod-communication.md

@@ -73,7 +73,7 @@ To enable pod-to-pod communication using pod hostnames in a Job, you must do the
 要在某 Job 中启用使用 Pod 主机名的 Pod 间通信，你必须执行以下操作：
 
 <!--
-1. Set up a [headless service](/docs/concepts/services-networking/service/#headless-services)
+1. Set up a [headless Service](/docs/concepts/services-networking/service/#headless-services)
 with a valid label selector for the pods created by your Job. The headless service must be in the same namespace as 
 the Job. One easy way to do this is to use the `job-name: <your-job-name>` selector, since the `job-name` label will be automatically added by Kubernetes. This configuration will trigger the DNS system to create records of the hostnames of 
 the pods running your Job.

content/zh-cn/docs/tasks/job/parallel-processing-expansion.md

@@ -28,7 +28,7 @@ this pattern fits more realistic use cases.
 本任务展示基于一个公共的模板运行多个{{< glossary_tooltip text="Jobs" term_id="job" >}}。
 你可以用这种方法来并行执行批处理任务。
 
-在本任务示例中，只有三个工作条目：_apple_、_banana_ 和 _cherry_。
+在本任务示例中，只有三个工作条目：**apple**、**banana** 和 **cherry**。
 示例任务处理每个条目时打印一个字符串之后结束。
 
 参考[在真实负载中使用 Job](#using-jobs-in-real-workloads)了解更适用于真实使用场景的模式。
@@ -76,7 +76,7 @@ First, download the following template of a job to a file called `job-tmpl.yaml`
 -->
 首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中。
 
-{{% code file="application/job/job-tmpl.yaml" %}}
+{{% code_sample file="application/job/job-tmpl.yaml" %}}
 
 ```shell
  # 使用 curl 下载 job-tmpl.yaml
@@ -101,8 +101,8 @@ variable, writing into a temporary directory named `jobs`. Run this now:
 -->
 ### 基于模板创建清单
 
-下面的 Shell 代码片段使用 `sed` 将字符串 `$ITEM` 替换为循环变量，并将结果
-写入到一个名为 `jobs` 的临时目录。
+下面的 Shell 代码片段使用 `sed` 将字符串 `$ITEM` 替换为循环变量，
+并将结果写入到一个名为 `jobs` 的临时目录。
 
 ```shell
 # 展开模板文件到多个文件中，每个文件对应一个要处理的条目
@@ -377,7 +377,7 @@ Kubernetes 接收清单文件并执行你所创建的 Job。
 kubectl delete job -l jobgroup=jobexample
 ```
 -->
-### 清理 {#cleanup-2}
+### 清理   {#cleanup-2}
 
 ```shell
 # 删除所创建的 Job
@@ -437,7 +437,7 @@ you can check on all Pods for these templated Jobs with a single command.
 {{< glossary_tooltip text="标签" term_id="label" >}}，以便能够将一个 Job
 的 Pod 与另一个 Job 的 Pod 区分开来。
 
-在本例中，每个 Job 及其 Pod 模板有一个标签: `jobgroup=jobexample`。
+在本例中，每个 Job 及其 Pod 模板有一个标签：`jobgroup=jobexample`。
 
 Kubernetes 自身对标签名 `jobgroup` 没有什么要求。
 为创建自同一模板的所有 Job 使用同一标签使得我们可以方便地同时操作组中的所有作业。

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

@@ -72,7 +72,7 @@ Pod 失效策略来避免不必要的 Pod 重启。
 
 首先，基于配置创建一个 Job：
 
-{{% code file="/controllers/job-pod-failure-policy-failjob.yaml" %}}
+{{% code_sample file="/controllers/job-pod-failure-policy-failjob.yaml" %}}
 
 <!--
 by running:
@@ -150,7 +150,7 @@ node while the Pod is running on it (within 90s since the Pod is scheduled).
 -->
 1. 基于配置创建 Job：
 
-   {{% code file="/controllers/job-pod-failure-policy-ignore.yaml" %}}
+   {{% code_sample file="/controllers/job-pod-failure-policy-ignore.yaml" %}}
 
    <!--
    by running:
@@ -250,7 +250,7 @@ deleted pods, in the `Pending` phase, to a terminal phase
 -->
 1. 首先基于配置创建一个 Job：
 
-   {{% code file="/controllers/job-pod-failure-policy-config-issue.yaml" %}}
+   {{% code_sample file="/controllers/job-pod-failure-policy-config-issue.yaml" %}}
 
    <!--
    by running: