Merge pull request #43826 from windsonsea/volumey

[zh] Sync /storage/volumes.md

Author: k8s-ci-robot

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

@@ -391,17 +391,15 @@ to learn more.
 ### emptyDir {#emptydir}
 
 <!--
-An `emptyDir` volume is first created when a Pod is assigned to a node, and
-exists as long as that Pod is running on that node. As the name says, the
-`emptyDir` volume is initially empty. All containers in the Pod can read and write the same
+For a Pod that defines an `emptyDir` volume, the volume is created when the Pod is assigned to a node.
+As the name says, the `emptyDir` volume is initially empty. All containers in the Pod can read and write the same
 files in the `emptyDir` volume, though that volume can be mounted at the same
 or different paths in each container. When a Pod is removed from a node for
 any reason, the data in the `emptyDir` is deleted permanently.
 -->
-当 Pod 分派到某个节点上时，`emptyDir` 卷会被创建，并且在 Pod 在该节点上运行期间，卷一直存在。
-就像其名称表示的那样，卷最初是空的。
-尽管 Pod 中的容器挂载 `emptyDir` 卷的路径可能相同也可能不同，这些容器都可以读写
-`emptyDir` 卷中相同的文件。
+对于定义了 `emptyDir` 卷的 Pod，在 Pod 被指派到某节点时此卷会被创建。
+就像其名称所表示的那样，`emptyDir` 卷最初是空的。尽管 Pod 中的容器挂载 `emptyDir`
+卷的路径可能相同也可能不同，但这些容器都可以读写 `emptyDir` 卷中相同的文件。
 当 Pod 因为某些原因被从节点上删除时，`emptyDir` 卷中的数据也会被永久删除。
 
 {{< note >}}
@@ -632,10 +630,10 @@ Dynamic provisioning is possible using a
 [StorageClass for GCE PD](/docs/concepts/storage/storage-classes/#gce-pd).
 Before creating a PersistentVolume, you must create the persistent disk:
 -->
-#### 手动供应基于区域 PD 的 PersistentVolume {#manually-provisioning-regional-pd-pv}
+#### 手动制备基于区域 PD 的 PersistentVolume {#manually-provisioning-regional-pd-pv}
 
 使用[为 GCE PD 定义的存储类](/zh-cn/docs/concepts/storage/storage-classes/#gce-pd)
-可以实现动态供应。在创建 PersistentVolume 之前，你首先要创建 PD。
+可以实现动态制备。在创建 PersistentVolume 之前，你首先要创建 PD。
 
 ```shell
 gcloud compute disks create --size=500GB my-data-disk
@@ -648,6 +646,9 @@ gcloud compute disks create --size=500GB my-data-disk
 -->
 #### 区域持久盘配置示例
 
+<!--
+# failure-domain.beta.kubernetes.io/zone should be used prior to 1.21
+-->
 ```yaml
 apiVersion: v1
 kind: PersistentVolume
@@ -770,7 +771,7 @@ and then removed entirely in the v1.26 release.
 Kubernetes {{< skew currentVersion >}} 不包含 `glusterfs` 卷类型。
 
 GlusterFS 树内存储驱动程序在 Kubernetes v1.25 版本中被弃用，然后在 v1.26 版本中被完全移除。
- 
+
 ### hostPath {#hostpath}
 
 {{< warning >}}
@@ -872,6 +873,10 @@ Watch out when using this type of volume, because:
 -->
 #### hostPath 配置示例
 
+<!--
+# directory location on host
+# this field is optional
+-->
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -887,7 +892,7 @@ spec:
   volumes:
   - name: test-volume
     hostPath:
-      # 宿主上目录位置
+      # 宿主机上目录位置
       path: /data
       # 此字段为可选
       type: Directory
@@ -903,14 +908,17 @@ you can try to mount directories and files separately, as shown in the
 `FileOrCreate` 模式不会负责创建文件的父目录。
 如果欲挂载的文件的父目录不存在，Pod 启动会失败。
 为了确保这种模式能够工作，可以尝试把文件和它对应的目录分开挂载，如
-[`FileOrCreate` 配置](#hostpath-fileorcreate-example) 所示。
+[`FileOrCreate` 配置](#hostpath-fileorcreate-example)所示。
 {{< /caution >}}
 
 <!--
 #### hostPath FileOrCreate configuration example {#hostpath-fileorcreate-example}
 -->
 #### hostPath FileOrCreate 配置示例  {#hostpath-fileorcreate-example}
 
+<!--
+# Ensure the file directory is created.
+-->
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -1191,6 +1199,9 @@ Here is an example Pod referencing a pre-provisioned Portworx volume:
 `portworxVolume` 类型的卷可以通过 Kubernetes 动态创建，也可以预先配备并在 Pod 内引用。
 下面是一个引用预先配备的 Portworx 卷的示例 Pod：
 
+<!--
+# This Portworx volume must already exist.
+-->
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -1253,7 +1264,7 @@ To enable the feature, set `CSIMigrationPortworx=true` in kube-controller-manage
 A projected volume maps several existing volume sources into the same
 directory. For more details, see [projected volumes](/docs/concepts/storage/projected-volumes/).
 -->
-### projected （投射）   {#projected}
+### 投射（projected）   {#projected}
 
 投射卷能将若干现有的卷来源映射到同一目录上。更多详情请参考[投射卷](/zh-cn/docs/concepts/storage/projected-volumes/)。
 
@@ -1354,7 +1365,7 @@ RBD CSI driver:
 * 你必须在集群中安装 v3.5.0 或更高版本的 Ceph CSI 驱动（`rbd.csi.ceph.com`）。
 * 因为 `clusterID` 是 CSI 驱动程序必需的参数，而树内存储类又将 `monitors`
   作为一个必需的参数，所以 Kubernetes 存储管理者需要根据 `monitors`
-  的哈希值（例：`#echo -n '<monitors_string>' | md5sum`）来创建
+  的哈希值（例如：`#echo -n '<monitors_string>' | md5sum`）来创建
   `clusterID`，并保持该 `monitors` 存在于该 `clusterID` 的配置中。
 * 同时，如果树内存储类的 `adminId` 的值不是 `admin`，那么其 `adminSecretName`
   就需要被修改成 `adminId` 参数的 base64 编码值。
@@ -1427,7 +1438,6 @@ For more information, see the [vSphere volume](https://github.com/kubernetes/exa
 
 {{< feature-state for_k8s_version="v1.26" state="stable" >}}
 
-
 <!--
 In Kubernetes {{< skew currentVersion >}}, all operations for the in-tree `vsphereVolume` type
 are redirected to the `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver.
@@ -1568,8 +1578,11 @@ The host directory `/var/log/pods/pod1` is mounted at `/logs` in the container.
 -->
 在这个示例中，`Pod` 使用 `subPathExpr` 来 `hostPath` 卷 `/var/log/pods` 中创建目录 `pod1`。
 `hostPath` 卷采用来自 `downwardAPI` 的 Pod 名称生成目录名。
-宿主目录 `/var/log/pods/pod1` 被挂载到容器的 `/logs` 中。
+宿主机目录 `/var/log/pods/pod1` 被挂载到容器的 `/logs` 中。
 
+<!--
+# The variable expansion uses round brackets (not curly brackets).
+-->
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -1652,8 +1665,8 @@ to the [volume plugin FAQ](https://github.com/kubernetes/community/blob/master/s
 -->
 CSI 和 FlexVolume 都允许独立于 Kubernetes 代码库开发卷插件，并作为扩展部署（安装）在 Kubernetes 集群上。
 
-对于希望创建树外（Out-Of-Tree）卷插件的存储供应商，请参考
-[卷插件常见问题](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)。
+对于希望创建树外（Out-Of-Tree）卷插件的存储供应商，
+请参考[卷插件常见问题](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)。
 
 ### CSI
 
@@ -1778,7 +1791,7 @@ persistent volume:
   该映射必须与 CSI 驱动程序返回的 `CreateVolumeResponse` 中的 `volume.attributes`
   字段的映射相对应；
   [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)中有相应的定义。
-  该映射通过`ControllerPublishVolumeRequest`、`NodeStageVolumeRequest`、和
+  该映射通过`ControllerPublishVolumeRequest`、`NodeStageVolumeRequest` 和
   `NodePublishVolumeRequest` 中的 `volume_context` 字段传递给 CSI 驱动。
 
 <!--
@@ -1912,7 +1925,7 @@ stand-alone binary that needs to be pre-installed on each Windows node.
 For more details, refer to the deployment guide of the CSI plugin you wish to deploy.
 -->
 CSI 节点插件需要执行多种特权操作，例如扫描磁盘设备和挂载文件系统等。
-这些操作在每个宿主操作系统上都是不同的。对于 Linux 工作节点而言，容器化的 CSI
+这些操作在每个宿主机操作系统上都是不同的。对于 Linux 工作节点而言，容器化的 CSI
 节点插件通常部署为特权容器。对于 Windows 工作节点而言，容器化 CSI
 节点插件的特权操作是通过 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)
 来支持的。csi-proxy 是一个由社区管理的、独立的可执行二进制文件，
@@ -1986,7 +1999,7 @@ The following FlexVolume [plugins](https://github.com/Microsoft/K8s-Storage-Plug
 deployed as PowerShell scripts on the host, support Windows nodes:
 -->
 下面的 FlexVolume [插件](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)
-以 PowerShell 脚本的形式部署在宿主系统上，支持 Windows 节点：
+以 PowerShell 脚本的形式部署在宿主机系统上，支持 Windows 节点：
 
 * [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd)
 * [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd)
@@ -2034,17 +2047,15 @@ in `Container.volumeMounts`. Its values are:
   cri-dockerd (Docker) is known to choose `rslave` mount propagation when the
   mount source contains the Docker daemon's root directory (`/var/lib/docker`).
 -->
-
 * `None` - 此卷挂载将不会感知到主机后续在此卷或其任何子目录上执行的挂载变化。
-   类似的，容器所创建的卷挂载在主机上是不可见的。这是默认模式。
+  类似的，容器所创建的卷挂载在主机上是不可见的。这是默认模式。
 
-   该模式等同于 [`mount(8)`](https://man7.org/linux/man-pages/man8/mount.8.html)中描述的
-   `rprivate` 挂载传播选项。
+  该模式等同于 [`mount(8)`](https://man7.org/linux/man-pages/man8/mount.8.html) 中描述的
+  `rprivate` 挂载传播选项。
 
-   然而，当 `rprivate` 传播选项不适用时，CRI 运行时可以转为选择 `rslave` 挂载传播选项
-   （即 `HostToContainer`）。当挂载源包含 Docker 守护进程的根目录（`/var/lib/docker`）时，
-   cri-dockerd (Docker) 已知可以选择 `rslave` 挂载传播选项。
-   。
+  然而，当 `rprivate` 传播选项不适用时，CRI 运行时可以转为选择 `rslave` 挂载传播选项
+  （即 `HostToContainer`）。当挂载源包含 Docker 守护进程的根目录（`/var/lib/docker`）时，
+  cri-dockerd (Docker) 已知可以选择 `rslave` 挂载传播选项。
 
 <!--
 * `HostToContainer` - This volume mount will receive all subsequent mounts
@@ -2084,7 +2095,7 @@ in `Container.volumeMounts`. Its values are:
 * `Bidirectional` - 这种卷挂载和 `HostToContainer` 挂载表现相同。
   另外，容器创建的卷挂载将被传播回至主机和使用同一卷的所有 Pod 的所有容器。
 
-  该模式等同于 [`mount(8)`](https://man7.org/linux/man-pages/man8/mount.8.html)中描述的
+  该模式等同于 [`mount(8)`](https://man7.org/linux/man-pages/man8/mount.8.html) 中描述的
   `rshared` 挂载传播选项。
 
   {{< warning >}}
@@ -2101,36 +2112,6 @@ in `Container.volumeMounts`. Its values are:
   此外，由 Pod 中的容器创建的任何卷挂载必须在终止时由容器销毁（卸载）。
   {{< /warning >}}
 
-<!--
-### Configuration
-
-Before mount propagation can work properly on some deployments (CoreOS,
-RedHat/Centos, Ubuntu) mount share must be configured correctly in
-Docker as shown below.
--->
-### 配置  {#configuration}
-
-在某些部署环境中，挂载传播正常工作前，必须在 Docker 中正确配置挂载共享（mount share），如下所示。
-
-<!--
-Edit your Docker's `systemd` service file. Set `MountFlags` as follows:
--->
-编辑你的 Docker `systemd` 服务文件，按下面的方法设置 `MountFlags`：
-
-```shell
-MountFlags=shared
-```
-
-<!--
-Or, remove `MountFlags=slave` if present. Then restart the Docker daemon:
--->
-或者，如果存在 `MountFlags=slave` 就删除掉。然后重启 Docker 守护进程：
-
-```shell
-sudo systemctl daemon-reload
-sudo systemctl restart docker
-```
-
 ## {{% heading "whatsnext" %}}
 
 <!--