From c82d8239d941e9e6b9a3c580e804de33bb0b15eb Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Tue, 10 Nov 2020 13:49:55 +0800 Subject: [PATCH] [zh] Resync docs/concepts/storage/volumes.md --- content/zh/docs/concepts/storage/volumes.md | 1532 ++++++++++--------- 1 file changed, 782 insertions(+), 750 deletions(-) diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md index 1a6ba538a0..cd16a93a54 100644 --- a/content/zh/docs/concepts/storage/volumes.md +++ b/content/zh/docs/concepts/storage/volumes.md @@ -14,58 +14,55 @@ weight: 10 - -容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。 -首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失——因为容器会以干净的状态重建。 -其次，当在一个 `Pod` 中同时运行多个容器时，常常需要在这些容器之间共享文件。 -Kubernetes 抽象出 `Volume` 对象来解决这两个问题。 +Container 中的文件在磁盘上是临时存放的，这给 Container 中运行的较重要的应用 +程序带来一些问题。问题之一是当容器崩溃时文件丢失。kubelet 会重新启动容器， +但容器会以干净的状态重启。 +第二个问题会在同一 `Pod` 中运行多个容器并共享文件时出现。 +Kubernetes {{< glossary_tooltip text="卷（Volume）" term_id="volume" >}} +这一抽象概念能够解决这两个问题。 -阅读本文前建议您熟悉一下 [Pods](/zh/docs/concepts/workloads/pods)。 +阅读本文前建议你熟悉一下 [Pods](/zh/docs/concepts/workloads/pods)。 +## 背景 {#background} -## 背景 - -Docker 也有 [Volume](https://docs.docker.com/storage/) 的概念，但对它只有少量且松散的管理。 -在 Docker 中，Volume 是磁盘上或者另外一个容器内的一个目录。 -直到最近，Docker 才支持对基于本地磁盘的 Volume 的生存期进行管理。 -虽然 Docker 现在也能提供 Volume 驱动程序，但是目前功能还非常有限 -（例如，截至 Docker 1.7，每个容器只允许有一个 Volume 驱动程序，并且无法将参数传递给卷）。 +Docker 也有 [卷（Volume）](https://docs.docker.com/storage/) 的概念，但对它只有少量且松散的管理。 +Docker 卷是磁盘上或者另外一个容器内的一个目录。 +Docker 提供卷驱动程序，但是其功能非常有限。 -另一方面，Kubernetes 卷具有明确的生命周期——与包裹它的 Pod 相同。 -因此，卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 -当然，当一个 Pod 不再存在时，卷也将不再存在。 -也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。 +Kubernetes 支持很多类型的卷。 +{{< glossary_tooltip term_id="pod" text="Pod" >}} 可以同时使用任意数目的卷类型。 +临时卷类型的生命周期与 Pod 相同，但持久卷可以比 Pod 的存活期长。 +因此，卷的存在时间会超出 Pod 中运行的所有容器，并且在容器重新启动时数据也会得到保留。 +当 Pod 不再存在时，卷也将不再存在。 -卷的核心是包含一些数据的目录，Pod 中的容器可以访问该目录。 -特定的卷类型可以决定这个目录如何形成的，并能决定它支持何种介质，以及目录中存放什么内容。 - - - -使用卷时, Pod 声明中需要提供卷的类型 (`.spec.volumes` 字段)和卷挂载的位置 (`.spec.containers.volumeMounts` 字段). +卷的核心是包含一些数据的一个目录，Pod 中的容器可以访问该目录。 +所采用的特定的卷类型将决定该目录如何形成的、使用何种介质保存数据以及目录中存放 +的内容。 -容器中的进程能看到由它们的 Docker 镜像和卷组成的文件系统视图。 +使用卷时, 在 `.spec.volumes` 字段中设置为 Pod 提供的卷，并在 +`.spec.containers[*].volumeMounts` 字段中声明卷在容器中的挂载位置。 +容器中的进程看到的是由它们的 Docker 镜像和卷组成的文件系统视图。 [Docker 镜像](https://docs.docker.com/userguide/dockerimages/) -位于文件系统层次结构的根部，并且任何 Volume 都挂载在镜像内的指定路径上。 -卷不能挂载到其他卷，也不能与其他卷有硬链接。 -Pod 中的每个容器必须独立地指定每个卷的挂载位置。 +位于文件系统层次结构的根部。各个卷则挂载在镜像内的指定路径上。 +卷不能挂载到其他卷之上，也不能与其他卷有硬链接。 +Pod 配置中的每个容器必须独立指定各个卷的挂载位置。 -## Volume 的类型 +## 卷类型 {#volume-types} Kubernetes 支持下列类型的卷： - - * [awsElasticBlockStore](#awselasticblockstore) - * [azureDisk](#azuredisk) - * [azureFile](#azurefile) - * [cephfs](#cephfs) - * [cinder](#cinder) - * [configMap](#configmap) - * [csi](#csi) - * [downwardAPI](#downwardapi) - * [emptyDir](#emptydir) - * [fc (fibre channel)](#fc) - * [flexVolume](#flexVolume) - * [flocker](#flocker) - * [gcePersistentDisk](#gcepersistentdisk) - * [gitRepo (deprecated)](#gitrepo) - * [glusterfs](#glusterfs) - * [hostPath](#hostpath) - * [iscsi](#iscsi) - * [local](#local) - * [nfs](#nfs) - * [persistentVolumeClaim](#persistentvolumeclaim) - * [projected](#projected) - * [portworxVolume](#portworxvolume) - * [quobyte](#quobyte) - * [rbd](#rbd) - * [scaleIO](#scaleio) - * [secret](#secret) - * [storageos](#storageos) - * [vsphereVolume](#vspherevolume) - - - -我们欢迎大家贡献其他的卷类型支持。 - ### awsElasticBlockStore {#awselasticblockstore} -`awsElasticBlockStore` 卷将 Amazon Web服务（AWS）[EBS 卷](https://aws.amazon.com/ebs/) 挂载到您的 Pod 中。 -与 `emptyDir` 在删除 Pod 时会被删除不同，EBS 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 -这意味着 EBS 卷可以预先填充数据，并且可以在 Pod 之间传递数据。 +`awsElasticBlockStore` 卷将 Amazon Web服务（AWS）[EBS 卷](https://aws.amazon.com/ebs/) +挂载到你的 Pod 中。与 `emptyDir` 在 Pod 被删除时也被删除不同，EBS 卷的内容在删除 Pod 时 +会被保留，卷只是被卸载掉了。 +这意味着 EBS 卷可以预先填充数据，并且该数据可以在 Pod 之间共享。 -{{< caution >}} -您在使用 EBS 卷之前必须先创建它，可以使用 `aws ec2 create-volume` 命令进行创建；也可以使用 AWS API 进行创建。 -{{< /caution >}} +{{< note >}} +你在使用 EBS 卷之前必须使用 `aws ec2 create-volume` 命令或者 AWS API 创建该卷。 +{{< /note >}} 使用 `awsElasticBlockStore` 卷时有一些限制： -* Pod 正在运行的节点必须是 AWS EC2 实例。 -* 这些实例需要与 EBS 卷在相同的地域（region）和可用区（availability-zone）。 +* Pod 运行所在的节点必须是 AWS EC2 实例。 +* 这些实例需要与 EBS 卷在相同的地域（Region）和可用区（Availability-Zone）。 * EBS 卷只支持被挂载到单个 EC2 实例上。 #### 创建 EBS 卷 -在将 EBS 卷用到 Pod 上之前，您首先要创建它。 +在将 EBS 卷用到 Pod 上之前，你首先要创建它。 ```shell aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 ``` -确保该区域与您的群集所在的区域相匹配。（也要检查卷的大小和 EBS 卷类型都适合您的用途！） +确保该区域与你的群集所在的区域相匹配。还要检查卷的大小和 EBS 卷类型都适合你的用途。 +#### AWS EBS CSI 卷迁移 + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + + +如果启用了对 `awsElasticBlockStore` 的 `CSIMigration` 特性支持，所有插件操作都 +不再指向树内插件（In-Tree Plugin），转而指向 `ebs.csi.aws.com` 容器存储接口 +（Container Storage Interface，CSI）驱动。为了使用此特性，必须在集群中安装 +[AWS EBS CSI 驱动](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)， +并确保 `CSIMigration` 和 `CSIMigrationAWS` Beta 功能特性被启用。 + + +#### AWS EBS CSI 迁移结束 + +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + + +如欲禁止 `awsElasticBlockStore` 存储插件被控制器管理器和 kubelet +组件加载，可将 `CSIMigrationAWSComplete` 特性门控设置为 `true`。此特性要求在 +集群中所有工作节点上安装 `ebs.csi.aws.com` 容器存储接口驱动。 + ### azureDisk {#azuredisk} -`azureDisk` 用来在 Pod 上挂载 Microsoft Azure [数据盘（Data Disk）](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/) . -更多详情请参考[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)。 +`azureDisk` 卷类型用来在 Pod 上挂载 Microsoft Azure +[数据盘（Data Disk）](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/) 。 +若需了解更多详情，请参考 [`azureDisk` 卷插件](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)。 -#### CSI迁移 +#### azureDisk 的 CSI 迁移 {#azuredisk-csi-migration} -{{< feature-state for_k8s_version="v1.15" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -启用azureDisk的CSI迁移功能后，它会将所有插件操作从现有的内建插件填添加disk.csi.azure.com容器存储接口（CSI）驱动程序中。 -为了使用此功能，必须在群集上安装 [Azure磁盘CSI驱动程序](https://github.com/kubernetes-sigs/azuredisk-csi-driver)， -并且 `CSIMigration` 和 `CSIMigrationAzureDisk` Alpha功能 必须启用。 +启用 `azureDisk` 的 `CSIMigration` 功能后，所有插件操作从现有的树内插件重定向到 +`disk.csi.azure.com` 容器存储接口（CSI）驱动程序。 +为了使用此功能，必须在集群中安装 +[Azure 磁盘 CSI 驱动程序](https://github.com/kubernetes-sigs/azuredisk-csi-driver)， +并且 `CSIMigration` 和 `CSIMigrationAzureDisk` 功能必须被启用。 ### azureFile {#azurefile} -`azureFile` 用来在 Pod 上挂载 Microsoft Azure 文件卷（File Volume） (SMB 2.1 和 3.0)。 -更多详情请参考[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)。 +`azureFile` 卷类型用来在 Pod 上挂载 Microsoft Azure 文件卷（File Volume）（SMB 2.1 和 3.0）。 +更多详情请参考 [`azureFile` 卷插件](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)。 -#### CSI迁移 +#### CSI 迁移 {#azurefile-csi-migration} {{< feature-state for_k8s_version="v1.15" state="alpha" >}} -启用azureFile的CSI迁移功能后，它会将所有插件操作从现有的内建插件填添加file.csi.azure.com容器存储接口（CSI）驱动程序中。 -为了使用此功能，必须在群集上安装 [Azure文件CSI驱动程序](https://github.com/kubernetes-sigs/azurefile-csi-driver)， -并且 `CSIMigration` 和 `CSIMigrationAzureFile` Alpha功能 必须启用。 +启用 `azureFile` 的 `CSIMigration` 功能后，所有插件操作将从现有的树内插件重定向到 +`file.csi.azure.com` 容器存储接口（CSI）驱动程序。 +要使用此功能，必须在集群中安装 [Azure 文件 CSI 驱动程序](https://github.com/kubernetes-sigs/azurefile-csi-driver)， +并且 `CSIMigration` 和 `CSIMigrationAzureFile` Alpha 功能特性必须被启用。 ### cephfs {#cephfs} @@ -291,20 +286,21 @@ Alpha features must be enabled. A `cephfs` volume allows an existing CephFS volume to be mounted into your Pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of a `cephfs` volume are preserved and the volume is merely -unmounted. This means that a CephFS volume can be pre-populated with data, and -that data can be "handed off" between Pods. CephFS can be mounted by multiple +unmounted. This means that a `cephfs` volume can be pre-populated with data, and +that data can be shared between Pods. The `cephfs` can be mounted by multiple writers simultaneously. --> -`cephfs` 允许您将现存的 CephFS 卷挂载到 Pod 中。 -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`cephfs` 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 -这意味着 CephFS 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。CephFS 卷可同时被多个写者挂载。 +`cephfs` 卷允许你将现存的 CephFS 卷挂载到 Pod 中。 +不像 `emptyDir` 那样会在 Pod 被删除的同时也会被删除，`cephfs` 卷的内容在 Pod 被删除 +时会被保留，只是卷被卸载了。这意味着 `cephfs` 卷可以被预先填充数据，且这些数据可以在 +Pod 之间共享。同一 `cephfs` 卷可同时被多个写者挂载。 -{{< caution >}} -在您使用 Ceph 卷之前，您的 Ceph 服务器必须正常运行并且要使用的 share 被导出（exported）。 -{{< /caution >}} +{{< note >}} +在使用 Ceph 卷之前，你的 Ceph 服务器必须已经运行并将要使用的 share 导出（exported）。 +{{< /note >}} {{< note >}} -先决条件：配置了OpenStack Cloud Provider 的 Kubernetes。 +Kubernetes 必须配置了 OpenStack Cloud Provider。 {{< /note >}} -`cinder` 用于将 OpenStack Cinder 卷安装到 Pod 中。 +`cinder` 卷类型用于将 OpenStack Cinder 卷挂载到 Pod 中。 -#### Cinder Volume示例配置 +#### Cinder 卷示例配置 ```yaml apiVersion: v1 @@ -343,55 +339,55 @@ spec: name: test-volume volumes: - name: test-volume - # This OpenStack volume must already exist. + # 此 OpenStack 卷必须已经存在 cinder: - volumeID: + volumeID: "" fsType: ext4 ``` -#### CSI迁移 +#### OpenStack CSI 迁移 -{{< feature-state for_k8s_version="v1.14" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} +启用 Cinder 的 `CSIMigration` 功能后，所有插件操作会从现有的树内插件重定向到 +`cinder.csi.openstack.org` 容器存储接口（CSI）驱动程序。 +为了使用此功能，必须在集群中安装 [Openstack Cinder CSI 驱动程序](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md)， +并且 `CSIMigration` 和 `CSIMigrationOpenStack` Beta 功能必须被启用。 -启用Cinder的CSI迁移功能后，它会将所有插件操作从现有的内建插件填添加 `cinder.csi.openstack.org` 容器存储接口（CSI）驱动程序中。 -为了使用此功能，必须在群集上安装 [Openstack Cinder CSI驱动程序](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md)， -并且 `CSIMigration` 和 `CSIMigrationOpenStack` Alpha功能 必须启用。 - - -### configMap {#configmap} +### configMap -[`configMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源提供了向 Pod 注入配置数据的方法。 -`ConfigMap` 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被应用到 Pod 中运行的容器化应用。 +[`configMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 卷 +提供了向 Pod 注入配置数据的方法。 +ConfigMap 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被 Pod 中运行的 +容器化应用使用。 - -当引用 `configMap` 对象时，你可以简单的在 Volume 中通过它名称来引用。 -还可以自定义 ConfigMap 中特定条目所要使用的路径。 -例如，要将名为 `log-config` 的 ConfigMap 挂载到名为 `configmap-pod` 的 Pod 中，您可以使用下面的 YAML： +引用 configMap 对象时，你可以在 volume 中通过它的名称来引用。 +你可以自定义 ConfigMap 中特定条目所要使用的路径。 +下面的配置显示了如何将名为 `log-config` 的 ConfigMap 挂载到名为 `configmap-pod` +的 Pod 中： ```yaml apiVersion: v1 @@ -420,41 +416,41 @@ its `log_level` entry are mounted into the Pod at path "`/etc/config/log_level`" Note that this path is derived from the volume's `mountPath` and the `path` keyed with `log_level`. --> -`log-config` ConfigMap 是以卷的形式挂载的， -存储在 `log_level` 条目中的所有内容都被挂载到 Pod 的 "`/etc/config/log_level`" 路径下。 -请注意，这个路径来源于 Volume 的 `mountPath` 和 `log_level` 键对应的 `path`。 +`log-config` ConfigMap 以卷的形式挂载，并且存储在 `log_level` 条目中的所有内容 +都被挂载到 Pod 的 `/etc/config/log_level` 路径下。 +请注意，这个路径来源于卷的 `mountPath` 和 `log_level` 键对应的 `path`。 -{{< caution >}} -在使用 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前您首先要创建它。 -{{< /caution >}} +* You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) + before you can use it. - {{< note >}} -容器以 [subPath](#using-subpath) 卷挂载方式使用 ConfigMap 时，将无法接收 ConfigMap 的更新。 +* 在使用 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前你首先要创建它。 +* 容器以 [subPath](#using-subpath) 卷挂载方式使用 ConfigMap 时，将无法接收 ConfigMap 的更新。 +* 文本数据挂载成文件时采用 UTF-8 字符编码。如果使用其他字符编码形式，可使用 + `binaryData` 字段。 {{< /note >}} -### downwardAPI {#downwardapi} +### downwardAPI - `downwardAPI` 卷用于使 downward API 数据对应用程序可用。 -这种卷类型挂载一个目录并在纯文本文件中写入请求的数据。 +这种卷类型挂载一个目录并在纯文本文件中写入所请求的数据。 {{< note >}} -容器以挂载 [subPath](#using-subpath) 卷的方式使用 downwardAPI 时，将不能接收到它的更新。 +容器以 [subPath](#using-subpath) 卷挂载方式使用 downwardAPI 时，将不能接收到它的更新。 {{< /note >}} 更多详细信息请参考 [`downwardAPI` 卷示例](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。 -### emptyDir {#emptydir} +### emptyDir - -当 Pod 指定到某个节点上时，首先创建的是一个 `emptyDir` 卷，并且只要 Pod 在该节点上运行，卷就一直存在。 -就像它的名称表示的那样，卷最初是空的。 -尽管 Pod 中的容器挂载 `emptyDir` 卷的路径可能相同也可能不同，但是这些容器都可以读写 `emptyDir` 卷中相同的文件。 -当 Pod 因为某些原因被从节点上删除时，`emptyDir` 卷中的数据也会永久删除。 +当 Pod 分派到某个 Node 上时，`emptyDir` 卷会被创建，并且在 Pod 在该节点上运行期间，卷一直存在。 +就像其名称表示的那样，卷最初是空的。 +尽管 Pod 中的容器挂载 `emptyDir` 卷的路径可能相同也可能不同，这些容器都可以读写 +`emptyDir` 卷中相同的文件。 +当 Pod 因为某些原因被从节点上删除时，`emptyDir` 卷中的数据也会被永久删除。 {{< note >}} -容器崩溃并不会导致 Pod 被从节点上移除，因此容器崩溃时 `emptyDir` 卷中的数据是安全的。 +容器崩溃并**不**会导致 Pod 被从节点上移除，因此容器崩溃期间 `emptyDir` 卷中的数据是安全的。 {{< /note >}} -默认情况下， `emptyDir` 卷存储在支持该节点所使用的介质上；这里的介质可以是磁盘或 SSD 或网络存储，这取决于您的环境。 -但是，您可以将 `emptyDir.medium` 字段设置为 `"Memory"`，以告诉 Kubernetes 为您安装 tmpfs（基于 RAM 的文件系统）。 +取决于你的环境，`emptyDir` 卷存储在该节点所使用的介质上；这里的介质可以是磁盘或 SSD +或网络存储。但是，你可以将 `emptyDir.medium` 字段设置为 `"Memory"`，以告诉 Kubernetes +为你挂载 tmpfs（基于 RAM 的文件系统）。 虽然 tmpfs 速度非常快，但是要注意它与磁盘不同。 -tmpfs 在节点重启时会被清除，并且您所写入的所有文件都会计入容器的内存消耗，受容器内存限制约束。 +tmpfs 在节点重启时会被清除，并且你所写入的所有文件都会计入容器的内存消耗，受容器内存限制约束。 -#### Pod 示例 +#### emptyDir 配置示例 ```yaml apiVersion: v1 @@ -538,22 +534,23 @@ spec: ### fc (光纤通道) {#fc} -`fc` 卷允许将现有的光纤通道卷挂载到 Pod 中。 -可以使用卷配置中的参数 `targetWWNs` 来指定单个或多个目标 WWN。 -如果指定多个 WWN，targetWWNs 期望这些 WWN 来自多路径连接。 +`fc` 卷类型允许将现有的光纤通道块存储卷挂载到 Pod 中。 +可以使用卷配置中的参数 `targetWWNs` 来指定单个或多个目标 WWN（World Wide Names）。 +如果指定了多个 WWN，targetWWNs 期望这些 WWN 来自多路径连接。 {{< caution >}} -您必须配置 FC SAN Zoning，以便预先向目标 WWN 分配和屏蔽这些 LUN（卷），这样 Kubernetes 主机才可以访问它们。 +你必须配置 FC SAN Zoning，以便预先向目标 WWN 分配和屏蔽这些 LUN（卷）， +这样 Kubernetes 主机才可以访问它们。 {{< /caution >}} -### flocker {#flocker} +### flocker （已弃用） {#flocker} [Flocker](https://github.com/ClusterHQ/flocker) 是一个开源的、集群化的容器数据卷管理器。 -Flocker 提供了由各种存储后备支持的数据卷的管理和编排。 +Flocker 提供了由各种存储后端所支持的数据卷的管理和编排。 -`flocker` 卷允许将一个 Flocker 数据集挂载到 Pod 中。 +使用 `flocker` 卷可以将一个 Flocker 数据集挂载到 Pod 中。 如果数据集在 Flocker 中不存在，则需要首先使用 Flocker CLI 或 Flocker API 创建数据集。 如果数据集已经存在，那么 Flocker 将把它重新附加到 Pod 被调度的节点。 -这意味着数据可以根据需要在 Pod 之间 "传递"。 +这意味着数据可以根据需要在 Pod 之间共享。 -{{< caution >}} -您在使用 Flocker 之前必须先安装运行自己的 Flocker。 -{{< /caution >}} +{{< note >}} +在使用 Flocker 之前你必须先安装运行自己的 Flocker。 +{{< /note >}} - 更多详情请参考 [Flocker 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)。 - ### gcePersistentDisk {#gcepersistentdisk} -`gcePersistentDisk` 卷能将谷歌计算引擎 (GCE) [持久盘（PD）](http://cloud.google.com/compute/docs/disks) 挂载到您的 Pod 中。 -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，持久盘卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 -这意味着持久盘卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 +`gcePersistentDisk` 卷能将谷歌计算引擎 (GCE) [持久盘（PD）](http://cloud.google.com/compute/docs/disks) +挂载到你的 Pod 中。 +不像 `emptyDir` 那样会在 Pod 被删除的同时也会被删除，持久盘卷的内容在删除 Pod +时会被保留，卷只是被卸载了。 +这意味着持久盘卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 {{< caution >}} -您在使用 PD 前，必须使用 `gcloud` 或者 GCE API 或 UI 创建它。 +在使用 PD 前，你必须使用 `gcloud` 或者 GCE API 或 UI 创建它。 {{< /caution >}} -PD 的一个特点是它们可以同时被多个消费者以只读方式挂载。 -这意味着您可以用数据集预先填充 PD，然后根据需要并行地在尽可能多的 Pod 中提供该数据集。 -不幸的是，PD 只能由单个使用者以读写模式挂载——即不允许同时写入。 +GCE PD 的一个特点是它们可以同时被多个消费者以只读方式挂载。 +这意味着你可以用数据集预先填充 PD，然后根据需要并行地在尽可能多的 Pod 中提供该数据集。 +不幸的是，PD 只能由单个使用者以读写模式挂载 —— 即不允许同时写入。 -在由 ReplicationController 所管理的 Pod 上使用 PD 将会失败，除非 PD 是只读模式或者副本的数量是 0 或 1。 +在由 ReplicationController 所管理的 Pod 上使用 GCE PD 将会失败，除非 PD +是只读模式或者副本的数量是 0 或 1。 -#### 创建持久盘（PD） +#### 创建 GCE 持久盘（PD） {#gce-create-persistent-disk} -在 Pod 中使用 GCE 持久盘之前，您首先要创建它。 +在 Pod 中使用 GCE 持久盘之前，你首先要创建它。 ```shell gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk @@ -665,7 +665,7 @@ gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk -#### Pod 示例 +#### GCE 持久盘配置示例 {#gce-pd-configuration-example} ```yaml apiVersion: v1 @@ -681,7 +681,7 @@ spec: name: test-volume volumes: - name: test-volume - # This GCE PD must already exist. + # 此 GCE PD 必须已经存在 gcePersistentDisk: pdName: my-data-disk fsType: ext4 @@ -689,15 +689,18 @@ spec: -#### 区域持久盘（Regional Persistent Disks） - -{{< feature-state for_k8s_version="v1.10" state="beta" >}} +#### 区域持久盘 {#regional-persistent-disks} -[区域持久盘](https://cloud.google.com/compute/docs/disks/#repds) 功能允许您创建能在同一区域的两个可用区中使用的持久盘。 -要使用这个功能，必须以持久盘的方式提供卷；Pod 不支持直接引用这种卷。 +[区域持久盘](https://cloud.google.com/compute/docs/disks/#repds) 功能允许你创建能在 +同一区域的两个可用区中使用的持久盘。 +要使用这个功能，必须以持久卷（PersistentVolume）的方式提供卷；直接从 Pod 引用这种卷 +是不可以的。 -#### 手动供应基于区域 PD 的 PersistentVolume +#### 手动供应基于区域 PD 的 PersistentVolume {#manually-provisioning-regional-pd-pv} -使用 [为 GCE PD 定义的存储类](/zh/docs/concepts/storage/storage-classes/#gce) 也可以动态供应。 -在创建 PersistentVolume 之前，您首先要创建 PD。 +使用[为 GCE PD 定义的存储类](/zh/docs/concepts/storage/storage-classes/#gce) 可以 +实现动态供应。在创建 PersistentVolume 之前，你首先要创建 PD。 ```shell gcloud beta compute disks create --size=500GB my-data-disk @@ -719,7 +722,6 @@ gcloud beta compute disks create --size=500GB my-data-disk - PersistentVolume 示例： ```yaml @@ -737,14 +739,23 @@ spec: gcePersistentDisk: pdName: my-data-disk fsType: ext4 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: failure-domain.beta.kubernetes.io/zone + operator: In + values: + - us-central1-a + - us-central1-b ``` -#### CSI迁移 +#### GCE CSI 迁移 {#gce-csi-migration} -{{< feature-state for_k8s_version="v1.14" state="alpha" >}} +{{< feature-state for_k8s_version="v1.17" state="beta" >}} -启用 GCE PD 的 CSI 迁移功能后，它会将所有插件操作从现有的内建插件填添加 `pd.csi.storage.gke.io` 容器存储接口（ CSI ）驱动程序中。 -为了使用此功能，必须在群集上安装 [GCE PD CSI驱动程序](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)， -并且 `CSIMigration` 和 `CSIMigrationGCE` Alpha功能 必须启用。 - +启用 GCE PD 的 `CSIMigration` 功能后，所有插件操作将从现有的树内插件重定向到 +`pd.csi.storage.gke.io` 容器存储接口（ CSI ）驱动程序。 +为了使用此功能，必须在集群中上安装 +[GCE PD CSI驱动程序](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)， +并且 `CSIMigration` 和 `CSIMigrationGCE` Beta 功能必须被启用。 -### gitRepo (已弃用) +### gitRepo (已弃用) {#gitrepo} {{< warning >}} -gitRepo 卷类型已经被废弃。如果需要在容器中提供 git 仓库，请将一个 [EmptyDir](#emptydir) 卷挂载到 InitContainer 中，使用 git 命令完成仓库的克隆操作，然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。 +`gitRepo` 卷类型已经被废弃。如果需要在容器中提供 git 仓库，请将一个 +[EmptyDir](#emptydir) 卷挂载到 InitContainer 中，使用 git 命令完成仓库的克隆操作， +然后将 [EmptyDir](#emptydir) 卷挂载到 Pod 的容器中。 {{< /warning >}} - `gitRepo` 卷是一个卷插件的例子。 -该卷类型挂载了一个空目录，并将一个 Git 代码仓库克隆到这个目录中供您使用。 -将来，这种卷可能被移动到一个更加解耦的模型中，而不是针对每个应用案例扩展 Kubernetes API。 +该查卷挂载一个空目录，并将一个 Git 代码仓库克隆到这个目录中供 Pod 使用。 -下面给出一个 gitRepo 卷的示例： +下面给出一个 `gitRepo` 卷的示例： ```yaml apiVersion: v1 @@ -806,7 +817,7 @@ spec: revision: "22f1d8406d464b0c0874075539c1f2e96c253775" ``` -### glusterfs {#glusterfs} +### glusterfs -`glusterfs` 卷能将 [Glusterfs](https://www.gluster.org) (一个开源的网络文件系统) 挂载到您的 Pod 中。 -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`glusterfs` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 -这意味着 `glusterfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。GlusterFS 可以被多个写者同时挂载。 +`glusterfs` 卷能将 [Glusterfs](https://www.gluster.org) (一个开源的网络文件系统) +挂载到你的 Pod 中。不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`glusterfs` +卷的内容在删除 Pod 时会被保存，卷只是被卸载。 +这意味着 `glusterfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 +GlusterFS 可以被多个写者同时挂载。 -{{< caution >}} -在使用前您必须先安装运行自己的 GlusterFS。 -{{< /caution >}} +{{< note >}} +在使用前你必须先安装运行自己的 GlusterFS。 +{{< /note >}} 更多详情请参考 [GlusterFS 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)。 -### hostPath {#hostpath} +### hostPath - -`hostPath` 卷能将主机节点文件系统上的文件或目录挂载到您的 Pod 中。 +`hostPath` 卷能将主机节点文件系统上的文件或目录挂载到你的 Pod 中。 虽然这不是大多数 Pod 需要的，但是它为一些应用程序提供了强大的逃生舱。 - 例如，`hostPath` 的一些用法有： -* 运行一个需要访问 Docker 引擎内部机制的容器；请使用 `hostPath` 挂载 `/var/lib/docker` 路径。 +* 运行一个需要访问 Docker 内部机制的容器；可使用 `hostPath` 挂载 `/var/lib/docker` 路径。 * 在容器中运行 cAdvisor 时，以 `hostPath` 方式挂载 `/sys`。 * 允许 Pod 指定给定的 `hostPath` 在运行 Pod 之前是否应该存在，是否应该创建以及应该以什么方式存在。 @@ -865,15 +876,13 @@ In addition to the required `path` property, user can optionally specify a `type The supported values for field `type` are: --> - 除了必需的 `path` 属性之外，用户可以选择性地为 `hostPath` 卷指定 `type`。 支持的 `type` 值如下： - - -| 取值 | 行为 | +| 取值 | 行为 | |:------|:---------| | | 空字符串（默认）用于向后兼容，这意味着在安装 hostPath 卷之前不会执行任何检查。 | -| `DirectoryOrCreate` | 如果在给定路径上什么都不存在，那么将根据需要创建空目录，权限设置为 0755，具有与 Kubelet 相同的组和所有权。 | +| `DirectoryOrCreate` | 如果在给定路径上什么都不存在，那么将根据需要创建空目录，权限设置为 0755，具有与 kubelet 相同的组和属主信息。 | | `Directory` | 在给定路径上必须存在的目录。| -| `FileOrCreate` | 如果在给定路径上什么都不存在，那么将在那里根据需要创建空文件，权限设置为 0644，具有与 Kubelet 相同的组和所有权。| +| `FileOrCreate` | 如果在给定路径上什么都不存在，那么将在那里根据需要创建空文件，权限设置为 0644，具有与 kubelet 相同的组和所有权。| | `File` | 在给定路径上必须存在的文件。| | `Socket` | 在给定路径上必须存在的 UNIX 套接字。| | `CharDevice` | 在给定路径上必须存在的字符设备。| @@ -898,28 +906,25 @@ The supported values for field `type` are: - 当使用这种类型的卷时要小心，因为： -* 具有相同配置（例如从 podTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。 -* 当 Kubernetes 按照计划添加资源感知的调度时，这类调度机制将无法考虑由 `hostPath` 使用的资源。 -* 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 -[特权容器](/docs/tasks/configure-pod-container/security-context/) -中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。 +* 具有相同配置（例如基于同一 PodTemplate 创建）的多个 Pod 会由于节点上文件的不同 + 而在不同节点上有不同的行为。 +* 下层主机上创建的文件或目录只能由 root 用户写入。你需要在 + [特权容器](/zh/docs/tasks/configure-pod-container/security-context/) + 中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。 -#### Pod 示例 +#### hostPath 配置示例： ```yaml apiVersion: v1 @@ -936,25 +941,29 @@ spec: volumes: - name: test-volume hostPath: - # directory location on host + # 宿主上目录位置 path: /data - # this field is optional + # 此字段为可选 type: Directory ``` {{< caution >}} -应当注意,`FileOrCreate` 类型不会负责创建文件的父目录。 -如果挂载挂载文件的父目录不存在，pod 启动会失败。 -为了确保这种 `type` 能够工作，可以尝试把文件和它对应的目录分开挂载，如下所示： +`FileOrCreate` 模式不会负责创建文件的父目录。 +如果欲挂载的文件的父目录不存在，Pod 启动会失败。 +为了确保这种模式能够工作，可以尝试把文件和它对应的目录分开挂载，如 +[`FileOrCreate` 配置](#hostpath-fileorcreate-example) 所示。 {{< /caution >}} -#### FileOrCreate pod 示例 + +#### hostPath FileOrCreate 配置示例 {#hostpath-fileorcreate-example} ```yaml apiVersion: v1 @@ -982,36 +991,37 @@ spec: type: FileOrCreate ``` -### iscsi {#iscsi} +### iscsi - -`iscsi` 卷能将 iSCSI (基于 IP 的 SCSI) 挂载到您的 Pod 中。 -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，持久盘 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 -这意味着 `iscsi` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 +`iscsi` 卷能将 iSCSI (基于 IP 的 SCSI) 卷挂载到你的 Pod 中。 +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`iscsi` 卷的内容在删除 Pod 时 +会被保留，卷只是被卸载。 +这意味着 `iscsi` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 {{< caution >}} -在您使用 iSCSI 卷之前，您必须拥有自己的 iSCSI 服务器，并在上面创建卷。 +在使用 iSCSI 卷之前，你必须拥有自己的 iSCSI 服务器，并在上面创建卷。 {{< /caution >}} iSCSI 的一个特点是它可以同时被多个用户以只读方式挂载。 -这意味着您可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 上提供它。不幸的是，iSCSI 卷只能由单个使用者以读写模式挂载——不允许同时写入。 +这意味着你可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 上使用它。 +不幸的是，iSCSI 卷只能由单个使用者以读写模式挂载。不允许同时写入。 +### local -### local {#local} - -{{< feature-state for_k8s_version="v1.14" state="stable" >}} - - -{{< note >}} -alpha 版本的 PersistentVolume NodeAffinity 注释已被取消，将在将来的版本中废弃。 -用户必须更新现有的使用该注解的 PersistentVolume，以使用新的 PersistentVolume `NodeAffinity` 字段。 -{{< /note >}} - - +### local -`local` 卷指的是所挂载的某个本地存储设备，例如磁盘、分区或者目录。 +`local` 卷所代表的是某个被挂载的本地存储设备，例如磁盘、分区或者目录。 `local` 卷只能用作静态创建的持久卷。尚不支持动态配置。 - -相比 `hostPath` 卷，`local` 卷可以以持久和可移植的方式使用，而无需手动将 Pod -调度到节点，因为系统通过查看 PersistentVolume 所属节点的亲和性配置，就能了解卷的节点约束。 +与 `hostPath` 卷相比，`local` 卷能够以持久和可移植的方式使用，而无需手动将 Pod +调度到节点。系统通过查看 PersistentVolume 的节点亲和性配置，就能了解卷的节点约束。 -然而，`local` 卷仍然取决于底层节点的可用性，并不是适合所有应用程序。 -如果节点变得不健康，那么`local` 卷也将变得不可访问，并且使用它的 Pod 将不能运行。 -使用 `local` 卷的应用程序必须能够容忍这种可用性的降低，以及因底层磁盘的耐用性特征而带来的潜在的数据丢失风险。 +然而，`local` 卷仍然取决于底层节点的可用性，并不适合所有应用程序。 +如果节点变得不健康，那么`local` 卷也将变得不可被 Pod 访问。使用它的 Pod 将不能运行。 +使用 `local` 卷的应用程序必须能够容忍这种可用性的降低，以及因底层磁盘的耐用性特征 +而带来的潜在的数据丢失风险。 下面是一个使用 `local` 卷和 `nodeAffinity` 的持久卷示例： @@ -1083,7 +1077,6 @@ metadata: spec: capacity: storage: 100Gi - # volumeMode field requires BlockVolume Alpha feature gate to be enabled. volumeMode: Filesystem accessModes: - ReadWriteOnce @@ -1102,35 +1095,35 @@ spec: ``` -使用 `local` 卷时，需要使用 PersistentVolume 对象的 `nodeAffinity` 字段。 -它使 Kubernetes 调度器能够将使用 `local` 卷的 Pod 正确地调度到合适的节点。 +使用 `local` 卷时，你需要设置 PersistentVolume 对象的 `nodeAffinity` 字段。 +Kubernetes 调度器使用 PersistentVolume 的 `nodeAffinity` 信息来将使用 `local` +卷的 Pod 调度到正确的节点。 -现在，可以将 PersistentVolume 对象的 `volumeMode` 字段设置为 "Block" +PersistentVolume 对象的 `volumeMode` 字段可被设置为 "Block" （而不是默认值 "Filesystem"），以将 `local` 卷作为原始块设备暴露出来。 -`volumeMode` 字段需要启用 Alpha 功能 `BlockVolume`。 - -当使用 `local` 卷时，建议创建一个 StorageClass，将 `volumeBindingMode` 设置为 `WaitForFirstConsumer`。 -请参考[示例](/zh/docs/concepts/storage/storage-classes/#local)。 -延迟卷绑定操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时， -会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod 亲和性和 Pod 反亲和性。 +使用 `local` 卷时，建议创建一个 StorageClass 并将其 `volumeBindingMode` 设置为 +`WaitForFirstConsumer`。要了解更多详细信息，请参考 +[local StorageClass 示例](/zh/docs/concepts/storage/storage-classes/#local)。 +延迟卷绑定的操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时， +会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod +亲和性和 Pod 反亲和性。 -您可以在 Kubernetes 之外单独运行静态驱动以改进对 local 卷的生命周期管理。 -请注意，此驱动不支持动态配置。 -有关如何运行外部 `local` 卷驱动的示例，请参考 +你可以在 Kubernetes 之外单独运行静态驱动以改进对 local 卷的生命周期管理。 +请注意，此驱动尚不支持动态配置。 +有关如何运行外部 `local` 卷驱动，请参考 [local 卷驱动用户指南](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner)。 {{< note >}} -如果不使用外部静态驱动来管理卷的生命周期，则用户需要手动清理和删除 local 类型的持久卷。 +如果不使用外部静态驱动来管理卷的生命周期，用户需要手动清理和删除 local 类型的持久卷。 {{< /note >}} -### nfs {#nfs} +### nfs -`nfs` 卷能将 NFS (网络文件系统) 挂载到您的 Pod 中。 -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`nfs` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 -这意味着 `nfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 +`nfs` 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`nfs` 卷的内容在删除 Pod +时会被保存，卷只是被卸载。 +这意味着 `nfs` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 {{< caution >}} -在您使用 NFS 卷之前，必须运行自己的 NFS 服务器并将目标 share 导出备用。 +在使用 NFS 卷之前，你必须运行自己的 NFS 服务器并将目标 share 导出备用。 {{< /caution >}} -`persistentVolumeClaim` 卷用来将[持久卷](/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。 -持久卷是用户在不知道特定云环境细节的情况下"申领"持久存储（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。 +`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume） +挂载到 Pod 中。 +持久卷申领（PersistentVolumeClaim）是用户在不知道特定云环境细节的情况下"申领"持久存储 +（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。 +更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/)。 -更多详情请参考[持久卷示例](/docs/concepts/storage/persistent-volumes/) +### portworxVolume {#portworxvolume} -### projected {#projected} + +`portworxVolume` 是一个可伸缩的块存储层，能够以超融合（hyperconverged）的方式与 Kubernetes 一起运行。 +[Portworx](https://portworx.com/use-case/kubernetes-storage/) 支持对服务器上存储的指纹处理、 +基于存储能力进行分层以及跨多个服务器整合存储容量。 +Portworx 可以以 in-guest 方式在虚拟机中运行，也可以在裸金属 Linux 节点上运行。 + + +`portworxVolume` 类型的卷可以通过 Kubernetes 动态创建，也可以预先配备并在 +Kubernetes Pod 内引用。 +下面是一个引用预先配备的 PortworxVolume 的示例 Pod： + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-portworx-volume-pod +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /mnt + name: pxvol + volumes: + - name: pxvol + # 此 Portworx 卷必须已经存在 + portworxVolume: + volumeID: "pxvol" + fsType: "" +``` + +{{< note >}} + +在 Pod 中使用 portworxVolume 之前，你要确保有一个名为 `pxvol` 的 PortworxVolume 存在。 +{{< /note >}} + + + +更多详情可以参考 [Portworx 卷](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md)。 + +### projected - `projected` 卷类型能将若干现有的卷来源映射到同一目录上。 目前，可以映射的卷来源类型如下： @@ -1218,27 +1267,14 @@ Currently, the following types of volume sources can be projected: All sources are required to be in the same namespace as the Pod. For more details, see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md). --> - 所有的卷来源需要和 Pod 处于相同的命名空间。 更多详情请参考[一体化卷设计文档](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)。 -服务帐户令牌的映射是 Kubernetes 1.11 版本中引入的一个功能，并在 1.12 版本中被提升为 Beta 功能。 -若要在 1.11 版本中启用此特性，需要显式设置 `TokenRequestProjection` -[功能开关](/zh/docs/reference/command-line-tools-reference/feature-gates/) 为 True。 - - - -#### 包含 secret、downwardAPI 和 configmap 的 Pod 示例如下： +#### 包含 Secret、downwardAPI 和 configMap 的 Pod 示例 {#example-configuration-secret-downwardapi-configmap} ```yaml apiVersion: v1 @@ -1279,10 +1315,10 @@ spec: ``` -带有非默认许可模式设置的多个 secret 的 Pod 示例如下： +下面是一个带有非默认访问权限设置的多个 secret 的 Pod 示例： ```yaml apiVersion: v1 @@ -1323,12 +1359,11 @@ parameters are nearly the same with two exceptions: volume source. However, as illustrated above, you can explicitly set the `mode` for each individual projection. --> +每个被投射的卷来源都在规约中的 `sources` 内列出。参数几乎相同，除了两处例外： -每个被投射的卷来源都在 spec 中的 `sources` 内列出。 -参数几乎相同，除了两处例外： - -* 对于 secret，`secretName` 字段已被变更为 `name` 以便与 ConfigMap 命名一致。 -* `defaultMode` 只能根据投射级别指定，而不是针对每个卷来源指定。不过，如上所述，您可以显式地为每个投射项设置 `mode` 值。 +* 对于 `secret`，`secretName` 字段已被变更为 `name` 以便与 ConfigMap 命名一致。 +* `defaultMode` 只能在整个投射卷级别指定，而无法针对每个卷来源指定。 + 不过，如上所述，你可以显式地为每个投射项设置 `mode` 值。 - 示例 Pod 具有包含注入服务帐户令牌的映射卷。 -例如，这个令牌可以被 Pod 容器用来访问 Kubernetes API服务器。 +该令牌可以被 Pod 中的容器用来访问 Kubernetes API 服务器。 `audience` 字段包含令牌的预期受众。 令牌的接收者必须使用令牌的受众中指定的标识符来标识自己，否则应拒绝令牌。 此字段是可选的，默认值是 API 服务器的标识符。 @@ -1380,142 +1414,91 @@ is optional and it defaults to the identifier of the API server. - -`expirationSeconds` 是服务帐户令牌的有效期。 +`expirationSeconds` 是服务帐户令牌的有效期时长。 默认值为 1 小时，必须至少 10 分钟（600 秒）。 -管理员还可以通过指定 API 服务器的 `--service-account-max-token-expiration` 选项来限制其最大值。 +管理员还可以通过设置 API 服务器的 `--service-account-max-token-expiration` 选项来 +限制其最大值。 `path` 字段指定相对于映射卷的挂载点的相对路径。 {{< note >}} 使用投射卷源作为 [subPath](#using-subpath) 卷挂载的容器将不会接收这些卷源的更新。 {{< /note >}} -### portworxVolume {#portworxvolume} - - - -`portworxVolume` 是一个可伸缩的块存储层，能够以超聚合（hyperconverged）的方式与 Kubernetes 一起运行。 -[Portworx](https://portworx.com/use-case/kubernetes-storage/) 支持对服务器上存储的指纹处理、基于存储能力进行分层以及跨多个服务器整合存储容量。 -Portworx 可以以 in-guest 方式在虚拟机中运行，也可以在裸金属 Linux 节点上运行。 - - - -`portworxVolume` 类型的卷可以通过 Kubernetes 动态创建，也可以在 Kubernetes Pod 内预先供应和引用。 -下面是一个引用预先配置的 PortworxVolume 的示例 Pod： - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: test-portworx-volume-pod -spec: - containers: - - image: k8s.gcr.io/test-webserver - name: test-container - volumeMounts: - - mountPath: /mnt - name: pxvol - volumes: - - name: pxvol - # This Portworx volume must already exist. - portworxVolume: - volumeID: "pxvol" - fsType: "" -``` - -{{< caution >}} - -在 Pod 中使用 portworxVolume 之前，请确保有一个名为 `pxvol` 的 PortworxVolume 存在。 -{{< /caution >}} - - - -更多详情和示例可以在[这里](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md)找到。 - -### quobyte {#quobyte} +### quobyte -`quobyte` 卷允许将现有的 [Quobyte](https://www.quobyte.com) 卷挂载到您的 Pod 中。 +`quobyte` 卷允许将现有的 [Quobyte](https://www.quobyte.com) 卷挂载到你的 Pod 中。 -{{< caution >}} -在使用 Quobyte 卷之前，您首先要进行安装并创建好卷。 -{{< /caution >}} +{{< note >}} +在使用 Quobyte 卷之前，你首先要进行安装 Quobyte 并创建好卷。 +{{< /note >}} -Quobyte 支持{{< glossary_tooltip text="容器存储接口" term_id="csi" >}}。 +Quobyte 支持{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}}。 推荐使用 CSI 插件以在 Kubernetes 中使用 Quobyte 卷。 -Quobyte 的 GitHub 项目具有[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi)以及使用示例来部署 CSI 的 Quobyte。 +Quobyte 的 GitHub 项目包含以 CSI 形式部署 Quobyte 的[说明](https://github.com/quobyte/quobyte-csi#quobyte-csi) +及使用示例。 -### rbd {#rbd} +### rbd -`rbd` 卷允许将 [Rados 块设备](https://ceph.com/docs/master/rbd/rbd/) 卷挂载到您的 Pod 中. -不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`rbd` 卷的内容在删除 Pod 时会被保存，卷只是被卸载掉了。 -这意味着 `rbd` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间"传递"。 +`rbd` 卷允许将 [Rados 块设备](https://ceph.com/docs/master/rbd/rbd/) 卷挂载到你的 Pod 中. +不像 `emptyDir` 那样会在删除 Pod 的同时也会被删除，`rbd` 卷的内容在删除 Pod 时 +会被保存，卷只是被卸载。 +这意味着 `rbd` 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。 {{< caution >}} -在使用 RBD 之前，您必须安装运行 Ceph。 +在使用 RBD 之前，你必须安装运行 Ceph。 {{< /caution >}} - -RBD 的一个特点是它可以同时被多个用户以只读方式挂载。 -这意味着您可以用数据集预先填充卷，然后根据需要从尽可能多的 Pod 中并行地提供卷。 -不幸的是，RBD 卷只能由单个使用者以读写模式安装——不允许同时写入。 +RBD 的一个特性是它可以同时被多个用户以只读方式挂载。 +这意味着你可以用数据集预先填充卷，然后根据需要在尽可能多的 Pod 中并行地使用卷。 +不幸的是，RBD 卷只能由单个使用者以读写模式安装。不允许同时写入。 更多详情请参考 [RBD 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)。 -### scaleIO {#scaleio} + +### scaleIO （已弃用） {#scaleio} - ScaleIO 是基于软件的存储平台，可以使用现有硬件来创建可伸缩的、共享的而且是网络化的块存储集群。 -`scaleIO` 卷插件允许部署的 Pod 访问现有的 ScaleIO 卷（或者它可以动态地为持久卷申领提供新的卷，参见[ScaleIO 持久卷](/docs/concepts/storage/persistent-volumes/#scaleio))。 +`scaleIO` 卷插件允许部署的 Pod 访问现有的 ScaleIO 卷（或者它可以动态地为持久卷申领提供新的卷， +参见 [ScaleIO 持久卷](/zh/docs/concepts/storage/persistent-volumes/#scaleio)）。 -{{< caution >}} -在使用前，您必须有个安装完毕且运行正常的 ScaleIO 集群，并且创建好了存储卷。 -{{< /caution >}} +{{< note >}} +在使用前，你必须有个安装完毕且运行正常的 ScaleIO 集群，并且创建好了存储卷。 +{{< /note >}} - 更多详情，请参考 [ScaleIO 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio)。 -### secret {#secret} +### secret - -`secret` 卷用来给 Pod 传递敏感信息，例如密码。您可以将 secret 存储在 Kubernetes API 服务器上，然后以文件的形式挂在到 Pod 中，无需直接与 Kubernetes 耦合。 -`secret` 卷由 tmpfs（基于 RAM 的文件系统）提供存储，因此它们永远不会被写入非易失性（持久化的）存储器。 +`secret` 卷用来给 Pod 传递敏感信息，例如密码。你可以将 Secret 存储在 Kubernetes +API 服务器上，然后以文件的形式挂在到 Pod 中，无需直接与 Kubernetes 耦合。 +`secret` 卷由 tmpfs（基于 RAM 的文件系统）提供存储，因此它们永远不会被写入非易失性 +（持久化的）存储器。 -{{< caution >}} -使用前您必须在 Kubernetes API 中创建 secret。 -{{< /caution >}} +{{< note >}} +使用前你必须在 Kubernetes API 中创建 secret。 +{{< /note >}} {{< note >}} -容器以 [subPath](#using-subpath) 卷的方式挂载 Secret 时，它将感知不到 Secret 的更新。 +容器以 [subPath](#using-subpath) 卷挂载方式挂载 Secret 时，将感知不到 Secret 的更新。 {{< /note >}} -Secret 的更多详情请参考[这里](/zh/docs/concepts/configuration/secret/)。 +更多详情请参考[配置 Secrets](/zh/docs/concepts/configuration/secret/)。 ### storageOS {#storageos} @@ -1611,7 +1594,7 @@ Secret 的更多详情请参考[这里](/zh/docs/concepts/configuration/secret/) A `storageos` volume allows an existing [StorageOS](https://www.storageos.com) volume to be mounted into your Pod. --> -`storageos` 卷允许将现有的 [StorageOS](https://www.storageos.com) 卷挂载到您的 Pod 中。 +`storageos` 卷允许将现有的 [StorageOS](https://www.storageos.com) 卷挂载到你的 Pod 中。 -StorageOS 在 Kubernetes 环境中以容器的形式运行，这使得应用能够从 Kubernetes 集群中的任何节点访问本地或关联的存储。 -为应对节点失效状况，可以复制数据。 +StorageOS 在 Kubernetes 环境中以容器的形式运行，这使得应用能够从 Kubernetes +集群中的任何节点访问本地的或挂接的存储。为应对节点失效状况，可以复制数据。 若需提高利用率和降低成本，可以考虑瘦配置（Thin Provisioning）和数据压缩。 {{< caution >}} -您必须在每个希望访问 StorageOS 卷的或者将向存储资源池贡献存储容量的节点上运行 StorageOS 容器。 -有关安装说明，请参阅 [StorageOS 文档](https://docs.storageos.com)。 +你必须在每个希望访问 StorageOS 卷的或者将向存储资源池贡献存储容量的节点上运行 +StorageOS 容器。有关安装说明，请参阅 [StorageOS 文档](https://docs.storageos.com)。 {{< /caution >}} ```yaml @@ -1668,26 +1651,27 @@ spec: volumes: - name: redis-data storageos: - # The `redis-vol01` volume must already exist within StorageOS in the `default` namespace. + # `redis-vol01` 卷必须在 StorageOS 中存在，并位于 `default` 名字空间内 volumeName: redis-vol01 fsType: ext4 ``` -更多关于动态供应和持久卷申领的信息请参考 [StorageOS 示例](https://github.com/kubernetes/examples/blob/master/volumes/storageos)。 +关于 StorageOS 的进一步信息、动态供应和持久卷申领等等，请参考 +[StorageOS 示例](https://github.com/kubernetes/examples/blob/master/volumes/storageos)。 ### vsphereVolume {#vspherevolume} {{< note >}} -前提条件：配备了 vSphere 云驱动的 Kubernetes。云驱动的配置方法请参考 +你必须配置 Kubernetes 的 vSphere 云驱动。云驱动的配置方法请参考 [vSphere 使用指南](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)。 {{< /note >}} @@ -1695,7 +1679,7 @@ configuration please refer [vSphere getting started guide](https://vmware.github A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod. The contents of a volume are preserved when it is unmounted. It supports both VMFS and VSAN datastore. --> -`vsphereVolume` 用来将 vSphere VMDK 卷挂载到您的 Pod 中。 +`vsphereVolume` 用来将 vSphere VMDK 卷挂载到你的 Pod 中。 在卸载卷时，卷的内容会被保留。 vSphereVolume 卷类型支持 VMFS 和 VSAN 数据仓库。 @@ -1703,15 +1687,15 @@ vSphereVolume 卷类型支持 VMFS 和 VSAN 数据仓库。 You must create VMDK using one of the following methods before using with Pod. --> {{< caution >}} -在挂载到 Pod 之前，您必须用下列方式之一创建 VMDK。 +在挂载到 Pod 之前，你必须用下列方式之一创建 VMDK。 {{< /caution >}} -#### 创建 VMDK 卷 +#### 创建 VMDK 卷 {#creating-vmdk-volume} 选择下列方式之一创建 VMDK。 @@ -1737,9 +1721,9 @@ vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk -#### vSphere VMDK 配置示例 +#### vSphere VMDK 配置示例 {#vsphere-vmdk-configuration} ```yaml apiVersion: v1 @@ -1755,22 +1739,86 @@ spec: name: test-volume volumes: - name: test-volume - # This VMDK volume must already exist. + # 此 VMDK 卷必须已经存在 vsphereVolume: volumePath: "[DatastoreName] volumes/myDisk" fsType: ext4 ``` -更多示例可以在[这里](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)找到。 +进一步信息可参考[vSphere 卷](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)。 +#### vSphere CSI 迁移 {#vsphere-csi-migration} -Sometimes, it is useful to share one volume for multiple uses in a single Pod. The `volumeMounts.subPath` -property can be used to specify a sub-path inside the referenced volume instead of its root. +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + + +当 `vsphereVolume` 的 `CSIMigration` 特性被启用时，所有插件操作都被从树内插件重定向到 +`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。 +为了使用此功能特性，必须在集群中安装[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)， +并启用 `CSIMigration` 和 `CSIMigrationvSphere` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 + + +此特性还要求 vSphere vCenter/ESXi 的版本至少为 7.0u1，且 HW 版本至少为 +VM version 15。 + +{{< note >}} + +vSphere CSI 驱动不支持内置 `vsphereVolume` 的以下 StorageClass 参数： + +* `diskformat` +* `hostfailurestotolerate` +* `forceprovisioning` +* `cachereservation` +* `diskstripes` +* `objectspacereservation` +* `iopslimit` + + +使用这些参数创建的现有卷将被迁移到 vSphere CSI 驱动，不过使用 vSphere +CSI 驱动所创建的新卷都不会理会这些参数。 + +{{< /note >}} + + +#### vSphere CSI 迁移完成 {#vsphere-csi-migration-complete} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + + +为了避免控制器管理器和 kubelet 加载 `vsphereVolume` 插件，你需要将 +`CSIMigrationVSphereComplete` 特性设置为 `true`。你还必须在所有工作节点上安装 +`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 驱动。 + + ## 使用 subPath {#using-path} @@ -1778,11 +1826,16 @@ property can be used to specify a sub-path inside the referenced volume instead `volumeMounts.subPath` 属性可用于指定所引用的卷内的子路径，而不是其根路径。 -下面是一个使用同一共享卷的、内含 LAMP 栈（Linux Apache Mysql PHP）的 Pod 的示例。 -HTML 内容被映射到卷的 `html` 文件夹，数据库将被存储在卷的 `mysql` 文件夹中： +下面例子展示了如何配置某包含 LAMP 堆栈（Linux Apache MySQL PHP）的 Pod 使用同一共享卷。 +此示例中的 `subPath` 配置不建议在生产环境中使用。 +PHP 应用的代码和相关数据映射到卷的 `html` 文件夹，MySQL 数据库存储在卷的 `mysql` 文件夹中： ```yaml apiVersion: v1 @@ -1813,28 +1866,30 @@ spec: ``` -### 使用带有扩展环境变量的 subPath +### 使用带有扩展环境变量的 subPath {#using-subpath-expanded-environment} -{{< feature-state for_k8s_version="v1.15" state="beta" >}} +{{< feature-state for_k8s_version="v1.17" state="stable" >}} -使用 `subPathExpr` 字段从 Downward API 环境变量构造 `subPath` 目录名。 -在使用此特性之前，必须启用 `VolumeSubpathEnvExpansion` 功能开关。 +使用 `subPathExpr` 字段可以基于 Downward API 环境变量来构造 `subPath` 目录名。 `subPath` 和 `subPathExpr` 属性是互斥的。 -在这个示例中，Pod 基于 Downward API 中的 Pod 名称，使用 `subPathExpr` -在 hostPath 卷 `/var/log/pods` 中创建目录 `pod1`。 -主机目录 `/var/log/pods/pod1` 挂载到了容器的 `/logs` 中。 +在这个示例中，Pod 使用 `subPathExpr` 来 hostPath 卷 `/var/log/pods` 中创建目录 `pod1`。 +`hostPath` 卷采用来自 `downwardAPI` 的 Pod 名称生成目录名。 +宿主目录 `/var/log/pods/pod1` 被挂载到容器的 `/logs` 中。 ```yaml apiVersion: v1 @@ -1872,44 +1927,43 @@ medium of the filesystem holding the kubelet root dir (typically `hostPath` volume can consume, and no isolation between Containers or between Pods. --> -## 资源 +## 资源 {#resources} -`emptyDir` 卷的存储介质（磁盘、SSD 等）是由保存 kubelet 根目录（通常是 `/var/lib/kubelet`）的文件系统的介质确定。 -`emptyDir` 卷或者 `hostPath` 卷可以消耗的空间没有限制，容器之间或 Pod 之间也没有隔离。 +`emptyDir` 卷的存储介质（磁盘、SSD 等）是由保存 kubelet 数据的根目录 +（通常是 `/var/lib/kubelet`）的文件系统的介质确定。 +Kubernetes 对 `emptyDir` 卷或者 `hostPath` 卷可以消耗的空间没有限制， +容器之间或 Pod 之间也没有隔离。 -将来，我们希望 `emptyDir` 卷和 `hostPath` 卷能够使用 -[resource](/zh/docs/concepts/configuration/manage-resources-containers/) -规约来请求一定量的空间， -并且能够为具有多种介质类型的集群选择要使用的介质类型。 +要了解如何使用资源规约来请求空间，可参考 +[如何管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。 + +## 树外（Out-of-Tree）卷插件 {#out-of-tree-volume-plugins} -## Out-of-Tree 卷插件 - -Out-of-Tree 卷插件包括容器存储接口（CSI）和 FlexVolume。 +Out-of-Tree 卷插件包括 +{{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} (CSI) +和 FlexVolume。 它们使存储供应商能够创建自定义存储插件，而无需将它们添加到 Kubernetes 代码仓库。 - -在引入 CSI 和 FlexVolume 之前，所有卷插件（如上面列出的卷类型）都是 "in-tree" 的， -这意味着它们是与 Kubernetes 的核心组件一同构建、链接、编译和交付的，并且这些插件都扩展了 Kubernetes 的核心 API。 +以前，所有卷插件（如上面列出的卷类型）都是“树内（In-Tree）”的。 +“树内”插件是与 Kubernetes 的核心组件一同构建、链接、编译和交付的。 这意味着向 Kubernetes 添加新的存储系统（卷插件）需要将代码合并到 Kubernetes 核心代码库中。 +CSI 和 FlexVolume 都允许独立于 Kubernetes 代码库开发卷插件，并作为扩展部署 +（安装）在 Kubernetes 集群上。 -CSI 和 FlexVolume 都允许独立于 Kubernetes 代码库开发卷插件，并作为扩展部署（安装）在 Kubernetes 集群上。 - -对于希望创建 out-of-tree 卷插件的存储供应商，请参考[这个 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)。 +对于希望创建树外（Out-Of-Tree）卷插件的存储供应商，请参考 +[卷插件常见问题](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)。 ### CSI -{{< feature-state for_k8s_version="v1.10" state="beta" >}} - - [容器存储接口](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) 为容器编排系统（如 Kubernetes）定义标准接口，以将任意存储系统暴露给它们的容器工作负载。 @@ -1944,17 +1996,14 @@ Please read the [CSI design proposal](https://github.com/kubernetes/community/bl CSI support was introduced as alpha in Kubernetes v1.9, moved to beta in Kubernetes v1.10, and is GA in Kubernetes v1.13. --> - 更多详情请阅读 [CSI 设计方案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)。 -CSI 的支持在 Kubernetes v1.9 中作为 alpha 特性引入，在 Kubernetes v1.10 中转为 beta 特性，并在 Kubernetes v1.13 正式 GA。 - {{< note >}} -Kubernetes v1.13中不支持 CSI 规范版本0.2和0.3，并将在以后的版本中删除。 +Kubernetes v1.13 废弃了对 CSI 规范版本 0.2 和 0.3 的支持，并将在以后的版本中删除。 {{< /note >}} {{< note >}} -CSI驱动程序可能并非在所有Kubernetes版本中都兼容。 -请查看特定CSI驱动程序的文档，以获取每个 Kubernetes 版本所支持的部署步骤以及兼容性列表。 +CSI 驱动可能并非兼容所有的 Kubernetes 版本。 +请查看特定 CSI 驱动的文档，以了解各个 Kubernetes 版本所支持的部署步骤以及兼容性列表。 {{< /note >}} +一旦在 Kubernetes 集群上部署了 CSI 兼容卷驱动程序，用户就可以使用 `csi` 卷类型来 +挂接、挂载 CSI 驱动所提供的卷。 + +`csi` 卷可以在 Pod 中以三种方式使用： + +* 通过 PersistentVolumeClaim(#persistentvolumeclaim) 对象引用 +* 使用[一般性的临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) + （Alpha 特性） +* 使用 [CSI 临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)， + 前提是驱动支持这种用法（Beta 特性） + + - -一旦在 Kubernetes 集群上部署了 CSI 兼容卷驱动程序，用户就可以使用 `csi` 卷类型来关联、挂载 CSI 驱动程序暴露出来的卷。 - -`csi` 卷类型不支持来自 Pod 的直接引用，只能通过 `PersistentVolumeClaim` 对象在 Pod 中引用。 - 存储管理员可以使用以下字段来配置 CSI 持久卷： - -- `driver`：指定要使用的卷驱动程序名称的字符串值。 - 这个值必须与 CSI 驱动程序在 `GetPluginInfoResponse` 中返回的值相对应；该接口定义在 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)中。 - Kubernetes 使用所给的值来标识要调用的 CSI 驱动程序；CSI 驱动程序也使用该值来辨识哪些 PV 对象属于该 CSI 驱动程序。 +- `driver`：指定要使用的卷驱动名称的字符串值。 + 这个值必须与 CSI 驱动程序在 `GetPluginInfoResponse` 中返回的值相对应； + 该接口定义在 [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)中。 + Kubernetes 使用所给的值来标识要调用的 CSI 驱动程序；CSI 驱动程序也使用该值来辨识 + 哪些 PV 对象属于该 CSI 驱动程序。 - `volumeHandle`：唯一标识卷的字符串值。 - 该值必须与CSI 驱动程序在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应；接口定义在 [CSI spec](https://github.com/container-storageinterface/spec/blob/master/spec.md#createvolume) 中。 + 该值必须与 CSI 驱动在 `CreateVolumeResponse` 的 `volume_id` 字段中返回的值相对应； + 接口定义在 [CSI spec](https://github.com/container-storageinterface/spec/blob/master/spec.md#createvolume) 中。 在所有对 CSI 卷驱动程序的调用中，引用该 CSI 卷时都使用此值作为 `volume_id` 参数。 -- `readOnly`：一个可选的布尔值，指示通过 `ControllerPublished` 关联该卷时是否设置该卷为只读。 - 默认值是 false。 - 该值通过 `ControllerPublishVolumeRequest` 中的 `readonly` 字段传递给 CSI 驱动程序。 +- `readOnly`：一个可选的布尔值，指示通过 `ControllerPublished` 关联该卷时是否设置 + 该卷为只读。默认值是 false。 + 该值通过 `ControllerPublishVolumeRequest` 中的 `readonly` 字段传递给 CSI 驱动。 - - `volumeAttributes`：一个字符串到字符串的映射表，用来设置卷的静态属性。 - 该映射必须与 CSI 驱动程序返回的 `CreateVolumeResponse` 中的 `volume.attributes` 字段的映射相对应；[CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中有相应的定义。 - 该映射通过`ControllerPublishVolumeRequest`、`NodeStageVolumeRequest`、和 `NodePublishVolumeRequest` 中的 `volume_attributes` 字段传递给 CSI 驱动。 + 该映射必须与 CSI 驱动程序返回的 `CreateVolumeResponse` 中的 `volume.attributes` + 字段的映射相对应； + [CSI 规范](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) 中有相应的定义。 + 该映射通过`ControllerPublishVolumeRequest`、`NodeStageVolumeRequest`、和 + `NodePublishVolumeRequest` 中的 `volume_attributes` 字段传递给 CSI 驱动。 -- `controllerPublishSecretRef`：对包含敏感信息的 secret 对象的引用；该敏感信息会被传递给 CSI 驱动来完成 CSI `ControllerPublishVolume` 和 `ControllerUnpublishVolume` 调用。 - 此字段是可选的；在不需要 secret 时可以是空的。 - 如果 secret 对象包含多个 secret，则所有的 secret 都会被传递。 +- `controllerPublishSecretRef`：对包含敏感信息的 Secret 对象的引用； + 该敏感信息会被传递给 CSI 驱动来完成 CSI `ControllerPublishVolume` 和 + `ControllerUnpublishVolume` 调用。 + 此字段是可选的；在不需要 Secret 时可以是空的。 + 如果 Secret 对象包含多个 Secret 条目，则所有的 Secret 条目都会被传递。 -- `nodeStageSecretRef`：对包含敏感信息的 secret 对象的引用，以传递给 CSI 驱动来完成 CSI `NodeStageVolume` 调用。 - 此字段是可选的，如果不需要 secret，则可能是空的。 - 如果 secret 对象包含多个 secret，则传递所有 secret。 +- `nodeStageSecretRef`：对包含敏感信息的 Secret 对象的引用。 + 该信息会传递给 CSI 驱动来完成 CSI `NodeStageVolume` 调用。 + 此字段是可选的，如果不需要 Secret，则可能是空的。 + 如果 Secret 对象包含多个 Secret 条目，则传递所有 Secret 条目。 -- `nodePublishSecretRef`：对包含敏感信息的 secret 对象的引用，以传递给 CSI 驱动来完成 CSI ``NodePublishVolume` 调用。 - 此字段是可选的，如果不需要 secret，则可能是空的。 - 如果 secret 对象包含多个 secret，则传递所有 secret。 +- `nodePublishSecretRef`：对包含敏感信息的 Secret 对象的引用。 + 该信息传递给 CSI 驱动来完成 CSI `NodePublishVolume` 调用。 + 此字段是可选的，如果不需要 Secret，则可能是空的。 + 如果 Secret 对象包含多个 Secret 条目，则传递所有 Secret 条目。 -#### CSI 原始块卷支持 +#### CSI 原始块卷支持 {#csi-raw-block-volume-support} -{{< feature-state for_k8s_version="v1.14" state="beta" >}} +{{< feature-state for_k8s_version="v1.18" state="stable" >}} - -从 1.11 版本开始，CSI 引入了对原始块卷的支持。该特性依赖于在 Kubernetes 的之前版本中引入的原始块卷（Raw Block Volume）功能。 -该特性将使具有外部 CSI 驱动程序的供应商能够在 Kubernetes 工作负载中实现原始块卷支持。 +具有外部 CSI 驱动程序的供应商能够在 Kubernetes 工作负载中实现原始块卷支持。 - -CSI块卷支持功能已启用，但默认情况下启用。必须为此功能启用的两个功能是“ BlockVolume”和“ CSIBlockVolume”。 - -``` ---feature-gates=BlockVolume=true,CSIBlockVolume=true -``` - -学习怎样[安装您的带有块卷支持的 PV/PVC](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)。 +你可以和以前一样，安装自己的 +[带有原始块卷支持的 PV/PVC](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)， +采用 CSI 对此过程没有影响。 - -#### CSI临时卷 +#### CSI 临时卷 {#csi-ephemeral-volumes} {{< feature-state for_k8s_version="v1.16" state="beta" >}} - -此功能使 CSI 卷可以直接嵌入 Pod 规范中，而不是 PersistentVolume 中。 以这种方式指定的卷是临时的，不会在 Pod 重新启动后持续存在。 - -实例： - -```yaml -kind: Pod -apiVersion: v1 -metadata: - name: my-csi-app -spec: - containers: - - name: my-frontend - image: busybox - 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 -``` +你可以直接在 Pod 规约中配置 CSI 卷。采用这种方式配置的卷都是临时卷， +无法在 Pod 重新启动后继续存在。 +进一步的信息可参阅[临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)。 - -此功能需要启用 CSIInlineVolume 功能门。 从Kubernetes 1.16开始默认启用它。 - -CSI 临时卷仅由一部分 CSI 驱动程序支持。 请在[此处](https://kubernetes-csi.github.io/docs/drivers.html)查看 CSI 驱动程序列表。 - - +有关如何开发 CSI 驱动的更多信息，请参考 [kubernetes-csi 文档](https://kubernetes-csi.github.io/docs/)。 + + +#### 从树内插件迁移到 CSI 驱动程序 {#migrating-to-csi-drivers-from-in-tree-plugins} -# 开发人员资源 -有关如何开发 CSI 驱动程序的更多信息，请参考[kubernetes-csi文档](https://kubernetes-csi.github.io/docs/) - -#### 从 in-tree 插件迁移到 CSI 驱动程序 - -{{< feature-state for_k8s_version="v1.14" state="alpha" >}} +{{< feature-state for_k8s_version="v1.17" state="beta" >}} +启用 `CSIMigration` 功能后，针对现有树内插件的操作会被重定向到相应的 CSI 插件 +（应已安装和配置）。 +因此，操作员在过渡到取代树内插件的 CSI 驱动时，无需对现有存储类、PV 或 PVC +（指树内插件）进行任何配置更改。 -启用 CSI 迁移功能后，会将针对现有 in-tree 插件的操作定向到相应的 CSI 插件（应安装和配置）。 -该功能实现了必要的转换逻辑和填充以无缝方式重新路由操作。 因此，操作员在过渡到取代树内插件的CSI驱动程序时，无需对现有存储类，PV 或 PVC（指 in-tree 插件)进行任何配置更改。 -在 Alpha 状态下，受支持的操作和功能包括供应/删除，附加/分离，安装/卸载和调整卷大小。 -上面的 "卷类型" 部分列出了支持 CSI 迁移并已实现相应 CSI 驱动程序的树内插件。 +所支持的操作和功能包括：配备（Provisioning）/删除、挂接（Attach）/解挂（Detach）、 +挂载（Mount）/卸载（Unmount）和调整卷大小。 -### FlexVolume {#flexVolume} +上面的[卷类型](#volume-types)节列出了支持 `CSIMigration` 并已实现相应 CSI +驱动程序的树内插件。 + +### flexVolume -FlexVolume 是一个自 1.2 版本（在 CSI 之前）以来在 Kubernetes 中一直存在的 out-of-tree 插件接口。 +FlexVolume 是一个自 1.2 版本（在 CSI 之前）以来在 Kubernetes 中一直存在的树外插件接口。 它使用基于 exec 的模型来与驱动程序对接。 -用户必须在每个节点（在某些情况下是主节点）上的预定义卷插件路径中安装 FlexVolume 驱动程序可执行文件。 +用户必须在每个节点（在某些情况下是主控节点）上的预定义卷插件路径中安装 +FlexVolume 驱动程序可执行文件。 -Pod 通过 `flexvolume` in-tree 插件与 Flexvolume 驱动程序交互。 -更多详情请参考[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)。 +Pod 通过 `flexvolume` 树内插件与 Flexvolume 驱动程序交互。 +更多详情请参考 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 示例。 +## 挂载卷的传播 {#mount-propagation} -## 挂载卷的传播 +挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器， +甚至共享到同一节点上的其他 Pod。 -挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器，甚至共享到同一节点上的其他 Pod。 - -卷的挂载传播特性由 Container.volumeMounts 中的 `mountPropagation` 字段控制。 +卷的挂载传播特性由 `Container.volumeMounts` 中的 `mountPropagation` 字段控制。 它的值包括： - * `None` - 此卷挂载将不会感知到主机后续在此卷或其任何子目录上执行的挂载变化。 +* `None` - 此卷挂载将不会感知到主机后续在此卷或其任何子目录上执行的挂载变化。 类似的，容器所创建的卷挂载在主机上是不可见的。这是默认模式。 - 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)中描述的 `private` 挂载传播选项。 + + 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + 中描述的 `private` 挂载传播选项。 - * `HostToContainer` - 此卷挂载将会感知到主机后续针对此卷或其任何子目录的挂载操作。 +* `HostToContainer` - 此卷挂载将会感知到主机后续针对此卷或其任何子目录的挂载操作。 换句话说，如果主机在此挂载卷中挂载任何内容，容器将能看到它被挂载在那里。 - 类似的，配置了 `Bidirectional` 挂载传播选项的 Pod 如果在同一卷上挂载了内容，挂载传播设置为 `HostToContainer` 的容器都将能看到这一变化。 + 类似的，配置了 `Bidirectional` 挂载传播选项的 Pod 如果在同一卷上挂载了内容， + 挂载传播设置为 `HostToContainer` 的容器都将能看到这一变化。 - 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 中描述的 `rslave` 挂载传播选项。 + 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + 中描述的 `rslave` 挂载传播选项。 - - * `Bidirectional` - 这种卷挂载和 `HostToContainer` 挂载表现相同。 - - 另外，容器创建的卷挂载将被传播回至主机和使用同一卷的所有 Pod 的所有容器。 - - 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 中描述的 `rshared` 挂载传播选项。 - - -{{< caution >}} -`Bidirectional` 形式的挂载传播可能比较危险。 -它可以破坏主机操作系统，因此它只被允许在特权容器中使用。 -强烈建议您熟悉 Linux 内核行为。 -此外，由 Pod 中的容器创建的任何卷挂载必须在终止时由容器销毁（卸载）。 -{{< /caution >}} +* `Bidirectional` - 这种卷挂载和 `HostToContainer` 挂载表现相同。 + 另外，容器创建的卷挂载将被传播回至主机和使用同一卷的所有 Pod 的所有容器。 + + 该模式等同于 [Linux 内核文档](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + 中描述的 `rshared` 挂载传播选项。 + + + {{< warning >}} + `Bidirectional` 形式的挂载传播可能比较危险。 + 它可以破坏主机操作系统，因此它只被允许在特权容器中使用。 + 强烈建议你熟悉 Linux 内核行为。 + 此外，由 Pod 中的容器创建的任何卷挂载必须在终止时由容器销毁（卸载）。 + {{< /warning >}} -### 配置 +### 配置 {#configuration} -在某些部署环境中，挂载传播正常工作前，必须在 Docker 中正确配置挂载共享（mount share），如下所示。 +在某些部署环境中，挂载传播正常工作前，必须在 Docker 中正确配置挂载共享（mount share）， +如下所示。 -编辑您的 Docker `systemd` 服务文件，按下面的方法设置 `MountFlags`： +编辑你的 Docker `systemd` 服务文件，按下面的方法设置 `MountFlags`： ```shell MountFlags=shared ``` + @@ -2330,14 +2364,12 @@ sudo systemctl daemon-reload sudo systemctl restart docker ``` - - ## {{% heading "whatsnext" %}} -* 参考[使用持久卷部署 WordPress 和 MySQL](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。 +参考[使用持久卷部署 WordPress 和 MySQL](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。