[zh] Sync changes to workload controllers

Author: tengqm

content/zh/docs/concepts/workloads/controllers/cron-jobs.md

@@ -154,6 +154,14 @@ at least once.
 如果 `startingDeadlineSeconds` 设置为很大的数值或未设置（默认），并且
 `concurrencyPolicy` 设置为 `Allow`，则作业将始终至少运行一次。
 
+{{< caution >}}
+<!--
+If `startingDeadlineSeconds` is set to a value less than 10 seconds, the CronJob may not be scheduled. This is because the CronJob controller checks things every 10 seconds.
+-->
+如果 `startingDeadlineSeconds` 的设置值低于 10 秒钟，CronJob 可能无法被调度。
+这是因为 CronJob 控制器每 10 秒钟执行一次检查。
+{{< /caution >}}
+
 <!--
 For every CronJob, the CronJob {{< glossary_tooltip term_id="controller" >}} checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error
 -->

content/zh/docs/concepts/workloads/controllers/daemonset.md

@@ -278,8 +278,8 @@ the related features.
 | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
 | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | 当出现类似网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 |
 | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | 当出现类似于网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 |
-| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | |
-| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | |
+| `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | DaemonSet Pod 被默认调度器调度时能够容忍磁盘压力属性。 |
+| `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | DaemonSet Pod 被默认调度器调度时能够容忍内存压力属性。 |
 | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSet Pod 能够容忍默认调度器所设置的 `unschedulable` 属性.  |
 | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | DaemonSet 在使用宿主网络时，能够容忍默认调度器所设置的 `network-unavailable` 属性。 |
 

content/zh/docs/concepts/workloads/controllers/deployment.md

@@ -102,24 +102,25 @@ In this example:
 
 <!--
 * The `selector` field defines how the Deployment finds which Pods to manage.
-  In this case, you simply select a label that is defined in the Pod template (`app: nginx`).
+  In this case, you select a label that is defined in the Pod template (`app: nginx`).
   However, more sophisticated selection rules are possible,
   as long as the Pod template itself satisfies the rule.
 -->
 * `selector` 字段定义 Deployment 如何查找要管理的 Pods。
-  在这里，你只需选择在 Pod 模板中定义的标签（`app: nginx`）。
+  在这里，你选择在 Pod 模板中定义的标签（`app: nginx`）。
   不过，更复杂的选择规则是也可能的，只要 Pod 模板本身满足所给规则即可。
 
+  {{< note >}}
   <!--
-  The `matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map
-  is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In",
-  and the values array contains only "value".
+  The `spec.selector.matchLabels` field is a map of {key,value} pairs.
+  A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`,
+  whose `key` field is "key", the `operator` is "In", and the `values` array contains only "value".
   All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
   -->
-  {{< note >}}
-  `matchLabels` 字段是 `{key,value}` 偶对的映射。在 `matchLabels` 映射中的单个 `{key,value}`
-  映射等效于 `matchExpressions` 中的一个元素，即其 `key` 字段是 “key”，operator 为 “In”，`value`
-  数组仅包含 “value”。在 `matchLabels` 和 `matchExpressions` 中给出的所有条件都必须满足才能匹配。
+  `spec.selector.matchLabels` 字段是 `{key,value}` 键值对映射。
+  在 `matchLabels` 映射中的每个 `{key,value}` 映射等效于 `matchExpressions` 中的一个元素，
+  即其 `key` 字段是 “key”，`operator` 为 “In”，`values` 数组仅包含 “value”。
+  在 `matchLabels` 和 `matchExpressions` 中给出的所有条件都必须满足才能匹配。
   {{< /note >}}
 
 <!--
@@ -347,15 +348,15 @@ is changed, for example if the labels or container images of the template are up
       deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
    ```
    <!--
-   or simply use the following command:
+   or use the following command:
    -->
    或者使用下面的命令：
 
    ```shell
    kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
    ```
 
-   <!-- The output is similar to this: -->
+   <!-- The output is similar to: -->
    输出类似于：
 
    ```
@@ -429,7 +430,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
   kubectl get rs
   ```
 
-  <!-- The output is similar to this: -->
+  <!-- The output is similar to: -->
   输出类似于：
 
   ```
@@ -1179,7 +1180,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
 这样做使得你能够在暂停和恢复执行之间应用多个修补程序，而不会触发不必要的上线操作。
 
 <!--
-* For example, with a Deployment that was just created:
+* For example, with a Deployment that was created:
   Get the Deployment details:
 -->
 * 例如，对于一个刚刚创建的 Deployment：

content/zh/docs/concepts/workloads/controllers/job.md

@@ -139,7 +139,7 @@ pi-5rwd7
 
 <!--
 Here, the selector is the same as the selector for the Job.  The `-output=jsonpath` option specifies an expression
-that just gets the name from each Pod in the returned list.
+with the name from each Pod in the returned list.
 
 View the standard output of one of the pods:
 -->

content/zh/docs/concepts/workloads/controllers/replicaset.md

@@ -345,7 +345,7 @@ pod2             1/1     Running   0          36s
 ## Writing a ReplicaSet Spec
 
 As with all other Kubernetes API objects, a ReplicaSet needs the `apiVersion`, `kind`, and `metadata` fields.
-For ReplicaSets, the kind is always just ReplicaSet.
+For ReplicaSets, the `kind` is always a ReplicaSet.
 In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated.
 Refer to the first lines of the `frontend.yaml` example for guidance.
 
@@ -357,7 +357,7 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib
 ## 编写 ReplicaSet 的 spec
 
 与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。
-对于 ReplicaSets 而言，其 kind 始终是 ReplicaSet。
+对于 ReplicaSets 而言，其 `kind` 始终是 ReplicaSet。
 在 Kubernetes 1.9 中，ReplicaSet 上的 API 版本 `apps/v1` 是其当前版本，且被
 默认启用。API 版本 `apps/v1beta2` 已被废弃。
 参考 `frontend.yaml` 示例的第一行。
@@ -375,7 +375,7 @@ The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-temp
 required to have labels in place. In our `frontend.yaml` example we had one label: `tier: frontend`.
 Be careful not to overlap with the selectors of other controllers, lest they try to adopt this Pod.
 
-For the template's [restart policy](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy) field,
+For the template's [restart policy](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) field,
 `.spec.template.spec.restartPolicy`, the only allowed value is `Always`, which is the default.
 -->
 ### Pod 模版

content/zh/docs/concepts/workloads/controllers/replicationcontroller.md

@@ -174,10 +174,10 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 <!--
 Here, the selector is the same as the selector for the ReplicationController (seen in the
 `kubectl describe` output), and in a different form in `replication.yaml`.  The `--output=jsonpath` option
-specifies an expression that just gets the name from each pod in the returned list.
+specifies an expression with the name from each pod in the returned list.
 -->
 这里，选择算符与 ReplicationController 的选择算符相同（参见 `kubectl describe` 输出），并以不同的形式出现在 `replication.yaml` 中。
-`--output=jsonpath` 选项指定了一个表达式，只从返回列表中的每个 Pod 中获取名称。
+`--output=jsonpath` 选项指定了一个表达式，仅从返回列表中的每个 Pod 中获取名称。
 
 <!--
 ## Writing a ReplicationController Spec
@@ -305,7 +305,7 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).  Kubectl wi
 for it to delete each pod before deleting the ReplicationController itself.  If this kubectl
 command is interrupted, it can be restarted.
 
-When using the REST API or go client library, you need to do the steps explicitly (scale replicas to
+When using the REST API or Go client library, you need to do the steps explicitly (scale replicas to
 0, wait for pod deletions, then delete the ReplicationController).
 -->
 ## 使用 ReplicationController {#working-with-replicationcontrollers}
@@ -317,24 +317,25 @@ When using the REST API or go client library, you need to do the steps explicitl
 kubectl 将 ReplicationController 缩放为 0 并等待以便在删除 ReplicationController 本身之前删除每个 Pod。
 如果这个 kubectl 命令被中断，可以重新启动它。
 
-当使用 REST API 或 go 客户端库时，你需要明确地执行这些步骤（缩放副本为 0、 等待 Pod 删除，之后删除 ReplicationController 资源）。
+当使用 REST API 或 Go 客户端库时，你需要明确地执行这些步骤（缩放副本为 0、
+等待 Pod 删除，之后删除 ReplicationController 资源）。
 
 <!--
-### Deleting just a ReplicationController
+### Deleting only a ReplicationController
 
 You can delete a ReplicationController without affecting any of its pods.
 
 Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).
 
-When using the REST API or go client library, simply delete the ReplicationController object.
+When using the REST API or Go client library, simply delete the ReplicationController object.
 -->
 ### 只删除 ReplicationController
 
 你可以删除一个 ReplicationController 而不影响它的任何 Pod。
 
 使用 kubectl，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=false` 选项。
 
-当使用 REST API 或 go 客户端库时，只需删除 ReplicationController 对象。
+当使用 REST API 或 Go 客户端库时，只需删除 ReplicationController 对象。
 
 <!--
 Once the original is deleted, you can create a new ReplicationController to replace it.  As long
@@ -373,11 +374,13 @@ As mentioned above, whether you have 1 pod you want to keep running, or 1000, a
 <!--
 ### Scaling
 
-The ReplicationController makes it easy to scale the number of replicas up or down, either manually or by an auto-scaling control agent, by simply updating the `replicas` field.
+The ReplicationController scales the number of replicas up or down by setting the `replicas` field.
+You can configure the ReplicationController to manage the replicas manually or by an auto-scaling control agent.
 -->
 ### 扩缩容   {#scaling}
 
-通过简单地更新 `replicas` 字段，ReplicationController 可以方便地横向扩容或缩容副本的数量，或手动或通过自动缩放控制代理。
+通过设置 `replicas` 字段，ReplicationController 可以方便地横向扩容或缩容副本的数量。
+你可以手动或通过自动缩放控制代理来控制 ReplicationController 执行此操作。
 
 <!--
 ### Rolling updates
@@ -463,11 +466,11 @@ Pods created by a ReplicationController are intended to be fungible and semantic
 <!--
 ## Responsibilities of the ReplicationController
 
-The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
+The ReplicationController ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
 -->
 ## ReplicationController 的职责
 
-ReplicationController 只需确保所需的 Pod 数量与其标签选择算符匹配，并且是可操作的。
+ReplicationController 仅确保所需的 Pod 数量与其标签选择算符匹配，并且是可操作的。
 目前，它的计数中只排除终止的 Pod。
 未来，可能会考虑系统提供的[就绪状态](https://issue.k8s.io/620)和其他信息，
 我们可能会对替换策略添加更多控制，