Merge pull request #32281 from sshukun/concepts-storage

[zh] Update storage pages in concepts

content/zh/docs/concepts/storage/persistent-volumes.md

@@ -666,7 +666,7 @@ size that is within the capacity limits of underlying storage provider. You can
 
 <!--
 Note that,
-although you can a specify a lower amount of storage than what was requested previously,
+although you can specify a lower amount of storage than what was requested previously,
 the new value must still be higher than `.status.capacity`.
 Kubernetes does not support shrinking a PVC to less than its current size.
 -->
@@ -810,7 +810,7 @@ Helper programs relating to the volume type may be required for consumption of a
 <!--
 ### Capacity
 
-Generally, a PV will have a specific storage capacity.  This is set using the PV's `capacity` attribute.  See the Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) to understand the units expected by `capacity`.
+Generally, a PV will have a specific storage capacity. This is set using the PV's `capacity` attribute. Read the glossary term [Quantity](/docs/reference/glossary/?all=true#term-quantity) to understand the units expected by `capacity`.
 
 Currently, storage size is the only resource that can be set or requested.  Future attributes may include IOPS, throughput, etc.
 -->
@@ -818,9 +818,9 @@ Currently, storage size is the only resource that can be set or requested.  Futu
 
 一般而言，每个 PV 卷都有确定的存储容量。
 容量属性是使用 PV 对象的 `capacity` 属性来设置的。
-参考 Kubernetes
-[资源模型（Resource Model）](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)
-设计提案，了解 `capacity` 字段可以接受的单位。
+参考词汇表中的
+[量纲（Quantity）](/zh/docs/reference/glossary/?all=true#term-quantity)
+词条，了解 `capacity` 字段可以接受的单位。
 
 目前，存储大小是可以设置和请求的唯一资源。
 未来可能会包含 IOPS、吞吐量等属性。
@@ -1038,19 +1038,19 @@ The following volume types support mount options:
 -->
 以下卷类型支持挂载选项：
 
-* AWSElasticBlockStore
-* AzureDisk
-* AzureFile
-* CephFS
-* Cinder （OpenStack 块存储）
-* GCEPersistentDisk
-* Glusterfs
-* NFS
-* Quobyte 卷
-* RBD （Ceph 块设备）
-* StorageOS
-* VsphereVolume
-* iSCSI
+* `awsElasticBlockStore`
+* `azureDisk`
+* `azureFile`
+* `cephfs`
+* `cinder` (**已弃用**于 v1.18)
+* `gcePersistentDisk`
+* `glusterfs`
+* `iscsi`
+* `nfs`
+* `quobyte` (**已弃用**于 v1.22)
+* `rbd`
+* `storageos` (**已弃用**于 v1.22)
+* `vsphereVolume`
 
 <!--
 Mount options are not validated, If a mount option is invalid, the mount fails.

content/zh/docs/concepts/storage/volumes.md

@@ -26,15 +26,15 @@ between containers running together in a `Pod`.
 The Kubernetes {{< glossary_tooltip text="volume" term_id="volume" >}} abstraction
 solves both of these problems.
 -->
-Container 中的文件在磁盘上是临时存放的，这给 Container 中运行的较重要的应用
-程序带来一些问题。问题之一是当容器崩溃时文件丢失。kubelet 会重新启动容器，
-但容器会以干净的状态重启。
+Container 中的文件在磁盘上是临时存放的，这给 Container 中运行的较重要的应用程序带来一些问题。
+问题之一是当容器崩溃时文件丢失。
+kubelet 会重新启动容器，但容器会以干净的状态重启。
 第二个问题会在同一 `Pod` 中运行多个容器并共享文件时出现。
 Kubernetes {{< glossary_tooltip text="卷（Volume）" term_id="volume" >}}
 这一抽象概念能够解决这两个问题。
 
 <!--
-Familiarity with [Pods](/docs/user-guide/pods) is suggested.
+Familiarity with [Pods](/docs/concepts/workloads/pods/) is suggested.
 -->
 阅读本文前建议你熟悉一下 [Pods](/zh/docs/concepts/workloads/pods)。 
 
@@ -59,15 +59,15 @@ Docker 提供卷驱动程序，但是其功能非常有限。
 Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}}
 can use any number of volume types simultaneously.
 Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond
-the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; 
-however, Kubernetes does not destroy persistent volumes. 
+the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes;
+however, Kubernetes does not destroy persistent volumes.
 For any kind of volume in a given pod, data is preserved across container restarts.
 -->
 Kubernetes 支持很多类型的卷。
 {{< glossary_tooltip term_id="pod" text="Pod" >}} 可以同时使用任意数目的卷类型。
 临时卷类型的生命周期与 Pod 相同，但持久卷可以比 Pod 的存活期长。
-当 Pod 不再存在时，Kubernetes 也会销毁临时卷；不过 Kubernetes 不会销毁
-持久卷。对于给定 Pod 中任何类型的卷，在容器重启期间数据都不会丢失。
+当 Pod 不再存在时，Kubernetes 也会销毁临时卷；不过 Kubernetes 不会销毁持久卷。
+对于给定 Pod 中任何类型的卷，在容器重启期间数据都不会丢失。
 
 <!--
 At its core, a volume is just a directory, possibly with some data in it, which
@@ -76,27 +76,41 @@ medium that backs it, and the contents of it are determined by the particular
 volume type used.
 -->
 卷的核心是一个目录，其中可能存有数据，Pod 中的容器可以访问该目录中的数据。
-所采用的特定的卷类型将决定该目录如何形成的、使用何种介质保存数据以及目录中存放
-的内容。
+所采用的特定的卷类型将决定该目录如何形成的、使用何种介质保存数据以及目录中存放的内容。
 
 <!--
 To use a volume, specify the volumes to provide for the Pod in `.spec.volumes`
 and declare where to mount those volumes into containers in `.spec.containers[*].volumeMounts`.
-A process in a container sees a filesystem view composed from their Docker
-image and volumes. The [Docker image](https://docs.docker.com/userguide/dockerimages/)
-is at the root of the filesystem hierarchy. Volumes mount at the specified paths within
-the image. Volumes can not mount onto other volumes or have hard links to
-other volumes. Each Container in the Pod's configuration must independently specify where to
-mount each volume.
+A process in a container sees a filesystem view composed from the initial contents of
+the {{< glossary_tooltip text="container image" term_id="image" >}}, plus volumes
+(if defined) mounted inside the container.
+The process sees a root filesystem that initially matches the contents of the container
+image.
+Any writes to within that filesystem hierarchy, if allowed, affect what that process views
+when it performs a subsequent filesystem access.
 -->
 使用卷时, 在 `.spec.volumes` 字段中设置为 Pod 提供的卷，并在
 `.spec.containers[*].volumeMounts` 字段中声明卷在容器中的挂载位置。
-容器中的进程看到的是由它们的 Docker 镜像和卷组成的文件系统视图。
-[Docker 镜像](https://docs.docker.com/userguide/dockerimages/) 
-位于文件系统层次结构的根部。各个卷则挂载在镜像内的指定路径上。
-卷不能挂载到其他卷之上，也不能与其他卷有硬链接。
+容器中的进程看到的文件系统视图是由它们的 {{< glossary_tooltip text="容器镜像" term_id="image" >}}
+的初始内容以及挂载在容器中的卷（如果定义了的话）所组成的。
+其中根文件系统同容器镜像的内容相吻合。
+任何在该文件系统下的写入操作，如果被允许的话，都会影响接下来容器中进程访问文件系统时所看到的内容。
+
+<!--
+Volumes mount at the [specified paths](#using-subpath) within
+the image.
+For each container defined within a Pod, you must independently specify where
+to mount each volume that the container uses.
+
+Volumes cannot mount within other volumes (but see [Using subPath](#using-subpath)
+for a related mechanism). Also, a volume cannot contain a hard link to anything in
+a different volume.
+-->
+卷挂载在镜像中的[指定路径](#using-subpath)下。
 Pod 配置中的每个容器必须独立指定各个卷的挂载位置。
 
+卷不能挂载到其他卷之上（不过存在一种[使用 subPath](#using-subpath) 的相关机制），也不能与其他卷有硬链接。
+
 <!--
 ## Types of Volumes
 
@@ -116,8 +130,8 @@ volume are persisted and the volume is unmounted. This means that an
 EBS volume can be pre-populated with data, and that data can be shared between pods.
 -->
 `awsElasticBlockStore` 卷将 Amazon Web服务（AWS）[EBS 卷](https://aws.amazon.com/ebs/)
-挂载到你的 Pod 中。与 `emptyDir` 在 Pod 被删除时也被删除不同，EBS 卷的内容在删除 Pod 时
-会被保留，卷只是被卸载掉了。
+挂载到你的 Pod 中。与 `emptyDir` 在 Pod 被删除时也被删除不同，EBS 卷的内容在删除 Pod
+时会被保留，卷只是被卸载掉了。
 这意味着 EBS 卷可以预先填充数据，并且该数据可以在 Pod 之间共享。
 
 <!--
@@ -204,9 +218,10 @@ driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
 must be installed on the cluster and the `CSIMigration` and `CSIMigrationAWS`
 beta features must be enabled.
 -->
-如果启用了对 `awsElasticBlockStore` 的 `CSIMigration` 特性支持，所有插件操作都
-不再指向树内插件（In-Tree Plugin），转而指向 `ebs.csi.aws.com` 容器存储接口
-（Container Storage Interface，CSI）驱动。为了使用此特性，必须在集群中安装
+如果启用了对 `awsElasticBlockStore` 的 `CSIMigration`
+特性支持，所有插件操作都不再指向树内插件（In-Tree Plugin），转而指向
+`ebs.csi.aws.com` 容器存储接口（Container Storage Interface，CSI）驱动。
+为了使用此特性，必须在集群中安装
 [AWS EBS CSI 驱动](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)，
 并确保 `CSIMigration` 和 `CSIMigrationAWS` Beta 功能特性被启用。
 
@@ -308,8 +323,9 @@ that data can be shared between Pods.  The `cephfs` can be mounted by multiple
 writers simultaneously.
 -->
 `cephfs` 卷允许你将现存的 CephFS 卷挂载到 Pod 中。
-不像 `emptyDir` 那样会在 Pod 被删除的同时也会被删除，`cephfs` 卷的内容在 Pod 被删除
-时会被保留，只是卷被卸载了。这意味着 `cephfs` 卷可以被预先填充数据，且这些数据可以在
+不像 `emptyDir` 那样会在 Pod 被删除的同时也会被删除，`cephfs`
+卷的内容在 Pod 被删除时会被保留，只是卷被卸载了。
+这意味着 `cephfs` 卷可以被预先填充数据，且这些数据可以在
 Pod 之间共享。同一 `cephfs` 卷可同时被多个写者挂载。
 
 <!--
@@ -375,7 +391,7 @@ It redirects all plugin operations from the existing in-tree plugin to the
 `cinder.csi.openstack.org` Container Storage Interface (CSI) Driver.
 [OpenStack Cinder CSI Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)
 must be installed on the cluster.
-You can disable Cinder CSI migration for your cluster by setting the `CSIMigrationOpenStack` 
+You can disable Cinder CSI migration for your cluster by setting the `CSIMigrationOpenStack`
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to `false`.
 If you disable the `CSIMigrationOpenStack` feature, the in-tree Cinder volume plugin takes responsibility
 for all aspects of Cinder volume storage management.
@@ -399,10 +415,9 @@ provides a way to inject configuration data into Pods.
 The data stored in a ConfigMap object can be referenced in a volume of type
 `configMap` and then consumed by containerized applications running in a Pod.
 -->
-[`configMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 卷
-提供了向 Pod 注入配置数据的方法。
-ConfigMap 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被 Pod 中运行的
-容器化应用使用。
+[`configMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
+卷提供了向 Pod 注入配置数据的方法。
+ConfigMap 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被 Pod 中运行的容器化应用使用。
 
 <!--
 When referencing a ConfigMap, you provide the name of the ConfigMap in the
@@ -442,8 +457,8 @@ its `log_level` entry are mounted into the Pod at path "`/etc/config/log_level`"
 Note that this path is derived from the volume's `mountPath` and the `path`
 keyed with `log_level`.
 -->
-`log-config` ConfigMap 以卷的形式挂载，并且存储在 `log_level` 条目中的所有内容
-都被挂载到 Pod 的 `/etc/config/log_level` 路径下。
+`log-config` ConfigMap 以卷的形式挂载，并且存储在 `log_level`
+条目中的所有内容都被挂载到 Pod 的 `/etc/config/log_level` 路径下。
 请注意，这个路径来源于卷的 `mountPath` 和 `log_level` 键对应的 `path`。
 
 <!--
@@ -544,8 +559,8 @@ backed volumes are sized to 50% of the memory on a Linux host.
 -->
 
 {{< note >}}
-当启用 `SizeMemoryBackedVolumes` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)时，
-你可以为基于内存提供的卷指定大小。
+当启用 `SizeMemoryBackedVolumes` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+时，你可以为基于内存提供的卷指定大小。
 如果未指定大小，则基于内存的卷的大小为 Linux 主机上内存的 50％。
 {{< /note>}}
 
@@ -589,8 +604,8 @@ targetWWNs expect that those WWNs are from multi-path connections.
 You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts can access them.
 -->
 {{< note >}}
-你必须配置 FC SAN Zoning，以便预先向目标 WWN 分配和屏蔽这些 LUN（卷），
-这样 Kubernetes 主机才可以访问它们。
+你必须配置 FC SAN Zoning，以便预先向目标 WWN 分配和屏蔽这些 LUN（卷），这样
+Kubernetes 主机才可以访问它们。
 {{< /note >}}
 
 <!--
@@ -737,10 +752,10 @@ feature allows the creation of Persistent Disks that are available in two zones
 within the same region. In order to use this feature, the volume must be provisioned
 as a PersistentVolume; referencing the volume directly from a Pod is not supported.
 -->
-[区域持久盘](https://cloud.google.com/compute/docs/disks/#repds) 功能允许你创建能在
-同一区域的两个可用区中使用的持久盘。
-要使用这个功能，必须以持久卷（PersistentVolume）的方式提供卷；直接从 Pod 引用这种卷
-是不可以的。
+[区域持久盘](https://cloud.google.com/compute/docs/disks/#repds)
+功能允许你创建能在同一区域的两个可用区中使用的持久盘。
+要使用这个功能，必须以持久卷（PersistentVolume）的方式提供卷；直接从
+Pod 引用这种卷是不可以的。
 
 <!--
 #### Manually provisioning a Regional PD PersistentVolume
@@ -750,8 +765,8 @@ Before creating a PersistentVolume, you must create the PD:
 -->
 #### 手动供应基于区域 PD 的 PersistentVolume {#manually-provisioning-regional-pd-pv}
 
-使用[为 GCE PD 定义的存储类](/zh/docs/concepts/storage/storage-classes/#gce) 可以
-实现动态供应。在创建 PersistentVolume 之前，你首先要创建 PD。
+使用[为 GCE PD 定义的存储类](/zh/docs/concepts/storage/storage-classes/#gce)
+可以实现动态供应。在创建 PersistentVolume 之前，你首先要创建 PD。
 
 ```shell
 gcloud beta compute disks create --size=500GB my-data-disk
@@ -824,8 +839,8 @@ and the kubelet, set the `InTreePluginGCEUnregister` flag to `true`.
 
 {{< feature-state for_k8s_version="v1.21" state="alpha" >}}
 
-要禁止控制器管理器和 kubelet 加载 `gcePersistentDisk` 存储插件，
-请将 `InTreePluginGCEUnregister` 标志设置为 `true`。
+要禁止控制器管理器和 kubelet 加载 `gcePersistentDisk` 存储插件，请将
+`InTreePluginGCEUnregister` 标志设置为 `true`。
 
 <!--
 ### gitRepo (deprecated) {#gitrepo}
@@ -838,8 +853,8 @@ The gitRepo volume type is deprecated. To provision a container with a git repo,
 -->
 {{< warning >}}
 `gitRepo` 卷类型已经被废弃。如果需要在容器中提供 git 仓库，请将一个
-[EmptyDir](#emptydir) 卷挂载到 InitContainer 中，使用 git 命令完成仓库的克隆操作，
-然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。
+[EmptyDir](#emptydir) 卷挂载到 InitContainer 中，使用 git
+命令完成仓库的克隆操作，然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。
 {{< /warning >}}
 
 <!--
@@ -916,8 +931,8 @@ be required to use `readOnly` mounts for the policy to be effective.
 HostPath 卷存在许多安全风险，最佳做法是尽可能避免使用 HostPath。
 当必须使用 HostPath 卷时，它的范围应仅限于所需的文件或目录，并以只读方式挂载。
 
-如果通过 AdmissionPolicy 限制 HostPath 对特定目录的访问，
-则必须要求 `volumeMounts` 使用 `readOnly` 挂载以使策略生效。
+如果通过 AdmissionPolicy 限制 HostPath 对特定目录的访问，则必须要求
+`volumeMounts` 使用 `readOnly` 挂载以使策略生效。
 {{< /warning >}}
 
 <!--
@@ -990,10 +1005,10 @@ Watch out when using this type of volume, because:
 -->
 当使用这种类型的卷时要小心，因为：
 
-* HostPath 卷可能会暴露特权系统凭据（例如 Kubelet）或特权 API（例如容器运行时套接字），
-  可用于容器逃逸或攻击集群的其他部分。
-* 具有相同配置（例如基于同一 PodTemplate 创建）的多个 Pod 会由于节点上文件的不同
-  而在不同节点上有不同的行为。
+* HostPath 卷可能会暴露特权系统凭据（例如 Kubelet）或特权
+  API（例如容器运行时套接字），可用于容器逃逸或攻击集群的其他部分。
+* 具有相同配置（例如基于同一 PodTemplate 创建）的多个 Pod
+  会由于节点上文件的不同而在不同节点上有不同的行为。
 * 下层主机上创建的文件或目录只能由 root 用户写入。你需要在
   [特权容器](/zh/docs/tasks/configure-pod-container/security-context/)
   中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。
@@ -1078,8 +1093,8 @@ unmounted.  This means that an iscsi volume can be pre-populated with data, and
 that data can be shared between pods.
 -->
 `iscsi` 卷能将 iSCSI (基于 IP 的 SCSI) 卷挂载到你的 Pod 中。
-不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`iscsi` 卷的内容在删除 Pod 时
-会被保留，卷只是被卸载。
+不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`iscsi`
+卷的内容在删除 Pod 时会被保留，卷只是被卸载。
 这意味着 `iscsi` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。
 
 <!--
@@ -1140,9 +1155,8 @@ The following is an example of PersistentVolume spec using a `local` volume and
 `nodeAffinity`:
 -->
 然而，`local` 卷仍然取决于底层节点的可用性，并不适合所有应用程序。
-如果节点变得不健康，那么`local` 卷也将变得不可被 Pod 访问。使用它的 Pod 将不能运行。
-使用 `local` 卷的应用程序必须能够容忍这种可用性的降低，以及因底层磁盘的耐用性特征
-而带来的潜在的数据丢失风险。
+如果节点变得不健康，那么 `local` 卷也将变得不可被 Pod 访问。使用它的 Pod 将不能运行。
+使用 `local` 卷的应用程序必须能够容忍这种可用性的降低，以及因底层磁盘的耐用性特征而带来的潜在的数据丢失风险。
 
 下面是一个使用 `local` 卷和 `nodeAffinity` 的持久卷示例：
 
@@ -1198,9 +1212,8 @@ such as node resource requirements, node selectors, Pod affinity, and Pod anti-a
 使用 `local` 卷时，建议创建一个 StorageClass 并将其 `volumeBindingMode` 设置为
 `WaitForFirstConsumer`。要了解更多详细信息，请参考
 [local StorageClass 示例](/zh/docs/concepts/storage/storage-classes/#local)。
-延迟卷绑定的操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时，
-会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod
-亲和性和 Pod 反亲和性。
+延迟卷绑定的操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时，会评估
+Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod亲和性和 Pod 反亲和性。
 
 <!--
 An external static provisioner can be run separately for improved management of
@@ -1258,10 +1271,9 @@ A `persistentVolumeClaim` volume is used to mount a
 are a way for users to "claim" durable storage (such as a GCE PersistentDisk or an
 iSCSI volume) without knowing the details of the particular cloud environment.
 -->
-`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume）
-挂载到 Pod 中。
-持久卷申领（PersistentVolumeClaim）是用户在不知道特定云环境细节的情况下"申领"持久存储
-（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。
+`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。
+持久卷申领（PersistentVolumeClaim）是用户在不知道特定云环境细节的情况下“申领”持久存储（例如
+GCE PersistentDisk 或者 iSCSI 卷）的一种方法。
 
 <!--
 See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/) for more
@@ -1277,8 +1289,8 @@ Kubernetes. [Portworx](https://portworx.com/use-case/kubernetes-storage/) finger
 and aggregates capacity across multiple servers. Portworx runs in-guest in virtual machines or on bare metal Linux nodes.
 -->
 `portworxVolume` 是一个可伸缩的块存储层，能够以超融合（hyperconverged）的方式与 Kubernetes 一起运行。
-[Portworx](https://portworx.com/use-case/kubernetes-storage/) 支持对服务器上存储的指纹处理、
-基于存储能力进行分层以及跨多个服务器整合存储容量。
+[Portworx](https://portworx.com/use-case/kubernetes-storage/)
+支持对服务器上存储的指纹处理、基于存储能力进行分层以及跨多个服务器整合存储容量。
 Portworx 可以以 in-guest 方式在虚拟机中运行，也可以在裸金属 Linux 节点上运行。
 
 <!--
@@ -1324,192 +1336,13 @@ For more details, see the [Portworx volume](https://github.com/kubernetes/exampl
 
 更多详情可以参考 [Portworx 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md)。
 
-### projected
+### projected （投射）
 
 <!--
-A `projected` volume maps several existing volume sources into the same directory.
-
-Currently, the following types of volume sources can be projected:
+A projected volume maps several existing volume sources into the same
+directory. For more details, see [projected volumes](/docs/concepts/storage/projected-volumes/).
 -->
-`projected` 卷类型能将若干现有的卷来源映射到同一目录上。
-
-目前，可以映射的卷来源类型如下：
-
-- [`secret`](#secret)
-- [`downwardAPI`](#downwardapi)
-- [`configMap`](#configmap)
-- `serviceAccountToken`
-
-<!--
-All sources are required to be in the same namespace as the Pod. For more details,
-see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md).
--->
-所有的卷来源需要和 Pod 处于相同的命名空间。
-更多详情请参考[一体化卷设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)。
-
-<!--
-#### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap}
--->
-
-#### 包含 Secret、downwardAPI 和 configMap 的 Pod 示例  {#example-configuration-secret-downwardapi-configmap}
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: volume-test
-spec:
-  containers:
-  - name: container-test
-    image: busybox
-    volumeMounts:
-    - name: all-in-one
-      mountPath: "/projected-volume"
-      readOnly: true
-  volumes:
-  - name: all-in-one
-    projected:
-      sources:
-      - secret:
-          name: mysecret
-          items:
-            - key: username
-              path: my-group/my-username
-      - downwardAPI:
-          items:
-            - path: "labels"
-              fieldRef:
-                fieldPath: metadata.labels
-            - path: "cpu_limit"
-              resourceFieldRef:
-                containerName: container-test
-                resource: limits.cpu
-      - configMap:
-          name: myconfigmap
-          items:
-            - key: config
-              path: my-group/my-config
-```
-
-<!--
-#### Example configuration: secrets with a non-default permission mode set {#example-configuration-secrets-nondefault-permission-mode}
--->
-
-下面是一个带有非默认访问权限设置的多个 secret 的 Pod 示例：
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: volume-test
-spec:
-  containers:
-  - name: container-test
-    image: busybox
-    volumeMounts:
-    - name: all-in-one
-      mountPath: "/projected-volume"
-      readOnly: true
-  volumes:
-  - name: all-in-one
-    projected:
-      sources:
-      - secret:
-          name: mysecret
-          items:
-            - key: username
-              path: my-group/my-username
-      - secret:
-          name: mysecret2
-          items:
-            - key: password
-              path: my-group/my-password
-              mode: 511
-```
-<!--
-Each projected volume source is listed in the spec under `sources`. The
-parameters are nearly the same with two exceptions:
-
-* For secrets, the `secretName` field has been changed to `name` to be consistent
-  with ConfigMap naming.
-* The `defaultMode` can only be specified at the projected level and not for each
-  volume source. However, as illustrated above, you can explicitly set the `mode`
-  for each individual projection.
--->
-每个被投射的卷来源都在规约中的 `sources` 内列出。参数几乎相同，除了两处例外：
-
-* 对于 `secret`，`secretName` 字段已被变更为 `name` 以便与 ConfigMap 命名一致。
-* `defaultMode` 只能在整个投射卷级别指定，而无法针对每个卷来源指定。
-  不过，如上所述，你可以显式地为每个投射项设置 `mode` 值。
-
-<!--
-When the `TokenRequestProjection` feature is enabled, you can inject the token
-for the current [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
-into a Pod at a specified path. Below is an example:
--->
-
-当开启 `TokenRequestProjection` 功能时，可以将当前
-[服务帐号](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)
-的令牌注入 Pod 中的指定路径。
-下面是一个例子：
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: sa-token-test
-spec:
-  containers:
-  - name: container-test
-    image: busybox
-    volumeMounts:
-    - name: token-vol
-      mountPath: "/service-account"
-      readOnly: true
-  volumes:
-  - name: token-vol
-    projected:
-      sources:
-      - serviceAccountToken:
-          audience: api
-          expirationSeconds: 3600
-          path: token
-```
-
-<!--
-The example Pod has a projected volume containing the injected service account
-token. This token can be used by a Pod's containers to access the Kubernetes API
-server. The `audience` field contains the intended audience of the
-token. A recipient of the token must identify itself with an identifier specified
-in the audience of the token, and otherwise should reject the token. This field
-is optional and it defaults to the identifier of the API server.
--->
-示例 Pod 具有包含注入服务帐户令牌的映射卷。
-该令牌可以被 Pod 中的容器用来访问 Kubernetes API 服务器。
-`audience` 字段包含令牌的预期受众。
-令牌的接收者必须使用令牌的受众中指定的标识符来标识自己，否则应拒绝令牌。
-此字段是可选的，默认值是 API 服务器的标识符。
-
-<!--
-The `expirationSeconds` is the expected duration of validity of the service account
-token. It defaults to 1 hour and must be at least 10 minutes (600 seconds). An administrator
-can also limit its maximum value by specifying the `-service-account-max-token-expiration`
-option for the API server. The `path` field specifies a relative path to the mount point
-of the projected volume.
--->
-`expirationSeconds` 是服务帐户令牌的有效期时长。
-默认值为 1 小时，必须至少 10 分钟（600 秒）。
-管理员还可以通过设置 API 服务器的 `--service-account-max-token-expiration` 选项来
-限制其最大值。
-`path` 字段指定相对于映射卷的挂载点的相对路径。
-
-{{< note >}}
-<!--
-A container using a projected volume source as a [subPath](#using-subpath) volume mount will not
-receive updates for those volume sources.
--->
-使用投射卷源作为 [subPath](#using-subpath) 卷挂载的容器将不会接收这些卷源的更新。
-{{< /note >}}
+投射卷能将若干现有的卷来源映射到同一目录上。更多详情请参考[投射卷](/zh/docs/concepts/storage/projected-volumes/)。
 
 ### quobyte (已弃用) {#quobyte}
 
@@ -1542,32 +1375,32 @@ Quobyte 的 GitHub 项目包含以 CSI 形式部署 Quobyte 的
 
 <!--
 An `rbd` volume allows a
-[Rados Block Device](https://docs.ceph.com/en/latest/rbd/) volume to mount into your
-Pod.  Unlike `emptyDir`, which is erased when a Pod is removed, the contents of
-a `rbd` volume are preserved and the volume is merely unmounted.  This
-means that a RBD volume can be pre-populated with data, and that data can
-be shared between pods.
+[Rados Block Device](https://docs.ceph.com/en/latest/rbd/) (RBD) volume to mount
+into your Pod. Unlike `emptyDir`, which is erased when a pod is removed, the
+contents of an `rbd` volume are preserved and the volume is unmounted. This
+means that a RBD volume can be pre-populated with data, and that data can be
+shared between pods.
 -->
-`rbd` 卷允许将 [Rados 块设备](https://docs.ceph.com/en/latest/rbd/) 卷挂载到你的 Pod 中.
-不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`rbd` 卷的内容在删除 Pod 时
-会被保存，卷只是被卸载。
+`rbd` 卷允许将 [Rados 块设备](https://docs.ceph.com/en/latest/rbd/)卷挂载到你的 Pod 中。
+不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`rbd` 卷的内容在删除 Pod 时会被保存，卷只是被卸载。
 这意味着 `rbd` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。
 
 <!--
-You must have your own Ceph installation running before you can use RBD.
+You must have a Ceph installation running before you can use RBD.
 -->
-{{< caution >}}
+{{< note >}}
 在使用 RBD 之前，你必须安装运行 Ceph。
-{{< /caution >}}
+{{< /note >}}
 
 <!--
 A feature of RBD is that it can be mounted as read-only by multiple consumers
-simultaneously.  This means that you can pre-populate a volume with your dataset
-and then serve it in parallel from as many Pods as you need.  Unfortunately,
+simultaneously. This means that you can pre-populate a volume with your dataset
+and then serve it in parallel from as many pods as you need. Unfortunately,
 RBD volumes can only be mounted by a single consumer in read-write mode.
 Simultaneous writers are not allowed.
 
-See the [RBD example](https://github.com/kubernetes/examples/tree/master/volumes/rbd) for more details.
+See the [RBD example](https://github.com/kubernetes/examples/tree/master/volumes/rbd)
+for more details.
 -->
 RBD 的一个特性是它可以同时被多个用户以只读方式挂载。
 这意味着你可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 中并行地使用卷。
@@ -1576,6 +1409,59 @@ RBD 的一个特性是它可以同时被多个用户以只读方式挂载。
 更多详情请参考
 [RBD 示例](https://github.com/kubernetes/examples/tree/master/volumes/rbd)。
 
+<!--
+#### RBD CSI migration
+-->
+#### RBD CSI 迁移 {#rbd-csi-migration}
+
+{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
+
+<!--
+The `CSIMigration` feature for `RBD`, when enabled, redirects all plugin
+operations from the existing in-tree plugin to the `rbd.csi.ceph.com` {{<
+glossary_tooltip text="CSI" term_id="csi" >}} driver. In order to use this
+feature, the
+[Ceph CSI driver](https://github.com/ceph/ceph-csi)
+must be installed on the cluster and the `CSIMigration` and `csiMigrationRBD`
+[feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
+must be enabled.
+-->
+启用 RBD 的 `CSIMigration` 功能后，所有插件操作从现有的树内插件重定向到
+`rbd.csi.ceph.com` {{<glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序。
+要使用该功能，必须在集群内安装
+[Ceph CSI 驱动](https://github.com/ceph/ceph-csi)，并启用 `CSIMigration` 和 `csiMigrationRBD` 
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+
+<!--
+As a Kubernetes cluster operator that administers storage, here are the
+prerequisites that you must complete before you attempt migration to the
+RBD CSI driver:
+
+* You must install the Ceph CSI driver (`rbd.csi.ceph.com`), v3.5.0 or above,
+  into your Kubernetes cluster.
+* considering the `clusterID` field is a required parameter for CSI driver for
+  its operations, but in-tree StorageClass has `monitors` field as a required
+  parameter, a Kubernetes storage admin has to create a clusterID based on the
+  monitors hash ( ex:`#echo -n
+  '<monitors_string>' | md5sum`) in the CSI config map and keep the monitors
+  under this clusterID configuration.
+* Also, if the value of `adminId` in the in-tree Storageclass is different from
+ `admin`, the `adminSecretName` mentioned in the in-tree Storageclass has to be
+  patched with the base64 value of the `adminId` parameter value, otherwise this
+  step can be skipped.
+-->
+{{< note >}}
+作为一位管理存储的 Kubernetes 集群操作者，在尝试迁移到 RBD CSI 驱动前，你必须完成下列先决事项：
+
+* 你必须在集群中安装 v3.5.0 或更高版本的 Ceph CSI 驱动（`rbd.csi.ceph.com`）。
+* 因为 `clusterID` 是 CSI 驱动程序必需的参数，而树内存储类又将 `monitors`
+  作为一个必需的参数，所以 Kubernetes 存储管理者需要根据 `monitors`
+  的哈希值（例：`#echo -n '<monitors_string>' | md5sum`）来创建
+  `clusterID`，并保持该 `monitors` 存在于该 `clusterID` 的配置中。
+* 同时，如果树内存储类的 `adminId` 的值不是 `admin`，那么其 `adminSecretName`
+  就需要被修改成 `adminId` 参数的 base64 编码值。
+{{< /note >}}
+
 ### secret
 
 <!--
@@ -1587,8 +1473,7 @@ non-volatile storage.
 -->
 `secret` 卷用来给 Pod 传递敏感信息，例如密码。你可以将 Secret 存储在 Kubernetes
 API 服务器上，然后以文件的形式挂在到 Pod 中，无需直接与 Kubernetes 耦合。
-`secret` 卷由 tmpfs（基于 RAM 的文件系统）提供存储，因此它们永远不会被写入非易失性
-（持久化的）存储器。
+`secret` 卷由 tmpfs（基于 RAM 的文件系统）提供存储，因此它们永远不会被写入非易失性（持久化的）存储器。
 
 <!--
 You must create a secret in the Kubernetes API before you can use it.
@@ -1790,8 +1675,8 @@ must be installed on the cluster and the `CSIMigration` and `CSIMigrationvSphere
 当 `vsphereVolume` 的 `CSIMigration` 特性被启用时，所有插件操作都被从树内插件重定向到
 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。
 为了使用此功能特性，必须在集群中安装
-[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)，
-并启用 `CSIMigration` 和 `CSIMigrationvSphere`
+[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)，并启用
+`CSIMigration` 和 `CSIMigrationvSphere`
 [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
 
 <!--
@@ -1837,6 +1722,28 @@ To turn off the `vsphereVolume` plugin from being loaded by the controller manag
 `InTreePluginvSphereUnregister` 特性设置为 `true`。你还必须在所有工作节点上安装
 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。
 
+<!--
+#### Portworx CSI migration
+-->
+#### Portworx CSI 迁移
+
+{{< feature-state for_k8s_version="v1.23" state="alpha" >}}
+
+<!--
+The `CSIMigration` feature for Portworx has been added but disabled by default in Kubernetes 1.23 since it's in alpha state.
+It redirects all plugin operations from the existing in-tree plugin to the
+`pxd.portworx.com` Container Storage Interface (CSI) Driver.
+[Portworx CSI Driver](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/)
+must be installed on the cluster.
+To enable the feature, set `CSIMigrationPortworx=true` in kube-controller-manager and kubelet.
+-->
+Kubernetes 1.23 中加入了 Portworx 的 `CSIMigration` 功能，但默认不会启用，因为该功能仍处于 alpha 阶段。
+该功能会将所有的插件操作从现有的树内插件重定向到
+`pxd.portworx.com` 容器存储接口（Container Storage Interface, CSI）驱动程序。
+集群中必须安装
+[Portworx CSI 驱动](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/)。
+要启用此功能，请在 kube-controller-manager 和 kubelet 中设置 `CSIMigrationPortworx=true`。
+
 <!--
 ## Using subPath {#using-subpath}
 
@@ -1844,7 +1751,7 @@ Sometimes, it is useful to share one volume for multiple uses in a single Pod.
 The `volumeMounts.subPath` property specifies a sub-path inside the referenced volume
 instead of its root.
 -->
-## 使用 subPath  {#using-path}
+## 使用 subPath  {#using-subpath}
 
 有时，在单个 Pod 中共享卷以供多方使用是很有用的。
 `volumeMounts.subPath` 属性可用于指定所引用的卷内的子路径，而不是其根路径。
@@ -1934,6 +1841,7 @@ spec:
     volumeMounts:
     - name: workdir1
       mountPath: /logs
+      # 包裹变量名的是小括号，而不是大括号
       subPathExpr: $(POD_NAME)
   restartPolicy: Never
   volumes:
@@ -1953,10 +1861,9 @@ Pods.
 -->
 ## 资源   {#resources}
 
-`emptyDir` 卷的存储介质（磁盘、SSD 等）是由保存 kubelet 数据的根目录
-（通常是 `/var/lib/kubelet`）的文件系统的介质确定。
-Kubernetes 对 `emptyDir` 卷或者 `hostPath` 卷可以消耗的空间没有限制，
-容器之间或 Pod 之间也没有隔离。
+`emptyDir` 卷的存储介质（磁盘、SSD 等）是由保存 kubelet
+数据的根目录（通常是 `/var/lib/kubelet`）的文件系统的介质确定。
+Kubernetes 对 `emptyDir` 卷或者 `hostPath` 卷可以消耗的空间没有限制，容器之间或 Pod 之间也没有隔离。
 
 <!--
 To learn about requesting space using a resource specification, see
@@ -1970,16 +1877,15 @@ To learn about requesting space using a resource specification, see
 ## Out-of-Tree Volume Plugins
 
 The out-of-tree volume plugins include
-{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI)
-and FlexVolume. They enable storage vendors to create custom storage plugins
-without adding them to the Kubernetes repository.
+{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI), and also FlexVolume (which is deprecated). These plugins enable storage vendors to create custom storage plugins
+without adding their plugin source code to the Kubernetes repository.
 -->
 ## 树外（Out-of-Tree）卷插件    {#out-of-tree-volume-plugins}
 
 Out-of-Tree 卷插件包括
-{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} (CSI)
-和 FlexVolume。
-它们使存储供应商能够创建自定义存储插件，而无需将它们添加到 Kubernetes 代码仓库。
+{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}}
+和 FlexVolume（已弃用）。
+它们使存储供应商能够创建自定义存储插件，而无需将插件源码添加到 Kubernetes 代码仓库。
 
 <!--
 Previously, all volume plugins were "in-tree". The "in-tree" plugins were built, linked, compiled,
@@ -1998,8 +1904,7 @@ extensions.
 For storage vendors looking to create an out-of-tree volume plugin, please refer
 to [this FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md).
 -->
-CSI 和 FlexVolume 都允许独立于 Kubernetes 代码库开发卷插件，并作为扩展部署
-（安装）在 Kubernetes 集群上。
+CSI 和 FlexVolume 都允许独立于 Kubernetes 代码库开发卷插件，并作为扩展部署（安装）在 Kubernetes 集群上。
 
 对于希望创建树外（Out-Of-Tree）卷插件的存储供应商，请参考
 [卷插件常见问题](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)。
@@ -2053,8 +1958,8 @@ A `csi` volume can be used in a Pod in three different ways:
 * with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)
 if the driver supports that (beta feature)
 -->
-一旦在 Kubernetes 集群上部署了 CSI 兼容卷驱动程序，用户就可以使用 `csi` 卷类型来
-挂接、挂载 CSI 驱动所提供的卷。
+一旦在 Kubernetes 集群上部署了 CSI 兼容卷驱动程序，用户就可以使用
+`csi` 卷类型来挂接、挂载 CSI 驱动所提供的卷。
 
 `csi` 卷可以在 Pod 中以三种方式使用：
 
@@ -2078,10 +1983,10 @@ persistent volume:
   CSI driver components to identify which PV objects belong to the CSI driver.
 -->
 - `driver`：指定要使用的卷驱动名称的字符串值。
-  这个值必须与 CSI 驱动程序在 `GetPluginInfoResponse` 中返回的值相对应；
-  该接口定义在 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)中。
-  Kubernetes 使用所给的值来标识要调用的 CSI 驱动程序；CSI 驱动程序也使用该值来辨识
-  哪些 PV 对象属于该 CSI 驱动程序。
+  这个值必须与 CSI 驱动程序在 `GetPluginInfoResponse` 中返回的值相对应；该接口定义在
+  [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)中。
+  Kubernetes 使用所给的值来标识要调用的 CSI 驱动程序；CSI
+  驱动程序也使用该值来辨识哪些 PV 对象属于该 CSI 驱动程序。
 
 <!--
 - `volumeHandle`: A string value that uniquely identifies the volume. This value
@@ -2091,8 +1996,8 @@ persistent volume:
   referencing the volume.
 -->
 - `volumeHandle`：唯一标识卷的字符串值。
-  该值必须与 CSI 驱动在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应；
-  接口定义在 [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中。
+  该值必须与 CSI 驱动在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应；接口定义在
+  [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中。
   在所有对 CSI 卷驱动程序的调用中，引用该 CSI 卷时都使用此值作为 `volume_id` 参数。
 
 <!--
@@ -2101,8 +2006,7 @@ persistent volume:
   passed to the CSI driver via the `readonly` field in the
   `ControllerPublishVolumeRequest`.
 -->
-- `readOnly`：一个可选的布尔值，指示通过 `ControllerPublished` 关联该卷时是否设置
-  该卷为只读。默认值是 false。
+- `readOnly`：一个可选的布尔值，指示通过 `ControllerPublished` 关联该卷时是否设置该卷为只读。默认值是 false。
   该值通过 `ControllerPublishVolumeRequest` 中的 `readonly` 字段传递给 CSI 驱动。
 
 <!--
@@ -2131,7 +2035,8 @@ persistent volume:
 - `volumeAttributes`：一个字符串到字符串的映射表，用来设置卷的静态属性。
   该映射必须与 CSI 驱动程序返回的 `CreateVolumeResponse` 中的 `volume.attributes`
   字段的映射相对应；
-  [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中有相应的定义。
+  [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)
+  中有相应的定义。
   该映射通过`ControllerPublishVolumeRequest`、`NodeStageVolumeRequest`、和
   `NodePublishVolumeRequest` 中的 `volume_attributes` 字段传递给 CSI 驱动。
 
@@ -2239,10 +2144,8 @@ provisioning/delete, attach/detach, mount/unmount and resizing of volumes.
 In-tree plugins that support `CSIMigration` and have a corresponding CSI driver implemented
 are listed in [Types of Volumes](#volume-types).
 -->
-启用 `CSIMigration` 功能后，针对现有树内插件的操作会被重定向到相应的 CSI 插件
-（应已安装和配置）。
-因此，操作员在过渡到取代树内插件的 CSI 驱动时，无需对现有存储类、PV 或 PVC
-（指树内插件）进行任何配置更改。
+启用 `CSIMigration` 功能后，针对现有树内插件的操作会被重定向到相应的 CSI 插件（应已安装和配置）。
+因此，操作员在过渡到取代树内插件的 CSI 驱动时，无需对现有存储类、PV 或 PVC（指树内插件）进行任何配置更改。
 
 所支持的操作和功能包括：配备（Provisioning）/删除、挂接（Attach）/解挂（Detach）、
 挂载（Mount）/卸载（Unmount）和调整卷大小。
@@ -2252,22 +2155,35 @@ are listed in [Types of Volumes](#volume-types).
 
 ### flexVolume
 
+{{< feature-state for_k8s_version="v1.23" state="deprecated" >}}
+
 <!--
-FlexVolume is an out-of-tree plugin interface that has existed in Kubernetes
-since version 1.2 (before CSI). It uses an exec-based model to interface with
-drivers. The FlexVolume driver binaries must be installed in a pre-defined volume
-plugin path on each node (and in some cases master).
+FlexVolume is an out-of-tree plugin interface that uses an exec-based model to interface
+with storage drivers. The FlexVolume driver binaries must be installed in a pre-defined
+volume plugin path on each node and in some cases the control plane nodes as well.
 
-Pods interact with FlexVolume drivers through the `flexvolume` in-tree plugin.
-More details can be found [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md).
+Pods interact with FlexVolume drivers through the `flexVolume` in-tree volume plugin.
+For more details, see the FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) document.
 -->
-FlexVolume 是一个自 1.2 版本（在 CSI 之前）以来在 Kubernetes 中一直存在的树外插件接口。
-它使用基于 exec 的模型来与驱动程序对接。
-用户必须在每个节点（在某些情况下是主控节点）上的预定义卷插件路径中安装
-FlexVolume 驱动程序可执行文件。
+FlexVolume 是一个使用基于 exec 的模型来与驱动程序对接的树外插件接口。
+用户必须在每个节点上的预定义卷插件路径中安装 FlexVolume
+驱动程序可执行文件，在某些情况下，控制平面节点中也要安装。
 
-Pod 通过 `flexvolume` 树内插件与 Flexvolume 驱动程序交互。
-更多详情请参考 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 示例。
+Pod 通过 `flexvolume` 树内插件与 FlexVolume 驱动程序交互。
+更多详情请参考 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 文档。
+
+<!--
+FlexVolume is deprecated. Using an out-of-tree CSI driver is the recommended way to integrate external storage with Kubernetes.
+
+Maintainers of FlexVolume driver should implement a CSI Driver and help to migrate users of FlexVolume drivers to CSI.
+Users of FlexVolume should move their workloads to use the equivalent CSI Driver.
+-->
+{{< note >}}
+FlexVolume 已弃用。推荐使用树外 CSI 驱动来将外部存储整合进 Kubernetes。
+
+FlexVolume 驱动的维护者应开发一个 CSI 驱动并帮助用户从 FlexVolume 驱动迁移到 CSI。
+FlexVolume 用户应迁移工作负载以使用对等的 CSI 驱动。
+{{< /note >}}
 
 <!--
 ## Mount propagation
@@ -2280,8 +2196,7 @@ Its values are:
 -->
 ## 挂载卷的传播   {#mount-propagation}
 
-挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器，
-甚至共享到同一节点上的其他 Pod。
+挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器，甚至共享到同一节点上的其他 Pod。
 
 卷的挂载传播特性由 `Container.volumeMounts` 中的 `mountPropagation` 字段控制。
 它的值包括：
@@ -2320,8 +2235,8 @@ Its values are:
 
   换句话说，如果主机在此挂载卷中挂载任何内容，容器将能看到它被挂载在那里。
 
-  类似的，配置了 `Bidirectional` 挂载传播选项的 Pod 如果在同一卷上挂载了内容，
-  挂载传播设置为 `HostToContainer` 的容器都将能看到这一变化。
+  类似的，配置了 `Bidirectional` 挂载传播选项的 Pod 如果在同一卷上挂载了内容，挂载传播设置为
+  `HostToContainer` 的容器都将能看到这一变化。
 
   该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
   中描述的 `rslave` 挂载传播选项。
@@ -2366,8 +2281,7 @@ Docker as shown below.
 -->
 ### 配置  {#configuration}
 
-在某些部署环境中，挂载传播正常工作前，必须在 Docker 中正确配置挂载共享（mount share），
-如下所示。
+在某些部署环境中，挂载传播正常工作前，必须在 Docker 中正确配置挂载共享（mount share），如下所示。
 
 <!--
 Edit your Docker's `systemd` service file.  Set `MountFlags` as follows: