Merge pull request #43365 from tengqm/zh-resync-storage
[zh] Resync storage concepts pagespull/43375/head
Kubernetes Prow Robot
GitHub
commit
b05919b0f8
|
|
@ -311,7 +311,7 @@ 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
|
||||
|
|
@ -319,11 +319,10 @@ object in the same namespace as the Pod and ensures that the PersistentVolumeCla
|
|||
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)。
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -105,10 +105,10 @@ 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`,
|
||||
|
|
@ -116,8 +116,8 @@ 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 对象
|
||||
|
|
|
|||
Loading…
Reference in New Issue