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
@@ -14,7 +14,7 @@ weight: 40

 {{% capture overview %}}

-<!-- 
+<!--
 The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}, and helps you obtain a deeper understanding of how Kubernetes works.
 -->

@@ -24,25 +24,25 @@ The Concepts section helps you learn about the parts of the Kubernetes system an

 {{% capture body %}}

-<!-- 
+<!--
 ## Overview
 -->

 ## 概述

-<!-- 
+<!--
 To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
 -->

 要使用 Kubernetes，你需要用 *Kubernetes API 对象* 来描述集群的 *预期状态（desired state）* ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 `kubectl`  来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。

-<!-- 
-Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator (PLEG). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster: 
+<!--
+Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator (PLEG). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
 -->

 一旦你设置了你所需的目标状态，*Kubernetes 控制面（control plane）* 会通过 Pod 生命周期事件生成器( PLEG )，促成集群的当前状态符合其预期状态。为此，Kubernetes 会自动执行各类任务，比如运行或者重启容器、调整给定应用的副本数等等。Kubernetes 控制面由一组运行在集群上的进程组成：

-<!-- 
+<!--
 * The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
 * Each individual non-master node in your cluster runs two processes:
  * **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
@@ -54,19 +54,19 @@ Once you've set your desired state, the *Kubernetes Control Plane* makes the clu
  * **[kubelet](/docs/admin/kubelet/)**，和 master 节点进行通信。
  * **[kube-proxy](/docs/admin/kube-proxy/)**，一种网络代理，将 Kubernetes 的网络服务代理到每个节点上。

-<!-- 
+<!--
 ## Kubernetes Objects
 -->

 ## Kubernetes 对象

 <!--
-Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details. 
+Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API; see the [Kubernetes Objects overview](/docs/concepts/abstractions/overview/) for more details.
 -->

 Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。参阅 [Kubernetes 对象概述](/docs/concepts/abstractions/overview/)以了解详细信息。

-<!-- 
+<!--
 The basic Kubernetes objects include:
 -->

@@ -101,7 +101,7 @@ The various parts of the Kubernetes Control Plane, such as the Kubernetes Master

 关于 Kubernetes 控制平面的各个部分，（如 Kubernetes 主控组件和 kubelet 进程），管理着 Kubernetes 如何与你的集群进行通信。控制平面维护着系统中所有的 Kubernetes 对象的状态记录，并且通过连续的控制循环来管理这些对象的状态。在任意的给定时间点，控制面的控制环都能响应集群中的变化，并且让系统中所有对象的实际状态与你提供的预期状态相匹配。

-<!-- 
+<!--
 For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state.
 -->

@@ -119,25 +119,25 @@ The Kubernetes master is responsible for maintaining the desired state for your

 Kubernetes master 节点负责维护集群的目标状态。当你要与 Kubernetes 通信时，使用如 `kubectl` 的命令行工具，就可以直接与 Kubernetes master 节点进行通信。

-<!-- 
+<!--
 > The "master" refers to a collection of processes managing the cluster state.  Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy.
 -->

 > "master" 是指管理集群状态的一组进程的集合。通常这些进程都跑在集群中一个单独的节点上，并且这个节点被称为 master 节点。master 节点也可以扩展副本数，来获取更好的可用性及冗余。

-<!-- 
+<!--
 ### Kubernetes Nodes
 -->

 ### Kubernetes Node 节点

-<!-- 
+<!--
 The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
 -->

 集群中的 node 节点（虚拟机、物理机等等）都是用来运行你的应用和云工作流的机器。Kubernetes master 节点控制所有 node 节点；你很少需要和 node 节点进行直接通信。

-<!-- 
+<!--
 #### Object Metadata


@@ -153,7 +153,7 @@ The nodes in a cluster are the machines (VMs, physical servers, etc) that run yo

 {{% capture whatsnext %}}

-<!-- 
+<!--
 If you would like to write a concept page, see
 [Using Page Templates](/docs/home/contribute/page-templates/)
 for information about the concept page type and the concept template.
@@ -79,7 +79,7 @@ The CCM consolidates all of the cloud-dependent logic from the preceding three c

 CCM 整合了前三个组件中的所有依赖于云的逻辑，以创建与云的单一集成点。CCM 的新架构如下所示：

-<!-- 
+<!--
 ![CCM Kube Arch](/images/docs/post-ccm-arch.png)
 -->

@@ -46,7 +46,7 @@ Master 组件通过非安全（没有加密或认证）端口和集群的 apiser
 从 apiserver 到 kubelet 的连接用于获取 pods 日志、连接（通过 kubectl）运行中的 pods，以及使用 kubelet 的端口转发功能。这些连接终止于 kubelet 的 HTTPS endpoint。


-默认的，apiserver 不会验证 kubelet 的服务证书，这会导致连接遭到中间人攻击，因而在不可信或公共网络上是不安全的。  
+默认的，apiserver 不会验证 kubelet 的服务证书，这会导致连接遭到中间人攻击，因而在不可信或公共网络上是不安全的。


 为了对这个连接进行认证，请使用 `--kubelet-certificate-authority` 标记给 apiserver 提供一个根证书捆绑，用于 kubelet 的服务证书。
@@ -40,7 +40,7 @@ manually through `easyrsa`, `openssl` or `cfssl`.
        tar xzf easy-rsa.tar.gz
        cd easy-rsa-master/easyrsa3
        ./easyrsa init-pki
-        
+
 <!--
 1.  Generate a CA. (`--batch` set automatic mode. `--req-cn` default CN to use.)
 -->
@@ -101,7 +101,7 @@ manually through `easyrsa`, `openssl` or `cfssl`.
 1.  生成密钥位数为 2048 的 ca.key：

        openssl genrsa -out ca.key 2048
-        
+
 <!--
 1.  According to the ca.key generate a ca.crt (use -days to set the certificate effective time):
 -->
@@ -222,7 +222,7 @@ Finally, add the same parameters into the API server start parameters.
        chmod +x cfssljson
        curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo
        chmod +x cfssl-certinfo
-        
+
 <!--
 1.  Create a directory to hold the artifacts and initialize cfssl:
 -->
@@ -258,7 +258,7 @@ Finally, add the same parameters into the API server start parameters.
            }
          }
        }
-        
+
 <!--
 1.  Create a JSON config file for CA certificate signing request (CSR), for example,
    `ca-csr.json`. Be sure to replace the values marked with angle brackets with
@@ -282,7 +282,7 @@ Finally, add the same parameters into the API server start parameters.
            "OU": "<organization unit>"
          }]
        }
-        
+
 <!--
 1.  Generate CA key (`ca-key.pem`) and certificate (`ca.pem`):
 -->
@@ -290,7 +290,7 @@ Finally, add the same parameters into the API server start parameters.
 1.  生成 CA 密钥（`ca-key.pem`）和证书（`ca.pem`）：

        ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca
-        
+
 <!--
 1.  Create a JSON config file for generating keys and certificates for the API
    server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with
@@ -328,7 +328,7 @@ Finally, add the same parameters into the API server start parameters.
            "OU": "<organization unit>"
          }]
        }
-        
+
 <!--
 1.  Generate the key and certificate for the API server, which are by default
    saved into file `server-key.pem` and `server.pem` respectively:
@@ -66,14 +66,14 @@ Kubernetes 知道如何通过文件 cloud.conf 与 OpenStack 进行交互。 该

 ```yaml
 [Global]
-username=user  
-password=pass  
-auth-url=https://<keystone_ip>/identity/v3  
-tenant-id=c869168a828847f39f7f06edd7305637  
+username=user
+password=pass
+auth-url=https://<keystone_ip>/identity/v3
+tenant-id=c869168a828847f39f7f06edd7305637
 domain-id=2a73b8f597c04551a0fdc8e95544be8a

 [LoadBalancer]
-subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a  
+subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
 ```

 #### 全局配置
@@ -163,7 +163,7 @@ the rotation and there are two files, one 10MB in size and one empty,
 `kubectl logs` will return an empty response.
 -->
 当前，如果有其他系统机制执行日志轮转，那么 `kubectl logs` 仅可查询到最新的日志内容。
-比如，一个 10MB 大小的文件，通过`logrotate` 执行轮转后生成两个文件，一个 10MB 大小，一个为空，所以 `kubectl logs` 将返回空。 
+比如，一个 10MB 大小的文件，通过`logrotate` 执行轮转后生成两个文件，一个 10MB 大小，一个为空，所以 `kubectl logs` 将返回空。
 {{< /note >}}

 [cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
@@ -36,7 +36,7 @@ content_template: templates/concept

    - 在每个节点上运行
    - 代理 UDP 和 TCP
-    - 不支持 HTTP 
+    - 不支持 HTTP
    - 提供负载均衡能力
    - 只用来访问 Service

@@ -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`：节点磁盘耗尽。
@@ -8,7 +8,7 @@ content_template: templates/concept

 {{% capture overview %}}

-本文介绍容器环境中对容器可用的资源。 
+本文介绍容器环境中对容器可用的资源。

 {{% /capture %}}

@@ -131,7 +131,7 @@ Docker将私有仓库的密钥存放在`$HOME/.dockercfg`或`$HOME/.docker/confi
 	 - 如果使用node IP ，`nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
   1.将本地的`.docker/config.json`拷贝到每个节点root用户目录下
     - 例如： `for n in $nodes; do scp ~/.docker/config.json root@$n:/root/.docker/config.json; done`
-	 
+	
 创建使用私有仓库的pod来验证，例如：

 ```yaml
@@ -8,14 +8,14 @@ weight: 20

 {{< feature-state for_k8s_version="v1.14" state="beta" >}}

-<!-- 
+<!--
 This page describes the RuntimeClass resource and runtime selection mechanism.
 -->

 这个文档主要说明了 RuntimeClass 资源和 kubernetes 指定容器运行时的功能。

 {{< warning >}}
-<!-- 
+<!--
 RuntimeClass includes *breaking* changes in the beta upgrade in v1.14. If you were using
 RuntimeClass prior to v1.14, see [Upgrading RuntimeClass from Alpha to
 Beta](#upgrading-runtimeclass-from-alpha-to-beta).
@@ -31,7 +31,7 @@ Kubernetes1.14 的 β 版的升级包含了 RuntimeClass 的 *破坏性* 的变

 {{% capture body %}}

-<!-- 
+<!--
 ## Runtime Class

 RuntimeClass is a feature for selecting the container runtime configuration. The container runtime
@@ -42,7 +42,7 @@ configuration is used to run a Pod's containers.

 RuntimeClass 是可以让用户选择容器运行时的功能。用户通过设定容器运行时可以选择 Pod 的容器运行在那种容器运行时之上。

-<!-- 
+<!--
 ## Motivation

 You can set a different RuntimeClass between different Pods to provide a balance of
@@ -98,7 +98,7 @@ CRI implementation for how to configure.
 RuntimeClass assumes a homogeneous node configuration across the cluster by default (which means
 that all nodes are configured the same way with respect to container runtimes). To support
 heterogenous node configurations, see [Scheduling](#scheduling) below.
--> 
+-->

 默认情况下，RuntimeClass 被假设为所有节点上的配置均为一致。(这意味着所有的 Node 节点的容器运行时必须以相同的方式进行设定)。
 要支持不同配置构节点配置，请参见下面的[Scheduling]（＃scheduling）。
@@ -154,7 +154,7 @@ Once RuntimeClasses are configured for the cluster, using them is very simple. S
 -->
 ### 使用方法

-一旦集群中的 RuntimeClass 的设定完成，接下来的使用就变得非常简单了。只需要设定 PodSpec 的 `runtimeClassName` 设定项。  
+一旦集群中的 RuntimeClass 的设定完成，接下来的使用就变得非常简单了。只需要设定 PodSpec 的 `runtimeClassName` 设定项。
 例如：

 ```yaml
@@ -220,7 +220,7 @@ Runtime handlers are configured through containerd's configuration at
 See containerd's config documentation for more details:
 https://github.com/containerd/cri/blob/master/docs/config.md
 -->
-`containerd` 的具体设定请参考下面的文档信息。  
+`containerd` 的具体设定请参考下面的文档信息。
 https://github.com/containerd/cri/blob/master/docs/config.md

 #### [cri-o](https://cri-o.io/)
@@ -230,7 +230,7 @@ Runtime handlers are configured through cri-o's configuration at `/etc/crio/crio
 handlers are configured under the [crio.runtime
 table](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table):
 -->
-运行时处理程序通过cri-o的配置在 `/etc/crio/crio.conf` 中进行配置。 
+运行时处理程序通过cri-o的配置在 `/etc/crio/crio.conf` 中进行配置。
 有效的处理程序在[crio.runtime表](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)下配置。

 ```
@@ -266,13 +266,13 @@ the intersection of the set of nodes selected by each. If there is a conflict, t
 rejected.
 -->

-从Kubernetes v1.16开始，RuntimeClass 通过 `scheduling` 字段添加了对异构集群的支持。 
-通过使用这些字段，可以确保将与此 RuntimeClass一 起运行的 Pod 调度到支持它的节点上。 
+从Kubernetes v1.16开始，RuntimeClass 通过 `scheduling` 字段添加了对异构集群的支持。
+通过使用这些字段，可以确保将与此 RuntimeClass一 起运行的 Pod 调度到支持它的节点上。
 要使用计划支持，您必须启用 RuntimeClass [admission controller] []（默认值，自1.16开始）。

 为了确保 Pod 被调度到支持特定 RuntimeClass 的节点上，
-那组节点应该具有一个公共标签，然后由 `runtimeclass.scheduling.nodeSelector` 字段选择该标签。 
-RuntimeClass 的 nodeSelector 在调度时与 Pod 的 nodeSelector 合并，有效地进行节点选择，并且调度到相应节点。 
+那组节点应该具有一个公共标签，然后由 `runtimeclass.scheduling.nodeSelector` 字段选择该标签。
+RuntimeClass 的 nodeSelector 在调度时与 Pod 的 nodeSelector 合并，有效地进行节点选择，并且调度到相应节点。
 如果有冲突，则将拒绝该 Pod 被调度。

 <!--
@@ -347,7 +347,7 @@ RuntimeClass Beta 功能包括以下更改：
 - 已在 RuntimeClass 定义中内联了 `spec`（即不再有RuntimeClassSpec）。
 - `runtimeHandler` 字段已重命名为 `handler`。
 - 所有 API 版本中现在都需要 `handler` 字段。 这意味着 Alpha API 中的 `runtimeHandler` 字段也是必须设定项。
- `handler`字段必须是有效的DNS标签（[RFC 1123](https://tools.ietf.org/html/rfc1123))，这意味着它不再包含 `.` 字符（在所有版本中）。 
+- `handler`字段必须是有效的DNS标签（[RFC 1123](https://tools.ietf.org/html/rfc1123))，这意味着它不再包含 `.` 字符（在所有版本中）。
   有效的处理程序匹配以下正则表达式：`^ [a-z0-9]（[-a-z0-9] * [a-z0-9]）？$`。

 <!--
@@ -7,7 +7,7 @@ weight: 10
 {{% capture overview %}}

 <!--
-The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs. 
+The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs.
 -->

 聚合层允许 Kubernetes 通过额外的 API 进行扩展，而不局限于 Kubernetes 核心 API 提供的功能。
@@ -26,7 +26,7 @@ The aggregation layer enables installing additional Kubernetes-style APIs in you
 聚合层使您的集群可以安装其他 Kubernetes 风格的 API。这些 API 可以是预编译的、第三方的解决方案提供的例如[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)、或者用户创建的类似[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)一样的API可以帮助你上手。

 <!--
-The aggregation layer runs in-process with the kube-apiserver. Until an extension resource is registered, the aggregation layer will do nothing. To register an API, users must add an APIService object, which "claims" the URL path in the Kubernetes API. At that point, the aggregation layer will proxy anything sent to that API path (e.g. /apis/myextension.mycompany.io/v1/…) to the registered APIService. 
+The aggregation layer runs in-process with the kube-apiserver. Until an extension resource is registered, the aggregation layer will do nothing. To register an API, users must add an APIService object, which "claims" the URL path in the Kubernetes API. At that point, the aggregation layer will proxy anything sent to that API path (e.g. /apis/myextension.mycompany.io/v1/…) to the registered APIService.
 -->

 聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。要注册 API，用户必须添加一个 APIService 对象，用它来申领 Kubernetes API 中的 URL 路径。自此以后，聚合层将会把发给该 API 路径的所有内容（例如 /apis/myextension.mycompany.io/v1/…）代理到已注册的 APIService。
@@ -117,7 +117,7 @@ multiple API versions, each at a different API path, such as `/api/v1` or
 ## API 版本

 为了使删除字段或者重构资源表示更加容易，Kubernetes 支持
-多个API版本。每一个版本都在不同API路径下，例如 `/api/v1` 或者 
+多个API版本。每一个版本都在不同API路径下，例如 `/api/v1` 或者
 `/apis/extensions/v1beta1`。

 <!--
@@ -187,7 +187,7 @@ The API group is specified in a REST path and in the `apiVersion` field of a ser

 ## API 组

-为了更容易地扩展Kubernetes API，我们实现了[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。 
+为了更容易地扩展Kubernetes API，我们实现了[*`API组`*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)。
 API组在REST路径和序列化对象的 **`apiVersion`** 字段中指定。

 <!--
@@ -239,9 +239,9 @@ to pick up the `--runtime-config` changes.

 ## 启用 API 组

-某些资源和API组默认情况下处于启用状态。 可以通过在apiserver上设置 `--runtime-config` 来启用或禁用它们。 
-`--runtime-config` 接受逗号分隔的值。 
-例如：要禁用batch/v1，请设置 `--runtime-config=batch/v1=false`，以启用batch/v2alpha1，请设置`--runtime-config=batch/v2alpha1`。 
+某些资源和API组默认情况下处于启用状态。 可以通过在apiserver上设置 `--runtime-config` 来启用或禁用它们。
+`--runtime-config` 接受逗号分隔的值。
+例如：要禁用batch/v1，请设置 `--runtime-config=batch/v1=false`，以启用batch/v2alpha1，请设置`--runtime-config=batch/v2alpha1`。
 该标志接受描述apiserver的运行时配置的逗号分隔的一组键值对。

 重要：启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 `--runtime-config` 更改生效。
@@ -257,7 +257,7 @@ apiserver. `--runtime-config` accepts comma separated values. For example: to di

 ## 启用组中资源

-DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs 和 ReplicaSets是默认启用的。 
+DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs 和 ReplicaSets是默认启用的。
 其他扩展资源可以通过在apiserver上设置 `--runtime-config` 来启用。
 `--runtime-config` 接受逗号分隔的值。 例如：要禁用 Deployment 和 Ingress，
 请设置 `--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false`
@@ -160,7 +160,7 @@ spec:
    image: nginx:1.7.9
    ports:
    - containerPort: 80
-          
+
 ```

 {{% /capture %}}
@@ -95,7 +95,7 @@ One way to create a Deployment using a `.yaml` file like the one above is to use
 in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example:
 -->

-使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的 
+使用类似于上面的 `.yaml` 文件来创建 Deployment，一种方式是使用 `kubectl` 命令行接口（CLI）中的
 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 命令，
 将 `.yaml` 文件作为参数。下面是一个示例：

@@ -33,12 +33,12 @@ need the features they provide.
 -->

 命名空间为名称提供了一个范围。
-资源的名称需要在命名空间内是惟一的，但不能跨命名空间。命名空间不能嵌套在另外一个命名空间内，而且每个 Kubernetes 
+资源的名称需要在命名空间内是惟一的，但不能跨命名空间。命名空间不能嵌套在另外一个命名空间内，而且每个 Kubernetes
 资源只能属于一个命名空间。

 <!--
 Namespaces provide a scope for names.  Names of resources need to be unique within a namespace,
-but not across namespaces. Namespaces can not be nested inside one another and each Kubernetes 
+but not across namespaces. Namespaces can not be nested inside one another and each Kubernetes
 resource can only be in one namespace.
 -->

@@ -100,7 +100,7 @@ Kubernetes starts with three initial namespaces:
   * `kube-system` The namespace for objects created by the Kubernetes system
   * `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.
 -->
-   
+
   * `default` 没有指明使用其它命名空间的对象所使用的默认命名空间
   * `kube-system` Kubernetes 系统创建对象所使用的命名空间
   * `kube-public` 这个命名空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。这个命名空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。这个命名空间的公共方面只是一种约定，而不是要求。
@@ -20,7 +20,7 @@ title: 资源配额
 - 如果资源的创建或更新违反了配额约束，则请求会失败，并返回 HTTP状态码 `403 FORBIDDEN` ，以及说明违反配额
  约束的信息。
 - 如果namespace下的计算资源 （如 `cpu` 和 `memory`）的配额被启用，则用户必须为这些资源设定请求值（request）
-  和约束值（limit），否则配额系统将拒绝Pod的创建。  
+  和约束值（limit），否则配额系统将拒绝Pod的创建。
  提示: 可使用 LimitRange 准入控制器来为没有设置计算资源需求的Pod设置默认值。
  作为示例，请参考 [演练](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/) 来避免这个问题。

@@ -36,10 +36,10 @@ title: 资源配额

 ## 启用资源配额

-资源配额的支持在很多Kubernetes版本中是默认开启的。 当 apiserver 的 
+资源配额的支持在很多Kubernetes版本中是默认开启的。 当 apiserver 的
 `--admission-control=` 参数中包含 `ResourceQuota` 时，资源配额会被启用。

-当namespace中存在一个 `ResourceQuota` 对象时，该namespace即开始实施资源配额管理。 
+当namespace中存在一个 `ResourceQuota` 对象时，该namespace即开始实施资源配额管理。
 一个namespace中最多只应存在一个 `ResourceQuota` 对象

 ## 计算资源配额
@@ -16,7 +16,7 @@ Modification not using HostAliases is not suggested because the file is managed

 当 DNS 配置以及其它选项不合理的时候，通过向 Pod 的 /etc/hosts 文件中添加条目，可以在 Pod 级别覆盖对主机名的解析。在 1.7 版本，用户可以通过 PodSpec 的 HostAliases 字段来添加这些自定义的条目。

-建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且可以在 Pod 创建/重启过程中被重写。 
+建议通过使用 HostAliases 来进行修改，因为该文件由 Kubelet 管理，并且可以在 Pod 创建/重启过程中被重写。
 {{% /capture %}}

 {{% capture body %}}
@@ -22,7 +22,7 @@ This guide uses a simple nginx server to demonstrate proof of concept. The same
 ## Kubernetes 连接容器模型

 既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。
-在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。 
+在讨论 Kubernetes 网络连接的方式之前，非常值得与 Docker 中 “正常” 方式的网络进行对比。



@@ -225,9 +225,9 @@ Kubernetes支持两种查找服务的主要模式: 环境变量和DNS。 前者

 <!--
 If the service environment variables are not desired (because possible clashing with expected program ones,
-too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks` 
-flag to `false` on the [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core). 
--> 
+too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks`
+flag to `false` on the [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core).
+-->

 如果不需要服务环境变量（因为可能与预期的程序冲突，可能要处理的变量太多，或者仅使用DNS等），则可以通过在
 [pod spec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)上将 `enableServiceLinks` 标志设置为 `false` 来禁用此模式。
@@ -54,7 +54,7 @@ For more up-to-date specification, see
 运行在Namespace `bar` 中的一个 Pod，可以简单地通过 DNS 查询 `foo` 来找到该 Service。
 运行在 Namespace `quux` 中的一个 Pod 可以通过 DNS 查询 `foo.bar` 找到该 Service。

-以下各节详细介绍了受支持的记录类型和支持的布局。 其中代码部分的布局，名称或查询命令均被视为实现细节，如有更改，恕不另行通知。 
+以下各节详细介绍了受支持的记录类型和支持的布局。 其中代码部分的布局，名称或查询命令均被视为实现细节，如有更改，恕不另行通知。
 有关最新规范请查看
 [Kubernetes 基于 DNS 的服务发现](https://github.com/kubernetes/dns/blob/master/docs/specification.md).

@@ -145,7 +145,7 @@ Example:
 在 v1.3 版本中，PodSpec 具有 `hostname` 字段，可以用来指定 Pod 的主机名。这个字段的值优先于 annotation `pod.beta.kubernetes.io/hostname`。
 在 v1.2 版本中引入了 beta 特性，用户可以为 Pod 指定 annotation，其中 `pod.beta.kubernetes.io/subdomain` 指定了 Pod 的子域名。
 最终的域名将是 “<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>”。
-举个例子，Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foo.bar.my-namespace.svc.cluster.local”。 
+举个例子，Pod 的主机名 annotation 设置为 “foo”，子域名 annotation 设置为 “bar”，在 Namespace “my-namespace” 中对应的 FQDN 为 “foo.bar.my-namespace.svc.cluster.local”。

 在 v1.3 版本中，PodSpec 具有 `subdomain` 字段，可以用来指定 Pod 的子域名。
 这个字段的值优先于 annotation `pod.beta.kubernetes.io/subdomain` 的值。
@@ -235,7 +235,7 @@ record unless `publishNotReadyAddresses=True` is set on the Service.

 因为没有为 Pod 名称创建A记录，所以要创建 Pod 的 A 记录需要 `hostname` 。

-没有 `hostname` 但带有 `subdomain` 的 Pod 只会为指向Pod的IP地址的 headless 服务创建 A 记录(`default-subdomain.my-namespace.svc.cluster-domain.example`)。 
+没有 `hostname` 但带有 `subdomain` 的 Pod 只会为指向Pod的IP地址的 headless 服务创建 A 记录(`default-subdomain.my-namespace.svc.cluster-domain.example`)。
 另外，除非在服务上设置了 `publishNotReadyAddresses=True`，否则 Pod 需要准备好 A 记录。
 {{< /note >}}

@@ -348,10 +348,10 @@ Pod 的 DNS 配置可让用户对 Pod 的 DNS 设置进行更多控制。
 -->

 - `nameservers`: 将用作于 Pod 的 DNS 服务器的 IP 地址列表。最多可以指定3个 IP 地址。 当 Pod 的 `dnsPolicy` 设置为 "`None`" 时，列表必须至少包含一个IP地址，否则此属性是可选的。列出的服务器将合并到从指定的 DNS 策略生成的基本名称服务器，并删除重复的地址。
- `searches`: 用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定后，提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。 
+- `searches`: 用于在 Pod 中查找主机名的 DNS 搜索域的列表。此属性是可选的。指定后，提供的列表将合并到根据所选 DNS 策略生成的基本搜索域名中。
   重复的域名将被删除。
    Kubernetes最多允许6个搜索域。
- `options`: 对象的可选列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。 
+- `options`: 对象的可选列表，其中每个对象可能具有 `name` 属性（必需）和 `value` 属性（可选）。 此属性中的内容将合并到从指定的 DNS 策略生成的选项。
   重复的条目将被删除。

 <!--
@@ -7,15 +7,15 @@ weight: 40
 {{% capture overview %}}

 <!--
-In order for the Ingress resource to work, the cluster must have an ingress controller running. 
+In order for the Ingress resource to work, the cluster must have an ingress controller running.

-Unlike other types of controllers which run as part of the `kube-controller-manager` binary, Ingress controllers 
-are not started automatically with a cluster. Use this page to choose the ingress controller implementation 
+Unlike other types of controllers which run as part of the `kube-controller-manager` binary, Ingress controllers
+are not started automatically with a cluster. Use this page to choose the ingress controller implementation
 that best fits your cluster.

 Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and
  [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
-  
+
 -->

 为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。
@@ -33,16 +33,16 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
 <!--
 ## Additional controllers

-* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress 
-  controller with [community](https://www.getambassador.io/docs) or 
+* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress
+  controller with [community](https://www.getambassador.io/docs) or
  [commercial](https://www.getambassador.io/pro/) support from [Datawire](https://www.datawire.io/).
-* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager).  
+* [AppsCode Inc.](https://appscode.com) offers support and maintenance for the most widely used [HAProxy](http://www.haproxy.org/) based ingress controller [Voyager](https://appscode.com/products/voyager).
 * [Contour](https://github.com/heptio/contour) is an [Envoy](https://www.envoyproxy.io) based ingress controller
  provided and supported by Heptio.
 * Citrix provides an [Ingress Controller](https://github.com/citrix/citrix-k8s-ingress-controller) for its hardware (MPX), virtualized (VPX) and [free containerized (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) for [baremetal](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) and [cloud](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments.
 * F5 Networks provides [support and maintenance](https://support.f5.com/csp/article/K86859508)
  for the [F5 BIG-IP Controller for Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest).
-* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).  
+* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io) which offers API Gateway functionality with enterprise support from [solo.io](https://www.solo.io).
 * [HAProxy Technologies](https://www.haproxy.com/) offers support and maintenance for the [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/).
 * [Istio](https://istio.io/) based ingress controller
  [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/).
@@ -58,13 +58,13 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
 -->
 ## 其他控制器

-* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress 
+* [Ambassador](https://www.getambassador.io/) API 网关， 一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress
  控制器，有着来自 [Datawire](https://www.datawire.io/) [社区](https://www.getambassador.io/docs)或[商业](https://www.getambassador.io/pro/)的支持。
-* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护.  
+* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 [HAProxy](http://www.haproxy.org/) 的 ingress 控制器 [Voyager](https://appscode.com/products/voyager) 提供支持和维护.
 * [Contour](https://github.com/heptio/contour) 是一个基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它由 Heptio 提供和支持。
 * Citrix 为其硬件（MPX），虚拟化（VPX）和 [免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) 提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)，用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和[云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。
 * F5 Networks 为 [用于 Kubernetes 的 F5 BIG-IP 控制器](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)提供[支持和维护](https://support.f5.com/csp/article/K86859508)。
-* [Gloo](https://gloo.solo.io) 是一个开源的基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它提供了 API 网关功能，有着来自 [solo.io](https://www.solo.io) 的企业级支持。 
+* [Gloo](https://gloo.solo.io) 是一个开源的基于 [Envoy](https://www.envoyproxy.io) 的 ingress 控制器，它提供了 API 网关功能，有着来自 [solo.io](https://www.solo.io) 的企业级支持。
 * [HAProxy Technologies](https://www.haproxy.com/) 为 [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress). See the [official documentation](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/) 提供支持和运维服务。
 * 基于 [Istio](https://istio.io/) 的 ingress 控制器[控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。
 * [Kong](https://konghq.com/) 为[用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller) 提供[社区](https://discuss.konghq.com/c/kubernetes)或[商业](https://konghq.com/kong-enterprise/)支持和维护。
@@ -76,9 +76,9 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i
 <!--
 ## Using multiple Ingress controllers

-You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) 
+You may deploy [any number of ingress controllers](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)
 within a cluster. When you create an ingress, you should annotate each ingress with the appropriate
-[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 
+[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
 to indicate which ingress controller should be used if more than one exists within your cluster.

 If you do not define a class, your cloud provider may use a default ingress controller.
@@ -90,7 +90,7 @@ controllers operate slightly differently.

 你可以在集群中部署[任意数量的 ingress 控制器](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)。
 创建 ingress 时，应该使用适当的
-[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 注解每个 ingress 
+[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 注解每个 ingress
 以表明在集群中如果有多个 ingress 控制器时，应该使用哪个 ingress 控制器。

 如果不定义 `ingress.class`，云提供商可能使用默认的 ingress 控制器。
@@ -62,7 +62,7 @@ Traffic routing is controlled by rules defined on the Ingress resource.

 ## Ingress 是什么？

-Ingress公开了从群集外部到群集内 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} 的HTTP和HTTPS路由。 
+Ingress公开了从群集外部到群集内 {{< link text="services" url="/docs/concepts/services-networking/service/" >}} 的HTTP和HTTPS路由。
 流量路由由Ingress资源上定义的规则控制。

 ```none
@@ -208,7 +208,7 @@ routed to your default backend.

 ### 默认后端

-没有设定规则的 Ingress 将所有流量发送到单个默认后端。 
+没有设定规则的 Ingress 将所有流量发送到单个默认后端。
 默认后端通常是 [Ingress控制器](/docs/concepts/services-networking/ingress-controllers) 的配置选项，并且未在Ingress资源中指定。

 如果没有主机或路径与 Ingress 对象中的 HTTP 请求匹配，则流量将路由到您的默认后端。
@@ -276,7 +276,7 @@ down to a minimum. For example, a setup like:

 ### 简单分列

-分列配置根据请求的 HTTP URI 将流量从单个IP地址路由到多个服务。 
+分列配置根据请求的 HTTP URI 将流量从单个IP地址路由到多个服务。
 通过Ingress，您可以将负载均衡器的数量保持在最低水平。 例如，如下设置：

 ```none
@@ -494,7 +494,7 @@ sure the TLS secret you created came from a certificate that contains a CN
 for `sslexample.foo.com`.
 -->

-在 Ingress 中引用此秘钥会告诉 Ingress 控制器使用 TLS 保护从客户端到负载均衡器的通道。 
+在 Ingress 中引用此秘钥会告诉 Ingress 控制器使用 TLS 保护从客户端到负载均衡器的通道。
 您需要确保创建包含 `sslexample.foo.com` 的 TLS 秘钥的 CN 的证书。

 ```yaml
@@ -528,7 +528,7 @@ platform specific Ingress controller to understand how TLS works in your environ

 各种 Ingress 控制器所支持的 TLS 功能之间存在间隙。请参阅有关文件
 [nginx](https://git.k8s.io/ingress-nginx/README.md#https)，
-[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)， 
+[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)，
 或任何其他平台特定的 Ingress 控制器，以了解 TLS 如何在您的环境中工作。
 {{< /note >}}

@@ -681,7 +681,7 @@ for details on deploying Ingress in a federated cluster.
 ## 跨可用区失败

 用于跨故障域传播流量的技术在云提供商之间是不同的。详情请查阅相关 Ingress 控制器的文档。
-请查看相关[Ingress控制器](/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。 
+请查看相关[Ingress控制器](/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。
 您还可以参考[联合文档](/docs/concepts/cluster-administration/federation/)，以获取有关在联合群集中部署Ingress的详细信息。


@@ -696,7 +696,7 @@ evolution of various Ingress controllers.

 ## 未来的工作

-跟踪 [SIG网络](https://github.com/kubernetes/community/tree/master/sig-network) 详细了解Ingress和相关资源的发展。 
+跟踪 [SIG网络](https://github.com/kubernetes/community/tree/master/sig-network) 详细了解Ingress和相关资源的发展。
 您也可以跟踪 [Ingress信息库](https://github.com/kubernetes/ingress/tree/master) 了解 Ingress 控制器进化的更多信息。

 <!--
@@ -56,7 +56,7 @@ An example `NetworkPolicy` might look like this:

 ## `NetworkPolicy` 资源

-查看 [网络策略](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解资源定义。 
+查看 [网络策略](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 来了解资源定义。

 下面是一个 `NetworkPolicy` 的示例:

@@ -152,7 +152,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-

  * 标签为 "role=frontend" 的 "default" 名称空间中的任何Pod
  * 名称空间中带有标签 "project=myproject" 的任何pod
-  * IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（即，除了 172.17.1.0/24 之外的所有 172.17.0.0/16）  
+  * IP 地址范围为 172.17.0.0–172.17.0.255 和 172.17.2.0–172.17.255.255（即，除了 172.17.1.0/24 之外的所有 172.17.0.0/16）
 3. 允许从带有 "project=myproject" 标签的命名空间下的任何 pod 到 "default" 命名空间下的 pod 的6379 TCP端口的连接。

 查看 [网络策略入门指南](/docs/getting-started-guides/network-policy/walkthrough) 了解更多示例。
@@ -177,7 +177,7 @@ __podSelector__: 这将在与 `NetworkPolicy` 相同的名称空间中选择特

 __namespaceSelector__: 这将选择特定的名称空间，应将所有 Pod 用作其输入源或输出目的地。

-__namespaceSelector__ *和* __podSelector__: 一个指定 `namespaceSelector` 和 `podSelector` 的 `to`/`from` 条目选择特定命名空间中的特定 Pod。注意使用正确的YAML语法；这项政策： 
+__namespaceSelector__ *和* __podSelector__: 一个指定 `namespaceSelector` 和 `podSelector` 的 `to`/`from` 条目选择特定命名空间中的特定 Pod。注意使用正确的YAML语法；这项政策：

 ```yaml
  ...
@@ -184,7 +184,7 @@ port definitions on a Service object.
 Each port definition can have the same `protocol`, or a different one.
 -->

-Pod中的端口定义具有名称字段，您可以在服务的 `targetTarget` 属性中引用这些名称。 
+Pod中的端口定义具有名称字段，您可以在服务的 `targetTarget` 属性中引用这些名称。
 即使服务中使用单个配置的名称混合使用 Pod，并且通过不同的端口号提供相同的网络协议，此功能也可以使用。
 这为部署和发展服务提供了很大的灵活性。
 例如，您可以更改Pods在新版本的后端软件中公开的端口号，而不会破坏客户端。
@@ -306,7 +306,7 @@ endpoints.
 Endpoint Slices provide additional attributes and functionality which is
 described in detail in [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/).
 -->
-Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。 
+Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。
 尽管从概念上讲与 Endpoint 非常相似，但 Endpoint 切片允许跨多个资源分布网络端点。
 默认情况下，一旦到达100个 Endpoint，该 Endpoint 切片将被视为“已满”，届时将创建其他 Endpoint 切片来存储任何其他 Endpoint。

@@ -345,7 +345,7 @@ There are a few reasons for using proxying for Services:

 ### 为什么不使用 DNS 轮询？

-时不时会有人问道，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？ 
+时不时会有人问道，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？
 例如，是否可以配置具有多个A值（或IPv6为AAAA）的DNS记录，并依靠轮询名称解析？

 使用服务代理有以下几个原因：
@@ -504,7 +504,7 @@ falls back to running in iptables proxy mode.

 要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 之前使 IPVS Linux 在节点上可用。

-当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。 
+当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。
 如果未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。

 {{< /note >}}
@@ -699,7 +699,7 @@ You can find more information about `ExternalName` resolution in

 您可以（几乎总是应该）使用[附加组件](/docs/concepts/cluster-administration/addons/)为Kubernetes集群设置DNS服务。

-支持群集的DNS服务器（例如CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 
+支持群集的DNS服务器（例如CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。
 如果在整个群集中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。

 例如，如果您在 Kubernetes 命名空间 `"my-ns"` 中有一个名为 `"my-service"` 的服务，
@@ -708,7 +708,7 @@ You can find more information about `ExternalName` resolution in

 其他命名空间中的Pod必须将名称限定为 `my-service.my-ns` 。 这些名称将解析为为服务分配的群集IP。

-Kubernetes 还支持命名端口的 DNS SRV（服务）记录。 
+Kubernetes 还支持命名端口的 DNS SRV（服务）记录。
 如果 `"my-service.my-ns"` 服务具有名为 `"http"`　的端口，且协议设置为`TCP`，
 则可以对 `_http._tcp.my-service.my-ns` 执行DNS SRV查询查询以发现该端口号, `"http"`以及IP地址。

@@ -888,7 +888,7 @@ For example:

 使用支持外部负载均衡器的云提供商的服务，设置 `type` 的值为 `"LoadBalancer"`，将为 `Service` 提供负载均衡器。
 负载均衡器是异步创建的，关于被提供的负载均衡器的信息将会通过 `Service` 的 `status.loadBalancer` 字段被发布出去。
-实例: 
+实例:

 ```yaml
 apiVersion: v1
@@ -945,10 +945,10 @@ For example, `MC_myResourceGroup_myAKSCluster_eastus`.

 Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the securityGroupName in the cloud provider configuration file. For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see, [Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip) or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357).
 -->
-在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP` ，则首先需要创建静态类型的公共IP地址资源。 
+在 **Azure** 上，如果要使用用户指定的公共类型 `loadBalancerIP` ，则首先需要创建静态类型的公共IP地址资源。
 此公共IP地址资源应与群集中其他自动创建的资源位于同一资源组中。 例如，`MC_myResourceGroup_myAKSCluster_eastus`。

-将分配的IP地址指定为loadBalancerIP。 确保您已更新云提供程序配置文件中的securityGroupName。 
+将分配的IP地址指定为loadBalancerIP。 确保您已更新云提供程序配置文件中的securityGroupName。
 有关对 `CreatingLoadBalancerFailed` 权限问题进行故障排除的信息，
 请参阅 [与Azure Kubernetes服务（AKS）负载平衡器一起使用静态IP地址](https://docs.microsoft.com/en-us/azure/aks/static-ip)或[通过高级网络在AKS群集上创建LoadBalancerFailed](https://github.com/Azure/AKS/issues/357)。
 {{< /note >}}
@@ -1245,7 +1245,7 @@ also be used to set maximum time, in seconds, to keep the existing connections o

 #### AWS上的连接排空

-可以将注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` 设置为 `"true"` 的值来管理 ELB 的连接消耗。 
+可以将注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` 设置为 `"true"` 的值来管理 ELB 的连接消耗。
 注释 `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` 也可以用于设置最大时间（以秒为单位），以保持现有连接在注销实例之前保持打开状态。

 ```yaml
@@ -1388,7 +1388,7 @@ public IP addresses, be aware that non-NLB traffic can also reach all instances
 in those modified security groups.
 -->

-如果未设置 `.spec.loadBalancerSourceRanges` ，则 Kubernetes 允许从 `0.0.0.0/0` 到节点安全组的流量。 
+如果未设置 `.spec.loadBalancerSourceRanges` ，则 Kubernetes 允许从 `0.0.0.0/0` 到节点安全组的流量。
 如果节点具有公共 IP 地址，请注意，非 NLB 流量也可以到达那些修改后的安全组中的所有实例。
 {{< /note >}}

@@ -1404,7 +1404,7 @@ the `my-service` Service in the `prod` namespace to `my.database.example.com`:

 ### 类型ExternalName {#externalname}

-类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择器，例如 `my-service` 或者 `cassandra`。 
+类型为 ExternalName 的服务将服务映射到 DNS 名称，而不是典型的选择器，例如 `my-service` 或者 `cassandra`。
 您可以使用 `spec.externalName` 参数指定这些服务。

 例如，以下 Service 定义将 `prod` 名称空间中的 `my-service` 服务映射到 `my.database.example.com`：
@@ -1427,7 +1427,7 @@ is intended to specify a canonical DNS name. To hardcode an IP address, consider
 [headless Services](#headless-services).
 -->

-ExternalName 接受 IPv4 地址字符串，但作为包含数字的 DNS 名称，而不是 IP 地址。 类似于 IPv4 地址的外部名称不能由 CoreDNS 或 ingress-nginx 解析，因为外部名称旨在指定规范的 DNS 名称。 
+ExternalName 接受 IPv4 地址字符串，但作为包含数字的 DNS 名称，而不是 IP 地址。 类似于 IPv4 地址的外部名称不能由 CoreDNS 或 ingress-nginx 解析，因为外部名称旨在指定规范的 DNS 名称。
 要对 IP 地址进行硬编码，请考虑使用 [headless Services](#headless-services)。
 {{< /note >}}

@@ -1442,7 +1442,7 @@ Service's `type`.
 -->

 当查找主机 `my-service.prod.svc.cluster.local` 时，群集DNS服务返回 `CNAME` 记录，其值为 `my.database.example.com`。
-访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。 
+访问 `my-service` 的方式与其他服务的方式相同，但主要区别在于重定向发生在 DNS 级别，而不是通过代理或转发。
 如果以后您决定将数据库移到群集中，则可以启动其 Pod，添加适当的选择器或端点以及更改服务的`类型`。

 {{< note >}}
@@ -1772,10 +1772,10 @@ Kubernetes supports SCTP as a `protocol` value in Service, Endpoint, NetworkPoli
 When the feature gate is enabled, you can set the `protocol` field of a Service, Endpoint, NetworkPolicy or Pod to `SCTP`. Kubernetes sets up the network accordingly for the SCTP associations, just like it does for TCP connections.
 -->

-Kubernetes 支持 SCTP 作为 Service，Endpoint，NetworkPolicy 和 Pod 定义中的 `协议` 值作为alpha功能。 
+Kubernetes 支持 SCTP 作为 Service，Endpoint，NetworkPolicy 和 Pod 定义中的 `协议` 值作为alpha功能。
 要启用此功能，集群管理员需要在apiserver上启用 `SCTPSupport` 功能门，例如 `--feature-gates = SCTPSupport = true，…`。

-启用功能门后，您可以将服务，端点，NetworkPolicy或Pod的 `protocol` 字段设置为 `SCTP`。 
+启用功能门后，您可以将服务，端点，NetworkPolicy或Pod的 `protocol` 字段设置为 `SCTP`。
 Kubernetes相应地为 SCTP 关联设置网络，就像为 TCP 连接一样。

 <!--
@@ -176,8 +176,8 @@ whatever reclaim policy they were assigned at creation.
 {{< feature-state for_k8s_version="v1.11" state="beta" >}}

 <!--
-Persistent Volumes can be configured to be expandable. This feature when set to `true`, 
-allows the users to resize the volume by editing the corresponding PVC object. 
+Persistent Volumes can be configured to be expandable. This feature when set to `true`,
+allows the users to resize the volume by editing the corresponding PVC object.

 The following types of volumes support volume expansion, when the underlying
 Storage Class has the field `allowVolumeExpansion` set to true.
@@ -646,7 +646,7 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部
 -->
    `diskformat`: `thin`, `zeroedthick` 和 `eagerzeroedthick`。默认值: `"thin"`。

-<!--    
+<!--
 2. Create a StorageClass with a disk format on a user specified datastore.
 -->
 2. 在用户指定的数据存储上创建磁盘格式的 StorageClass。
@@ -942,8 +942,8 @@ parameters:
  When `kind` is `shared`, all unmanaged disks are created in a few shared
  storage accounts in the same resource group as the cluster. When `kind` is
  `dedicated`, a new dedicated storage account will be created for the new
-  unmanaged disk in the same resource group as the cluster. When `kind` is 
-  `managed`, all managed disks are created in the same resource group as 
+  unmanaged disk in the same resource group as the cluster. When `kind` is
+  `managed`, all managed disks are created in the same resource group as
  the cluster.
 -->
 * `storageaccounttype`：Azure 存储帐户 Sku 层。默认为空。
@@ -985,12 +985,12 @@ parameters:
  group are searched to find one that matches `skuName` and `location`. If a
  storage account is provided, it must reside in the same resource group as the
  cluster, and `skuName` and `location` are ignored.
-* `secretNamespace`: the namespace of the secret that contains the Azure Storage 
+* `secretNamespace`: the namespace of the secret that contains the Azure Storage
  Account Name and Key. Default is the same as the Pod.
 * `secretName`: the name of the secret that contains the Azure Storage Account Name and
  Key. Default is `azure-storage-account-<accountName>-secret`
 * `readOnly`: a flag indicating whether the storage will be mounted as read only.
-  Defaults to false which means a read/write mount. This setting will impact the 
+  Defaults to false which means a read/write mount. This setting will impact the
  `ReadOnly` setting in VolumeMounts as well.
 -->
 * `skuName`：Azure 存储帐户 Sku 层。默认为空。
@@ -1003,9 +1003,9 @@ parameters:
 * `readOnly`：指示是否将存储安装为只读的标志。默认为 false，表示 读/写 挂载。 该设置也会影响VolumeMounts中的 `ReadOnly` 设置。

 <!--
-During storage provisioning, a secret named by `secretName` is created for the 
-mounting credentials. If the cluster has enabled both 
-[RBAC](/docs/reference/access-authn-authz/rbac/) and 
+During storage provisioning, a secret named by `secretName` is created for the
+mounting credentials. If the cluster has enabled both
+[RBAC](/docs/reference/access-authn-authz/rbac/) and
 [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles),
 add the `create` permission of resource `secret` for clusterrole
 `system:controller:persistent-volume-binder`.
@@ -1014,7 +1014,7 @@ add the `create` permission of resource `secret` for clusterrole
 为 `system:controller:persistent-volume-binder` 的 clusterrole 添加 `secret` 资源的 `create` 权限。

 <!--
-In a multi-tenancy context, it is strongly recommended to set the value for 
+In a multi-tenancy context, it is strongly recommended to set the value for
 `secretNamespace` explicitly, otherwise the storage account credentials may
 be read by other users.
 -->
@@ -5,28 +5,28 @@ content_template: templates/concept

 {{% capture overview %}}

-<!-- 
+<!--
 This page describes the maximum number of volumes that can be attached
 to a Node for various cloud providers.
 -->

 此页面描述了各个云供应商可关联至一个节点的最大卷数。

-<!-- 
+<!--
 Cloud providers like Google, Amazon, and Microsoft typically have a limit on
 how many volumes can be attached to a Node. It is important for Kubernetes to
 respect those limits. Otherwise, Pods scheduled on a Node could get stuck
 waiting for volumes to attach.
 -->

-谷歌、亚马逊和微软等云供应商通常对可以关联到节点的卷数量进行限制。 
+谷歌、亚马逊和微软等云供应商通常对可以关联到节点的卷数量进行限制。
 Kubernetes 需要尊重这些限制。 否则，在节点上调度的 Pod 可能会卡住去等待卷的关联。

 {{% /capture %}}

 {{% capture body %}}

-<!-- 
+<!--
 ## Kubernetes default limits

 The Kubernetes scheduler has default limits on the number of volumes
@@ -36,7 +36,7 @@ that can be attached to a Node:
 ## Kubernetes 的默认限制

 The Kubernetes 调度器对关联于一个节点的卷数有默认限制：
-<!-- 
+<!--
 <table>
  <tr><th>Cloud service</th><th>Maximum volumes per Node</th></tr>
  <tr><td><a href="https://aws.amazon.com/ebs/">Amazon Elastic Block Store (EBS)</a></td><td>39</td></tr>
@@ -51,7 +51,7 @@ The Kubernetes 调度器对关联于一个节点的卷数有默认限制：
  <tr><td><a href="https://azure.microsoft.com/en-us/services/storage/main-disks/">Microsoft Azure Disk Storage</a></td><td>16</td></tr>
 </table>

-<!-- 
+<!--
 ## Custom limits

 You can change these limits by setting the value of the
@@ -72,7 +72,7 @@ The limit applies to the entire cluster, so it affects all Nodes.

 此限制应用于整个集群，所以它会影响所有节点。

-<!-- 
+<!--
 ## Dynamic volume limits
 -->

@@ -80,7 +80,7 @@ The limit applies to the entire cluster, so it affects all Nodes.

 {{< feature-state state="beta" for_k8s_version="v1.12" >}}

-<!-- 
+<!--
 Kubernetes 1.11 introduced support for dynamic volume limits based on Node type as an Alpha feature.
 In Kubernetes 1.12 this feature is graduating to Beta and will be enabled by default.

@@ -102,7 +102,7 @@ Kubernetes 1.11 引入了基于节点类型的动态卷限制的支持作为 Alp
 - Azure Disk
 - CSI

-<!-- 
+<!--
 When the dynamic volume limits feature is enabled, Kubernetes automatically
 determines the Node type and enforces the appropriate number of attachable
 volumes for the node. For example:
@@ -110,7 +110,7 @@ volumes for the node. For example:

 启用动态卷限制功能后，Kubernetes 会自动确定节点类型并确保节点上可关联的卷数目合规。 例如：

-<!-- 
+<!--
 * On
 <a href="https://cloud.google.com/compute/">Google Compute Engine</a>,
 up to 128 volumes can be attached to a node, [depending on the node
@@ -6,7 +6,7 @@ weight: 20

 {{% capture overview %}}

-<!-- 
+<!--
 This document describes the concept of `VolumeSnapshotClass` in Kubernetes. Familiarity
 with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
 [storage classes](/docs/concepts/storage/storage-classes) is suggested.
@@ -19,7 +19,7 @@ with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and

 {{% capture body %}}

-<!-- 
+<!--
 ## Introduction

 Just like `StorageClass` provides a way for administrators to describe the "classes"
@@ -31,7 +31,7 @@ way to describe the "classes" of storage when provisioning a volume snapshot.

 就像 `StorageClass` 为管理员提供了一种在配置卷时描述存储“类”的方法，`VolumeSnapshotClass` 提供了一种在配置卷快照时描述存储“类”的方法。

-<!-- 
+<!--
 ## The VolumeSnapshotClass Resource

 Each `VolumeSnapshotClass` contains the fields `snapshotter` and `parameters`,
@@ -66,18 +66,18 @@ snapshotter: csi-hostpath
 parameters:
 ```

-<!-- 
+<!--
 ### Snapshotter

 Volume snapshot classes have a snapshotter that determines what CSI volume plugin is
 used for provisioning VolumeSnapshots. This field must be specified.
 -->
- 
+
 ### 快照生成器（Snapshotter）

 卷快照类具有一个快照生成器，用于确定配置 VolumeSnapshot 的 CSI 卷插件。 必须指定此字段。

-<!-- 
+<!--
 ## Parameters

 Volume snapshot classes have parameters that describe volume snapshots belonging to
@@ -29,7 +29,7 @@ Kubernetes 抽象出 `Volume` 对象来解决这两个问题。
 Familiarity with [Pods](/docs/user-guide/pods) is suggested.
 -->

-阅读本文前建议您熟悉一下 [Pods](/docs/user-guide/pods)。 
+阅读本文前建议您熟悉一下 [Pods](/docs/user-guide/pods)。

 {{% /capture %}}

@@ -473,7 +473,7 @@ It mounts a directory and writes the requested data in plain text files.
 -->

 `downwardAPI` 卷用于使 downward API 数据对应用程序可用。
-这种卷类型挂载一个目录并在纯文本文件中写入请求的数据。 
+这种卷类型挂载一个目录并在纯文本文件中写入请求的数据。

 {{< note >}}

@@ -1149,7 +1149,7 @@ guide](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner).

 您可以在 Kubernetes 之外单独运行静态驱动以改进对 local 卷的生命周期管理。
 请注意，此驱动不支持动态配置。
-有关如何运行外部 `local` 卷驱动的示例，请参考 
+有关如何运行外部 `local` 卷驱动的示例，请参考
 [local 卷驱动用户指南](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner)。

 {{< note >}}
@@ -1502,7 +1502,7 @@ means that a RBD volume can be pre-populated with data, and that data can
 be "handed off" between Pods.
 -->

-`rbd` 卷允许将 [Rados 块设备](http://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中. 
+`rbd` 卷允许将 [Rados 块设备](http://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中.
 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`rbd` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。
 这意味着 `rbd` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。

@@ -1734,7 +1734,7 @@ You must create VMDK using one of the following methods before using with Pod.
 Choose one of the following methods to create a VMDK.
 -->

-#### 创建 VMDK 卷 
+#### 创建 VMDK 卷

 选择下列方式之一创建 VMDK。

@@ -2086,7 +2086,7 @@ persistent volume:
 - `volumeAttributes`：一个字符串到字符串的映射表，用来设置卷的静态属性。
  该映射必须与 CSI 驱动程序返回的 `CreateVolumeResponse` 中的 `volume.attributes` 字段的映射相对应；[CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中有相应的定义。
  该映射通过`ControllerPublishVolumeRequest`、`NodeStageVolumeRequest`、和 `NodePublishVolumeRequest` 中的 `volume_attributes` 字段传递给 CSI 驱动。
-  
+
 <!--
 - `controllerPublishSecretRef`: A reference to the secret object containing
  sensitive information to pass to the CSI driver to complete the CSI
@@ -2098,7 +2098,7 @@ persistent volume:
 - `controllerPublishSecretRef`：对包含敏感信息的 secret 对象的引用；该敏感信息会被传递给 CSI 驱动来完成 CSI `ControllerPublishVolume` 和 `ControllerUnpublishVolume` 调用。
  此字段是可选的；在不需要 secret 时可以是空的。
  如果 secret 对象包含多个 secret，则所有的 secret 都会被传递。
-   
+
 <!--
 - `nodeStageSecretRef`: A reference to the secret object containing
  sensitive information to pass to the CSI driver to complete the CSI
@@ -2118,7 +2118,7 @@ persistent volume:
  secret is required. If the secret object contains more than one secret, all
  secrets are passed.
 -->
-  
+
 - `nodePublishSecretRef`：对包含敏感信息的 secret 对象的引用，以传递给 CSI 驱动来完成 CSI ``NodePublishVolume` 调用。
  此字段是可选的，如果不需要 secret，则可能是空的。
  如果 secret 对象包含多个 secret，则传递所有 secret。
@@ -2308,9 +2308,9 @@ Its values are:
   [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
 -->
 * `HostToContainer` - 此卷挂载将会感知到主机后续针对此卷或其任何子目录的挂载操作。
-   
+
  换句话说，如果主机在此挂载卷中挂载任何内容，容器将能看到它被挂载在那里。
-   
+
  类似的，配置了 `Bidirectional` 挂载传播选项的 Pod 如果在同一卷上挂载了内容，挂载传播设置为 `HostToContainer` 的容器都将能看到这一变化。

  该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 中描述的 `rslave` 挂载传播选项。
@@ -159,7 +159,7 @@ Job 根据它所创建的 Pod 的并行度，负责重试创建 Pod，并就决

 和其它 Kubernetes 配置一样，Cron Job 需要 `apiVersion`、 `kind`、和 `metadata` 这三个字段。
 关于如何实现一个配置文件的更新信息，参考文档 [部署应用](/docs/user-guide/deploying-applications)、
-[配置容器](/docs/user-guide/configuring-containers) 和 
+[配置容器](/docs/user-guide/configuring-containers) 和
 [使用 kubectl 管理资源](/docs/user-guide/working-with-resources)。

 Cron Job 也需要 [`.spec` 段](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
@@ -16,7 +16,7 @@ redirect_from:
 _DaemonSet_ 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。
 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

- 
+

 使用 DaemonSet 的一些典型用法：

@@ -188,7 +188,7 @@ pod "myapp-pod" created
 $ kubectl get -f myapp.yaml
 NAME        READY     STATUS     RESTARTS   AGE
 myapp-pod   0/1       Init:0/2   0          6m
-$ kubectl describe -f myapp.yaml 
+$ kubectl describe -f myapp.yaml
 Name:          myapp-pod
 Namespace:     default
 [...]
@@ -268,7 +268,7 @@ Init 容器的端口将不会在 Service 中进行聚集。
 特别地，被写到 `EmptyDirs` 中文件的代码，应该对输出文件可能已经存在做好准备。

 Init 容器具有应用容器的所有字段。
-然而 Kubernetes 禁止使用 `readinessProbe`，因为 Init 容器不能够定义不同于完成（completion）的就绪（readiness）。 
+然而 Kubernetes 禁止使用 `readinessProbe`，因为 Init 容器不能够定义不同于完成（completion）的就绪（readiness）。
 这会在验证过程中强制执行。


@@ -25,7 +25,7 @@ pod 中，这些信息可以包括 secret、 卷、卷挂载和环境变量。

 ## PodPreset 如何工作

-Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时，会将 Pod Preset 
+Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时，会将 Pod Preset
 应用于接收到的 pod 创建请求中。
 当出现 pod 创建请求时，系统会执行以下操作：

@@ -36,9 +36,9 @@ Kubernetes 提供了准入控制器 (`PodPreset`)，该控制器被启用时，
 1. 为改动的 pod spec 添加注解，来表明它被 `PodPreset` 所修改。 注解形如：
 `podpreset.admission.kubernetes.io/podpreset-<pod-preset name>": "<resource version>"`。

-一个 Pod 可能不与任何 Pod Preset 匹配，也可能匹配多个 Pod Preset。 同时，一个 `PodPreset` 
+一个 Pod 可能不与任何 Pod Preset 匹配，也可能匹配多个 Pod Preset。 同时，一个 `PodPreset`
 可能不应用于任何 Pod，也可能应用于多个 Pod。 当 `PodPreset` 应用于一个或多个 Pod 时，Kubernetes
-修改 pod spec。 对于 `Env`、 `EnvFrom` 和 `VolumeMounts` 的改动， Kubernetes 修改 pod 
+修改 pod spec。 对于 `Env`、 `EnvFrom` 和 `VolumeMounts` 的改动， Kubernetes 修改 pod
 中所有容器的规格，对于卷的改动，Kubernetes 修改 Pod spec。

 {{< note >}}