[zh] Sync changes from English site (7)

2020-11-16 14:16:15 +08:00
parent edbab98ce4
commit 089040daa7
10 changed files with 494 additions and 347 deletions
@@ -18,7 +18,7 @@ with [volumes](/docs/concepts/storage/volumes/) and
 [persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
 -->
 本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 [卷](/zh/docs/concepts/storage/volumes/) 和
-[持久卷](/docs/concepts/storage/persistent-volumes) 的概念。
+[持久卷](/zh/docs/concepts/storage/persistent-volumes) 的概念。

 <!-- body -->

@@ -67,7 +67,7 @@ for details.
 -->
 管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类 ：
 更多详情请参阅
-[PersistentVolumeClaim 章节](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
+[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。

 ```yaml
 apiVersion: storage.k8s.io/v1
@@ -90,15 +90,16 @@ volumeBindingMode: Immediate
 Each StorageClass has a provisioner that determines what volume plugin is used
 for provisioning PVs. This field must be specified.
 -->
-### 存储分配器
+### 存储制备器  {#provisioner}

-每个 StorageClass 都有一个分配器，用来决定使用哪个卷插件分配 PV。该字段必须指定。
+每个 StorageClass 都有一个制备器（Provisioner），用来决定使用哪个卷插件制备 PV。
+该字段必须指定。

 <!--
 | Volume Plugin        | Internal Provisioner| Config Example                       |
 -->

-| 卷插件               | 内置分配器 |               配置例子                |
+| 卷插件               | 内置制备器 |               配置例子                |
 |:---------------------|:----------:|:-------------------------------------:|
 | AWSElasticBlockStore |  &#x2713;  |          [AWS EBS](#aws-ebs)          |
 | AzureFile            |  &#x2713;  |       [Azure File](#azure-file)       |
@@ -131,24 +132,25 @@ run, what volume plugin it uses (including Flex), etc. The repository
 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
 houses a library for writing external provisioners that implements the bulk of
 the specification. Some external provisioners are listed under the repository
-[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage).
+[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner).
 -->
-您不限于指定此处列出的 "内置" 分配器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。
-您还可以运行和指定外部分配器，这些独立的程序遵循由 Kubernetes 定义的
+你不限于指定此处列出的 "内置" 制备器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。
+你还可以运行和指定外部制备器，这些独立的程序遵循由 Kubernetes 定义的
 [规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。
 外部供应商的作者完全可以自由决定他们的代码保存于何处、打包方式、运行方式、使用的插件（包括 Flex）等。
 代码仓库 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
-包含一个用于为外部分配器编写功能实现的类库。可以通过下面的代码仓库，查看外部分配器列表。
+包含一个用于为外部制备器编写功能实现的类库。你可以访问代码仓库
+[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
+了解外部驱动列表。

-[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage).

 <!--
 For example, NFS doesn't provide an internal provisioner, but an external
 provisioner can be used. There are also cases when 3rd party storage
 vendors provide their own external provisioner.
 -->
-例如，NFS 没有内部分配器，但可以使用外部分配器。
-也有第三方存储供应商提供自己的外部分配器。
+例如，NFS 没有内部制备器，但可以使用外部制备器。
+也有第三方存储供应商提供自己的外部制备器。

 <!--
 ### Reclaim Policy
@@ -228,7 +230,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid.

 由 StorageClass 动态创建的 PersistentVolume 将使用类中 `mountOptions` 字段指定的挂载选项。

-如果卷插件不支持挂载选项，却指定了该选项，则分配操作会失败。
+如果卷插件不支持挂载选项，却指定了该选项，则制备操作会失败。
 挂载选项在 StorageClass 和 PV 上都不会做验证，所以如果挂载选项无效，那么这个 PV 就会失败。

 <!--
@@ -240,7 +242,7 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
 The `volumeBindingMode` field controls when [volume binding and dynamic
 provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
 -->
-`volumeBindingMode` 字段控制了[卷绑定和动态分配](/docs/concepts/storage/persistent-volumes/#provisioning)
+`volumeBindingMode` 字段控制了[卷绑定和动态制备](/zh/docs/concepts/storage/persistent-volumes/#provisioning)
 应该发生在什么时候。

 <!--
@@ -250,8 +252,9 @@ backends that are topology-constrained and not globally accessible from all Node
 in the cluster, PersistentVolumes will be bound or provisioned without knowledge of the Pod's scheduling
 requirements. This may result in unschedulable Pods.
 -->
-默认情况下，`Immediate` 模式表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态分配。
-对于由于拓扑限制而非集群所有节点可达的存储后端，PersistentVolume 会在不知道 Pod 调度要求的情况下绑定或者分配。
+默认情况下，`Immediate` 模式表示一旦创建了 PersistentVolumeClaim 也就完成了卷绑定和动态制备。
+对于由于拓扑限制而非集群所有节点可达的存储后端，PersistentVolume
+会在不知道 Pod 调度要求的情况下绑定或者制备。

 <!--
 A cluster administrator can address this issue by specifying the `WaitForFirstConsumer` mode which
@@ -265,8 +268,8 @@ anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-a
 and [taints and tolerations](/docs/concepts/configuration/taint-and-toleration).
 -->
 集群管理员可以通过指定 `WaitForFirstConsumer` 模式来解决此问题。
-该模式将延迟 PersistentVolume 的绑定和分配，直到使用该 PersistentVolumeClaim 的 Pod 被创建。
-PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或分配。这些包括但不限于
+该模式将延迟 PersistentVolume 的绑定和制备，直到使用该 PersistentVolumeClaim 的 Pod 被创建。
+PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或制备。这些包括但不限于
 [资源需求](/zh/docs/concepts/configuration/manage-resources-containers/)、
 [节点筛选器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)、
 [pod 亲和性和互斥性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)、
@@ -279,7 +282,7 @@ The following plugins support `WaitForFirstConsumer` with dynamic provisioning:
 * [GCEPersistentDisk](#gce-pd)
 * [AzureDisk](#azure-disk)
 -->
-以下插件支持动态分配的 `WaitForFirstConsumer` 模式:
+以下插件支持动态供应的 `WaitForFirstConsumer` 模式:

 * [AWSElasticBlockStore](#aws-ebs)
 * [GCEPersistentDisk](#gce-pd)
@@ -304,7 +307,7 @@ and pre-created PVs, but you'll need to look at the documentation for a specific
 to see its supported topology keys and examples.
 -->
 动态配置和预先创建的 PV 也支持 [CSI卷](/zh/docs/concepts/storage/volumes/#csi)，
-但是您需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。
+但是你需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。

 <!--
 ### Allowed Topologies
@@ -317,7 +320,8 @@ When a cluster operator specifies the `WaitForFirstConsumer` volume binding mode
 to restrict provisioning to specific topologies in most situations. However,
 if still required, `allowedTopologies` can be specified.
 -->
-当集群操作人员使用了 `WaitForFirstConsumer` 的卷绑定模式，在大部分情况下就没有必要将配置限制为特定的拓扑结构。
+当集群操作人员使用了 `WaitForFirstConsumer` 的卷绑定模式，
+在大部分情况下就没有必要将制备限制为特定的拓扑结构。
 然而，如果还有需要的话，可以使用 `allowedTopologies`。

 <!--
@@ -325,7 +329,8 @@ This example demonstrates how to restrict the topology of provisioned volumes to
 zones and should be used as a replacement for the `zone` and `zones` parameters for the
 supported plugins.
 -->
-这个例子描述了如何将分配卷的拓扑限制在特定的区域，在使用时应该根据插件支持情况替换 `zone` 和 `zones` 参数。
+这个例子描述了如何将供应卷的拓扑限制在特定的区域，在使用时应该根据插件
+支持情况替换 `zone` 和 `zones` 参数。

 ```yaml
 apiVersion: storage.k8s.io/v1
@@ -359,10 +364,12 @@ exceed 256 KiB.
 -->
 ## 参数

-Storage class 具有描述属于卷的参数。取决于分配器，可以接受不同的参数。
-例如，参数 type 的值 io1 和参数 iopsPerGB 特定于 EBS PV。当参数被省略时，会使用默认值。
+Storage class 具有描述属于卷的参数。取决于制备器，可以接受不同的参数。
+例如，参数 type 的值 io1 和参数 iopsPerGB 特定于 EBS PV。
+当参数被省略时，会使用默认值。

-一个 StorageClass 最多可以定义 512 个参数。这些参数对象的总长度不能超过 256 KiB, 包括参数的键和值。
+一个 StorageClass 最多可以定义 512 个参数。这些参数对象的总长度不能
+超过 256 KiB, 包括参数的键和值。

 ### AWS EBS

@@ -405,9 +412,11 @@ parameters:
 * `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见
  [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。
 * `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`，
-  通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone` 和 `zones` 参数不能同时使用。
+  通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。
+  `zone` 和 `zones` 参数不能同时使用。
 * `zones`(弃用)：以逗号分隔的 AWS 区域列表。
-  如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。
+  如果没有指定 `zone` 和 `zones`，通常卷会在 Kubernetes 集群节点所在的
+  活动区域中轮询调度分配。`zone`和`zones`参数不能同时使用。
 * `iopsPerGB`：只适用于 `io1` 卷。每 GiB 每秒 I/O 操作。
  AWS 卷插件将其与请求卷的大小相乘以计算 IOPS 的容量，
  并将其限制在 20000 IOPS（AWS 支持的最高值，请参阅
@@ -465,7 +474,7 @@ parameters:
 <!--
 If `replication-type` is set to `none`, a regular (zonal) PD will be provisioned.
 -->
-如果 `replication-type` 设置为 `none`，会分配一个常规（当前区域内的）持久化磁盘。
+如果 `replication-type` 设置为 `none`，会制备一个常规（当前区域内的）持久化磁盘。

 <!--
 If `replication-type` is set to `regional-pd`, a
@@ -477,10 +486,10 @@ specified, Kubernetes will arbitrarily choose among the specified zones. If the
 `zones` parameter is omitted, Kubernetes will arbitrarily choose among zones
 managed by the cluster.
 -->
-如果 `replication-type` 设置为 `regional-pd`，会分配一个
+如果 `replication-type` 设置为 `regional-pd`，会制备一个
 [区域性持久化磁盘（Regional Persistent Disk）](https://cloud.google.com/compute/docs/disks/#repds)。
 在这种情况下，用户必须使用 `zones` 而非 `zone` 来指定期望的复制区域（zone）。
-如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里分配。
+如果指定来两个特定的区域，区域性持久化磁盘会在这两个区域里制备。
 如果指定了多于两个的区域，Kubernetes 会选择其中任意两个区域。
 如果省略了 `zones` 参数，Kubernetes 会在集群管理的区域中任意选择。

@@ -530,8 +539,8 @@ parameters:
  for authentication to the REST server. This parameter is deprecated in favor
  of `secretNamespace` + `secretName`.
 -->
-* `resturl`：分配 gluster 卷的需求的 Gluster REST 服务/Heketi 服务 url。
-  通用格式应该是 `IPaddress:Port`，这是 GlusterFS 动态分配器的必需参数。
+* `resturl`：制备 gluster 卷的需求的 Gluster REST 服务/Heketi 服务 url。
+  通用格式应该是 `IPaddress:Port`，这是 GlusterFS 动态制备器的必需参数。
  如果 Heketi 服务在 OpenShift/kubernetes 中安装并暴露为可路由服务，则可以使用类似于
  `http://heketi-storage-project.cloudapps.mystorage.com` 的格式，其中 fqdn 是可解析的 heketi 服务网址。
 * `restauthenabled`：Gluster REST 服务身份验证布尔值，用于启用对 REST 服务器的身份验证。
@@ -557,7 +566,8 @@ parameters:
    Example of a secret can be found in
    [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml).
 -->
-* `secretNamespace`，`secretName`：Secret 实例的标识，包含与 Gluster REST 服务交互时使用的用户密码。
+* `secretNamespace`，`secretName`：Secret 实例的标识，包含与 Gluster
+  REST 服务交互时使用的用户密码。
  这些参数是可选的，`secretNamespace` 和 `secretName` 都省略时使用空密码。
  所提供的 Secret 必须将类型设置为 "kubernetes.io/glusterfs"，例如以这种方式创建：

@@ -581,12 +591,13 @@ parameters:
  specified, the volume will be provisioned with a value between 2000-2147483647
  which are defaults for gidMin and gidMax respectively.
 -->
-* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当分配卷时，
+* `clusterid`：`630372ccdc720a92c681fb928f27b53f` 是集群的 ID，当制备卷时，
  Heketi 将会使用这个文件。它也可以是一个 clusterid 列表，例如：
  `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`。这个是可选参数。
 * `gidMin`，`gidMax`：storage class GID 范围的最小值和最大值。
-  在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态分配卷。这些是可选的值。
-  如果不指定，卷将被分配一个 2000-2147483647 之间的值，这是 gidMin 和 gidMax 的默认值。
+  在此范围（gidMin-gidMax）内的唯一值（GID）将用于动态制备卷。这些是可选的值。
+  如果不指定，所制备的卷为一个 2000-2147483647 之间的值，这是 gidMin 和
+  gidMax 的默认值。

 <!--
 * `volumetype` : The volume type and its parameters can be configured with this
@@ -609,18 +620,22 @@ parameters:
    `gluster-dynamic-<claimname>`. The dynamic endpoint and service are automatically
    deleted when the persistent volume claim is deleted.
 -->
-* `volumetype`：卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型，则由分配器决定卷的类型。
-   例如：
+* `volumetype`：卷的类型及其参数可以用这个可选值进行配置。如果未声明卷类型，则
+  由制备器决定卷的类型。
+  例如：

-   * 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量.
-   * 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量.
-   * 'Distribute volume': `volumetype: none`
+  * 'Replica volume': `volumetype: replicate:3` 其中 '3' 是 replica 数量.
+  * 'Disperse/EC volume': `volumetype: disperse:4:2` 其中 '4' 是数据，'2' 是冗余数量.
+  * 'Distribute volume': `volumetype: none`

-  有关可用的卷类型和管理选项，请参阅 [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。
+  有关可用的卷类型和管理选项，请参阅
+  [管理指南](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html)。

-  更多相关的参考信息，请参阅 [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。
+  更多相关的参考信息，请参阅
+  [如何配置 Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology)。

-  当动态分配持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>` 的端点和 headless service。在 PVC 被删除时动态端点和 headless service 会自动被删除。
+  当动态制备持久卷时，Gluster 插件自动创建名为 `gluster-dynamic-<claimname>`
+  的端点和无头服务。在 PVC 被删除时动态端点和无头服务会自动被删除。

 ### OpenStack Cinder

@@ -638,7 +653,8 @@ parameters:
 * `availability`: Availability Zone. If not specified, volumes are generally
  round-robin-ed across all active zones where Kubernetes cluster has a node.
 -->
-* `availability`：可用区域。如果没有指定，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。
+* `availability`：可用区域。如果没有指定，通常卷会在 Kubernetes 集群节点
+  所在的活动区域中轮转调度。

 <!--
 {{< note >}}
@@ -648,7 +664,8 @@ This internal provisioner of OpenStack is deprecated. Please use [the external c
 -->
 {{< note >}}
 {{< feature-state state="deprecated" for_k8s_version="1.11" >}}
-OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部驱动程序](https://github.com/kubernetes/cloud-provider-openstack)。
+OpenStack 的内部驱动已经被弃用。请使用
+[OpenStack 的外部云驱动](https://github.com/kubernetes/cloud-provider-openstack)。
 {{< /note >}}

 ### vSphere
@@ -658,108 +675,107 @@ OpenStack 的内部驱动程序已经被弃用。请使用 [OpenStack 的外部
 -->
 1. 使用用户指定的磁盘格式创建一个 StorageClass。

-    ```yaml
-    apiVersion: storage.k8s.io/v1
-    kind: StorageClass
-    metadata:
-      name: fast
-    provisioner: kubernetes.io/vsphere-volume
-    parameters:
-      diskformat: zeroedthick
-    ```
+   ```yaml
+   apiVersion: storage.k8s.io/v1
+   kind: StorageClass
+   metadata:
+     name: fast
+   provisioner: kubernetes.io/vsphere-volume
+   parameters:
+     diskformat: zeroedthick
+   ```

-    <!--
-    `diskformat`: `thin`, `zeroedthick` and `eagerzeroedthick`. Default: `"thin"`.
-    -->
-
-    `diskformat`: `thin`, `zeroedthick` 和 `eagerzeroedthick`。默认值: `"thin"`。
+   <!--
+   `diskformat`: `thin`, `zeroedthick` and `eagerzeroedthick`. Default: `"thin"`.
+   -->
+   `diskformat`: `thin`, `zeroedthick` 和 `eagerzeroedthick`。默认值: `"thin"`。

 <!--
 2. Create a StorageClass with a disk format on a user specified datastore.
 -->
 2. 在用户指定的数据存储上创建磁盘格式的 StorageClass。

-    ```yaml
-    apiVersion: storage.k8s.io/v1
-    kind: StorageClass
-    metadata:
-      name: fast
-    provisioner: kubernetes.io/vsphere-volume
-    parameters:
-        diskformat: zeroedthick
-        datastore: VSANDatastore
-    ```
+   ```yaml
+   apiVersion: storage.k8s.io/v1
+   kind: StorageClass
+   metadata:
+     name: fast
+   provisioner: kubernetes.io/vsphere-volume
+   parameters:
+       diskformat: zeroedthick
+       datastore: VSANDatastore
+   ```

-    <!--
-    `datastore`: The user can also specify the datastore in the StorageClass.
-    The volume will be created on the datastore specified in the storage class,
-    which in this case is `VSANDatastore`. This field is optional. If the
-    datastore is not specified, then the volume will be created on the datastore
-    specified in the vSphere config file used to initialize the vSphere Cloud
-    Provider.
-    -->
+   <!--
+   `datastore`: The user can also specify the datastore in the StorageClass.
+   The volume will be created on the datastore specified in the storage class,
+   which in this case is `VSANDatastore`. This field is optional. If the
+   datastore is not specified, then the volume will be created on the datastore
+   specified in the vSphere config file used to initialize the vSphere Cloud
+   Provider.
+   -->

-    `datastore`：用户也可以在 StorageClass 中指定数据存储。
-    卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。
-    该字段是可选的。
-    如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere 
-    配置文件中指定的数据存储上创建该卷。
+   `datastore`：用户也可以在 StorageClass 中指定数据存储。
+   卷将在 storage class 中指定的数据存储上创建，在这种情况下是 `VSANDatastore`。
+   该字段是可选的。
+   如果未指定数据存储，则将在用于初始化 vSphere Cloud Provider 的 vSphere 
+   配置文件中指定的数据存储上创建该卷。

 <!--
 3. Storage Policy Management inside kubernetes
 -->
 3. Kubernetes 中的存储策略管理

-    <!--
-    * Using existing vCenter SPBM policy
+   <!--
+   * Using existing vCenter SPBM policy

-        One of the most important features of vSphere for Storage Management is
-        policy based Management. Storage Policy Based Management (SPBM) is a
-        storage policy framework that provides a single unified control plane
-        across a broad range of data services and storage solutions. SPBM enables
-        vSphere administrators to overcome upfront storage provisioning challenges,
-        such as capacity planning, differentiated service levels and managing
-        capacity headroom.
+     One of the most important features of vSphere for Storage Management is
+     policy based Management. Storage Policy Based Management (SPBM) is a
+     storage policy framework that provides a single unified control plane
+     across a broad range of data services and storage solutions. SPBM enables
+     vSphere administrators to overcome upfront storage provisioning challenges,
+     such as capacity planning, differentiated service levels and managing
+     capacity headroom.

-        The SPBM policies can be specified in the StorageClass using the
-        `storagePolicyName` parameter.
+     The SPBM policies can be specified in the StorageClass using the
+     `storagePolicyName` parameter.
    -->

    * 使用现有的 vCenter SPBM 策略

-        vSphere 用于存储管理的最重要特性之一是基于策略的管理。
-        基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的
-        跨越广泛的数据服务和存储解决方案。
-        SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。
+      vSphere 用于存储管理的最重要特性之一是基于策略的管理。
+      基于存储策略的管理（SPBM）是一个存储策略框架，提供单一的统一控制平面的
+      跨越广泛的数据服务和存储解决方案。
+      SPBM 使能 vSphere 管理员克服先期的存储配置挑战，如容量规划，差异化服务等级和管理容量空间。

-        SPBM 策略可以在 StorageClass 中使用 `storagePolicyName` 参数声明。
+      SPBM 策略可以在 StorageClass 中使用 `storagePolicyName` 参数声明。

    <!--
    * Virtual SAN policy support inside Kubernetes

-        Vsphere Infrastructure (VI) Admins will have the ability to specify custom
-        Virtual SAN Storage Capabilities during dynamic volume provisioning. You
-        can now define storage requirements, such as performance and availability,
-        in the form of storage capabilities during dynamic volume provisioning.
-        The storage capability requirements are converted into a Virtual SAN
-        policy which are then pushed down to the Virtual SAN layer when a
-        persistent volume (virtual disk) is being created. The virtual disk is
-        distributed across the Virtual SAN datastore to meet the requirements.
+      Vsphere Infrastructure (VI) Admins will have the ability to specify custom
+      Virtual SAN Storage Capabilities during dynamic volume provisioning. You
+      can now define storage requirements, such as performance and availability,
+      in the form of storage capabilities during dynamic volume provisioning.
+      The storage capability requirements are converted into a Virtual SAN
+      policy which are then pushed down to the Virtual SAN layer when a
+      persistent volume (virtual disk) is being created. The virtual disk is
+      distributed across the Virtual SAN datastore to meet the requirements.

-        You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)
-        for more details on how to use storage policies for persistent volumes
-        management.
+      You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)
+      for more details on how to use storage policies for persistent volumes
+      management.
    -->

    * Kubernetes 内的 Virtual SAN 策略支持

-        Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN
-        存储功能。您现在可以定义存储需求，例如性能和可用性，当动态卷供分配时会以存储功能的形式提供。
-        存储功能需求会转换为 Virtual SAN 策略，然后当持久卷（虚拟磁盘）在创建时，
-        会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。
+      Vsphere Infrastructure（VI）管理员将能够在动态卷配置期间指定自定义 Virtual SAN
+      存储功能。你现在可以在动态制备卷期间以存储能力的形式定义存储需求，例如性能和可用性。
+      存储能力需求会转换为 Virtual SAN 策略，之后当持久卷（虚拟磁盘）被创建时，
+      会将其推送到 Virtual SAN 层。虚拟磁盘分布在 Virtual SAN 数据存储中以满足要求。

-        更多有关 persistent volume 管理的存储策略的详细信息，
-        您可以参考 [基于存储策略的动态分配卷管理](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)。
+      你可以参考[基于存储策略的动态制备卷管理](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)，
+      进一步了解有关持久卷管理的存储策略的详细信息。

 <!--
 There are few
@@ -767,7 +783,7 @@ There are few
 which you try out for persistent volume management inside Kubernetes for vSphere.
 -->
 有几个 [vSphere 例子](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)
-供您在 Kubernetes for vSphere 中尝试进行 persistent volume 管理。
+供你在 Kubernetes for vSphere 中尝试进行持久卷管理。

 ### Ceph RBD

@@ -882,7 +898,7 @@ parameters:
 * `registry`：用于挂载卷的 Quobyte registry。你可以指定 registry 为 ``<host>:<port>``
  或者如果你想指定多个 registry，你只需要在他们之间添加逗号，例如
  ``<host1>:<port>,<host2>:<port>,<host3>:<port>``。
-  主机可以是一个 IP 地址，或者如果您有正在运行的 DNS，您也可以提供 DNS 名称。
+  主机可以是一个 IP 地址，或者如果你有正在运行的 DNS，你也可以提供 DNS 名称。
 * `adminSecretNamespace`：`adminSecretName`的 namespace。
  默认值是 "default"。

@@ -920,7 +936,7 @@ parameters:
 -->
 * `user`：对这个用户映射的所有访问权限。默认是 "root"。
 * `group`：对这个组映射的所有访问权限。默认是 "nfsnobody"。
-* `quobyteConfig`：使用指定的配置来创建卷。您可以创建一个新的配置，或者，可以修改 Web console 或
+* `quobyteConfig`：使用指定的配置来创建卷。你可以创建一个新的配置，或者，可以修改 Web console 或
  quobyte CLI 中现有的配置。默认是 "BASE"。
 * `quobyteTenant`：使用指定的租户 ID 创建/删除卷。这个 Quobyte 租户必须已经于 Quobyte。
  默认是 "DEFAULT"。
@@ -1053,17 +1069,19 @@ mounting credentials. If the cluster has enabled both
 add the `create` permission of resource `secret` for clusterrole
 `system:controller:persistent-volume-binder`.
 -->
-在存储分配期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了
-[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和 [控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)，
-为 `system:controller:persistent-volume-binder` 的 clusterrole 添加 `secret` 资源的 `create` 权限。
+在存储制备期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了
+[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和
+[控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)，
+为 `system:controller:persistent-volume-binder` 的 clusterrole 添加
+`Secret` 资源的 `create` 权限。

 <!--
 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.
 -->
-
-在多租户上下文中，强烈建议显式设置 `secretNamespace` 的值，否则其他用户可能会读取存储帐户凭据。
+在多租户上下文中，强烈建议显式设置 `secretNamespace` 的值，否则
+其他用户可能会读取存储帐户凭据。

 <!--
 ### Portworx Volume
@@ -1108,14 +1126,19 @@ parameters:
 * `block_size`：以 Kbytes 为单位的块大小（默认值：`32`）。
 * `repl`：同步副本数量，以复制因子 `1..3`（默认值：`1`）的形式提供。
  这里需要填写字符串，即，`"1"` 而不是 `1`。
-* `io_priority`：决定是否从更高性能或者较低优先级存储创建卷 `high/medium/low`（默认值：`low`）。
-* `snap_interval`：触发快照的时钟/时间间隔（分钟）。快照是基于与先前快照的增量变化，0 是禁用快照（默认：`0`）。
+* `io_priority`：决定是否从更高性能或者较低优先级存储创建卷
+  `high/medium/low`（默认值：`low`）。
+* `snap_interval`：触发快照的时钟/时间间隔（分钟）。
+  快照是基于与先前快照的增量变化，0 是禁用快照（默认：`0`）。
  这里需要填写字符串，即，是 `"70"` 而不是 `70`。
 * `aggregation_level`：指定卷分配到的块数量，0 表示一个非聚合卷（默认：`0`）。
  这里需要填写字符串，即，是 `"0"` 而不是 `0`。
-* `ephemeral`：指定卷在卸载后进行清理还是持久化。 `emptyDir` 的使用场景可以将这个值设置为 true ，
-  `persistent volumes` 的使用场景可以将这个值设置为 false（例如 Cassandra 这样的数据库）
-  `true/false`（默认为 `false`）。这里需要填写字符串，即，是 `"true"` 而不是 `true`。
+* `ephemeral`：指定卷在卸载后进行清理还是持久化。
+  `emptyDir` 的使用场景可以将这个值设置为 true ，
+  `persistent volumes` 的使用场景可以将这个值设置为 false
+  （例如 Cassandra 这样的数据库）
+  `true/false`（默认为 `false`）。这里需要填写字符串，即，
+  是 `"true"` 而不是 `true`。

 ### ScaleIO

@@ -1171,8 +1194,8 @@ kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \
 ```
 -->
 ScaleIO Kubernetes 卷插件需要配置一个 Secret 对象。
-secret 必须用 `kubernetes.io/scaleio` 类型创建，并与引用它的 PVC 所属的名称空间使用相同的值
-如下面的命令所示：
+Secret 必须用 `kubernetes.io/scaleio` 类型创建，并与引用它的
+PVC 所属的名称空间使用相同的值。如下面的命令所示：

 ```shell
 kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \
@@ -1210,13 +1233,17 @@ parameters:
 * `adminSecretName`: The name of the secret to use for obtaining the StorageOS
  API credentials. If not specified, default values will be attempted.
 -->
-* `pool`：分配卷的 StorageOS 分布式容量池的名称。如果未指定，则使用通常存在的 `default` 池。
-* `description`：分配给动态创建的卷的描述。所有卷描述对于 storage class 都是相同的，
+* `pool`：制备卷的 StorageOS 分布式容量池的名称。如果未指定，则使用
+  通常存在的 `default` 池。
+* `description`：指定给动态创建的卷的描述。所有卷描述对于存储类而言都是相同的，
  但不同的 storage class 可以使用不同的描述，以区分不同的使用场景。
  默认为 `Kubernetas volume`。
-* `fsType`：请求的默认文件系统类型。请注意，在 StorageOS 中用户定义的规则可以覆盖此值。默认为 `ext4`
-* `adminSecretNamespace`：API 配置 secret 所在的命名空间。如果设置了 adminSecretName，则是必需的。
-* `adminSecretName`：用于获取 StorageOS API 凭证的 secret 名称。如果未指定，则将尝试默认值。
+* `fsType`：请求的默认文件系统类型。
+  请注意，在 StorageOS 中用户定义的规则可以覆盖此值。默认为 `ext4`
+* `adminSecretNamespace`：API 配置 secret 所在的命名空间。
+  如果设置了 adminSecretName，则是必需的。
+* `adminSecretName`：用于获取 StorageOS API 凭证的 secret 名称。
+  如果未指定，则将尝试默认值。

 <!--
 The StorageOS Kubernetes volume plugin can use a Secret object to specify an
@@ -1253,7 +1280,8 @@ and referenced with the `adminSecretNamespace` parameter. Secrets used by
 pre-provisioned volumes must be created in the same namespace as the PVC that
 references it.
 -->
-用于动态分配卷的 Secret 可以在任何名称空间中创建，并通过 `adminSecretNamespace` 参数引用。
+用于动态制备卷的 Secret 可以在任何名称空间中创建，并通过
+`adminSecretNamespace` 参数引用。
 预先配置的卷使用的 Secret 必须在与引用它的 PVC 在相同的名称空间中。

 <!--
@@ -1277,13 +1305,14 @@ Local volumes do not currently support dynamic provisioning, however a StorageCl
 should still be created to delay volume binding until pod scheduling. This is
 specified by the `WaitForFirstConsumer` volume binding mode.
 -->
-本地卷还不支持动态分配，然而还是需要创建 StorageClass 以延迟卷绑定，直到完成 pod 的调度。这是由 `WaitForFirstConsumer` 卷绑定模式指定的。
+本地卷还不支持动态制备，然而还是需要创建 StorageClass 以延迟卷绑定，
+直到完成 Pod 的调度。这是由 `WaitForFirstConsumer` 卷绑定模式指定的。

 <!--
 Delaying volume binding allows the scheduler to consider all of a pod's
 scheduling constraints when choosing an appropriate PersistentVolume for a
 PersistentVolumeClaim.
 -->
-延迟卷绑定使得调度器在为 PersistentVolumeClaim 选择一个合适的 PersistentVolume 时能考虑到所有 pod 的调度限制。
-
+延迟卷绑定使得调度器在为 PersistentVolumeClaim 选择一个合适的
+PersistentVolume 时能考虑到所有 Pod 的调度限制。