diff --git a/content/zh/docs/concepts/storage/persistent-volumes.md b/content/zh/docs/concepts/storage/persistent-volumes.md index 34341afd97..fdf9e6ee50 100644 --- a/content/zh/docs/concepts/storage/persistent-volumes.md +++ b/content/zh/docs/concepts/storage/persistent-volumes.md @@ -666,7 +666,7 @@ size that is within the capacity limits of underlying storage provider. You can @@ -810,7 +810,7 @@ Helper programs relating to the volume type may be required for consumption of a @@ -818,9 +818,9 @@ Currently, storage size is the only resource that can be set or requested. Futu 一般而言,每个 PV 卷都有确定的存储容量。 容量属性是使用 PV 对象的 `capacity` 属性来设置的。 -参考 Kubernetes -[资源模型(Resource Model)](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) -设计提案,了解 `capacity` 字段可以接受的单位。 +参考词汇表中的 +[量纲(Quantity)](/zh/docs/reference/glossary/?all=true#term-quantity) +词条,了解 `capacity` 字段可以接受的单位。 目前,存储大小是可以设置和请求的唯一资源。 未来可能会包含 IOPS、吞吐量等属性。 @@ -1038,19 +1038,19 @@ The following volume types support mount options: --> 以下卷类型支持挂载选项: -* AWSElasticBlockStore -* AzureDisk -* AzureFile -* CephFS -* Cinder (OpenStack 块存储) -* GCEPersistentDisk -* Glusterfs -* NFS -* Quobyte 卷 -* RBD (Ceph 块设备) -* StorageOS -* VsphereVolume -* iSCSI +* `awsElasticBlockStore` +* `azureDisk` +* `azureFile` +* `cephfs` +* `cinder` (**已弃用**于 v1.18) +* `gcePersistentDisk` +* `glusterfs` +* `iscsi` +* `nfs` +* `quobyte` (**已弃用**于 v1.22) +* `rbd` +* `storageos` (**已弃用**于 v1.22) +* `vsphereVolume` 阅读本文前建议你熟悉一下 [Pods](/zh/docs/concepts/workloads/pods)。 @@ -59,8 +59,8 @@ Docker 提供卷驱动程序,但是其功能非常有限。 Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}} can use any number of volume types simultaneously. Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond -the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; -however, Kubernetes does not destroy persistent volumes. +the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; +however, Kubernetes does not destroy persistent volumes. For any kind of volume in a given pod, data is preserved across container restarts. --> Kubernetes 支持很多类型的卷。 @@ -82,21 +82,36 @@ volume type used. 使用卷时, 在 `.spec.volumes` 字段中设置为 Pod 提供的卷,并在 `.spec.containers[*].volumeMounts` 字段中声明卷在容器中的挂载位置。 -容器中的进程看到的是由它们的 Docker 镜像和卷组成的文件系统视图。 -[Docker 镜像](https://docs.docker.com/userguide/dockerimages/) -位于文件系统层次结构的根部。各个卷则挂载在镜像内的指定路径上。 -卷不能挂载到其他卷之上,也不能与其他卷有硬链接。 +容器中的进程看到的文件系统视图是由它们的 {{< glossary_tooltip text="容器镜像" term_id="image" >}} +的初始内容以及挂载在容器中的卷(如果定义了的话)所组成的。 +其中根文件系统同容器镜像的内容相吻合。 +任何在该文件系统下的写入操作,如果被允许的话,都会影响接下来容器中进程访问文件系统时所看到的内容。 + + +卷中 [指定的路径](#using-subpath) 将会被挂载。 Pod 配置中的每个容器必须独立指定各个卷的挂载位置。 +卷不能挂载到其他卷之上(不过存在一种相关的机制 [使用 subPath](#using-subpath)),也不能与其他卷有硬链接。 + -`projected` 卷类型能将若干现有的卷来源映射到同一目录上。 - -目前,可以映射的卷来源类型如下: - -- [`secret`](#secret) -- [`downwardAPI`](#downwardapi) -- [`configMap`](#configmap) -- `serviceAccountToken` - - -所有的卷来源需要和 Pod 处于相同的命名空间。 -更多详情请参考[一体化卷设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)。 - - - -#### 包含 Secret、downwardAPI 和 configMap 的 Pod 示例 {#example-configuration-secret-downwardapi-configmap} - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: volume-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: all-in-one - mountPath: "/projected-volume" - readOnly: true - volumes: - - name: all-in-one - projected: - sources: - - secret: - name: mysecret - items: - - key: username - path: my-group/my-username - - downwardAPI: - items: - - path: "labels" - fieldRef: - fieldPath: metadata.labels - - path: "cpu_limit" - resourceFieldRef: - containerName: container-test - resource: limits.cpu - - configMap: - name: myconfigmap - items: - - key: config - path: my-group/my-config -``` - - - -下面是一个带有非默认访问权限设置的多个 secret 的 Pod 示例: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: volume-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: all-in-one - mountPath: "/projected-volume" - readOnly: true - volumes: - - name: all-in-one - projected: - sources: - - secret: - name: mysecret - items: - - key: username - path: my-group/my-username - - secret: - name: mysecret2 - items: - - key: password - path: my-group/my-password - mode: 511 -``` - -每个被投射的卷来源都在规约中的 `sources` 内列出。参数几乎相同,除了两处例外: - -* 对于 `secret`,`secretName` 字段已被变更为 `name` 以便与 ConfigMap 命名一致。 -* `defaultMode` 只能在整个投射卷级别指定,而无法针对每个卷来源指定。 - 不过,如上所述,你可以显式地为每个投射项设置 `mode` 值。 - - - -当开启 `TokenRequestProjection` 功能时,可以将当前 -[服务帐号](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens) -的令牌注入 Pod 中的指定路径。 -下面是一个例子: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: sa-token-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: token-vol - mountPath: "/service-account" - readOnly: true - volumes: - - name: token-vol - projected: - sources: - - serviceAccountToken: - audience: api - expirationSeconds: 3600 - path: token -``` - - -示例 Pod 具有包含注入服务帐户令牌的映射卷。 -该令牌可以被 Pod 中的容器用来访问 Kubernetes API 服务器。 -`audience` 字段包含令牌的预期受众。 -令牌的接收者必须使用令牌的受众中指定的标识符来标识自己,否则应拒绝令牌。 -此字段是可选的,默认值是 API 服务器的标识符。 - - -`expirationSeconds` 是服务帐户令牌的有效期时长。 -默认值为 1 小时,必须至少 10 分钟(600 秒)。 -管理员还可以通过设置 API 服务器的 `--service-account-max-token-expiration` 选项来 -限制其最大值。 -`path` 字段指定相对于映射卷的挂载点的相对路径。 - -{{< note >}} - -使用投射卷源作为 [subPath](#using-subpath) 卷挂载的容器将不会接收这些卷源的更新。 -{{< /note >}} +投射卷能将若干现有的卷来源映射到同一目录上。更多详情请参考 [投射卷](/zh/docs/concepts/storage/projected-volumes/)。 ### quobyte (已弃用) {#quobyte} @@ -1542,11 +1378,11 @@ Quobyte 的 GitHub 项目包含以 CSI 形式部署 Quobyte 的 `rbd` 卷允许将 [Rados 块设备](https://docs.ceph.com/en/latest/rbd/) 卷挂载到你的 Pod 中. 不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除,`rbd` 卷的内容在删除 Pod 时 @@ -1554,20 +1390,21 @@ be shared between pods. 这意味着 `rbd` 卷可以被预先填充数据,并且这些数据可以在 Pod 之间共享。 -{{< caution >}} +{{< note >}} 在使用 RBD 之前,你必须安装运行 Ceph。 -{{< /caution >}} +{{< /note >}} RBD 的一个特性是它可以同时被多个用户以只读方式挂载。 这意味着你可以用数据集预先填充卷,然后根据需要在尽可能多的 Pod 中并行地使用卷。 @@ -1576,6 +1413,59 @@ RBD 的一个特性是它可以同时被多个用户以只读方式挂载。 更多详情请参考 [RBD 示例](https://github.com/kubernetes/examples/tree/master/volumes/rbd)。 + +#### RBD CSI 迁移 {#rbd-csi-migration} + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + + +启用 RBD 的 `CSIMigration` 功能后,所有插件操作从现有的树内插件重定向到 +`rbd.csi.ceph.com` {{}} 驱动程序。 +要使用该功能,必须在集群内安装 [Ceph CSI driver](https://github.com/ceph/ceph-csi) +并启用 `CSIMigration` 和 `csiMigrationRBD` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 + + +{{< note >}} +作为一位管理存储的 Kubernetes 集群操作者,在尝试迁移到 RBD CSI 驱动前,你必须完成下列先决事项: + +* 你必须在集群中安装 v3.5.0 或更高版本的 Ceph CSI 驱动(`rbd.csi.ceph.com`)。 +* 因为 `clusterID` 是 CSI 驱动程序必需的参数,而树内存储类又将 `monitors` 作为一个必需的参数, + 所以 Kubernetes 存储管理者需要根据 `monitors` 的哈希值 + (例:`#echo -n '' | md5sum`)来创建 `clusterID`, + 并保持该 `monitors` 存在于该 `clusterID` 的配置中。 +* 同时,如果树内存储类的 `adminId` 的值与 `admin` 不同,那么其 `adminSecretName` 就需要 + 被修改成 `adminId` 的 base64 编码后的值。 +{{< /note >}} + ### secret +#### Portworx CSI 迁移 + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + + +Kubernetes 1.23 中加入了 Portworx 的 `CSIMigration` 功能,但默认不会启用,因为该功能仍处于 alpha 阶段。 +该功能会将所有的插件操作从现有的树内插件重定向到 +`pxd.portworx.com` 容器存储接口(Container Storage Interface, CSI)驱动程序。 +集群中必须安装 +[Portworx CSI Driver](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/)。 +要启用此功能,请在 kube-controller-manager 和 kubelet 中设置 `CSIMigrationPortworx=true`。 + -## 使用 subPath {#using-path} +## 使用 subPath {#using-subpath} 有时,在单个 Pod 中共享卷以供多方使用是很有用的。 `volumeMounts.subPath` 属性可用于指定所引用的卷内的子路径,而不是其根路径。 @@ -1934,6 +1846,7 @@ spec: volumeMounts: - name: workdir1 mountPath: /logs + # 包裹变量名的是小括号,而不是大括号 subPathExpr: $(POD_NAME) restartPolicy: Never volumes: @@ -1970,16 +1883,15 @@ To learn about requesting space using a resource specification, see ## Out-of-Tree Volume Plugins The out-of-tree volume plugins include -{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) -and FlexVolume. They enable storage vendors to create custom storage plugins -without adding them to the Kubernetes repository. +{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI), and also FlexVolume (which is deprecated). These plugins enable storage vendors to create custom storage plugins +without adding their plugin source code to the Kubernetes repository. --> ## 树外(Out-of-Tree)卷插件 {#out-of-tree-volume-plugins} Out-of-Tree 卷插件包括 {{< glossary_tooltip text="容器存储接口(CSI)" term_id="csi" >}} (CSI) -和 FlexVolume。 -它们使存储供应商能够创建自定义存储插件,而无需将它们添加到 Kubernetes 代码仓库。 +和 FlexVolume (已弃用)。 +它们使存储供应商能够创建自定义存储插件,而无需将插件源码添加到 Kubernetes 代码仓库。 -FlexVolume 是一个自 1.2 版本(在 CSI 之前)以来在 Kubernetes 中一直存在的树外插件接口。 -它使用基于 exec 的模型来与驱动程序对接。 -用户必须在每个节点(在某些情况下是主控节点)上的预定义卷插件路径中安装 -FlexVolume 驱动程序可执行文件。 +FlexVolume 是一个使用基于 exec 的模型来与驱动程序对接的树外插件接口。 +用户必须在每个节点上的预定义卷插件路径中安装FlexVolume 驱动程序可执行文件, +在某些情况下,控制平面节点中也要安装。 Pod 通过 `flexvolume` 树内插件与 Flexvolume 驱动程序交互。 -更多详情请参考 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 示例。 +更多详情请参考 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 文档。 + + +{{< note >}} +FlexVolume 已弃用。推荐使用树外 CSI 驱动来将外部存储整合进 Kubernetes。 + +FlexVolume 驱动的维护者应开发一个 CSI 驱动并帮助用户从 FlexVolume 驱动迁移到 CSI。 +FlexVolume 用户应迁移工作负载以使用对等的 CSI 驱动。 +{{< /note >}}