Merge pull request #43365 from tengqm/zh-resync-storage

[zh] Resync storage concepts pages

Author: k8s-ci-robot

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

@@ -311,19 +311,18 @@ spec:
 
 <!--
 The key design idea is that the
-[parameters for a volume claim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)
+[parameters for a volume claim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1-core)
 are allowed inside a volume source of the Pod. Labels, annotations and
 the whole set of fields for a PersistentVolumeClaim are supported. When such a Pod gets
 created, the ephemeral volume controller then creates an actual PersistentVolumeClaim
 object in the same namespace as the Pod and ensures that the PersistentVolumeClaim
 gets deleted when the Pod gets deleted.
 -->
 关键的设计思想是在 Pod 的卷来源中允许使用
-[卷申领的参数](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-core)。
+[卷申领的参数](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1-core)。
 PersistentVolumeClaim 的标签、注解和整套字段集均被支持。
-创建这样一个 Pod 后，
-临时卷控制器在 Pod 所属的命名空间中创建一个实际的 PersistentVolumeClaim 对象，
-并确保删除 Pod 时，同步删除 PersistentVolumeClaim。
+创建这样一个 Pod 后，临时卷控制器在 Pod 所属的命名空间中创建一个实际的
+PersistentVolumeClaim 对象，并确保删除 Pod 时，同步删除 PersistentVolumeClaim。
 
 <!--
 That triggers volume binding and/or provisioning, either immediately if
@@ -336,8 +335,7 @@ access to the volume once it is available.
 -->
 如上设置将触发卷的绑定与/或制备，相应动作或者在
 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}
-使用即时卷绑定时立即执行，
-或者当 Pod 被暂时性调度到某节点时执行 (`WaitForFirstConsumer` 卷绑定模式)。
+使用即时卷绑定时立即执行，或者当 Pod 被暂时性调度到某节点时执行 (`WaitForFirstConsumer` 卷绑定模式)。
 对于通用的临时卷，建议采用后者，这样调度器就可以自由地为 Pod 选择合适的节点。
 对于即时绑定，调度器则必须选出一个节点，使得在卷可用时，能立即访问该卷。
 
@@ -355,8 +353,8 @@ and in this case you need to ensure that volume clean up happens separately.
 拥有通用临时存储的 Pod 是提供临时存储 (ephemeral storage) 的 PersistentVolumeClaim 的所有者。
 当 Pod 被删除时，Kubernetes 垃圾收集器会删除 PVC，
 然后 PVC 通常会触发卷的删除，因为存储类的默认回收策略是删除卷。
-你可以使用带有 `retain` 回收策略的 StorageClass 创建准临时 (quasi-ephemeral) 本地存储：
-该存储比 Pod 寿命长，在这种情况下，你需要确保单独进行卷清理。
+你可以使用带有 `retain` 回收策略的 StorageClass 创建准临时 (Quasi-Ephemeral) 本地存储：
+该存储比 Pod 寿命长，所以在这种情况下，你需要确保单独进行卷清理。
 
 <!--
 While these PVCs exist, they can be used like any other PVC. In
@@ -382,7 +380,7 @@ interact with the PVC because one does not have to search for it once
 the Pod name and volume name are known.
 -->
 自动创建的 PVC 采取确定性的命名机制：名称是 Pod 名称和卷名称的组合，中间由连字符(`-`)连接。
-在上面的示例中，PVC 将命名为 `my-app-scratch-volume` 。
+在上面的示例中，PVC 将被命名为 `my-app-scratch-volume` 。
 这种确定性的命名机制使得与 PVC 交互变得更容易，因为一旦知道 Pod 名称和卷名，就不必搜索它。
 
 <!--
@@ -391,10 +389,10 @@ Pods (a Pod "pod-a" with volume "scratch" and another Pod with name
 "pod" and volume "a-scratch" both end up with the same PVC name
 "pod-a-scratch") and between Pods and manually created PVCs.
 -->
-这种命名机制也引入了潜在的冲突，
-不同的 Pod 之间（名为 “Pod-a” 的 Pod 挂载名为 "scratch" 的卷，
-和名为 "pod" 的 Pod 挂载名为 “a-scratch” 的卷，这两者均会生成名为
-"pod-a-scratch" 的 PVC），或者在 Pod 和手工创建的 PVC 之间可能出现冲突。
+这种命名机制也引入了潜在的冲突，不同的 Pod 之间（名为 “Pod-a” 的
+Pod 挂载名为 "scratch" 的卷，和名为 "pod" 的 Pod 挂载名为 “a-scratch” 的卷，
+这两者均会生成名为 "pod-a-scratch" 的 PVC），或者在 Pod 和手工创建的
+PVC 之间可能出现冲突。
 
 <!--
 Such conflicts are detected: a PVC is only used for an ephemeral
@@ -403,15 +401,15 @@ ownership relationship. An existing PVC is not overwritten or
 modified. But this does not resolve the conflict because without the
 right PVC, the Pod cannot start.
 -->
-以下冲突会被检测到：如果 PVC 是为 Pod 创建的，那么它只用于临时卷。
+这类冲突会被检测到：如果 PVC 是为 Pod 创建的，那么它只用于临时卷。
 此检测基于所有权关系。现有的 PVC 不会被覆盖或修改。
 但这并不能解决冲突，因为如果没有正确的 PVC，Pod 就无法启动。
 
+{{< caution >}}
 <!--
 Take care when naming Pods and volumes inside the
 same namespace, so that these conflicts can't occur.
 -->
-{{< caution >}}
 当同一个命名空间中命名 Pod 和卷时，要小心，以防止发生此类冲突。
 {{< /caution >}}
 
@@ -461,7 +459,7 @@ See [local ephemeral storage](/docs/concepts/configuration/manage-resources-cont
 
 - 有关设计的更多信息，参阅
   [Ephemeral Inline CSI volumes KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md)。
-- 本特性下一步开发的更多信息，参阅
+- 关于本特性下一步开发的更多信息，参阅
   [enhancement tracking issue #596](https://github.com/kubernetes/enhancements/issues/596)。
 
 <!--

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

@@ -925,13 +925,13 @@ Older versions of Kubernetes also supported the following in-tree PersistentVolu
   (**not available** in v1.26)
 * `photonPersistentDisk` - Photon controller persistent disk.
   (**not available** starting v1.15)
-* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume
+* `scaleIO` - ScaleIO volume
   (**not available** starting v1.21)
-* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage
+* `flocker` - Flocker storage
   (**not available** starting v1.25)
-* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume
+* `quobyte` - Quobyte volume
   (**not available** starting v1.25)
-* [`storageos`](/docs/concepts/storage/volumes/#storageos) - StorageOS volume
+* `storageos` - StorageOS volume
   (**not available** starting v1.25)
 -->
 旧版本的 Kubernetes 仍支持这些“树内（In-Tree）”持久卷类型：
@@ -943,13 +943,10 @@ Older versions of Kubernetes also supported the following in-tree PersistentVolu
 * [`cinder`](/zh-cn/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage)
   （v1.27 开始**不可用**）
 * `photonPersistentDisk` - Photon 控制器持久化盘。（从 v1.15 版本开始将**不可用**）
-* [`scaleIO`](/zh-cn/docs/concepts/storage/volumes/#scaleio) - ScaleIO 卷（v1.21 之后**不可用**）
-* [`flocker`](/zh-cn/docs/concepts/storage/volumes/#flocker) - Flocker 存储
-  （v1.25 之后**不可用**）
-* [`quobyte`](/zh-cn/docs/concepts/storage/volumes/#quobyte) - Quobyte 卷
-  （v1.25 之后**不可用**）
-* [`storageos`](/zh-cn/docs/concepts/storage/volumes/#storageos) - StorageOS 卷
-  （v1.25 之后**不可用**）
+* `scaleIO` - ScaleIO 卷（v1.21 之后**不可用**）
+* `flocker` - Flocker 存储 （v1.25 之后**不可用**）
+* `quobyte` - Quobyte 卷 （v1.25 之后**不可用**）
+* `storageos` - StorageOS 卷 （v1.25 之后**不可用**）
 
 <!--
 ## Persistent Volumes

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

@@ -59,14 +59,14 @@ see the [all-in-one volume](https://git.k8s.io/design-proposals-archive/node/all
 -->
 ### 带有 Secret、DownwardAPI 和 ConfigMap 的配置示例 {#example-configuration-secret-downwardapi-configmap}
 
-{{< codenew file="pods/storage/projected-secret-downwardapi-configmap.yaml" >}}
+{{% code_sample file="pods/storage/projected-secret-downwardapi-configmap.yaml" %}}
 
 <!--
 ### Example configuration: secrets with a non-default permission mode set {#example-configuration-secrets-nondefault-permission-mode}
 -->
 ### 带有非默认权限模式设置的 Secret 的配置示例 {#example-configuration-secrets-nondefault-permission-mode}
 
-{{< codenew file="pods/storage/projected-secrets-nondefault-permission-mode.yaml" >}}
+{{% code_sample file="pods/storage/projected-secrets-nondefault-permission-mode.yaml" %}}
 
 <!--
 Each projected volume source is listed in the spec under `sources`. The
@@ -94,7 +94,7 @@ into a Pod at a specified path. For example:
 你可以将当前[服务账号](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens)的令牌注入到
 Pod 中特定路径下。例如：
 
-{{< codenew file="pods/storage/projected-service-account-token.yaml" >}}
+{{% code_sample file="pods/storage/projected-service-account-token.yaml" %}}
 
 <!--
 The example Pod has a projected volume containing the injected service account

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

@@ -57,12 +57,10 @@ class needs to be dynamically provisioned.
 <!--
 The name of a StorageClass object is significant, and is how users can
 request a particular class. Administrators set the name and other parameters
-of a class when first creating StorageClass objects, and the objects cannot
-be updated once they are created.
+of a class when first creating StorageClass objects.
 -->
 StorageClass 对象的命名很重要，用户使用这个命名来请求生成一个特定的类。
-当创建 StorageClass 对象时，管理员设置 StorageClass 对象的命名和其他参数，
-一旦创建了对象就不能再对其更新。
+当创建 StorageClass 对象时，管理员设置 StorageClass 对象的命名和其他参数。
 
 <!--
 Administrators can specify a default StorageClass only for PVCs that don't

content/zh-cn/docs/concepts/storage/volume-snapshot-classes.md

@@ -105,19 +105,19 @@ used for provisioning VolumeSnapshots. This field must be specified.
 <!--
 ### DeletionPolicy
 
-Volume snapshot classes have a deletionPolicy. It enables you to configure what 
-happens to a VolumeSnapshotContent when the VolumeSnapshot object it is bound to 
-is to be deleted. The deletionPolicy of a volume snapshot class can either be 
-`Retain` or `Delete`. This field must be specified.
+Volume snapshot classes have a [deletionPolicy](/docs/concepts/storage/volume-snapshots/#delete).
+It enables you to configure what happens to a VolumeSnapshotContent when the VolumeSnapshot
+object it is bound to is to be deleted. The deletionPolicy of a volume snapshot class can
+either be `Retain` or `Delete`. This field must be specified.
 
 If the deletionPolicy is `Delete`, then the underlying storage snapshot will be 
 deleted along with the VolumeSnapshotContent object. If the deletionPolicy is `Retain`, 
 then both the underlying snapshot and VolumeSnapshotContent remain.
 -->
 ### 删除策略 {#deletion-policy}
 
-卷快照类具有 `deletionPolicy` 属性。用户可以配置当所绑定的 VolumeSnapshot
-对象将被删除时，如何处理 VolumeSnapshotContent 对象。
+卷快照类具有 [deletionPolicy] 属性(/zh-cn/docs/concepts/storage/volume-snapshots/#delete)。
+用户可以配置当所绑定的 VolumeSnapshot 对象将被删除时，如何处理 VolumeSnapshotContent 对象。
 卷快照类的这个策略可以是 `Retain` 或者 `Delete`。这个策略字段必须指定。
 
 如果删除策略是 `Delete`，那么底层的存储快照会和 VolumeSnapshotContent 对象