Merge pull request #42255 from my-git9/path-16696

[zh-cn] sync run-application/*

Author: k8s-ci-robot

content/zh-cn/docs/tasks/run-application/configure-pdb.md

@@ -39,7 +39,7 @@ nodes.
 - 你是 Kubernetes 集群中某应用的所有者，该应用有高可用要求。
 - 你应了解如何部署[无状态应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)
   和/或[有状态应用](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)。
-- 你应当已经阅读过关于 [Pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/) 的文档。
+- 你应当已经阅读过关于 [Pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/)的文档。
 - 用户应当与集群所有者或服务提供者确认其遵从 Pod 干扰预算（Pod Disruption Budgets）的规则。
 
 <!-- steps -->
@@ -54,7 +54,7 @@ nodes.
 -->
 ## 用 PodDisruptionBudget 来保护应用   {#protecting-app-with-pdb}
 
-1. 确定想要使用 PodDisruptionBudget (PDB) 来保护的应用。
+1. 确定想要使用 PodDisruptionBudget（PDB）来保护的应用。
 1. 考虑应用对干扰的反应。
 1. 以 YAML 文件形式定义 PDB。
 1. 通过 YAML 文件创建 PDB 对象。
@@ -146,7 +146,7 @@ due to a voluntary disruption.
       (允许同时出现更多的干扰)。
 - 可重新启动的批处理任务：
   - 关注：自发干扰的情况下，需要确保任务完成。
-    - 可能的解决方案：不创建 PDB。 任务控制器会创建一个替换 Pod。
+    - 可能的解决方案：不创建 PDB。任务控制器会创建一个替换 Pod。
 
 <!--
 ### Rounding logic when specifying percentages
@@ -221,8 +221,8 @@ PodDisruptionBudgets. For policy/v1beta1 an empty selector matches zero pods, wh
 for policy/v1 an empty selector matches every pod in the namespace.
 -->
 `policy/v1beta1` 和 `policy/v1` API 中 PodDisruptionBudget 的空选择算符的行为
-略有不同。在 `policy/v1beta1` 中，空的选择算符不会匹配任何 Pods，而
-`policy/v1` 中，空的选择算符会匹配名字空间中所有 Pods。
+略有不同。在 `policy/v1beta1` 中，空的选择算符不会匹配任何 Pod，而
+`policy/v1` 中，空的选择算符会匹配名字空间中所有 Pod。
 {{< /note >}}
 
 <!--
@@ -235,7 +235,7 @@ is the `scale` of the controller managing the pods being selected by the
 用户在同一个 `PodDisruptionBudget` 中只能够指定 `maxUnavailable` 和 `minAvailable` 中的一个。
 `maxUnavailable` 只能够用于控制存在相应控制器的 Pod 的驱逐（即不受控制器控制的 Pod 不在
 `maxUnavailable` 控制范围内）。在下面的示例中，
-“所需副本” 指的是相应控制器的 `scale`，控制器对 `PodDisruptionBudget` 所选择的 Pod 进行管理。
+“所需副本”指的是相应控制器的 `scale`，控制器对 `PodDisruptionBudget` 所选择的 Pod 进行管理。
 
 <!--
 Example 1: With a `minAvailable` of 5, evictions are allowed as long as they leave behind
@@ -311,14 +311,14 @@ Example PDB Using minAvailable:
 -->
 使用 minAvailable 的 PDB 示例：
 
-{{< codenew file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" >}}
+{{% codenew file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" %}}
 
 <!--
 Example PDB Using maxUnavailable:
 -->
 使用 maxUnavailable 的 PDB 示例：
 
-{{< codenew file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" >}}
+{{% codenew file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" %}}
 
 <!--
 For example, if the above `zk-pdb` object selects the pods of a StatefulSet of size 3, both
@@ -368,7 +368,7 @@ zk-pdb   2               N/A               0                     7s
 <!--
 If there are matching pods (say, 3), then you would see something like this:
 -->
-假设有匹配的 Pod (比如说 3 个), 那么用户会看到类似下面的信息：
+假设有匹配的 Pod（比如说 3 个），那么用户会看到类似下面的信息：
 
 ```shell
 kubectl get poddisruptionbudgets
@@ -477,7 +477,7 @@ Policies:
   （`.status.currentHealthy` 至少等于 `.status.desiredHealthy`）时才能被驱逐。
 
 : 此策略确保已受干扰的应用程序所运行的 Pod 会尽可能成为健康。
-  这对排空节点有负面影响，可能会因 PDB 守护的应用程序行为错误而阻止排空。
+  这对腾空节点有负面影响，可能会因 PDB 守护的应用程序行为错误而阻止腾空。
   更具体地说，这些应用程序的 Pod 处于 `CrashLoopBackOff` 状态
   （由于漏洞或错误配置）或其 Pod 只是未能报告 `Ready` 状况。
 
@@ -505,7 +505,7 @@ Policies:
 <!--
 Pods in `Pending`, `Succeeded` or `Failed` phase are always considered for eviction.
 -->
-处于`Pending`、`Succeeded` 或 `Failed` 阶段的 Pod 总是被考虑驱逐。
+处于 `Pending`、`Succeeded` 或 `Failed` 阶段的 Pod 总是被考虑驱逐。
 {{< /note >}}
 
 <!--
@@ -535,7 +535,7 @@ You can use a PDB with pods controlled by another resource, by an
 - only `.spec.minAvailable` can be used, not `.spec.maxUnavailable`.
 - only an integer value can be used with `.spec.minAvailable`, not a percentage.
 -->
-- 只能够使用 `.spec.minAvailable` ，而不能够使用 `.spec.maxUnavailable。`
+- 只能够使用 `.spec.minAvailable`，而不能够使用 `.spec.maxUnavailable。`
 - 只能够使用整数作为 `.spec.minAvailable` 的值，而不能使用百分比。
 
 <!--
@@ -551,4 +551,4 @@ PDBs is when pods are being transitioned from one PDB to another.
 
 你可以使用能够选择属于工作负载资源的 Pod 的子集或超集的选择算符。
 驱逐 API 将不允许驱逐被多个 PDB 覆盖的任何 Pod，因此大多数用户都希望避免重叠的选择算符。
-重叠 PDB 的一种合理用途是将 Pod 从一个 PDB 转交到另一个 PDB 的场合。
+重叠 PDB 的一种合理用途是将 Pod 从一个 PDB 转交到另一个 PDB 的场合。

content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md

@@ -39,7 +39,7 @@ running for the workload.
 目的是自动扩缩工作负载以满足需求。
 
 水平扩缩意味着对增加的负载的响应是部署更多的 {{< glossary_tooltip text="Pod" term_id="pod" >}}。
-这与 “垂直（Vertical）” 扩缩不同，对于 Kubernetes，
+这与“垂直（Vertical）”扩缩不同，对于 Kubernetes，
 垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod。
 
 <!--
@@ -104,7 +104,7 @@ using the following manifest:
 为了演示 HorizontalPodAutoscaler，你将首先启动一个 Deployment 用 `hpa-example` 镜像运行一个容器，
 然后使用以下清单文件将其暴露为一个 {{< glossary_tooltip term_id="service">}}：
 
-{{< codenew file="application/php-apache.yaml" >}}
+{{% codenew file="application/php-apache.yaml" %}}
 
 <!--
 To do so, run the following command:
@@ -415,7 +415,7 @@ the only other supported resource metric is memory.  These resources do not chan
 to cluster, and should always be available, as long as the `metrics.k8s.io` API is available.
 -->
 需要注意的是，`targetCPUUtilizationPercentage` 字段已经被名为 `metrics` 的数组所取代。
-CPU 利用率这个度量指标是一个 *resource metric*（资源度量指标），因为它表示容器上指定资源的百分比。
+CPU 利用率这个度量指标是一个 **resource metric**（资源度量指标），因为它表示容器上指定资源的百分比。
 除 CPU 外，你还可以指定其他资源度量指标。默认情况下，目前唯一支持的其他资源度量指标为内存。
 只要 `metrics.k8s.io` API 存在，这些资源度量指标就是可用的，并且他们不会在不同的 Kubernetes 集群中改变名称。
 
@@ -433,7 +433,7 @@ There are two other types of metrics, both of which are considered *custom metri
 object metrics.  These metrics may have names which are cluster specific, and require a more
 advanced cluster monitoring setup.
 -->
-还有两种其他类型的度量指标，他们被认为是 *custom metrics*（自定义度量指标）：
+还有两种其他类型的度量指标，他们被认为是 **custom metrics**（自定义度量指标）：
 即 Pod 度量指标和 Object 度量指标。
 这些度量指标可能具有特定于集群的名称，并且需要更高级的集群监控设置。
 
@@ -444,7 +444,7 @@ They work much like resource metrics, except that they *only* support a `target`
 -->
 第一种可选的度量指标类型是 **Pod 度量指标**。这些指标从某一方面描述了 Pod，
 在不同 Pod 之间进行平均，并通过与一个目标值比对来确定副本的数量。
-它们的工作方式与资源度量指标非常相像，只是它们 **仅** 支持 `target` 类型为 `AverageValue`。
+它们的工作方式与资源度量指标非常相像，只是它们**仅**支持 `target` 类型为 `AverageValue`。
 
 <!--
 Pod metrics are specified using a metric block like this:
@@ -589,7 +589,7 @@ label, you can specify the following metric block to scale only on GET requests:
 -->
 ### 基于更特别的度量值来扩缩   {#autoscaing-on-more-specific-metrics}
 
-许多度量流水线允许你通过名称或附加的 **标签** 来描述度量指标。
+许多度量流水线允许你通过名称或附加的**标签**来描述度量指标。
 对于所有非资源类型度量指标（Pod、Object 和后面将介绍的 External），
 可以额外指定一个标签选择算符。例如，如果你希望收集包含 `verb` 标签的
 `http_requests` 度量指标，可以按如下所示设置度量指标块，使得扩缩操作仅针对
@@ -735,7 +735,7 @@ HorizontalPodAutoscaler.
 -->
 对于上面展示的这个 HorizontalPodAutoscaler，我们可以看出有若干状态条件处于健康状态。
 首先，`AbleToScale` 表明 HPA 是否可以获取和更新扩缩信息，以及是否存在阻止扩缩的各种回退条件。
-其次，`ScalingActive` 表明 HPA 是否被启用（即目标的副本数量不为零） 以及是否能够完成扩缩计算。
+其次，`ScalingActive` 表明 HPA 是否被启用（即目标的副本数量不为零）以及是否能够完成扩缩计算。
 当这一状态为 `False` 时，通常表明获取度量指标存在问题。
 最后一个条件 `ScalingLimited` 表明所需扩缩的值被 HorizontalPodAutoscaler
 所定义的最大或者最小值所限制（即已经达到最大或者最小扩缩值）。
@@ -775,7 +775,7 @@ can use the following manifest to create it declaratively:
 -->
 除了使用 `kubectl autoscale` 命令，也可以使用以下清单以声明方式创建 HorizontalPodAutoscaler：
 
-{{< codenew file="application/hpa/php-apache.yaml" >}}
+{{% codenew file="application/hpa/php-apache.yaml" %}}
 
 <!--
 Then, create the autoscaler by executing the following command:

content/zh-cn/docs/tasks/run-application/run-replicated-stateful-application.md

@@ -98,7 +98,7 @@ Create the ConfigMap from the following YAML configuration file:
 
 使用以下的 YAML 配置文件创建 ConfigMap ：
 
-{{< codenew file="application/mysql/mysql-configmap.yaml" >}}
+{{% codenew file="application/mysql/mysql-configmap.yaml" %}}
 
 ```shell
 kubectl apply -f https://k8s.io/examples/application/mysql/mysql-configmap.yaml
@@ -132,7 +132,7 @@ Create the Services from the following YAML configuration file:
 
 使用以下 YAML 配置文件创建服务：
 
-{{< codenew file="application/mysql/mysql-services.yaml" >}}
+{{% codenew file="application/mysql/mysql-services.yaml" %}}
 
 ```shell
 kubectl apply -f https://k8s.io/examples/application/mysql/mysql-services.yaml

content/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application.md

@@ -11,7 +11,8 @@ This page shows you how to run a single-instance stateful application
 in Kubernetes using a PersistentVolume and a Deployment. The
 application is MySQL.
 -->
-本文介绍在 Kubernetes 中如何使用 PersistentVolume 和 Deployment 运行一个单实例有状态应用。该应用是 MySQL.
+本文介绍在 Kubernetes 中如何使用 PersistentVolume 和 Deployment 运行一个单实例有状态应用。
+该示例应用是 MySQL。
 
 ## {{% heading "objectives" %}}
 
@@ -20,9 +21,9 @@ application is MySQL.
 * Create a MySQL Deployment.
 * Expose MySQL to other pods in the cluster at a known DNS name.
 -->
-* 在你的环境中创建一个引用磁盘的 PersistentVolume
-* 创建一个 MySQL Deployment.
-* 在集群内以一个已知的 DNS 名称将 MySQL 暴露给其他 Pod
+* 在你的环境中创建一个引用磁盘的 PersistentVolume。
+* 创建一个 MySQL Deployment。
+* 在集群内以一个已知的 DNS 名称将 MySQL 暴露给其他 Pod。
 
 ## {{% heading "prerequisites" %}}
 
@@ -44,9 +45,9 @@ satisfied by any existing volume that meets the requirements,
 or by a dynamic provisioner.
 -->
 你可以通过创建一个 Kubernetes Deployment 并使用 PersistentVolumeClaim 将其连接到
-某已有的 PV 卷来运行一个有状态的应用。
-例如，这里的 YAML 描述的是一个运行 MySQL 的 Deployment，其中引用了 PVC 申领。
-文件为 /var/lib/mysql 定义了加载卷，并创建了一个 PVC 申领，寻找一个 20G 大小的卷。
+某已有的 PersistentVolume 来运行一个有状态的应用。
+例如，这里的 YAML 描述的是一个运行 MySQL 的 Deployment，其中引用了 PersistentVolumeClaim。
+文件为 /var/lib/mysql 定义了卷挂载，并创建了一个 PersistentVolumeClaim，寻找一个 20G 大小的卷。
 该申领可以通过现有的满足需求的卷来满足，也可以通过动态供应卷的机制来满足。
 
 <!--
@@ -55,10 +56,10 @@ Note: The password is defined in the config yaml, and this is insecure. See
 for a secure solution.
 -->
 注意：在配置的 YAML 文件中定义密码的做法是不安全的。具体安全解决方案请参考
-[Kubernetes Secrets](/zh-cn/docs/concepts/configuration/secret/).
+[Kubernetes Secrets](/zh-cn/docs/concepts/configuration/secret/)。
 
-{{< codenew file="application/mysql/mysql-deployment.yaml" >}}
-{{< codenew file="application/mysql/mysql-pv.yaml" >}}
+{{% codenew file="application/mysql/mysql-deployment.yaml" %}}
+{{% codenew file="application/mysql/mysql-pv.yaml" %}}
 
 <!--
 1. Deploy the PV and PVC of the YAML file:
@@ -81,7 +82,7 @@ for a secure solution.
 <!--
 1. Display information about the Deployment:
 -->
-3. 展示 Deployment 相关信息:
+3. 展示 Deployment 相关信息：
 
    ```shell
    kubectl describe deployment mysql
@@ -133,7 +134,7 @@ for a secure solution.
 <!--
 1. List the pods created by the Deployment:
 -->
-4. 列举出 Deployment 创建的 pods:
+4. 列举出 Deployment 创建的 Pod：
 
    ```shell
    kubectl get pods -l app=mysql
@@ -190,11 +191,11 @@ Run a MySQL client to connect to the server:
 -->
 ## 访问 MySQL 实例   {#accessing-the-mysql-instance}
 
-前面 YAML 文件中创建了一个允许集群内其他 Pod 访问的数据库服务。该服务中选项
-`clusterIP: None` 让服务 DNS 名称直接解析为 Pod 的 IP 地址。
-当在一个服务下只有一个 Pod 并且不打算增加 Pod 的数量这是最好的.
+前面 YAML 文件中创建了一个允许集群内其他 Pod 访问的数据库 Service。该 Service 中选项
+`clusterIP: None` 让 Service 的 DNS 名称直接解析为 Pod 的 IP 地址。
+当在一个 Service 下只有一个 Pod 并且不打算增加 Pod 的数量这是最好的。
 
-运行 MySQL 客户端以连接到服务器:
+运行 MySQL 客户端以连接到服务器：
 
 ```shell
 kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword
@@ -225,7 +226,7 @@ specific to stateful apps:
 ## 更新   {#updating}
 
 Deployment 中镜像或其他部分同往常一样可以通过 `kubectl apply` 命令更新。
-以下是特定于有状态应用的一些注意事项:
+以下是特定于有状态应用的一些注意事项：
 
 <!--
 * Don't scale the app. This setup is for single-instance apps
@@ -240,11 +241,10 @@ Deployment 中镜像或其他部分同往常一样可以通过 `kubectl apply` 
 -->
 * 不要对应用进行规模扩缩。这里的设置仅适用于单实例应用。下层的 PersistentVolume
   仅只能挂载到一个 Pod 上。对于集群级有状态应用，请参考
-  [StatefulSet 文档](/zh-cn/docs/concepts/workloads/controllers/statefulset/).
+  [StatefulSet 文档](/zh-cn/docs/concepts/workloads/controllers/statefulset/)。
 * 在 Deployment 的 YAML 文件中使用 `strategy:` `type: Recreate`。
-  该选项指示 Kubernetes _不_ 使用滚动升级。滚动升级无法工作，因为这里一次不能
-  运行多个 Pod。在使用更新的配置文件创建新的 Pod 前，`Recreate` 策略将
-  保证先停止第一个 Pod。
+  该选项指示 Kubernetes **不**使用滚动升级。滚动升级无法工作，因为这里一次不能运行多个
+  Pod。在使用更新的配置文件创建新的 Pod 前，`Recreate` 策略将保证先停止第一个 Pod。
 
 <!--
 ## Deleting a deployment
@@ -253,7 +253,7 @@ Delete the deployed objects by name:
 -->
 ## 删除 Deployment    {#deleting-a-deployment}
 
-通过名称删除部署的对象:
+通过名称删除部署的对象：
 
 ```shell
 kubectl delete deployment,svc mysql
@@ -269,7 +269,7 @@ PersistentVolume when it sees that you deleted the PersistentVolumeClaim.
 Some dynamic provisioners (such as those for EBS and PD) also release the
 underlying resource upon deleting the PersistentVolume.
 -->
-如果通过手动的方式供应 PersistentVolume, 那么也需要手动删除它以释放下层资源。
+如果通过手动的方式供应 PersistentVolume，那么也需要手动删除它以释放下层资源。
 如果是用动态供应方式创建的 PersistentVolume，在删除 PersistentVolumeClaim 后
 PersistentVolume 将被自动删除。
 一些存储服务（比如 EBS 和 PD）也会在 PersistentVolume 被删除时自动回收下层资源。
@@ -286,6 +286,7 @@ PersistentVolume 将被自动删除。
 * [Volumes](/docs/concepts/storage/volumes/) and [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
 -->
 * 欲进一步了解 Deployment 对象，请参考 [Deployment 对象](/zh-cn/docs/concepts/workloads/controllers/deployment/)
+
 * 进一步了解[部署应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)
 
 * 参阅 [kubectl run 文档](/docs/reference/generated/kubectl/kubectl-commands/#run)

content/zh-cn/docs/tasks/run-application/run-stateless-application-deployment.md

@@ -39,10 +39,10 @@ a Deployment that runs the nginx:1.14.2 Docker image:
 ## 创建并了解一个 nginx Deployment
 
 你可以通过创建一个 Kubernetes Deployment 对象来运行一个应用, 且你可以在一个
-YAML 文件中描述 Deployment。例如, 下面这个 YAML 文件描述了一个运行 nginx:1.14.2
+YAML 文件中描述 Deployment。例如，下面这个 YAML 文件描述了一个运行 nginx:1.14.2
 Docker 镜像的 Deployment：
 
-{{< codenew file="application/deployment.yaml" >}}
+{{% codenew file="application/deployment.yaml" %}}
 
 <!--
 1. Create a Deployment based on the YAML file:
@@ -142,7 +142,7 @@ specifies that the deployment should be updated to use nginx 1.16.1.
 你可以通过应用一个新的 YAML 文件来更新 Deployment。下面的 YAML 文件指定该
 Deployment 镜像更新为 nginx 1.16.1。
 
-{{< codenew file="application/deployment-update.yaml" >}}
+{{% codenew file="application/deployment-update.yaml" %}}
 
 <!--
 1. Apply the new YAML file:
@@ -174,7 +174,7 @@ should have four Pods:
 你可以通过应用新的 YAML 文件来增加 Deployment 中 Pod 的数量。
 下面的 YAML 文件将 `replicas` 设置为 4，指定该 Deployment 应有 4 个 Pod：
 
-{{< codenew file="application/deployment-scale.yaml" >}}
+{{% codenew file="application/deployment-scale.yaml" %}}
 
 <!--
 1. Apply the new YAML file:
@@ -197,7 +197,7 @@ should have four Pods:
    <!--
    The output is similar to this:
    -->
-   输出的结果类似于:
+   输出的结果类似于：
 
    ```
    NAME                               READY     STATUS    RESTARTS   AGE