Switch language name 'zh' to 'zh-cn'
This is the first step to rename 'zh' to 'zh-cn'. There are several reasons why we rename the language name.
- The upstream docsy theme changed the language name, leading to many warnings during site build;
The side-effect is that the i18n strings are no longer working.
- We believe renaming the language is the right thing to do, because this move can make room for other variants of Chinese language, such as 'zh-tw', 'zh-sg' etc.
There would be several follow-ups to this PR, such as fixing the intra-site links, adding redirects etc.
We will lock up changes to zh/zh-cn pages for the moment, until this one gets in.
This PR is based on commit cdad0a7342.
This commit is contained in:
Qiming Teng
@@ -0,0 +1,5 @@
|
||||
---
|
||||
title: "存储"
|
||||
weight: 70
|
||||
description: 为集群中的 Pods 提供长期和临时存储的方法。
|
||||
---
|
||||
@@ -0,0 +1,211 @@
|
||||
---
|
||||
title: 动态卷供应
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
title: Dynamic Volume Provisioning
|
||||
content_type: concept
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
Dynamic volume provisioning allows storage volumes to be created on-demand.
|
||||
Without dynamic provisioning, cluster administrators have to manually make
|
||||
calls to their cloud or storage provider to create new storage volumes, and
|
||||
then create [`PersistentVolume` objects](/docs/concepts/storage/persistent-volumes/)
|
||||
to represent them in Kubernetes. The dynamic provisioning feature eliminates
|
||||
the need for cluster administrators to pre-provision storage. Instead, it
|
||||
automatically provisions storage when it is requested by users.
|
||||
-->
|
||||
动态卷供应允许按需创建存储卷。
|
||||
如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，
|
||||
然后在 Kubernetes 集群创建
|
||||
[`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。
|
||||
动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Background
|
||||
-->
|
||||
## 背景
|
||||
|
||||
<!--
|
||||
The implementation of dynamic volume provisioning is based on the API object `StorageClass`
|
||||
from the API group `storage.k8s.io`. A cluster administrator can define as many
|
||||
`StorageClass` objects as needed, each specifying a *volume plugin* (aka
|
||||
*provisioner*) that provisions a volume and the set of parameters to pass to
|
||||
that provisioner when provisioning.
|
||||
-->
|
||||
动态卷供应的实现基于 `storage.k8s.io` API 组中的 `StorageClass` API 对象。
|
||||
集群管理员可以根据需要定义多个 `StorageClass` 对象，每个对象指定一个*卷插件*（又名 *provisioner*），
|
||||
卷插件向卷供应商提供在创建卷时需要的数据卷信息及相关参数。
|
||||
|
||||
<!--
|
||||
A cluster administrator can define and expose multiple flavors of storage (from
|
||||
the same or different storage systems) within a cluster, each with a custom set
|
||||
of parameters. This design also ensures that end users don't have to worry
|
||||
about the complexity and nuances of how storage is provisioned, but still
|
||||
have the ability to select from multiple storage options.
|
||||
-->
|
||||
集群管理员可以在集群中定义和公开多种存储（来自相同或不同的存储系统），每种都具有自定义参数集。
|
||||
该设计也确保终端用户不必担心存储供应的复杂性和细微差别，但仍然能够从多个存储选项中进行选择。
|
||||
|
||||
<!--
|
||||
More information on storage classes can be found
|
||||
[here](/docs/concepts/storage/storage-classes/).
|
||||
-->
|
||||
点击[这里](/zh/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。
|
||||
|
||||
<!--
|
||||
## Enabling Dynamic Provisioning
|
||||
-->
|
||||
## 启用动态卷供应 {#enabling-dynamic-provisioning}
|
||||
|
||||
<!--
|
||||
To enable dynamic provisioning, a cluster administrator needs to pre-create
|
||||
one or more StorageClass objects for users.
|
||||
StorageClass objects define which provisioner should be used and what parameters
|
||||
should be passed to that provisioner when dynamic provisioning is invoked.
|
||||
The name of a StorageClass object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
The following manifest creates a storage class "slow" which provisions standard
|
||||
disk-like persistent disks.
|
||||
-->
|
||||
要启用动态供应功能，集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。
|
||||
`StorageClass` 对象定义当动态供应被调用时，哪一个驱动将被使用和哪些参数将被传递给驱动。
|
||||
StorageClass 对象的名字必须是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
|
||||
以下清单创建了一个 `StorageClass` 存储类 "slow"，它提供类似标准磁盘的永久磁盘。
|
||||
|
||||
```yaml
|
||||
apiVersion: storage.k8s.io/v1
|
||||
kind: StorageClass
|
||||
metadata:
|
||||
name: slow
|
||||
provisioner: kubernetes.io/gce-pd
|
||||
parameters:
|
||||
type: pd-standard
|
||||
```
|
||||
|
||||
<!--
|
||||
The following manifest creates a storage class "fast" which provisions
|
||||
SSD-like persistent disks.
|
||||
-->
|
||||
以下清单创建了一个 "fast" 存储类，它提供类似 SSD 的永久磁盘。
|
||||
|
||||
```yaml
|
||||
apiVersion: storage.k8s.io/v1
|
||||
kind: StorageClass
|
||||
metadata:
|
||||
name: fast
|
||||
provisioner: kubernetes.io/gce-pd
|
||||
parameters:
|
||||
type: pd-ssd
|
||||
```
|
||||
|
||||
<!--
|
||||
## Using Dynamic Provisioning
|
||||
-->
|
||||
## 使用动态卷供应
|
||||
|
||||
<!--
|
||||
Users request dynamically provisioned storage by including a storage class in
|
||||
their `PersistentVolumeClaim`. Before Kubernetes v1.6, this was done via the
|
||||
`volume.beta.kubernetes.io/storage-class` annotation. However, this annotation
|
||||
is deprecated since v1.9. Users now can and should instead use the
|
||||
`storageClassName` field of the `PersistentVolumeClaim` object. The value of
|
||||
this field must match the name of a `StorageClass` configured by the
|
||||
administrator (see [below](#enabling-dynamic-provisioning)).
|
||||
-->
|
||||
用户通过在 `PersistentVolumeClaim` 中包含存储类来请求动态供应的存储。
|
||||
在 Kubernetes v1.9 之前，这通过 `volume.beta.kubernetes.io/storage-class` 注解实现。然而，这个注解自 v1.6 起就不被推荐使用了。
|
||||
用户现在能够而且应该使用 `PersistentVolumeClaim` 对象的 `storageClassName` 字段。
|
||||
这个字段的值必须能够匹配到集群管理员配置的 `StorageClass` 名称（见[下面](#enabling-dynamic-provisioning)）。
|
||||
|
||||
<!--
|
||||
To select the "fast" storage class, for example, a user would create the
|
||||
following PersistentVolumeClaim:
|
||||
-->
|
||||
例如，要选择 “fast” 存储类，用户将创建如下的 PersistentVolumeClaim：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: claim1
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
storageClassName: fast
|
||||
resources:
|
||||
requests:
|
||||
storage: 30Gi
|
||||
```
|
||||
|
||||
<!--
|
||||
This claim results in an SSD-like Persistent Disk being automatically
|
||||
provisioned. When the claim is deleted, the volume is destroyed.
|
||||
-->
|
||||
该声明会自动供应一块类似 SSD 的永久磁盘。
|
||||
在删除该声明后，这个卷也会被销毁。
|
||||
|
||||
<!--
|
||||
## Defaulting Behavior
|
||||
-->
|
||||
## 设置默认值的行为
|
||||
|
||||
<!--
|
||||
Dynamic provisioning can be enabled on a cluster such that all claims are
|
||||
dynamically provisioned if no storage class is specified. A cluster administrator
|
||||
can enable this behavior by:
|
||||
-->
|
||||
可以在集群上启用动态卷供应，以便在未指定存储类的情况下动态设置所有声明。
|
||||
集群管理员可以通过以下方式启用此行为：
|
||||
|
||||
<!--
|
||||
- Marking one `StorageClass` object as *default*;
|
||||
- Making sure that the [`DefaultStorageClass` admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
|
||||
is enabled on the API server.
|
||||
-->
|
||||
- 标记一个 `StorageClass` 为 *默认*；
|
||||
- 确保 [`DefaultStorageClass` 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。
|
||||
|
||||
<!--
|
||||
An administrator can mark a specific `StorageClass` as default by adding the
|
||||
`storageclass.kubernetes.io/is-default-class` annotation to it.
|
||||
When a default `StorageClass` exists in a cluster and a user creates a
|
||||
`PersistentVolumeClaim` with `storageClassName` unspecified, the
|
||||
`DefaultStorageClass` admission controller automatically adds the
|
||||
`storageClassName` field pointing to the default storage class.
|
||||
-->
|
||||
管理员可以通过向其添加 `storageclass.kubernetes.io/is-default-class` 注解来将特定的 `StorageClass` 标记为默认。
|
||||
当集群中存在默认的 `StorageClass` 并且用户创建了一个未指定 `storageClassName` 的 `PersistentVolumeClaim` 时，
|
||||
`DefaultStorageClass` 准入控制器会自动向其中添加指向默认存储类的 `storageClassName` 字段。
|
||||
|
||||
<!--
|
||||
Note that there can be at most one *default* storage class on a cluster, or
|
||||
a `PersistentVolumeClaim` without `storageClassName` explicitly specified cannot
|
||||
be created.
|
||||
-->
|
||||
请注意，集群上最多只能有一个 *默认* 存储类，否则无法创建没有明确指定
|
||||
`storageClassName` 的 `PersistentVolumeClaim`。
|
||||
|
||||
<!--
|
||||
## Topology Awareness
|
||||
-->
|
||||
## 拓扑感知
|
||||
|
||||
<!--
|
||||
In [Multi-Zone](/docs/setup/multiple-zones) clusters, Pods can be spread across
|
||||
Zones in a Region. Single-Zone storage backends should be provisioned in the Zones where
|
||||
Pods are scheduled. This can be accomplished by setting the [Volume Binding
|
||||
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
|
||||
-->
|
||||
在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
|
||||
单区域存储后端应该被供应到 Pod 被调度到的区域。
|
||||
这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。
|
||||
|
||||
@@ -0,0 +1,484 @@
|
||||
---
|
||||
title: 临时卷
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- jsafrane
|
||||
- saad-ali
|
||||
- msau42
|
||||
- xing-yang
|
||||
- pohly
|
||||
title: Ephemeral Volumes
|
||||
content_type: concept
|
||||
weight: 30
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This document describes _ephemeral volumes_ in Kubernetes. Familiarity
|
||||
with [volumes](/docs/concepts/storage/volumes/) is suggested, in
|
||||
particular PersistentVolumeClaim and PersistentVolume.
|
||||
-->
|
||||
本文档描述 Kubernetes 中的 _临时卷（Ephemeral Volume）_。
|
||||
建议先了解[卷](/zh/docs/concepts/storage/volumes/)，特别是 PersistentVolumeClaim 和 PersistentVolume。
|
||||
|
||||
<!-- body -->
|
||||
<!--
|
||||
Some application need additional storage but don't care whether that
|
||||
data is stored persistently across restarts. For example, caching
|
||||
services are often limited by memory size and can move infrequently
|
||||
used data into storage that is slower than memory with little impact
|
||||
on overall performance.
|
||||
-->
|
||||
有些应用程序需要额外的存储，但并不关心数据在重启后仍然可用。
|
||||
例如，缓存服务经常受限于内存大小，将不常用的数据转移到比内存慢、但对总体性能的影响很小的存储中。
|
||||
|
||||
<!--
|
||||
Other applications expect some read-only input data to be present in
|
||||
files, like configuration data or secret keys.
|
||||
-->
|
||||
另有些应用程序需要以文件形式注入的只读数据，比如配置数据或密钥。
|
||||
|
||||
<!--
|
||||
_Ephemeral volumes_ are designed for these use cases. Because volumes
|
||||
follow the Pod's lifetime and get created and deleted along with the
|
||||
Pod, Pods can be stopped and restarted without being limited to where
|
||||
some persistent volume is available.
|
||||
-->
|
||||
_临时卷_ 就是为此类用例设计的。因为卷会遵从 Pod 的生命周期，与 Pod 一起创建和删除，
|
||||
所以停止和重新启动 Pod 时，不会受持久卷在何处可用的限制。
|
||||
|
||||
<!--
|
||||
Ephemeral volumes are specified _inline_ in the Pod spec, which
|
||||
simplifies application deployment and management.
|
||||
-->
|
||||
临时卷在 Pod 规约中以 _内联_ 方式定义，这简化了应用程序的部署和管理。
|
||||
|
||||
<!--
|
||||
### Types of ephemeral volumes
|
||||
-->
|
||||
### 临时卷的类型 {#types-of-ephemeral-volumes}
|
||||
|
||||
<!--
|
||||
Kubernetes supports several different kinds of ephemeral volumes for
|
||||
different purposes:
|
||||
- [emptyDir](/docs/concepts/storage/volumes/#emptydir): empty at Pod startup,
|
||||
with storage coming locally from the kubelet base directory (usually
|
||||
the root disk) or RAM
|
||||
- [configMap](/docs/concepts/storage/volumes/#configmap),
|
||||
[downwardAPI](/docs/concepts/storage/volumes/#downwardapi),
|
||||
[secret](/docs/concepts/storage/volumes/#secret): inject different
|
||||
kinds of Kubernetes data into a Pod
|
||||
- [CSI ephemeral volumes](#csi-ephemeral-volumes):
|
||||
similar to the previous volume kinds, but provided by special
|
||||
[CSI drivers](https://github.com/container-storage-interface/spec/blob/master/spec.md)
|
||||
which specifically [support this feature](https://kubernetes-csi.github.io/docs/drivers.html)
|
||||
- [generic ephemeral volumes](#generic-ephemeral-volumes), which
|
||||
can be provided by all storage drivers that also support persistent volumes
|
||||
-->
|
||||
Kubernetes 为了不同的目的，支持几种不同类型的临时卷：
|
||||
- [emptyDir](/zh/docs/concepts/storage/volumes/#emptydir)：
|
||||
Pod 启动时为空，存储空间来自本地的 kubelet 根目录（通常是根磁盘）或内存
|
||||
- [configMap](/zh/docs/concepts/storage/volumes/#configmap)、
|
||||
[downwardAPI](/zh/docs/concepts/storage/volumes/#downwardapi)、
|
||||
[secret](/zh/docs/concepts/storage/volumes/#secret)：
|
||||
将不同类型的 Kubernetes 数据注入到 Pod 中
|
||||
- [CSI 临时卷](/zh/docs/concepts/storage/volumes/#csi-ephemeral-volumes)：
|
||||
类似于前面的卷类型，但由专门[支持此特性](https://kubernetes-csi.github.io/docs/drivers.html)
|
||||
的指定
|
||||
[CSI 驱动程序](https://github.com/container-storage-interface/spec/blob/master/spec.md)提供
|
||||
- [通用临时卷](#generic-ephemeral-volumes)：
|
||||
它可以由所有支持持久卷的存储驱动程序提供
|
||||
|
||||
<!--
|
||||
`emptyDir`, `configMap`, `downwardAPI`, `secret` are provided as
|
||||
[local ephemeral
|
||||
storage](/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage).
|
||||
They are managed by kubelet on each node.
|
||||
|
||||
CSI ephemeral volumes *must* be provided by third-party CSI storage
|
||||
drivers.
|
||||
-->
|
||||
`emptyDir`、`configMap`、`downwardAPI`、`secret` 是作为
|
||||
[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)
|
||||
提供的。它们由各个节点上的 kubelet 管理。
|
||||
|
||||
CSI 临时卷 *必须* 由第三方 CSI 存储驱动程序提供。
|
||||
|
||||
<!--
|
||||
Generic ephemeral volumes *can* be provided by third-party CSI storage
|
||||
drivers, but also by any other storage driver that supports dynamic
|
||||
provisioning. Some CSI drivers are written specifically for CSI
|
||||
ephemeral volumes and do not support dynamic provisioning: those then
|
||||
cannot be used for generic ephemeral volumes.
|
||||
-->
|
||||
通用临时卷 *可以* 由第三方 CSI 存储驱动程序提供，也可以由支持动态配置的任何其他存储驱动程序提供。
|
||||
一些专门为 CSI 临时卷编写的 CSI 驱动程序，不支持动态供应：因此这些驱动程序不能用于通用临时卷。
|
||||
|
||||
<!--
|
||||
The advantage of using third-party drivers is that they can offer
|
||||
functionality that Kubernetes itself does not support, for example
|
||||
storage with different performance characteristics than the disk that
|
||||
is managed by kubelet, or injecting different data.
|
||||
-->
|
||||
使用第三方驱动程序的优势在于，它们可以提供 Kubernetes 本身不支持的功能，
|
||||
例如，与 kubelet 管理的磁盘具有不同运行特征的存储，或者用来注入不同的数据
|
||||
|
||||
<!--
|
||||
### CSI ephemeral volumes
|
||||
-->
|
||||
### CSI 临时卷 {#csi-ephemeral-volumes}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
<!--
|
||||
This feature requires the `CSIInlineVolume` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It
|
||||
is enabled by default starting with Kubernetes 1.16.
|
||||
|
||||
CSI ephemeral volumes are only supported by a subset of CSI drivers.
|
||||
The Kubernetes CSI [Drivers list](https://kubernetes-csi.github.io/docs/drivers.html)
|
||||
shows which drivers support ephemeral volumes.
|
||||
-->
|
||||
|
||||
该特性需要启用参数 `CSIInlineVolume`
|
||||
[特性门控（feature gate）](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
该参数从 Kubernetes 1.16 开始默认启用。
|
||||
|
||||
{{< note >}}
|
||||
只有一部分 CSI 驱动程序支持 CSI 临时卷。Kubernetes CSI
|
||||
[驱动程序列表](https://kubernetes-csi.github.io/docs/drivers.html)
|
||||
显示了支持临时卷的驱动程序。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
Conceptually, CSI ephemeral volumes are similar to `configMap`,
|
||||
`downwardAPI` and `secret` volume types: the storage is managed locally on each
|
||||
node and is created together with other local resources after a Pod has been
|
||||
scheduled onto a node. Kubernetes has no concept of rescheduling Pods
|
||||
anymore at this stage. Volume creation has to be unlikely to fail,
|
||||
otherwise Pod startup gets stuck. In particular, [storage capacity
|
||||
aware Pod scheduling](/docs/concepts/storage/storage-capacity/) is *not*
|
||||
supported for these volumes. They are currently also not covered by
|
||||
the storage resource usage limits of a Pod, because that is something
|
||||
that kubelet can only enforce for storage that it manages itself.
|
||||
|
||||
|
||||
Here's an example manifest for a Pod that uses CSI ephemeral storage:
|
||||
-->
|
||||
从概念上讲，CSI 临时卷类似于 `configMap`、`downwardAPI` 和 `secret` 类型的卷：
|
||||
其存储在每个节点本地管理，并在将 Pod 调度到节点后与其他本地资源一起创建。
|
||||
在这个阶段，Kubernetes 没有重新调度 Pods 的概念。卷创建不太可能失败，否则 Pod 启动将会受阻。
|
||||
特别是，这些卷 **不** 支持[感知存储容量的 Pod 调度](/zh/docs/concepts/storage/storage-capacity/)。
|
||||
它们目前也没包括在 Pod 的存储资源使用限制中，因为 kubelet 只能对它自己管理的存储强制执行。
|
||||
|
||||
下面是使用 CSI 临时存储的 Pod 的示例清单：
|
||||
|
||||
```yaml
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: my-csi-app
|
||||
spec:
|
||||
containers:
|
||||
- name: my-frontend
|
||||
image: busybox:1.28
|
||||
volumeMounts:
|
||||
- mountPath: "/data"
|
||||
name: my-csi-inline-vol
|
||||
command: [ "sleep", "1000000" ]
|
||||
volumes:
|
||||
- name: my-csi-inline-vol
|
||||
csi:
|
||||
driver: inline.storage.kubernetes.io
|
||||
volumeAttributes:
|
||||
foo: bar
|
||||
```
|
||||
|
||||
<!--
|
||||
The `volumeAttributes` determine what volume is prepared by the
|
||||
driver. These attributes are specific to each driver and not
|
||||
standardized. See the documentation of each CSI driver for further
|
||||
instructions.
|
||||
|
||||
-->
|
||||
|
||||
`volumeAttributes` 决定驱动程序准备什么样的卷。这些属性特定于每个驱动程序，且没有实现标准化。
|
||||
有关进一步的说明，请参阅每个 CSI 驱动程序的文档。
|
||||
|
||||
<!--
|
||||
### CSI driver restrictions
|
||||
|
||||
CSI ephemeral volumes allow users to provide `volumeAttributes`
|
||||
directly to the CSI driver as part of the Pod spec. A CSI driver
|
||||
allowing `volumeAttributes` that are typically restricted to
|
||||
administrators is NOT suitable for use in an inline ephemeral volume.
|
||||
For example, parameters that are normally defined in the StorageClass
|
||||
should not be exposed to users through the use of inline ephemeral volumes.
|
||||
-->
|
||||
|
||||
### CSI 驱动程序限制 {#csi-driver-restrictions}
|
||||
|
||||
CSI 临时卷允许用户直接向 CSI 驱动程序提供 `volumeAttributes`，它会作为 Pod 规约的一部分。
|
||||
允许 `volumeAttributes` 的 CSI 驱动程序通常仅限于管理员使用，不适合在内联临时卷中使用。
|
||||
例如，通常在 StorageClass 中定义的参数不应通过使用内联临时卷向用户公开。
|
||||
|
||||
作为一个集群管理员，你可以使用
|
||||
[PodSecurityPolicy](/zh/docs/concepts/security/pod-security-policy/)
|
||||
来控制在 Pod 中可以使用哪些 CSI 驱动程序，
|
||||
具体则是通过 [`allowedCSIDrivers` 字段](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy)
|
||||
指定。
|
||||
|
||||
<!--
|
||||
Cluster administrators who need to restrict the CSI drivers that are
|
||||
allowed to be used as inline volumes within a Pod spec may do so by:
|
||||
- Removing `Ephemeral` from `volumeLifecycleModes` in the CSIDriver spec, which prevents the driver from being used as an inline ephemeral volume.
|
||||
- Using an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) to restrict how this driver is used.
|
||||
-->
|
||||
如果集群管理员需要限制 CSI 驱动程序在 Pod 规约中被作为内联卷使用，可以这样做：
|
||||
- 从 CSIDriver 规约的 `volumeLifecycleModes` 中删除 `Ephemeral`，这可以防止驱动程序被用作内联临时卷。
|
||||
- 使用[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
来限制如何使用此驱动程序。
|
||||
|
||||
<!--
|
||||
### Generic ephemeral volumes
|
||||
-->
|
||||
### 通用临时卷 {#generic-ephemeral-volumes}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
<!--
|
||||
Generic ephemeral volumes are similar to `emptyDir` volumes in the
|
||||
sense that they provide a per-pod directory for scratch data that is
|
||||
usually empty after provisioning. But they may also have additional
|
||||
features:
|
||||
|
||||
- Storage can be local or network-attached.
|
||||
- Volumes can have a fixed size that Pods are not able to exceed.
|
||||
- Volumes may have some initial data, depending on the driver and
|
||||
parameters.
|
||||
- Typical operations on volumes are supported assuming that the driver
|
||||
supports them, including
|
||||
[snapshotting](/docs/concepts/storage/volume-snapshots/),
|
||||
[cloning](/docs/concepts/storage/volume-pvc-datasource/),
|
||||
[resizing](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims),
|
||||
and [storage capacity tracking](/docs/concepts/storage/storage-capacity/).
|
||||
|
||||
Example:
|
||||
-->
|
||||
通用临时卷类似于 `emptyDir` 卷，因为它为每个 Pod 提供临时数据存放目录，
|
||||
在最初制备完毕时一般为空。不过通用临时卷也有一些额外的功能特性：
|
||||
|
||||
- 存储可以是本地的，也可以是网络连接的。
|
||||
- 卷可以有固定的大小，Pod 不能超量使用。
|
||||
- 卷可能有一些初始数据，这取决于驱动程序和参数。
|
||||
- 当驱动程序支持，卷上的典型操作将被支持，包括
|
||||
（[快照](/zh/docs/concepts/storage/volume-snapshots/)、
|
||||
[克隆](/zh/docs/concepts/storage/volume-pvc-datasource/)、
|
||||
[调整大小](/zh/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)和
|
||||
[存储容量跟踪](/zh/docs/concepts/storage/storage-capacity/)）。
|
||||
|
||||
示例：
|
||||
|
||||
```yaml
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: my-app
|
||||
spec:
|
||||
containers:
|
||||
- name: my-frontend
|
||||
image: busybox:1.28
|
||||
volumeMounts:
|
||||
- mountPath: "/scratch"
|
||||
name: scratch-volume
|
||||
command: [ "sleep", "1000000" ]
|
||||
volumes:
|
||||
- name: scratch-volume
|
||||
ephemeral:
|
||||
volumeClaimTemplate:
|
||||
metadata:
|
||||
labels:
|
||||
type: my-frontend-volume
|
||||
spec:
|
||||
accessModes: [ "ReadWriteOnce" ]
|
||||
storageClassName: "scratch-storage-class"
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
```
|
||||
|
||||
<!--
|
||||
### Lifecycle and PersistentVolumeClaim
|
||||
-->
|
||||
### 生命周期和 PersistentVolumeClaim {#lifecycle-and-persistentvolumeclaim}
|
||||
|
||||
<!--
|
||||
The key design idea is that the
|
||||
[parameters for a volume claim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralvolumesource-v1alpha1-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)。
|
||||
PersistentVolumeClaim 的标签、注解和整套字段集均被支持。
|
||||
创建这样一个 Pod 后，
|
||||
临时卷控制器在 Pod 所属的命名空间中创建一个实际的 PersistentVolumeClaim 对象，
|
||||
并确保删除 Pod 时，同步删除 PersistentVolumeClaim。
|
||||
|
||||
<!--
|
||||
That triggers volume binding and/or provisioning, either immediately if
|
||||
the {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} uses immediate volume binding or when the Pod is
|
||||
tentatively scheduled onto a node (`WaitForFirstConsumer` volume
|
||||
binding mode). The latter is recommended for generic ephemeral volumes
|
||||
because then the scheduler is free to choose a suitable node for
|
||||
the Pod. With immediate binding, the scheduler is forced to select a node that has
|
||||
access to the volume once it is available.
|
||||
-->
|
||||
如上设置将触发卷的绑定与/或准备操作，相应动作或者在
|
||||
{{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}
|
||||
使用即时卷绑定时立即执行，
|
||||
或者当 Pod 被暂时性调度到某节点时执行 (`WaitForFirstConsumer` 卷绑定模式)。
|
||||
对于常见的临时卷，建议采用后者，这样调度器就可以自由地为 Pod 选择合适的节点。
|
||||
对于即时绑定，调度器则必须选出一个节点，使得在卷可用时，能立即访问该卷。
|
||||
|
||||
<!--
|
||||
In terms of [resource ownership](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents),
|
||||
a Pod that has generic ephemeral storage is the owner of the PersistentVolumeClaim(s)
|
||||
that provide that ephemeral storage. When the Pod is deleted,
|
||||
the Kubernetes garbage collector deletes the PVC, which then usually
|
||||
triggers deletion of the volume because the default reclaim policy of
|
||||
storage classes is to delete volumes. You can create quasi-ephemeral local storage
|
||||
using a StorageClass with a reclaim policy of `retain`: the storage outlives the Pod,
|
||||
and in this case you need to ensure that volume clean up happens separately.
|
||||
-->
|
||||
就[资源所有权](/zh/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)而言，
|
||||
拥有通用临时存储的 Pod 是提供临时存储 (ephemeral storage) 的 PersistentVolumeClaim 的所有者。
|
||||
当 Pod 被删除时，Kubernetes 垃圾收集器会删除 PVC，
|
||||
然后 PVC 通常会触发卷的删除，因为存储类的默认回收策略是删除卷。
|
||||
你可以使用带有 `retain` 回收策略的 StorageClass 创建准临时 (quasi-ephemeral) 本地存储：
|
||||
该存储比 Pod 寿命长，在这种情况下，你需要确保单独进行卷清理。
|
||||
|
||||
<!--
|
||||
While these PVCs exist, they can be used like any other PVC. In
|
||||
particular, they can be referenced as data source in volume cloning or
|
||||
snapshotting. The PVC object also holds the current status of the
|
||||
volume.
|
||||
-->
|
||||
当这些 PVC 存在时，它们可以像其他 PVC 一样使用。
|
||||
特别是，它们可以被引用作为批量克隆或快照的数据源。
|
||||
PVC对象还保持着卷的当前状态。
|
||||
|
||||
<!--
|
||||
### PersistentVolumeClaim naming
|
||||
-->
|
||||
### PersistentVolumeClaim 的命名 {#persistentvolumeclaim-naming}
|
||||
|
||||
<!--
|
||||
Naming of the automatically created PVCs is deterministic: the name is
|
||||
a combination of Pod name and volume name, with a hyphen (`-`) in the
|
||||
middle. In the example above, the PVC name will be
|
||||
`my-app-scratch-volume`. This deterministic naming makes it easier to
|
||||
interact with the PVC because one does not have to search for it once
|
||||
the Pod name and volume name are known.
|
||||
-->
|
||||
自动创建的 PVCs 的命名是确定的：此名称是 Pod 名称和卷名称的组合，中间由连字符(`-`)连接。
|
||||
在上面的示例中，PVC 将命名为 `my-app-scratch-volume` 。
|
||||
这种确定性命名方式使得与 PVC 交互变得更容易，因为一旦知道 Pod 名称和卷名，就不必搜索它。
|
||||
|
||||
<!--
|
||||
The deterministic naming also introduces a potential conflict between different
|
||||
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 之间。
|
||||
|
||||
<!--
|
||||
Such conflicts are detected: a PVC is only used for an ephemeral
|
||||
volume if it was created for the Pod. This check is based on the
|
||||
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 不会被覆盖或修改。
|
||||
但这并不能解决冲突，因为如果没有正确的 PVC，Pod 就无法启动。
|
||||
|
||||
<!--
|
||||
Take care when naming Pods and volumes inside the
|
||||
same namespace, so that these conflicts can't occur.
|
||||
-->
|
||||
{{< caution >}}
|
||||
当命名 Pods 和卷出现在同一个命名空间中时，要小心，以防止发生此类冲突。
|
||||
{{< /caution >}}
|
||||
|
||||
<!--
|
||||
### Security
|
||||
-->
|
||||
### 安全 {#security}
|
||||
|
||||
<!--
|
||||
Enabling the GenericEphemeralVolume feature allows users to create
|
||||
PVCs indirectly if they can create Pods, even if they do not have
|
||||
permission to create PVCs directly. Cluster administrators must be
|
||||
aware of this. If this does not fit their security model, they should
|
||||
use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) that rejects objects like Pods that have a generic ephemeral volume.
|
||||
-->
|
||||
启用 GenericEphemeralVolume 特性会导致那些没有 PVCs 创建权限的用户，
|
||||
在创建 Pods 时，被允许间接的创建 PVCs。
|
||||
集群管理员必须意识到这一点。
|
||||
如果这不符合他们的安全模型，他们应该使用一个[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
拒绝包含通用临时卷的 Pods。
|
||||
|
||||
<!--
|
||||
The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota) still applies, so
|
||||
even if users are allowed to use this new mechanism, they cannot use
|
||||
it to circumvent other policies.
|
||||
-->
|
||||
[为 PVC 卷所设置的逐名字空间的配额](/zh/docs/concepts/policy/resource-quotas/#storage-resource-quota)
|
||||
仍然有效，因此即使允许用户使用这种新机制，他们也不能使用它来规避其他策略。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
### Ephemeral volumes managed by kubelet
|
||||
|
||||
See [local ephemeral storage](/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage).
|
||||
-->
|
||||
### kubelet 管理的临时卷 {#ephemeral-volumes-managed-by-kubelet}
|
||||
|
||||
参阅[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)。
|
||||
|
||||
<!--
|
||||
### CSI ephemeral volumes
|
||||
|
||||
- For more information on the design, see the [Ephemeral Inline CSI
|
||||
volumes KEP](https://github.com/kubernetes/enhancements/blob/ad6021b3d61a49040a3f835e12c8bb5424db2bbb/keps/sig-storage/20190122-csi-inline-volumes.md).
|
||||
- For more information on further development of this feature, see the [enhancement tracking issue #596](https://github.com/kubernetes/enhancements/issues/596).
|
||||
-->
|
||||
### CSI 临时卷 {#csi-ephemeral-volumes}
|
||||
|
||||
- 有关设计的更多信息，参阅
|
||||
[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)。
|
||||
|
||||
<!--
|
||||
### Generic ephemeral volumes
|
||||
|
||||
- For more information on the design, see the
|
||||
[Generic ephemeral inline volumes KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md).
|
||||
-->
|
||||
### 通用临时卷 {#generic-ephemeral-volumes}
|
||||
|
||||
- 有关设计的更多信息，参阅
|
||||
[Generic ephemeral inline volumes KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1698-generic-ephemeral-volumes/README.md)。
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,229 @@
|
||||
---
|
||||
title: 投射卷
|
||||
content_type: concept
|
||||
weight: 21 # just after persistent volumes
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- marosset
|
||||
- jsturtevant
|
||||
- zshihang
|
||||
title: Projected Volumes
|
||||
content_type: concept
|
||||
weight: 21 # just after persistent volumes
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This document describes _projected volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
|
||||
-->
|
||||
本文档描述 Kubernetes 中的*投射卷（Projected Volumes）*。
|
||||
建议先熟悉[卷](/zh/docs/concepts/storage/volumes/)概念。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Introduction
|
||||
|
||||
A `projected` volume maps several existing volume sources into the same directory.
|
||||
|
||||
Currently, the following types of volume sources can be projected:
|
||||
|
||||
* [`secret`](/docs/concepts/storage/volumes/#secret)
|
||||
* [`downwardAPI`](/docs/concepts/storage/volumes/#downwardapi)
|
||||
* [`configMap`](/docs/concepts/storage/volumes/#configmap)
|
||||
* [`serviceAccountToken`](#serviceaccounttoken)
|
||||
-->
|
||||
## 介绍 {#introduction}
|
||||
|
||||
一个 `projected` 卷可以将若干现有的卷源映射到同一个目录之上。
|
||||
|
||||
目前，以下类型的卷源可以被投射：
|
||||
|
||||
* [`secret`](/zh/docs/concepts/storage/volumes/#secret)
|
||||
* [`downwardAPI`](/zh/docs/concepts/storage/volumes/#downwardapi)
|
||||
* [`configMap`](/zh/docs/concepts/storage/volumes/#configmap)
|
||||
* [`serviceAccountToken`](#serviceaccounttoken)
|
||||
|
||||
<!--
|
||||
All sources are required to be in the same namespace as the Pod. For more details,
|
||||
see the [all-in-one volume](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md) design document.
|
||||
-->
|
||||
所有的卷源都要求处于 Pod 所在的同一个名字空间内。进一步的详细信息，可参考
|
||||
[一体化卷](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md)设计文档。
|
||||
|
||||
<!--
|
||||
### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap}
|
||||
-->
|
||||
### 带有 Secret、DownwardAPI 和 ConfigMap 的配置示例 {#example-configuration-secret-downwardapi-configmap}
|
||||
|
||||
{{< codenew 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" >}}
|
||||
|
||||
<!--
|
||||
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` 属性。
|
||||
|
||||
<!--
|
||||
## serviceAccountToken projected volumes {#serviceaccounttoken}
|
||||
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. For example:
|
||||
-->
|
||||
## serviceAccountToken 投射卷 {#serviceaccounttoken}
|
||||
当 `TokenRequestProjection` 特性被启用时，你可以将当前
|
||||
[服务账号](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)
|
||||
的令牌注入到 Pod 中特定路径下。例如：
|
||||
|
||||
{{< codenew file="pods/storage/projected-service-account-token.yaml" >}}
|
||||
|
||||
<!--
|
||||
The example Pod has a projected volume containing the injected service account
|
||||
token. Containers in this Pod can use that token to access the Kubernetes API
|
||||
server, authenticating with the identity of [the pod's ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/).
|
||||
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 服务器， 使用
|
||||
[pod 的 ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
进行身份验证。`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`](/docs/concepts/storage/volumes/#using-subpath)
|
||||
volume mount will not receive updates for those volume sources.
|
||||
-->
|
||||
以 [`subPath`](/zh/docs/concepts/storage/volumes/#using-subpath)
|
||||
形式使用投射卷源的容器无法收到对应卷源的更新。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
## SecurityContext interactions
|
||||
-->
|
||||
## 与 SecurityContext 间的关系 {#securitycontext-interactions}
|
||||
|
||||
<!--
|
||||
The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the the correct owner permissions set.
|
||||
-->
|
||||
关于在投射的服务账号卷中处理文件访问权限的[提案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal)
|
||||
介绍了如何使得所投射的文件具有合适的属主访问权限。
|
||||
|
||||
### Linux
|
||||
|
||||
<!--
|
||||
In Linux pods that have a projected volume and `RunAsUser` set in the Pod
|
||||
[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context),
|
||||
the projected files have the correct ownership set including container user
|
||||
ownership.
|
||||
-->
|
||||
在包含了投射卷并在
|
||||
[`SecurityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)
|
||||
中设置了 `RunAsUser` 属性的 Linux Pod 中，投射文件具有正确的属主属性设置，
|
||||
其中包含了容器用户属主。
|
||||
|
||||
### Windows
|
||||
|
||||
<!--
|
||||
In Windows pods that have a projected volume and `RunAsUsername` set in the
|
||||
Pod `SecurityContext`, the ownership is not enforced due to the way user
|
||||
accounts are managed in Windows. Windows stores and manages local user and group
|
||||
accounts in a database file called Security Account Manager (SAM). Each
|
||||
container maintains its own instance of the SAM database, to which the host has
|
||||
no visibility into while the container is running. Windows containers are
|
||||
designed to run the user mode portion of the OS in isolation from the host,
|
||||
hence the maintenance of a virtual SAM database. As a result, the kubelet running
|
||||
on the host does not have the ability to dynamically configure host file
|
||||
ownership for virtualized container accounts. It is recommended that if files on
|
||||
the host machine are to be shared with the container then they should be placed
|
||||
into their own volume mount outside of `C:\`.
|
||||
-->
|
||||
在包含了投射卷并在 `SecurityContext` 中设置了 `RunAsUsername` 的 Windows Pod 中,
|
||||
由于 Windows 中用户账号的管理方式问题，文件的属主无法正确设置。
|
||||
Windows 在名为安全账号管理器（Security Account Manager，SAM）
|
||||
的数据库中保存本地用户和组信息。每个容器会维护其自身的 SAM 数据库实例，
|
||||
宿主系统无法窥视到容器运行期间数据库内容。Windows 容器被设计用来运行操作系统的用户态部分，
|
||||
与宿主系统之间隔离，因此维护了一个虚拟的 SAM 数据库。
|
||||
所以，在宿主系统上运行的 kubelet 无法动态为虚拟的容器账号配置宿主文件的属主。
|
||||
如果需要将宿主机器上的文件与容器共享，建议将它们放到挂载于 `C:\` 之外
|
||||
的独立卷中。
|
||||
|
||||
<!--
|
||||
By default, the projected files will have the following ownership as shown for
|
||||
an example projected volume file:
|
||||
-->
|
||||
默认情况下，所投射的文件会具有如下例所示的属主属性设置：
|
||||
|
||||
```powershell
|
||||
PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List
|
||||
|
||||
Path : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt
|
||||
Owner : BUILTIN\Administrators
|
||||
Group : NT AUTHORITY\SYSTEM
|
||||
Access : NT AUTHORITY\SYSTEM Allow FullControl
|
||||
BUILTIN\Administrators Allow FullControl
|
||||
BUILTIN\Users Allow ReadAndExecute, Synchronize
|
||||
Audit :
|
||||
Sddl : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)
|
||||
```
|
||||
|
||||
<!--
|
||||
This implies all administrator users like `ContainerAdministrator` will have
|
||||
read, write and execute access while, non-administrator users will have read and
|
||||
execute access.
|
||||
-->
|
||||
这意味着，所有类似 `ContainerAdministrator` 的管理员用户都具有读、写和执行访问权限，
|
||||
而非管理员用户将具有读和执行访问权限。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
In general, granting the container access to the host is discouraged as it can
|
||||
open the door for potential security exploits.
|
||||
|
||||
Creating a Windows Pod with `RunAsUser` in it's `SecurityContext` will result in
|
||||
the Pod being stuck at `ContainerCreating` forever. So it is advised to not use
|
||||
the Linux only `RunAsUser` option with Windows Pods.
|
||||
-->
|
||||
总体而言，为容器授予访问宿主系统的权限这种做法是不推荐的，因为这样做可能会打开潜在的安全性攻击之门。
|
||||
|
||||
在创建 Windows Pod 时，如过在其 `SecurityContext` 中设置了 `RunAsUser`，
|
||||
Pod 会一直阻塞在 `ContainerCreating` 状态。因此，建议不要在 Windows
|
||||
节点上使用仅针对 Linux 的 `RunAsUser` 选项。
|
||||
{{< /note >}}
|
||||
|
||||
@@ -0,0 +1,167 @@
|
||||
---
|
||||
title: 存储容量
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
Storage capacity is limited and may vary depending on the node on
|
||||
which a pod runs: network-attached storage might not be accessible by
|
||||
all nodes, or storage is local to a node to begin with.
|
||||
|
||||
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
|
||||
|
||||
This page describes how Kubernetes keeps track of storage capacity and
|
||||
how the scheduler uses that information to [schedule Pods](/docs/concepts/scheduling-eviction/) onto nodes
|
||||
that have access to enough storage capacity for the remaining missing
|
||||
volumes. Without storage capacity tracking, the scheduler may choose a
|
||||
node that doesn't have enough capacity to provision a volume and
|
||||
multiple scheduling retries will be needed.
|
||||
-->
|
||||
存储容量是有限的，并且会因为运行 Pod 的节点不同而变化：
|
||||
网络存储可能并非所有节点都能够访问，或者对于某个节点存储是本地的。
|
||||
|
||||
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
|
||||
|
||||
本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将
|
||||
[Pod 调度](/zh/docs/concepts/scheduling-eviction/)到能够访问到足够存储容量的节点上。
|
||||
如果没有跟踪存储容量，调度程序可能会选择一个没有足够容量来提供卷的节点，并且需要多次调度重试。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
<!--
|
||||
Kubernetes v{{< skew currentVersion >}} includes cluster-level API support for
|
||||
storage capacity tracking. To use this you must also be using a CSI driver that
|
||||
supports capacity tracking. Consult the documentation for the CSI drivers that
|
||||
you use to find out whether this support is available and, if so, how to use
|
||||
it. If you are not running Kubernetes v{{< skew currentVersion >}}, check the
|
||||
documentation for that version of Kubernetes.
|
||||
-->
|
||||
Kubernetes v{{< skew currentVersion >}} 包含了对存储容量跟踪的集群级 API 支持。
|
||||
要使用它，你还必须使用支持容量跟踪的 CSI 驱动程序。请查阅你使用的 CSI 驱动程序的文档，
|
||||
以了解此支持是否可用，如果可用，该如何使用它。如果你运行的不是
|
||||
Kubernetes v{{< skew currentVersion >}}，请查看对应版本的 Kubernetes 文档。
|
||||
|
||||
<!-- body -->
|
||||
<!--
|
||||
## API
|
||||
|
||||
There are two API extensions for this feature:
|
||||
- [CSIStorageCapacity](/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1/) objects:
|
||||
these get produced by a CSI driver in the namespace
|
||||
where the driver is installed. Each object contains capacity
|
||||
information for one storage class and defines which nodes have
|
||||
access to that storage.
|
||||
- [The `CSIDriverSpec.StorageCapacity` field](/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1/#CSIDriverSpec):
|
||||
when set to `true`, the Kubernetes scheduler will consider storage
|
||||
capacity for volumes that use the CSI driver.
|
||||
-->
|
||||
## API
|
||||
|
||||
这个特性有两个 API 扩展接口：
|
||||
- [CSIStorageCapacity](/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1/) 对象：这些对象由
|
||||
CSI 驱动程序在安装驱动程序的命名空间中产生。
|
||||
每个对象都包含一个存储类的容量信息，并定义哪些节点可以访问该存储。
|
||||
- [`CSIDriverSpec.StorageCapacity` 字段](/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1/#CSIDriverSpec)：
|
||||
设置为 true 时，Kubernetes 调度程序将考虑使用 CSI 驱动程序的卷的存储容量。
|
||||
|
||||
<!--
|
||||
## Scheduling
|
||||
|
||||
Storage capacity information is used by the Kubernetes scheduler if:
|
||||
- a Pod uses a volume that has not been created yet,
|
||||
- that volume uses a {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} which references a CSI driver and
|
||||
uses `WaitForFirstConsumer` [volume binding
|
||||
mode](/docs/concepts/storage/storage-classes/#volume-binding-mode),
|
||||
and
|
||||
- the `CSIDriver` object for the driver has `StorageCapacity` set to
|
||||
true.
|
||||
|
||||
In that case, the scheduler only considers nodes for the Pod which
|
||||
have enough storage available to them. This check is very
|
||||
simplistic and only compares the size of the volume against the
|
||||
capacity listed in `CSIStorageCapacity` objects with a topology that
|
||||
includes the node.
|
||||
|
||||
For volumes with `Immediate` volume binding mode, the storage driver
|
||||
decides where to create the volume, independently of Pods that will
|
||||
use the volume. The scheduler then schedules Pods onto nodes where the
|
||||
volume is available after the volume has been created.
|
||||
|
||||
For [CSI ephemeral volumes](/docs/concepts/storage/volumes/#csi),
|
||||
scheduling always happens without considering storage capacity. This
|
||||
is based on the assumption that this volume type is only used by
|
||||
special CSI drivers which are local to a node and do not need
|
||||
significant resources there.
|
||||
-->
|
||||
## 调度
|
||||
|
||||
如果有以下情况，存储容量信息将会被 Kubernetes 调度程序使用：
|
||||
- Pod 使用的卷还没有被创建，
|
||||
- 卷使用引用了 CSI 驱动的 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}，
|
||||
并且使用了 `WaitForFirstConsumer` [卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)，
|
||||
- 驱动程序的 `CSIDriver` 对象的 `StorageCapacity` 被设置为 true。
|
||||
|
||||
在这种情况下，调度程序仅考虑将 Pod 调度到有足够存储容量的节点上。这个检测非常简单，
|
||||
仅将卷的大小与 `CSIStorageCapacity` 对象中列出的容量进行比较，并使用包含该节点的拓扑。
|
||||
|
||||
对于具有 `Immediate` 卷绑定模式的卷，存储驱动程序将决定在何处创建该卷，而不取决于将使用该卷的 Pod。
|
||||
然后，调度程序将 Pod 调度到创建卷后可使用该卷的节点上。
|
||||
|
||||
对于 [CSI 临时卷](/zh/docs/concepts/storage/volumes/#csi)，调度总是在不考虑存储容量的情况下进行。
|
||||
这是基于这样的假设：该卷类型仅由节点本地的特殊 CSI 驱动程序使用，并且不需要大量资源。
|
||||
|
||||
<!--
|
||||
## Rescheduling
|
||||
|
||||
When a node has been selected for a Pod with `WaitForFirstConsumer`
|
||||
volumes, that decision is still tentative. The next step is that the
|
||||
CSI storage driver gets asked to create the volume with a hint that the
|
||||
volume is supposed to be available on the selected node.
|
||||
|
||||
Because Kubernetes might have chosen a node based on out-dated
|
||||
capacity information, it is possible that the volume cannot really be
|
||||
created. The node selection is then reset and the Kubernetes scheduler
|
||||
tries again to find a node for the Pod.
|
||||
-->
|
||||
## 重新调度
|
||||
|
||||
当为带有 `WaitForFirstConsumer` 的卷的 Pod 来选择节点时，该决定仍然是暂定的。
|
||||
下一步是要求 CSI 存储驱动程序创建卷，并提示该卷在被选择的节点上可用。
|
||||
|
||||
因为 Kubernetes 可能会根据已经过时的存储容量信息来选择一个节点，因此可能无法真正创建卷。
|
||||
然后就会重置节点选择，Kubernetes 调度器会再次尝试为 Pod 查找节点。
|
||||
|
||||
<!--
|
||||
## Limitations
|
||||
|
||||
Storage capacity tracking increases the chance that scheduling works
|
||||
on the first try, but cannot guarantee this because the scheduler has
|
||||
to decide based on potentially out-dated information. Usually, the
|
||||
same retry mechanism as for scheduling without any storage capacity
|
||||
information handles scheduling failures.
|
||||
|
||||
One situation where scheduling can fail permanently is when a Pod uses
|
||||
multiple volumes: one volume might have been created already in a
|
||||
topology segment which then does not have enough capacity left for
|
||||
another volume. Manual intervention is necessary to recover from this,
|
||||
for example by increasing capacity or deleting the volume that was
|
||||
already created.
|
||||
-->
|
||||
## 限制
|
||||
|
||||
存储容量跟踪增加了调度器第一次尝试即成功的机会，但是并不能保证这一点，因为调度器必须根据可能过期的信息来进行决策。
|
||||
通常，与没有任何存储容量信息的调度相同的重试机制可以处理调度失败。
|
||||
|
||||
当 Pod 使用多个卷时，调度可能会永久失败：一个卷可能已经在拓扑段中创建，而该卷又没有足够的容量来创建另一个卷，
|
||||
要想从中恢复，必须要进行手动干预，比如通过增加存储容量或者删除已经创建的卷。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
- For more information on the design, see the
|
||||
[Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md).
|
||||
-->
|
||||
- 想要获得更多该设计的信息，查看
|
||||
[Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)。
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,146 @@
|
||||
---
|
||||
title: 特定于节点的卷数限制
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- ---
|
||||
reviewers:
|
||||
- jsafrane
|
||||
- saad-ali
|
||||
- thockin
|
||||
- msau42
|
||||
title: Node-specific Volume Limits
|
||||
content_type: concept
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page describes the maximum number of volumes that can be attached
|
||||
to a Node for various cloud providers.
|
||||
-->
|
||||
此页面描述了各个云供应商可关联至一个节点的最大卷数。
|
||||
|
||||
<!--
|
||||
Cloud providers like Google, Amazon, and Microsoft typically have a limit on
|
||||
how many volumes can be attached to a Node. It is important for Kubernetes to
|
||||
respect those limits. Otherwise, Pods scheduled on a Node could get stuck
|
||||
waiting for volumes to attach.
|
||||
-->
|
||||
谷歌、亚马逊和微软等云供应商通常对可以关联到节点的卷数量进行限制。
|
||||
Kubernetes 需要尊重这些限制。 否则，在节点上调度的 Pod 可能会卡住去等待卷的关联。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Kubernetes default limits
|
||||
|
||||
The Kubernetes scheduler has default limits on the number of volumes
|
||||
that can be attached to a Node:
|
||||
-->
|
||||
## Kubernetes 的默认限制
|
||||
|
||||
The Kubernetes 调度器对关联于一个节点的卷数有默认限制：
|
||||
<!--
|
||||
<table>
|
||||
<tr><th>Cloud service</th><th>Maximum volumes per Node</th></tr>
|
||||
<tr><td><a href="https://aws.amazon.com/ebs/">Amazon Elastic Block Store (EBS)</a></td><td>39</td></tr>
|
||||
<tr><td><a href="https://cloud.google.com/persistent-disk/">Google Persistent Disk</a></td><td>16</td></tr>
|
||||
<tr><td><a href="https://azure.microsoft.com/en-us/services/storage/main-disks/">Microsoft Azure Disk Storage</a></td><td>16</td></tr>
|
||||
</table>
|
||||
-->
|
||||
<table>
|
||||
<tr><th>云服务</th><th>每节点最大卷数</th></tr>
|
||||
<tr><td><a href="https://aws.amazon.com/ebs/">Amazon Elastic Block Store (EBS)</a></td><td>39</td></tr>
|
||||
<tr><td><a href="https://cloud.google.com/persistent-disk/">Google Persistent Disk</a></td><td>16</td></tr>
|
||||
<tr><td><a href="https://azure.microsoft.com/en-us/services/storage/main-disks/">Microsoft Azure Disk Storage</a></td><td>16</td></tr>
|
||||
</table>
|
||||
|
||||
<!--
|
||||
## Custom limits
|
||||
|
||||
You can change these limits by setting the value of the
|
||||
`KUBE_MAX_PD_VOLS` environment variable, and then starting the scheduler.
|
||||
CSI drivers might have a different procedure, see their documentation
|
||||
on how to customize their limits.
|
||||
|
||||
Use caution if you set a limit that is higher than the default limit. Consult
|
||||
the cloud provider's documentation to make sure that Nodes can actually support
|
||||
the limit you set.
|
||||
|
||||
The limit applies to the entire cluster, so it affects all Nodes.
|
||||
-->
|
||||
## 自定义限制
|
||||
|
||||
你可以通过设置 `KUBE_MAX_PD_VOLS` 环境变量的值来设置这些限制，然后再启动调度器。
|
||||
CSI 驱动程序可能具有不同的过程，关于如何自定义其限制请参阅相关文档。
|
||||
|
||||
如果设置的限制高于默认限制，请谨慎使用。请参阅云提供商的文档以确保节点可支持你设置的限制。
|
||||
|
||||
此限制应用于整个集群，所以它会影响所有节点。
|
||||
|
||||
<!--
|
||||
## Dynamic volume limits
|
||||
-->
|
||||
## 动态卷限制
|
||||
|
||||
{{< feature-state state="stable" for_k8s_version="v1.17" >}}
|
||||
|
||||
<!--
|
||||
Dynamic volume limits are supported for following volume types.
|
||||
|
||||
- Amazon EBS
|
||||
- Google Persistent Disk
|
||||
- Azure Disk
|
||||
- CSI
|
||||
-->
|
||||
以下卷类型支持动态卷限制。
|
||||
|
||||
- Amazon EBS
|
||||
- Google Persistent Disk
|
||||
- Azure Disk
|
||||
- CSI
|
||||
|
||||
<!--
|
||||
For volumes managed by in-tree volume plugins, Kubernetes automatically determines the Node
|
||||
type and enforces the appropriate maximum number of volumes for the node. For example:
|
||||
-->
|
||||
对于由内建插件管理的卷，Kubernetes 会自动确定节点类型并确保节点上可关联的卷数目合规。 例如：
|
||||
|
||||
<!--
|
||||
* On
|
||||
<a href="https://cloud.google.com/compute/">Google Compute Engine</a>,
|
||||
up to 127 volumes can be attached to a node, [depending on the node
|
||||
type](https://cloud.google.com/compute/docs/disks/#pdnumberlimits).
|
||||
|
||||
* For Amazon EBS disks on M5,C5,R5,T3 and Z1D instance types, Kubernetes allows only 25
|
||||
volumes to be attached to a Node. For other instance types on
|
||||
<a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>,
|
||||
Kubernetes allows 39 volumes to be attached to a Node.
|
||||
|
||||
* On Azure, up to 64 disks can be attached to a node, depending on the node type. For more details, refer to [Sizes for virtual machines in Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes).
|
||||
|
||||
* If a CSI storage driver advertises a maximum number of volumes for a Node (using `NodeGetInfo`), the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} honors that limit.
|
||||
Refer to the [CSI specifications](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) for details.
|
||||
|
||||
* For volumes managed by in-tree plugins that have been migrated to a CSI driver, the maximum number of volumes will be the one reported by the CSI driver.
|
||||
-->
|
||||
* 在
|
||||
<a href="https://cloud.google.com/compute/">Google Compute Engine</a>环境中,
|
||||
[根据节点类型](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)最多可以将127个卷关联到节点。
|
||||
|
||||
* 对于 M5、C5、R5、T3 和 Z1D 类型实例的 Amazon EBS 磁盘，Kubernetes 仅允许 25 个卷关联到节点。
|
||||
对于 ec2 上的其他实例类型
|
||||
<a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>,
|
||||
Kubernetes 允许 39 个卷关联至节点。
|
||||
|
||||
* 在 Azure 环境中, 根据节点类型，最多 64 个磁盘可以关联至一个节点。
|
||||
更多详细信息，请参阅[Azure 虚拟机的数量大小](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes)。
|
||||
|
||||
* 如果 CSI 存储驱动程序（使用 `NodeGetInfo` ）为节点通告卷数上限，则 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} 将遵守该限制值。
|
||||
参考 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) 获取更多详细信息。
|
||||
|
||||
* 对于由已迁移到 CSI 驱动程序的树内插件管理的卷，最大卷数将是 CSI 驱动程序报告的卷数。
|
||||
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: 卷健康监测
|
||||
content_type: concept
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- jsafrane
|
||||
- saad-ali
|
||||
- msau42
|
||||
- xing-yang
|
||||
title: Volume Health Monitoring
|
||||
content_type: concept
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
|
||||
<!--
|
||||
{{< glossary_tooltip text="CSI" term_id="csi" >}} volume health monitoring allows CSI Drivers to detect abnormal volume conditions from the underlying storage systems and report them as events on {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}} or {{< glossary_tooltip text="Pods" term_id="pod" >}}.
|
||||
-->
|
||||
{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷健康监测支持 CSI 驱动从底层的存储系统着手，
|
||||
探测异常的卷状态，并以事件的形式上报到 {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}}
|
||||
或 {{< glossary_tooltip text="Pods" term_id="pod" >}}.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Volume health monitoring
|
||||
-->
|
||||
## 卷健康监测 {#volume-health-monitoring}
|
||||
|
||||
<!--
|
||||
Kubernetes _volume health monitoring_ is part of how Kubernetes implements the Container Storage Interface (CSI). Volume health monitoring feature is implemented in two components: an External Health Monitor controller, and the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}.
|
||||
|
||||
If a CSI Driver supports Volume Health Monitoring feature from the controller side, an event will be reported on the related {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} (PVC) when an abnormal volume condition is detected on a CSI volume.
|
||||
-->
|
||||
Kubernetes _卷健康监测_ 是 Kubernetes 容器存储接口（CSI）实现的一部分。
|
||||
卷健康监测特性由两个组件实现：外部健康监测控制器和 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}。
|
||||
|
||||
如果 CSI 驱动器通过控制器的方式支持卷健康监测特性，那么只要在 CSI 卷上监测到异常卷状态，就会在
|
||||
{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} (PVC)
|
||||
中上报一个事件。
|
||||
|
||||
<!--
|
||||
The External Health Monitor {{< glossary_tooltip text="controller" term_id="controller" >}} also watches for node failure events. You can enable node failure monitoring by setting the `enable-node-watcher` flag to true. When the external health monitor detects a node failure event, the controller reports an Event will be reported on the PVC to indicate that pods using this PVC are on a failed node.
|
||||
|
||||
If a CSI Driver supports Volume Health Monitoring feature from the node side, an Event will be reported on every Pod using the PVC when an abnormal volume condition is detected on a CSI volume. In addition, Volume Health information is exposed as Kubelet VolumeStats metrics. A new metric kubelet_volume_stats_health_status_abnormal is added. This metric includes two labels: `namespace` and `persistentvolumeclaim`. The count is either 1 or 0. 1 indicates the volume is unhealthy, 0 indicates volume is healthy. For more information, please check [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor#kubelet-metrics-changes).
|
||||
-->
|
||||
外部健康监测{{< glossary_tooltip text="控制器" term_id="controller" >}}也会监测节点失效事件。
|
||||
如果要启动节点失效监测功能，你可以设置标志 `enable-node-watcher` 为 `true`。
|
||||
当外部健康监测器检测到节点失效事件，控制器会报送一个事件，该事件会在 PVC 上继续上报，
|
||||
以表明使用此 PVC 的 Pod 正位于一个失效的节点上。
|
||||
|
||||
如果 CSI 驱动程序支持节点测的卷健康检测，那当在 CSI 卷上检测到异常卷时，
|
||||
会在使用该 PVC 的每个Pod 上触发一个事件。
|
||||
此外，卷运行状况信息作为 Kubelet VolumeStats 指标公开。
|
||||
添加了一个新的指标 kubelet_volume_stats_health_status_abnormal。
|
||||
该指标包括两个标签：`namespace` 和 `persistentvolumeclaim`。
|
||||
计数为 1 或 0。1 表示卷不正常，0 表示卷正常。更多信息请访问[KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor#kubelet-metrics-changes)。
|
||||
|
||||
<!--
|
||||
You need to enable the `CSIVolumeHealth` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to use this feature from the node side.
|
||||
-->
|
||||
{{< note >}}
|
||||
你需要启用 `CSIVolumeHealth`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
|
||||
才能在节点上使用此特性。
|
||||
{{< /note >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
See the [CSI driver documentation](https://kubernetes-csi.github.io/docs/drivers.html) to find out which CSI drivers have implemented this feature.
|
||||
-->
|
||||
参阅 [CSI 驱动程序文档](https://kubernetes-csi.github.io/docs/drivers.html)，
|
||||
可以找出有哪些 CSI 驱动程序实现了此特性。
|
||||
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
title: CSI 卷克隆
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- jsafrane
|
||||
- saad-ali
|
||||
- thockin
|
||||
- msau42
|
||||
title: CSI Volume Cloning
|
||||
content_type: concept
|
||||
weight: 60
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested.
|
||||
-->
|
||||
本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉
|
||||
[卷](/zh/docs/concepts/storage/volumes)。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Introduction
|
||||
|
||||
The {{< glossary_tooltip text="CSI" term_id="csi" >}} Volume Cloning feature adds support for specifying existing {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}s in the `dataSource` field to indicate a user would like to clone a {{< glossary_tooltip term_id="volume" >}}.
|
||||
-->
|
||||
## 介绍
|
||||
|
||||
{{< glossary_tooltip text="CSI" term_id="csi" >}} 卷克隆功能增加了通过在
|
||||
`dataSource` 字段中指定存在的
|
||||
{{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}，
|
||||
来表示用户想要克隆的 {{< glossary_tooltip term_id="volume" >}}。
|
||||
|
||||
<!--
|
||||
A Clone is defined as a duplicate of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The only difference is that upon provisioning, rather than creating a "new" empty Volume, the back end device creates an exact duplicate of the specified Volume.
|
||||
-->
|
||||
克隆（Clone），意思是为已有的 Kubernetes 卷创建副本，它可以像任何其它标准卷一样被使用。
|
||||
唯一的区别就是配置后，后端设备将创建指定完全相同的副本，而不是创建一个“新的”空卷。
|
||||
|
||||
<!--
|
||||
The implementation of cloning, from the perspective of the Kubernetes API, adds the ability to specify an existing PVC as a dataSource during new PVC creation. The source PVC must be bound and available (not in use).
|
||||
|
||||
Users need to be aware of the following when using this feature:
|
||||
-->
|
||||
从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时，
|
||||
增加了指定一个现有 PVC 作为数据源的能力。源 PVC 必须是 bound
|
||||
状态且可用的（不在使用中）。
|
||||
|
||||
用户在使用该功能时，需要注意以下事项：
|
||||
|
||||
<!--
|
||||
* Cloning support (`VolumePVCDataSource`) is only available for CSI drivers.
|
||||
* Cloning support is only available for dynamic provisioners.
|
||||
* CSI drivers may or may not have implemented the volume cloning functionality.
|
||||
* You can only clone a PVC when it exists in the same namespace as the destination PVC (source and destination must be in the same namespace).
|
||||
* Cloning is only supported within the same Storage Class.
|
||||
- Destination volume must be the same storage class as the source
|
||||
- Default storage class can be used and storageClassName omitted in the spec
|
||||
* Cloning can only be performed between two volumes that use the same VolumeMode setting (if you request a block mode volume, the source MUST also be block mode)
|
||||
-->
|
||||
* 克隆支持（`VolumePVCDataSource`）仅适用于 CSI 驱动。
|
||||
* 克隆支持仅适用于 动态供应器。
|
||||
* CSI 驱动可能实现，也可能未实现卷克隆功能。
|
||||
* 仅当 PVC 与目标 PVC 存在于同一命名空间（源和目标 PVC 必须在相同的命名空间）时，才可以克隆 PVC。
|
||||
* 仅在同一存储类中支持克隆。
|
||||
- 目标卷必须和源卷具有相同的存储类
|
||||
- 可以使用默认的存储类并且 storageClassName 字段在规格中忽略了
|
||||
* 克隆只能在两个使用相同 VolumeMode 设置的卷中进行
|
||||
（如果请求克隆一个块存储模式的卷，源卷必须也是块存储模式）。
|
||||
|
||||
<!--
|
||||
## Provisioning
|
||||
|
||||
Clones are provisioned like any other PVC with the exception of adding a dataSource that references an existing PVC in the same namespace.
|
||||
-->
|
||||
## 制备
|
||||
|
||||
克隆卷与其他任何 PVC 一样配置，除了需要增加 dataSource 来引用同一命名空间中现有的 PVC。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: clone-of-pvc-1
|
||||
namespace: myns
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
storageClassName: cloning
|
||||
resources:
|
||||
requests:
|
||||
storage: 5Gi
|
||||
dataSource:
|
||||
kind: PersistentVolumeClaim
|
||||
name: pvc-1
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
You must specify a capacity value for `spec.resources.requests.storage`,
|
||||
and the value you specify must be the same or larger than the capacity of the source volume.
|
||||
-->
|
||||
你必须为 `spec.resources.requests.storage` 指定一个值，并且你指定的值必须大于或等于源卷的值。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
The result is a new PVC with the name `clone-of-pvc-1` that has the exact same content as the specified source `pvc-1`.
|
||||
-->
|
||||
结果是一个名称为 `clone-of-pvc-1` 的新 PVC 与指定的源 `pvc-1` 拥有相同的内容。
|
||||
|
||||
<!--
|
||||
## Usage
|
||||
|
||||
Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone.
|
||||
-->
|
||||
## 使用
|
||||
|
||||
一旦新的 PVC 可用，被克隆的 PVC 像其他 PVC 一样被使用。
|
||||
可以预期的是，新创建的 PVC 是一个独立的对象。
|
||||
可以独立使用、克隆、快照或删除它，而不需要考虑它的原始数据源 PVC。
|
||||
这也意味着，源没有以任何方式链接到新创建的 PVC，它也可以被修改或删除，而不会影响到新创建的克隆。
|
||||
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
title: 卷快照类
|
||||
content_type: concept
|
||||
weight: 41 # 置于卷快照章节后
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This document describes the concept of VolumeSnapshotClass in Kubernetes. Familiarity
|
||||
with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
|
||||
[storage classes](/docs/concepts/storage/storage-classes) is suggested.
|
||||
-->
|
||||
本文档描述了 Kubernetes 中 VolumeSnapshotClass 的概念。建议熟悉
|
||||
[卷快照（Volume Snapshots）](/zh/docs/concepts/storage/volume-snapshots/)和
|
||||
[存储类（Storage Class）](/zh/docs/concepts/storage/storage-classes)。
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Introduction
|
||||
|
||||
Just like StorageClass provides a way for administrators to describe the "classes"
|
||||
of storage they offer when provisioning a volume, VolumeSnapshotClass provides a
|
||||
way to describe the "classes" of storage when provisioning a volume snapshot.
|
||||
-->
|
||||
## 介绍 {#introduction}
|
||||
|
||||
就像 StorageClass 为管理员提供了一种在配置卷时描述存储“类”的方法，
|
||||
VolumeSnapshotClass 提供了一种在配置卷快照时描述存储“类”的方法。
|
||||
|
||||
<!--
|
||||
## The VolumeSnapshotClass Resource
|
||||
|
||||
Each VolumeSnapshotClass contains the fields `driver`, `deletionPolicy`, and `parameters`,
|
||||
which are used when a VolumeSnapshot belonging to the class needs to be
|
||||
dynamically provisioned.
|
||||
|
||||
The name of a VolumeSnapshotClass 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 VolumeSnapshotClass objects, and the objects cannot
|
||||
be updated once they are created.
|
||||
|
||||
{{< note >}}
|
||||
Installation of the CRDs is the responsibility of the Kubernetes distribution. Without the required CRDs present, the creation of a VolumeSnapshotClass fails.
|
||||
{{< /note >}}
|
||||
|
||||
-->
|
||||
## VolumeSnapshotClass 资源 {#the-volumesnapshortclass-resource}
|
||||
|
||||
每个 VolumeSnapshotClass 都包含 `driver`、`deletionPolicy` 和 `parameters` 字段，
|
||||
在需要动态配置属于该类的 VolumeSnapshot 时使用。
|
||||
|
||||
VolumeSnapshotClass 对象的名称很重要，是用户可以请求特定类的方式。
|
||||
管理员在首次创建 VolumeSnapshotClass 对象时设置类的名称和其他参数，
|
||||
对象一旦创建就无法更新。
|
||||
|
||||
{{< note >}}
|
||||
CRD 的安装是 Kubernetes 发行版的责任。 如果不存在所需的 CRD，则 VolumeSnapshotClass 的创建将失败。
|
||||
{{< /note >}}
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshotClass
|
||||
metadata:
|
||||
name: csi-hostpath-snapclass
|
||||
driver: hostpath.csi.k8s.io
|
||||
deletionPolicy: Delete
|
||||
parameters:
|
||||
```
|
||||
|
||||
<!--
|
||||
Administrators can specify a default VolumeSnapshotClass for VolumeSnapshots
|
||||
that don't request any particular class to bind to by adding the
|
||||
`snapshot.storage.kubernetes.io/is-default-class: "true"` annotation:
|
||||
-->
|
||||
管理员可以为未请求任何特定类绑定的 VolumeSnapshots 指定默认的 VolumeSnapshotClass，
|
||||
方法是设置注解 `snapshot.storage.kubernetes.io/is-default-class: "true"`：
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshotClass
|
||||
metadata:
|
||||
name: csi-hostpath-snapclass
|
||||
annotations:
|
||||
snapshot.storage.kubernetes.io/is-default-class: "true"
|
||||
driver: hostpath.csi.k8s.io
|
||||
deletionPolicy: Delete
|
||||
parameters:
|
||||
```
|
||||
|
||||
<!--
|
||||
### Driver
|
||||
|
||||
Volume snapshot classes have a driver that determines what CSI volume plugin is
|
||||
used for provisioning VolumeSnapshots. This field must be specified.
|
||||
-->
|
||||
### 驱动程序 {#driver}
|
||||
|
||||
卷快照类有一个驱动程序，用于确定配置 VolumeSnapshot 的 CSI 卷插件。
|
||||
此字段必须指定。
|
||||
|
||||
<!--
|
||||
### 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.
|
||||
|
||||
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 对象。
|
||||
卷快照类的这个策略可以是 `Retain` 或者 `Delete`。这个策略字段必须指定。
|
||||
|
||||
如果删除策略是 `Delete`，那么底层的存储快照会和 VolumeSnapshotContent 对象
|
||||
一起删除。如果删除策略是 `Retain`，那么底层快照和 VolumeSnapshotContent
|
||||
对象都会被保留。
|
||||
|
||||
<!--
|
||||
## Parameters
|
||||
|
||||
Volume snapshot classes have parameters that describe volume snapshots belonging to
|
||||
the volume snapshot class. Different parameters may be accepted depending on the
|
||||
`driver`.
|
||||
-->
|
||||
## 参数 {#parameters}
|
||||
|
||||
卷快照类具有描述属于该卷快照类的卷快照的参数，可根据 `driver` 接受不同的参数。
|
||||
@@ -0,0 +1,356 @@
|
||||
---
|
||||
title: 卷快照
|
||||
content_type: concept
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Volume Snapshots
|
||||
content_type: concept
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="1.17" state="beta" >}}
|
||||
|
||||
<!--
|
||||
In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
|
||||
-->
|
||||
在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
|
||||
的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Introduction
|
||||
-->
|
||||
|
||||
## 介绍 {#introduction}
|
||||
|
||||
<!--
|
||||
Similar to how API resources `PersistentVolume` and `PersistentVolumeClaim` are used to provision volumes for users and administrators, `VolumeSnapshotContent` and `VolumeSnapshot` API resources are provided to create volume snapshots for users and administrators.
|
||||
-->
|
||||
与 `PersistentVolume` 和 `PersistentVolumeClaim` 两个 API 资源用于给用户和管理员提供卷类似，`VolumeSnapshotContent` 和 `VolumeSnapshot` 两个 API 资源用于给用户和管理员创建卷快照。
|
||||
|
||||
<!--
|
||||
A `VolumeSnapshotContent` is a snapshot taken from a volume in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a PersistentVolume is a cluster resource.
|
||||
-->
|
||||
`VolumeSnapshotContent` 是一种快照，从管理员已提供的集群中的卷获取。就像持久卷是集群的资源一样，它也是集群中的资源。
|
||||
|
||||
<!--
|
||||
A `VolumeSnapshot` is a request for snapshot of a volume by a user. It is similar to a PersistentVolumeClaim.
|
||||
-->
|
||||
`VolumeSnapshot` 是用户对于卷的快照的请求。它类似于持久卷声明。
|
||||
|
||||
<!--
|
||||
`VolumeSnapshotClass` allows you to specify different attributes belonging to a `VolumeSnapshot`. These attributes may differ among snapshots taken from the same volume on the storage system and therefore cannot be expressed by using the same `StorageClass` of a `PersistentVolumeClaim`.
|
||||
-->
|
||||
`VolumeSnapshotClass` 允许指定属于 `VolumeSnapshot` 的不同属性。在从存储系统的相同卷上获取的快照之间，这些属性可能有所不同，因此不能通过使用与 `PersistentVolumeClaim` 相同的 `StorageClass` 来表示。
|
||||
|
||||
<!--
|
||||
Volume snapshots provide Kubernetes users with a standardized way to copy a volume's contents at a particular point in time without creating an entirely new volume. This functionality enables, for example, database administrators to backup databases before performing edit or delete modifications.
|
||||
-->
|
||||
卷快照能力为 Kubernetes 用户提供了一种标准的方式来在指定时间点
|
||||
复制卷的内容，并且不需要创建全新的卷。例如，这一功能使得数据库管理员
|
||||
能够在执行编辑或删除之类的修改之前对数据库执行备份。
|
||||
|
||||
<!--
|
||||
Users need to be aware of the following when using this feature:
|
||||
-->
|
||||
当使用该功能时，用户需要注意以下几点：
|
||||
|
||||
<!--
|
||||
* API Objects `VolumeSnapshot`, `VolumeSnapshotContent`, and `VolumeSnapshotClass` are {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, not part of the core API.
|
||||
* `VolumeSnapshot` support is only available for CSI drivers.
|
||||
* As part of the deployment process of `VolumeSnapshot`, the Kubernetes team provides a snapshot controller to be deployed into the control plane, and a sidecar helper container called csi-snapshotter to be deployed together with the CSI driver. The snapshot controller watches `VolumeSnapshot` and `VolumeSnapshotContent` objects and is responsible for the creation and deletion of `VolumeSnapshotContent` object. The sidecar csi-snapshotter watches `VolumeSnapshotContent` objects and triggers `CreateSnapshot` and `DeleteSnapshot` operations against a CSI endpoint.
|
||||
* There is also a validating webhook server which provides tightened validation on snapshot objects. This should be installed by the Kubernetes distros along with the snapshot controller and CRDs, not CSI drivers. It should be installed in all Kubernetes clusters that has the snapshot feature enabled.
|
||||
* CSI drivers may or may not have implemented the volume snapshot functionality. The CSI drivers that have provided support for volume snapshot will likely use the csi-snapshotter. See [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) for details.
|
||||
* The CRDs and snapshot controller installations are the responsibility of the Kubernetes distribution.
|
||||
-->
|
||||
* API 对象 `VolumeSnapshot`，`VolumeSnapshotContent` 和 `VolumeSnapshotClass`
|
||||
是 {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}，
|
||||
不属于核心 API。
|
||||
* `VolumeSnapshot` 支持仅可用于 CSI 驱动。
|
||||
* 作为 `VolumeSnapshot` 部署过程的一部分，Kubernetes 团队提供了一个部署于控制平面的快照控制器，
|
||||
并且提供了一个叫做 `csi-snapshotter` 的边车（Sidecar）辅助容器，和 CSI 驱动程序一起部署。
|
||||
快照控制器监视 `VolumeSnapshot` 和 `VolumeSnapshotContent` 对象，
|
||||
并且负责创建和删除 `VolumeSnapshotContent` 对象。
|
||||
边车 csi-snapshotter 监视 `VolumeSnapshotContent` 对象，
|
||||
并且触发针对 CSI 端点的 `CreateSnapshot` 和 `DeleteSnapshot` 的操作。
|
||||
* 还有一个验证性质的 Webhook 服务器，可以对快照对象进行更严格的验证。
|
||||
Kubernetes 发行版应将其与快照控制器和 CRD（而非 CSI 驱动程序）一起安装。
|
||||
此服务器应该安装在所有启用了快照功能的 Kubernetes 集群中。
|
||||
* CSI 驱动可能实现，也可能没有实现卷快照功能。CSI 驱动可能会使用 csi-snapshotter
|
||||
来提供对卷快照的支持。详见 [CSI 驱动程序文档](https://kubernetes-csi.github.io/docs/)
|
||||
* Kubernetes 负责 CRDs 和快照控制器的安装。
|
||||
|
||||
<!--
|
||||
## Lifecycle of a volume snapshot and volume snapshot content
|
||||
|
||||
`VolumeSnapshotContents` are resources in the cluster. `VolumeSnapshots` are requests for those resources. The interaction between `VolumeSnapshotContents` and `VolumeSnapshots` follow this lifecycle:
|
||||
-->
|
||||
## 卷快照和卷快照内容的生命周期 {#lifecycle-of-a-volume-snapshot-and-volume-snapshot-content}
|
||||
|
||||
`VolumeSnapshotContents` 是集群中的资源。`VolumeSnapshots` 是对于这些资源的请求。`VolumeSnapshotContents` 和 `VolumeSnapshots` 之间的交互遵循以下生命周期：
|
||||
|
||||
<!--
|
||||
### Provisioning Volume Snapshot
|
||||
|
||||
There are two ways snapshots may be provisioned: pre-provisioned or dynamically provisioned.
|
||||
-->
|
||||
### 供应卷快照 {#provisioning-volume-snapshot}
|
||||
|
||||
快照可以通过两种方式进行配置：预配置或动态配置。
|
||||
|
||||
<!--
|
||||
#### Pre-provisioned {#static}
|
||||
A cluster administrator creates a number of `VolumeSnapshotContents`. They carry the details of the real volume snapshot on the storage system which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
|
||||
-->
|
||||
#### 预配置 {#static}
|
||||
集群管理员创建多个 `VolumeSnapshotContents`。它们带有存储系统上实际卷快照的详细信息，可以供集群用户使用。它们存在于 Kubernetes API 中，并且能够被使用。
|
||||
|
||||
<!--
|
||||
#### Dynamic
|
||||
|
||||
Instead of using a pre-existing snapshot, you can request that a snapshot to be dynamically taken from a PersistentVolumeClaim. The [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) specifies storage provider-specific parameters to use when taking a snapshot.
|
||||
-->
|
||||
#### 动态的 {#dynamic}
|
||||
|
||||
可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。
|
||||
在获取快照时，[卷快照类](/zh/docs/concepts/storage/volume-snapshot-classes/)
|
||||
指定要用的特定于存储提供程序的参数。
|
||||
|
||||
<!--
|
||||
### Binding
|
||||
|
||||
The snapshot controller handles the binding of a `VolumeSnapshot` object with an appropriate `VolumeSnapshotContent` object, in both pre-provisioned and dynamically provisioned scenarios. The binding is a one-to-one mapping.
|
||||
-->
|
||||
### 绑定 {#binding}
|
||||
|
||||
在预配置和动态配置场景下，快照控制器处理绑定 `VolumeSnapshot` 对象和其合适的 `VolumeSnapshotContent` 对象。绑定关系是一对一的。
|
||||
|
||||
<!--
|
||||
In the case of pre-provisioned binding, the VolumeSnapshot will remain unbound until the requested VolumeSnapshotContent object is created.
|
||||
-->
|
||||
在预配置快照绑定场景下，`VolumeSnapshotContent` 对象创建之后，才会和 `VolumeSnapshot` 进行绑定。
|
||||
|
||||
<!--
|
||||
### Persistent Volume Claim as Snapshot Source Protection
|
||||
|
||||
The purpose of this protection is to ensure that in-use
|
||||
{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
|
||||
API objects are not removed from the system while a snapshot is being taken from it (as this may result in data loss).
|
||||
|
||||
-->
|
||||
### 快照源的持久性卷声明保护
|
||||
|
||||
这种保护的目的是确保在从系统中获取快照时，不会将正在使用的
|
||||
{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}}
|
||||
API 对象从系统中删除（因为这可能会导致数据丢失）。
|
||||
|
||||
<!--
|
||||
|
||||
While a snapshot is being taken of a PersistentVolumeClaim, that PersistentVolumeClaim is in-use. If you delete a PersistentVolumeClaim API object in active use as a snapshot source, the PersistentVolumeClaim object is not removed immediately. Instead, removal of the PersistentVolumeClaim object is postponed until the snapshot is readyToUse or aborted.
|
||||
-->
|
||||
如果一个 PVC 正在被快照用来作为源进行快照创建，则该 PVC 是使用中的。如果用户删除正作为快照源的 PVC API 对象，则 PVC 对象不会立即被删除掉。相反，PVC 对象的删除将推迟到任何快照不在主动使用它为止。当快照的 `Status` 中的 `ReadyToUse`值为 `true` 时，PVC 将不再用作快照源。
|
||||
|
||||
当从 `PersistentVolumeClaim` 中生成快照时，`PersistentVolumeClaim` 就在被使用了。如果删除一个作为快照源的 `PersistentVolumeClaim` 对象，这个 `PersistentVolumeClaim` 对象不会立即被删除的。相反，删除 `PersistentVolumeClaim` 对象的动作会被放弃，或者推迟到快照的 Status 为 ReadyToUse时再执行。
|
||||
|
||||
<!--
|
||||
### Delete
|
||||
|
||||
Deletion is triggered by deleting the `VolumeSnapshot` object, and the `DeletionPolicy` will be followed. 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.
|
||||
-->
|
||||
### 删除 {#delete}
|
||||
|
||||
删除 `VolumeSnapshot` 对象触发删除 `VolumeSnapshotContent` 操作，并且 `DeletionPolicy` 会紧跟着执行。如果 `DeletionPolicy` 是 `Delete`，那么底层存储快照会和 `VolumeSnapshotContent` 一起被删除。如果 `DeletionPolicy` 是 `Retain`，那么底层快照和 `VolumeSnapshotContent` 都会被保留。
|
||||
|
||||
<!--
|
||||
## VolumeSnapshots
|
||||
|
||||
Each VolumeSnapshot contains a spec and a status.
|
||||
-->
|
||||
## 卷快照 {#volume-snapshots}
|
||||
|
||||
每个 `VolumeSnapshot` 包含一个 spec 和一个状态。
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshot
|
||||
metadata:
|
||||
name: new-snapshot-test
|
||||
spec:
|
||||
volumeSnapshotClassName: csi-hostpath-snapclass
|
||||
source:
|
||||
persistentVolumeClaimName: pvc-test
|
||||
```
|
||||
|
||||
<!--
|
||||
`persistentVolumeClaimName` is the name of the PersistentVolumeClaim data source for the snapshot. This field is required for dynamically provisioning a snapshot.
|
||||
|
||||
A volume snapshot can request a particular class by specifying the name of a
|
||||
[VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/)
|
||||
using the attribute `volumeSnapshotClassName`. If nothing is set, then the default class is used if available.
|
||||
-->
|
||||
`persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。
|
||||
这个字段是动态配置快照中的必填字段。
|
||||
|
||||
卷快照可以通过指定 [VolumeSnapshotClass](/zh/docs/concepts/storage/volume-snapshot-classes/)
|
||||
使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。
|
||||
|
||||
<!--
|
||||
For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
|
||||
-->
|
||||
如下面例子所示，对于预配置的快照，需要给快照指定 `volumeSnapshotContentName` 来作为源。
|
||||
对于预配置的快照 `source` 中的`volumeSnapshotContentName` 字段是必填的。
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshot
|
||||
metadata:
|
||||
name: test-snapshot
|
||||
spec:
|
||||
source:
|
||||
volumeSnapshotContentName: test-content
|
||||
```
|
||||
|
||||
<!--
|
||||
## Volume Snapshot Contents
|
||||
|
||||
Each VolumeSnapshot contains a spec and a status, which is the specification and status of the volume snapshot.
|
||||
Each VolumeSnapshotContent contains a spec and status. In dynamic provisioning, the snapshot common controller creates `VolumeSnapshotContent` objects. Here is an example:
|
||||
-->
|
||||
每个 VolumeSnapshotContent 对象包含 spec 和 status。在动态配置时，快照通用控制器创建 `VolumeSnapshotContent` 对象。下面是例子：
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshotContent
|
||||
metadata:
|
||||
name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455
|
||||
spec:
|
||||
deletionPolicy: Delete
|
||||
driver: hostpath.csi.k8s.io
|
||||
source:
|
||||
volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002
|
||||
sourceVolumeMode: Filesystem
|
||||
volumeSnapshotClassName: csi-hostpath-snapclass
|
||||
volumeSnapshotRef:
|
||||
name: new-snapshot-test
|
||||
namespace: default
|
||||
uid: 72d9a349-aacd-42d2-a240-d775650d2455
|
||||
```
|
||||
|
||||
<!--
|
||||
`volumeHandle` is the unique identifier of the volume created on the storage backend and returned by the CSI driver during the volume creation. This field is required for dynamically provisioning a snapshot. It specifies the volume source of the snapshot.
|
||||
|
||||
For pre-provisioned snapshots, you (as cluster administrator) are responsible for creating the `VolumeSnapshotContent` object as follows.
|
||||
-->
|
||||
`volumeHandle` 是存储后端创建卷的唯一标识符，在卷创建期间由 CSI 驱动程序返回。动态设置快照需要此字段。它指出了快照的卷源。
|
||||
|
||||
对于预配置快照，你（作为集群管理员）要按如下命令来创建 `VolumeSnapshotContent` 对象。
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshotContent
|
||||
metadata:
|
||||
name: new-snapshot-content-test
|
||||
spec:
|
||||
deletionPolicy: Delete
|
||||
driver: hostpath.csi.k8s.io
|
||||
source:
|
||||
snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
|
||||
sourceVolumeMode: Filesystem
|
||||
volumeSnapshotRef:
|
||||
name: new-snapshot-test
|
||||
namespace: default
|
||||
```
|
||||
<!--
|
||||
`snapshotHandle` is the unique identifier of the volume snapshot created on the storage backend. This field is required for the pre-provisioned snapshots. It specifies the CSI snapshot id on the storage system that this `VolumeSnapshotContent` represents.
|
||||
-->
|
||||
`snapshotHandle` 是存储后端创建卷的唯一标识符。对于预设置快照，这个字段是必须的。它指定此 `VolumeSnapshotContent` 表示的存储系统上的 CSI 快照 id。
|
||||
|
||||
<!--
|
||||
`sourceVolumeMode` is the mode of the volume whose snapshot is taken. The value
|
||||
of the `sourceVolumeMode` field can be either `Filesystem` or `Block`. If the
|
||||
source volume mode is not specified, Kubernetes treats the snapshot as if the
|
||||
source volume's mode is unknown.
|
||||
-->
|
||||
`sourceVolumeMode` 是创建快照的卷的模式。`sourceVolumeMode` 字段的值可以是
|
||||
`Filesystem` 或 `Block`。如果没有指定源卷模式，Kubernetes 会将快照视为未知的源卷模式。
|
||||
|
||||
<!--
|
||||
## Converting the volume mode of a Snapshot {#convert-volume-mode}
|
||||
|
||||
If the `VolumeSnapshots` API installed on your cluster supports the `sourceVolumeMode`
|
||||
field, then the API has the capability to prevent unauthorized users from converting
|
||||
the mode of a volume.
|
||||
|
||||
To check if your cluster has capability for this feature, run the following command:
|
||||
-->
|
||||
## 转换快照的卷模式 {#convert-volume-mode}
|
||||
|
||||
如果在你的集群上安装的 `VolumeSnapshots` API 支持 `sourceVolumeMode`
|
||||
字段，则该 API 可以防止未经授权的用户转换卷的模式。
|
||||
|
||||
要检查你的集群是否具有此特性的能力，可以运行如下命令：
|
||||
|
||||
```yaml
|
||||
$ kubectl get crd volumesnapshotcontent -o yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
If you want to allow users to create a `PersistentVolumeClaim` from an existing
|
||||
`VolumeSnapshot`, but with a different volume mode than the source, the annotation
|
||||
`snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"`needs to be added to
|
||||
the `VolumeSnapshotContent` that corresponds to the `VolumeSnapshot`.
|
||||
-->
|
||||
如果你希望允许用户从现有的 `VolumeSnapshot` 创建 `PersistentVolumeClaim`，
|
||||
但是使用与源卷不同的卷模式，则需要添加注解
|
||||
`snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"`
|
||||
到对应 `VolumeSnapshot` 的 `VolumeSnapshotContent` 中。
|
||||
<!--
|
||||
For pre-provisioned snapshots, `Spec.SourceVolumeMode` needs to be populated
|
||||
by the cluster administrator.
|
||||
|
||||
An example `VolumeSnapshotContent` resource with this feature enabled would look like:
|
||||
-->
|
||||
对于预配置的快照，`Spec.SourceVolumeMode` 需要由集群管理员填充。
|
||||
|
||||
启用此特性的 `VolumeSnapshotContent` 资源示例如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshotContent
|
||||
metadata:
|
||||
name: new-snapshot-content-test
|
||||
annotations:
|
||||
- snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"
|
||||
spec:
|
||||
deletionPolicy: Delete
|
||||
driver: hostpath.csi.k8s.io
|
||||
source:
|
||||
snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
|
||||
sourceVolumeMode: Filesystem
|
||||
volumeSnapshotRef:
|
||||
name: new-snapshot-test
|
||||
namespace: default
|
||||
```
|
||||
|
||||
<!--
|
||||
## Provisioning Volumes from Snapshots
|
||||
-->
|
||||
## 从快照供应卷
|
||||
|
||||
<!--
|
||||
You can provision a new volume, pre-populated with data from a snapshot, by using
|
||||
the *dataSource* field in the `PersistentVolumeClaim` object.
|
||||
-->
|
||||
你可以配置一个新卷，该卷预填充了快照中的数据，在 `持久卷声明` 对象中使用 *dataSource* 字段。
|
||||
|
||||
<!--
|
||||
For more details, see
|
||||
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
|
||||
-->
|
||||
更多详细信息，请参阅
|
||||
[卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,132 @@
|
||||
---
|
||||
title: Windows 存储
|
||||
content_type: concept
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- jingxu97
|
||||
- mauriciopoppe
|
||||
- jayunit100
|
||||
- jsturtevant
|
||||
- marosset
|
||||
- aravindhp
|
||||
title: Windows Storage
|
||||
content_type: concept
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
This page provides an storage overview specific to the Windows operating system.
|
||||
-->
|
||||
此页面提供特定于 Windows 操作系统的存储概述。
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Persistent storage {#storage}
|
||||
|
||||
Windows has a layered filesystem driver to mount container layers and create a copy
|
||||
filesystem based on NTFS. All file paths in the container are resolved only within
|
||||
the context of that container.
|
||||
-->
|
||||
## 持久存储 {#storage}
|
||||
Windows 有一个分层文件系统驱动程序用来挂载容器层和创建基于 NTFS 的文件系统拷贝。
|
||||
容器中的所有文件路径仅在该容器的上下文中解析。
|
||||
|
||||
<!--
|
||||
* With Docker, volume mounts can only target a directory in the container, and not
|
||||
an individual file. This limitation does not apply to containerd.
|
||||
* Volume mounts cannot project files or directories back to the host filesystem.
|
||||
* Read-only filesystems are not supported because write access is always required
|
||||
for the Windows registry and SAM database. However, read-only volumes are supported.
|
||||
* Volume user-masks and permissions are not available. Because the SAM is not shared
|
||||
between the host & container, there's no mapping between them. All permissions are
|
||||
resolved within the context of the container.
|
||||
-->
|
||||
* 使用 Docker 时，卷挂载只能是容器中的目录，而不能是单个文件。此限制不适用于 containerd。
|
||||
* 卷挂载不能将文件或目录映射回宿主文件系统。
|
||||
* 不支持只读文件系统，因为 Windows 注册表和 SAM 数据库始终需要写访问权限。不过，Windows 支持只读的卷。
|
||||
* 不支持卷的用户掩码和访问许可，因为宿主与容器之间并不共享 SAM，二者之间不存在映射关系。
|
||||
所有访问许可都是在容器上下文中解析的。
|
||||
|
||||
<!--
|
||||
As a result, the following storage functionality is not supported on Windows nodes:
|
||||
-->
|
||||
因此，Windows 节点不支持以下存储功能：
|
||||
|
||||
<!--
|
||||
* Volume subpath mounts: only the entire volume can be mounted in a Windows container
|
||||
* Subpath volume mounting for Secrets
|
||||
* Host mount projection
|
||||
* Read-only root filesystem (mapped volumes still support `readOnly`)
|
||||
* Block device mapping
|
||||
* Memory as the storage medium (for example, `emptyDir.medium` set to `Memory`)
|
||||
* File system features like uid/gid; per-user Linux filesystem permissions
|
||||
* Setting [secret permissions with DefaultMode](/docs/concepts/configuration/secret/#secret-files-permissions) (due to UID/GID dependency)
|
||||
* NFS based storage/volume support
|
||||
* Expanding the mounted volume (resizefs)
|
||||
-->
|
||||
* 卷子路径挂载：只能在 Windows 容器上挂载整个卷
|
||||
* Secret 的子路径挂载
|
||||
* 宿主挂载映射
|
||||
* 只读的根文件系统（映射的卷仍然支持 `readOnly`）
|
||||
* 块设备映射
|
||||
* 内存作为存储介质（例如 `emptyDir.medium` 设置为 `Memory`）
|
||||
* 类似 UID/GID、各用户不同的 Linux 文件系统访问许可等文件系统特性
|
||||
* 使用 [DefaultMode 设置 Secret 权限](/zh/docs/concepts/configuration/secret/#secret-files-permissions)
|
||||
（因为该特性依赖 UID/GID）
|
||||
* 基于 NFS 的存储和卷支持
|
||||
* 扩展已挂载卷（resizefs）
|
||||
|
||||
<!--
|
||||
Kubernetes {{< glossary_tooltip text="volumes" term_id="volume" >}} enable complex
|
||||
applications, with data persistence and Pod volume sharing requirements, to be deployed
|
||||
on Kubernetes. Management of persistent volumes associated with a specific storage
|
||||
back-end or protocol includes actions such as provisioning/de-provisioning/resizing
|
||||
of volumes, attaching/detaching a volume to/from a Kubernetes node and
|
||||
mounting/dismounting a volume to/from individual containers in a pod that needs to
|
||||
persist data.
|
||||
-->
|
||||
使用 Kubernetes {{< glossary_tooltip text="卷" term_id="volume" >}}，
|
||||
对数据持久性和 Pod 卷共享有需求的复杂应用也可以部署到 Kubernetes 上。
|
||||
管理与特定存储后端或协议相关的持久卷时，相关的操作包括：对卷的制备（Provisioning）、
|
||||
去配（De-provisioning）和调整大小，将卷挂接到 Kubernetes 节点或从节点上解除挂接，
|
||||
将卷挂载到需要持久数据的 Pod 中的某容器上或从容器上卸载。
|
||||
|
||||
<!--
|
||||
Volume management components are shipped as Kubernetes volume
|
||||
[plugin](/docs/concepts/storage/volumes/#types-of-volumes).
|
||||
The following broad classes of Kubernetes volume plugins are supported on Windows:
|
||||
-->
|
||||
卷管理组件作为 Kubernetes 卷[插件](/zh/docs/concepts/storage/volumes/#types-of-volumes)发布。
|
||||
Windows 支持以下类型的 Kubernetes 卷插件：
|
||||
|
||||
<!--
|
||||
* [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexVolume)
|
||||
* Please note that FlexVolumes have been deprecated as of 1.23
|
||||
* [`CSI Plugins`](/docs/concepts/storage/volumes/#csi)
|
||||
-->
|
||||
* [`FlexVolume plugins`](/zh/docs/concepts/storage/volumes/#flexVolume)
|
||||
* 请注意自 1.23 版本起，FlexVolume 已被弃用
|
||||
* [`CSI Plugins`](/zh/docs/concepts/storage/volumes/#csi)
|
||||
|
||||
<!--
|
||||
##### In-tree volume plugins
|
||||
|
||||
The following in-tree plugins support persistent storage on Windows nodes:
|
||||
-->
|
||||
##### 树内（In-Tree）卷插件 {#in-tree-volume-plugins}
|
||||
|
||||
以下树内（In-Tree）插件支持 Windows 节点上的持久存储：
|
||||
|
||||
<!--
|
||||
* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore)
|
||||
* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk)
|
||||
* [`azureFile`](/docs/concepts/storage/volumes/#azurefile)
|
||||
* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk)
|
||||
* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume)
|
||||
-->
|
||||
* [`awsElasticBlockStore`](/zh/docs/concepts/storage/volumes/#awselasticblockstore)
|
||||
* [`azureDisk`](/zh/docs/concepts/storage/volumes/#azuredisk)
|
||||
* [`azureFile`](/zh/docs/concepts/storage/volumes/#azurefile)
|
||||
* [`gcePersistentDisk`](/zh/docs/concepts/storage/volumes/#gcepersistentdisk)
|
||||
* [`vsphereVolume`](/zh/docs/concepts/storage/volumes/#vspherevolume)
|
||||
Reference in New Issue
Block a user