Remove trailing spaces from zh documents(#16742) (#16794)

2019-10-15 18:23:51 +09:00
parent 0268ed0c18
commit b05129acc3
106 changed files with 648 additions and 648 deletions
@@ -383,7 +383,7 @@ with namespaces, it can prevent one team from hogging all the resources.

 通过查看 `Pods` 部分，您将看到哪些 Pod 占用的节点上的资源。

-Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。 
+Pod 可用的资源量小于节点容量，因为系统守护程序使用一部分可用资源。
 [NodeStatus](/docs/resources-reference/{{< param "version" >}}/#nodestatus-v1-core) 的 `allocatable` 字段给出了可用于 Pod 的资源量。
 有关更多信息，请参阅 [节点可分配资源](https://git.k8s.io/community/contributors/design-proposals/node-allocatable.md)。

@@ -484,7 +484,7 @@ If an optional runtime partition is used, root partition will not hold any image
 ## 本地临时存储

 Kubernetes版本1.8引入了新资源_ephemeral-storage_，用于管理本地临时存储。
-在每个Kubernetes节点中，kubelet的根目录（默认为 /var/lib/kubelet）和日志目录（ /var/log ）存储在节点的根分区上。 
+在每个Kubernetes节点中，kubelet的根目录（默认为 /var/lib/kubelet）和日志目录（ /var/log ）存储在节点的根分区上。
 Pods还通过emptyDir卷，容器日志，镜像层和容器可写层共享和使用此分区。

 该分区是“临时”分区，应用程序无法从该分区获得任何性能SLA（例如磁盘IOPS）。 本地临时存储管理仅适用于根分区。 图像层和可写层的可选分区超出范围。
@@ -553,7 +553,7 @@ spec:
 ### How Pods with ephemeral-storage requests are scheduled

 When you create a Pod, the Kubernetes scheduler selects a node for the Pod to
-run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see ["Node Allocatable"](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). 
+run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. For more information, see ["Node Allocatable"](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable).

 The scheduler ensures that the sum of the resource requests of the scheduled Containers is less than the capacity of the node.
 -->
@@ -594,7 +594,7 @@ as alpha functionality for monitoring only.
 ### 监控临时存储消耗

 使用本地临时存储时，kubelet 会持续对本地临时存储时进行监视。
-通过定期扫描，来监视每个 emptyDir 卷，日志目录和可写层。 
+通过定期扫描，来监视每个 emptyDir 卷，日志目录和可写层。
 从Kubernetes 1.15开始，作为集群操作员的一个选项，可以通过[项目配额](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) 来管理 emptyDir 卷（但是不包括日志目录或可写层）。
 项目配额最初是在XFS中实现的，最近又被移植到ext4fs中。 项目配额可用于监视和执行； 从Kubernetes 1.15开始，它们可用作Alpha功能仅用于监视。

@@ -608,8 +608,8 @@ continues to consume space.  This space will be tracked by the quota,
 but will not be seen by a directory scan.
 -->

-配额比目录扫描更快，更准确。 
-将目录分配给项目时，在该目录下创建的所有文件都将在该项目中创建，内核仅需跟踪该项目中的文件正在使用多少块。 
+配额比目录扫描更快，更准确。
+将目录分配给项目时，在该目录下创建的所有文件都将在该项目中创建，内核仅需跟踪该项目中的文件正在使用多少块。
 如果创建并删除了文件，但是文件描述符已打开，它将继续占用空间。 该空间将由配额跟踪，但目录扫描不会检查。

 <!--
@@ -620,7 +620,7 @@ IDs must be registered in `/etc/projects` and `/etc/projid` to prevent
 Kubernetes from using them.
 -->

-Kubernetes使用从1048576开始的项目ID。正在使用的ID注册于 `/etc/projects` 和 `/etc/projid`。 
+Kubernetes使用从1048576开始的项目ID。正在使用的ID注册于 `/etc/projects` 和 `/etc/projid`。
 如果此范围内的项目ID用于系统上的其他目的，则这些项目ID必须在 `/etc/projects` 和 `/etc/projid` 中注册，以防止Kubernetes使用它们。

 <!--
@@ -745,9 +745,9 @@ that requests the resource to be scheduled on that node.

 ##### 其他资源
 为了发布新的节点级拓展资源，集群操作员可以向API服务器提交 `PATCH` HTTP 请求，
-以在 `status.capacity` 中为集群中的节点指定可用数量。 
-完成此操作后，节点的 `status.capacity` 将包含新资源。 
-由kubelet异步使用新资源自动更新 `status.allocatable` 字段。 
+以在 `status.capacity` 中为集群中的节点指定可用数量。
+完成此操作后，节点的 `status.capacity` 将包含新资源。
+由kubelet异步使用新资源自动更新 `status.allocatable` 字段。
 请注意，由于调度程序在评估Pod适合性时使用节点的状态 `status.allocatable` 值，
 因此在用新资源修补节点容量和请求在该节点上调度资源的第一个Pod之间可能会有短暂的延迟。

@@ -761,7 +761,7 @@ is `k8s-master`.

 **示例:**

-这是一个示例，显示了如何使用 `curl` 进行HTTP请求，该请求在主节点为 `k8s-master` 的子节点 `k8s-node-1` 
+这是一个示例，显示了如何使用 `curl` 进行HTTP请求，该请求在主节点为 `k8s-master` 的子节点 `k8s-node-1`
 上通告五个 `example.com/foo` 资源。

 ```shell
@@ -779,7 +779,7 @@ in the patch path. The operation path value in JSON-Patch is interpreted as a
 JSON-Pointer. For more details, see
 -->

-在前面的请求中，`~1` 是 Patch 路径中字符 `/` 的编码。 JSON-Patch中的操作路径值被解释为JSON-Pointer。 
+在前面的请求中，`~1` 是 Patch 路径中字符 `/` 的编码。 JSON-Patch中的操作路径值被解释为JSON-Pointer。
 有关更多详细信息，请参见
 [IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3).
 {{< /note >}}
@@ -854,7 +854,7 @@ _invalid_ quantities are `0.5` and `1500m`.

 ### 消耗扩展资源

-就像 CPU 和内存一样，用户可以使用 Pod 的扩展资源。 
+就像 CPU 和内存一样，用户可以使用 Pod 的扩展资源。
 调度程序负责核算资源，因此不会同时将过多的可用资源分配给 Pod。

 {{< note >}}
@@ -948,7 +948,7 @@ consistency across providers and platforms.
 在 kubernetes 1.5 版本中仅允许在容器上指定资源量。计划改进对所有容器在 Pod 中共享资源的计量，
 如 [emptyDir volume](/docs/concepts/storage/volumes/#emptydir)。

-在 kubernetes 1.5 版本中仅支持容器对 CPU 和内存的申请和限制。计划增加新的资源类型，包括节点磁盘空间资源和一个可支持自定义 
+在 kubernetes 1.5 版本中仅支持容器对 CPU 和内存的申请和限制。计划增加新的资源类型，包括节点磁盘空间资源和一个可支持自定义
 [资源类型](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/resources.md) 的框架。

 Kubernetes 通过支持通过多级别的 [服务质量](http://issue.k8s.io/168) 来支持资源的过度使用。
@@ -80,7 +80,7 @@ clusters and namespaces.
 A *context* element in a kubeconfig file is used to group access parameters
 under a convenient name. Each context has three parameters: cluster, namespace, and user.
 By default, the `kubectl` command-line tool uses parameters from
-the *current context* to communicate with the cluster. 
+the *current context* to communicate with the cluster.
 --->
 通过 kubeconfig 文件中的 *context* 元素，使用简便的名称来对访问参数进行分组。每个上下文都有三个参数：cluster、namespace 和 user。默认情况下，`kubectl` 命令行工具使用 *当前上下文* 中的参数与集群进行通信。

@@ -156,7 +156,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
     Even if the second file has non-conflicting entries under `red-user`, discard them.
 --->
 1. 如果设置了 `--kubeconfig` 参数，则仅使用指定的文件。不进行合并。此参数只能使用一次。
-   
+
   否则，如果设置了 `KUBECONFIG` 环境变量，将它用作应合并的文件列表。根据以下规则合并 `KUBECONFIG` 环境变量中列出的文件：

   * 忽略空文件名。
@@ -35,7 +35,7 @@ This is a living document. If you think of something that is not on this list bu
 -->
 - 在推送到集群之前，配置文件应存储在版本控制中。
 这允许您在必要时快速回滚配置更改。
- 它还有助于集群重新创建和恢复。 
+ 它还有助于集群重新创建和恢复。

 <!--
 - Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly.
@@ -104,7 +104,7 @@ This is a living document. If you think of something that is not on this list bu
 <!--
  *This does imply an ordering requirement* - any `Service` that a `Pod` wants to access must be created before the `Pod` itself, or else the environment variables will not be populated.  DNS does not have this restriction.
 -->
-  *这确实意味着订购要求* - 必须在`Pod`本身之前创建`Pod`想要访问的任何`Service`，否则将不会填充环境变量。 
+  *这确实意味着订购要求* - 必须在`Pod`本身之前创建`Pod`想要访问的任何`Service`，否则将不会填充环境变量。
   DNS没有此限制。

 <!--
@@ -224,7 +224,7 @@ To make sure the container always uses the same version of the image, you can sp
 You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
 -->

-在生产中部署容器时应避免使用 `:latest` 标记，因为更难跟踪正在运行的镜像版本，并且更难以正确回滚。 
+在生产中部署容器时应避免使用 `:latest` 标记，因为更难跟踪正在运行的镜像版本，并且更难以正确回滚。
 {{< /note >}}

 {{< note >}}
@@ -121,8 +121,8 @@ If the password you are using has special characters, you need to escape them us
     kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\\*d\\$zDsb
 You do not need to escape special characters in passwords from files (`--from-file`).
 -->
- 
- 
+
+
 特殊字符（例如 `$`,  `\*` 和 `!` ）需要转义。
 如果您使用的密码具有特殊字符，则需要使用 `\\` 字符对其进行转义。 例如，如果您的实际密码是 `S!B\*d$zDsb` ，则应通过以下方式执行命令：
     kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\\*d\\$zDsb
@@ -376,9 +376,9 @@ the option `-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if

 data和stringData的键必须由字母数字字符 '-', '_' 或者 '.' 组成。

-** 编码注意：** 秘密数据的序列化 JSON 和 YAML 值被编码为base64字符串。 
-换行符在这些字符串中无效，因此必须省略。 
-在 Darwin / macOS 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来分隔长行。 
+** 编码注意：** 秘密数据的序列化 JSON 和 YAML 值被编码为base64字符串。
+换行符在这些字符串中无效，因此必须省略。
+在 Darwin / macOS 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来分隔长行。
 相反，Linux用户 *应该* 在 `base64` 命令中添加选项 `-w 0`， 或者，如果`-w`选项不可用的情况下，
 执行 `base64 | tr -d '\n'`。

@@ -395,7 +395,7 @@ For example, to generate a Secret from files `./username.txt` and `./password.tx

 #### 从生成器创建 Secret
 Kubectl 从1.14版本开始支持 [使用 Kustomize 管理对象](/docs/tasks/manage-kubernetes-objects/kustomization/)
-使用此新功能，您还可以从生成器创建一个 Secret，然后将其应用于在 Apiserver 上创建对象。 
+使用此新功能，您还可以从生成器创建一个 Secret，然后将其应用于在 Apiserver 上创建对象。
 生成器应在目录内的“ kustomization.yaml”中指定。

 例如，从文件 `./username.txt` 和 `./password.txt` 生成一个 Secret。
@@ -953,7 +953,7 @@ field set to that of the service account.
 See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)
 for a detailed explanation of that process.
 -->
- 
+
 ### 安排 imagePullSecrets 自动附加

 您可以手动创建 imagePullSecret，并从 serviceAccount 引用它。使用该 serviceAccount 创建的任何 pod 和默认使用该 serviceAccount 的 pod 将会将其的 imagePullSecret 字段设置为服务帐户的 imagePullSecret 字段。有关该过程的详细说明，请参阅 [将 ImagePullSecrets 添加到服务帐户](/docs/tasks/configure-pod-container/configure-service-account/#adding-imagepullsecrets-to-a-service-account)。
@@ -1141,7 +1141,7 @@ Make the kustomization.yaml with SecretGenerator

 下面的例子说明一个 pod 消费一个包含 prod 凭据的 secret，另一个 pod 使用测试环境凭据消费 secret。

-通过秘钥生成器制作 kustomization.yaml 
+通过秘钥生成器制作 kustomization.yaml

 ```shell
 kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11
@@ -326,7 +326,7 @@ certain condition is true. The following taints are built in:
    this node, the kubelet removes this taint.
  -->
  此外，Kubernetes 1.6 已经支持（alpha阶段）节点问题的表示。换句话说，当某种条件为真时，node controller会自动给节点添加一个 taint。当前内置的 taint 包括：
-  
+
 * `node.kubernetes.io/not-ready`：节点未准备好。这相当于节点状态 `Ready` 的值为 "`False`"。
 * `node.kubernetes.io/unreachable`：node controller 访问不到节点. 这相当于节点状态 `Ready` 的值为 "`Unknown`"。
 * `node.kubernetes.io/out-of-disk`：节点磁盘耗尽。