Kubernetes中支持的全部磁盘挂载卷简介发表于 2018年1月26日
7400 字 | 阅读须要 15 分钟
容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet 会重启它，可是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）从新启动。其次，在 Pod 中同时运行多个容器时，这些容器之间一般须要共享文件。Kubernetes 中的 Volume 抽象就很好的解决了这些问题。
本文已归档到kubernetes-handbook。阅读本文前建议您先熟悉 pod。php
背景
Docker 中也有一个 volume 的概念，尽管它稍微宽松一些，管理也不多。在 Docker 中，卷就像是磁盘或是另外一个容器中的一个目录。它的生命周期不受管理，直到最近才有了 local-disk-backed 卷。Docker 如今提供了卷驱动程序，可是功能还很是有限（例如Docker1.7只容许每一个容器使用一个卷驱动，而且没法给卷传递参数）。html
另外一方面，Kubernetes 中的卷有明确的寿命——与封装它的 Pod 相同。因此，卷的生命比 Pod 中的全部容器都长，当这个容器重启时数据仍然得以保存。固然，当 Pod 再也不存在时，卷也将不复存在。也许更重要的是，Kubernetes 支持多种类型的卷，Pod 能够同时使用任意数量的卷。node
卷的核心是目录，可能还包含了一些数据，能够经过 pod 中的容器来访问。该目录是如何造成的、支持该目录的介质以及其内容取决于所使用的特定卷类型。mysql
要使用卷，须要为 pod 指定为卷（spec.volumes 字段）以及将它挂载到容器的位置（spec.containers.volumeMounts 字段）。linux
容器中的进程看到的是由其 Docker 镜像和卷组成的文件系统视图。 Docker 镜像位于文件系统层次结构的根目录，任何卷都被挂载在镜像的指定路径中。卷没法挂载到其余卷上或与其余卷有硬链接。Pod 中的每一个容器都必须独立指定每一个卷的挂载位置。nginx
卷的类型
Kubernetes 支持如下类型的卷：git
awsElasticBlockStoreazureDiskazureFilecephfscsidownwardAPIemptyDirfc(fibre channel)flockergcePersistentDiskgitRepoglusterfshostPathiscsilocalnfspersistentVolumeClaimprojectedportworxVolumequobyterbdscaleIOsecretstorageosvsphereVolume
咱们欢迎额外贡献。github
awsElasticBlockStore
awsElasticBlockStore 卷将Amazon Web Services（AWS）EBS Volume 挂载到您的容器中。与 emptyDir 类型会在删除 Pod 时被清除不一样，EBS 卷的的内容会保留下来，仅仅是被卸载。这意味着 EBS 卷能够预先填充数据，而且能够在数据包之间“切换”数据。web
重要提示：您必须使用 aws ec2 create-volume 或 AWS API 建立 EBS 卷，才能使用它。redis
使用 awsElasticBlockStore 卷时有一些限制：
- 运行 Pod 的节点必须是 AWS EC2 实例
- 这些实例须要与 EBS 卷位于相同的区域和可用区域
- EBS 仅支持卷和 EC2 实例的一对一的挂载
建立 EBS 卷
在 pod 中使用的 EBS 卷以前，您须要先建立它。
aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2
确保区域与您启动集群的区域相匹配（而且检查大小和 EBS 卷类型是否适合您的使用！）
AWS EBS 示例配置
apiVersion: v1 kind: Pod metadata: name: test-ebs spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /test-ebs name: test-volume volumes: - name: test-volume # This AWS EBS volume must already exist. awsElasticBlockStore: volumeID: <volume-id> fsType: ext4
azureDisk
AzureDisk 用于将 Microsoft Azure Data Disk 挂载到 Pod 中。
更多细节能够在这里找到。
azureFile
azureFile 用于将 Microsoft Azure File Volume（SMB 2.1 和 3.0）挂载到 Pod 中。
更多细节能够在这里找到。
cephfs
cephfs 卷容许将现有的 CephFS 卷挂载到您的容器中。不像 emptyDir，当删除 Pod 时被删除，cephfs 卷的内容将被保留，卷仅仅是被卸载。这意味着 CephFS 卷能够预先填充数据，而且能够在数据包之间“切换”数据。 CephFS 能够被多个写设备同时挂载。
重要提示：您必须先拥有本身的 Ceph 服务器，而后才能使用它。
有关更多详细信息，请参见CephFS示例。
csi
CSI 表明容器存储接口，CSI 试图创建一个行业标准接口的规范，借助 CSI 容器编排系统（CO）能够将任意存储系统暴露给本身的容器工做负载。有关详细信息，请查看设计方案。
csi 卷类型是一种 in-tree 的 CSI 卷插件，用于 Pod 与在同一节点上运行的外部 CSI 卷驱动程序交互。部署 CSI 兼容卷驱动后，用户可使用 csi 做为卷类型来挂载驱动提供的存储。
CSI 持久化卷支持是在 Kubernetes v1.9 中引入的，做为一个 alpha 特性，必须由集群管理员明确启用。换句话说，集群管理员须要在 apiserver、controller-manager 和 kubelet 组件的 “--feature-gates =” 标志中加上 “CSIPersistentVolume = true”。
CSI 持久化卷具备如下字段可供用户指定：
driver：一个字符串值，指定要使用的卷驱动程序的名称。必须少于 63 个字符，并以一个字符开头。驱动程序名称能够包含 “.”、“-”、“_” 或数字。volumeHandle：一个字符串值，惟一标识从 CSI 卷插件的CreateVolume调用返回的卷名。随后在卷驱动程序的全部后续调用中使用卷句柄来引用该卷。readOnly：一个可选的布尔值，指示卷是否被发布为只读。默认是 false。
downwardAPI
downwardAPI 卷用于使向下 API 数据（downward API data）对应用程序可用。它挂载一个目录，并将请求的数据写入纯文本文件。
参考 downwardAPI 卷示例查看详细信息。
emptyDir
当 Pod 被分配给节点时，首先建立 emptyDir 卷，而且只要该 Pod 在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。Pod 中的容器能够读取和写入 emptyDir 卷中的相同文件，尽管该卷能够挂载到每一个容器中的相同或不一样路径上。当出于任何缘由从节点中删除 Pod 时，emptyDir 中的数据将被永久删除。
注意：容器崩溃不会从节点中移除 pod，所以 emptyDir 卷中的数据在容器崩溃时是安全的。
emptyDir 的用法有：
- 暂存空间，例如用于基于磁盘的合并排序
- 用做长时间计算崩溃恢复时的检查点
- Web服务器容器提供数据时，保存内容管理器容器提取的文件
Pod 示例
apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: {}
fc (fibre channel)
fc 卷容许将现有的 fc 卷挂载到 pod 中。您可使用卷配置中的 targetWWN 参数指定单个或多个目标全球通用名称（World Wide Name）。若是指定了多个 WWN，则 targetWWN 指望这些 WWN 来自多路径链接。
重要提示：您必须配置 FC SAN 区域划分，并预先将这些 LUN（卷）分配并屏蔽到目标 WWN，以便 Kubernetes 主机能够访问它们。
参考 FC 示例获取详细信息。
flocker
Flocker 是一款开源的集群容器数据卷管理器。它提供了由各类存储后端支持的数据卷的管理和编排。
flocker 容许将 Flocker 数据集挂载到 pod 中。若是数据集在 Flocker 中不存在，则须要先使用 Flocker CLI 或使用 Flocker API 建立数据集。若是数据集已经存在，它将被 Flocker 从新链接到 pod 被调度的节点上。这意味着数据能够根据须要在数据包之间“切换”。
重要提示：您必须先运行本身的 Flocker 安装程序才能使用它。
参考 Flocker 示例获取更多详细信息。
gcePersistentDisk
gcePersistentDisk 卷将 Google Compute Engine（GCE）Persistent Disk 挂载到您的容器中。与删除 Pod 时删除的 emptyDir 不一样，PD 的内容被保留，只是卸载了卷。这意味着 PD 能够预先填充数据，而且数据能够在 Pod 之间“切换”。
重要提示：您必须先使用 gcloud 或 GCE API 或 UI 建立一个 PD，而后才能使用它。
使用 gcePersistentDisk 时有一些限制：
- 运行 Pod 的节点必须是 GCE 虚拟机
- 那些虚拟机须要在与 PD 同样在 GCE 项目和区域中
PD 的一个特色是它们能够同时被多个用户以只读方式挂载。这意味着您能够预先使用您的数据集填充 PD，而后根据须要给多个 Pod 中并行提供。不幸的是，只能由单个消费者以读写模式挂载 PD，而不容许同时写入。 在由 ReplicationController 控制的 pod 上使用 PD 将会失败，除非 PD 是只读的或者副本数是 0 或 1。
建立 PD
在您在 pod 中使用 GCE PD 以前，须要先建立它。
gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk
Pod 示例
apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /test-pd name: test-volume volumes: - name: test-volume # This GCE PD must already exist. gcePersistentDisk: pdName: my-data-disk fsType: ext4
gitRepo
gitRepo 卷是一个能够演示卷插件功能的示例。它会挂载一个空目录并将 git 存储库克隆到您的容器中。未来，这样的卷可能会转移到一个更加分离的模型，而不是为每一个这样的用例扩展 Kubernetes API。
下面是 gitRepo 卷示例：
apiVersion: v1 kind: Pod metadata: name: server spec: containers: - image: nginx name: nginx volumeMounts: - mountPath: /mypath name: git-volume volumes: - name: git-volume gitRepo: repository: "git@somewhere:me/my-git-repository.git" revision: "22f1d8406d464b0c0874075539c1f2e96c253775"
glusterfs
glusterfs 卷容许将 Glusterfs（一个开放源代码的网络文件系统）卷挂载到您的集群中。与删除 Pod 时删除的 emptyDir 不一样，glusterfs 卷的内容将被保留，而卷仅仅被卸载。这意味着 glusterfs 卷能够预先填充数据，而且能够在数据包之间“切换”数据。 GlusterFS 能够同时由多个写入挂载。
重要提示：您必须先自行安装 GlusterFS，才能使用它。
有关更多详细信息，请参阅 GlusterFS 示例。
hostPath
hostPath 卷将主机节点的文件系统中的文件或目录挂载到集群中。该功能大多数 Pod 都用不到，但它为某些应用程序提供了一个强大的解决方法。
例如，hostPath 的用途以下：
- 运行须要访问 Docker 内部的容器；使用
/var/lib/docker的hostPath - 在容器中运行 cAdvisor；使用
/dev/cgroups的hostPath - 容许 pod 指定给定的 hostPath 是否应该在 pod 运行以前存在，是否应该建立，以及它应该以什么形式存在
除了所需的 path 属性以外，用户还能够为 hostPath 卷指定 type。
type 字段支持如下值：
| 值 | 行为 |
|---|---|
| 空字符串（默认）用于向后兼容，这意味着在挂载 hostPath 卷以前不会执行任何检查。 | |
DirectoryOrCreate |
若是在给定的路径上没有任何东西存在，那么将根据须要在那里建立一个空目录，权限设置为 0755，与 Kubelet 具备相同的组和全部权。 |
Directory |
给定的路径下必须存在目录 |
FileOrCreate |
若是在给定的路径上没有任何东西存在，那么会根据须要建立一个空文件，权限设置为 0644，与 Kubelet 具备相同的组和全部权。 |
File |
给定的路径下必须存在文件 |
Socket |
给定的路径下必须存在 UNIX 套接字 |
CharDevice |
给定的路径下必须存在字符设备 |
BlockDevice |
给定的路径下必须存在块设备 |
使用这种卷类型是请注意，由于：
- 因为每一个节点上的文件都不一样，具备相同配置（例如从 podTemplate 建立的）的 pod 在不一样节点上的行为可能会有所不一样
- 当 Kubernetes 按照计划添加资源感知调度时，将没法考虑
hostPath使用的资源 - 在底层主机上建立的文件或目录只能由 root 写入。您须要在特权容器中以 root 身份运行进程，或修改主机上的文件权限以便写入
hostPath卷
Pod 示例
apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /test-pd name: test-volume volumes: - name: test-volume hostPath: # directory location on host path: /data # this field is optional type: Directory
iscsi
iscsi 卷容许将现有的 iSCSI（SCSI over IP）卷挂载到容器中。不像 emptyDir，删除 Pod 时 iscsi 卷的内容将被保留，卷仅仅是被卸载。这意味着 iscsi 卷能够预先填充数据，而且这些数据能够在 pod 之间“切换”。
重要提示：必须先建立本身的 iSCSI 服务器，而后才能使用它。
iSCSI 的一个特色是它能够同时被多个用户以只读方式安装。这意味着您能够预先使用您的数据集填充卷，而后根据须要向多个额 pod 同时提供。不幸的是，iSCSI 卷只能由单个使用者以读写模式挂载——不容许同时写入。
有关更多详细信息，请参见 iSCSI示例。
local
这个 alpha 功能要求启用 PersistentLocalVolumes feature gate。
注意：从 1.9 开始，VolumeScheduling feature gate 也必须启用。
local 卷表示挂载的本地存储设备，如磁盘、分区或目录。
本地卷只能用做静态建立的 PersistentVolume。
与 HostPath 卷相比，local 卷能够以持久的方式使用，而无需手动将 pod 调度到节点上，由于系统会经过查看 PersistentVolume 上的节点关联性来了解卷的节点约束。
可是，local 卷仍然受底层节点的可用性影响，并不适用于全部应用程序。
如下是使用 local 卷的示例 PersistentVolume 规范：
apiVersion: v1 kind: PersistentVolume metadata: name: example-pv annotations: "volume.alpha.kubernetes.io/node-affinity": '{ "requiredDuringSchedulingIgnoredDuringExecution": { "nodeSelectorTerms": [ { "matchExpressions": [ { "key": "kubernetes.io/hostname", "operator": "In", "values": ["example-node"] } ]} ]} }' spec: capacity: storage: 100Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete storageClassName: local-storage local: path: /mnt/disks/ssd1
注意：本地 PersistentVolume 清理和删除须要手动干预，无外部提供程序。
从 1.9 开始，本地卷绑定能够被延迟，直到经过具备 StorageClass 中的 WaitForFirstConsumer 设置为volumeBindingMode 的 pod 开始调度。请参阅示例。延迟卷绑定可确保卷绑定决策也可使用任何其余节点约束（例如节点资源需求，节点选择器，pod 亲和性和 pod 反亲和性）进行评估。
有关 local 卷类型的详细信息，请参见本地持久化存储用户指南。
nfs
nfs 卷容许将现有的 NFS（网络文件系统）共享挂载到您的容器中。不像 emptyDir，当删除 Pod 时，nfs 卷的内容被保留，卷仅仅是被卸载。这意味着 NFS 卷能够预填充数据，而且能够在 pod 之间“切换”数据。 NFS 能够被多个写入者同时挂载。
重要提示：您必须先拥有本身的 NFS 服务器才能使用它，而后才能使用它。
有关更多详细信息，请参见NFS示例。
persistentVolumeClaim
persistentVolumeClaim 卷用于将 PersistentVolume 挂载到容器中。PersistentVolumes 是在用户不知道特定云环境的细节的状况下“声明”持久化存储（例如 GCE PersistentDisk 或 iSCSI 卷）的一种方式。
有关更多详细信息，请参阅 PersistentVolumes 示例。
projected
projected 卷将几个现有的卷源映射到同一个目录中。
目前，能够映射如下类型的卷来源：
secretdownwardAPIconfigMap
全部来源都必须在与 pod 相同的命名空间中。有关更多详细信息，请参阅 all-in-one 卷设计文档。
带有 secret、downward API 和 configmap 的 pod
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
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。
portworxVolume
portworxVolume 是一个与 Kubernetes 一块儿，以超融合模式运行的弹性块存储层。Portwork 指纹存储在服务器中，基于功能的分层，以及跨多个服务器聚合容量。 Portworx 在虚拟机或裸机 Linux 节点上运行。
portworxVolume 能够经过 Kubernetes 动态建立，也能够在 Kubernetes pod 中预先设置和引用。
如下是一个引用预先配置的 PortworxVolume 的示例 pod：
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: "<fs-type>"
重要提示：在 pod 中使用以前，请确保您有一个名为 pxvol 的现有 PortworxVolume。
更多的细节和例子能够在这里找到。
quobyte
quobyte 卷容许将现有的 Quobyte 卷挂载到容器中。
重要提示：您必须先建立本身的 Quobyte 安装程序，而后才能使用它。
有关更多详细信息，请参见 Quobyte示例。
rbd
rbd 卷容许将 Rados Block Device 卷挂载到容器中。不像 emptyDir，删除 Pod 时 rbd卷的内容被保留，卷仅仅被卸载。这意味着 RBD 卷能够预先填充数据，而且能够在 pod 之间“切换”数据。
重要提示：您必须先自行安装 Ceph，而后才能使用 RBD。
RBD 的一个特色是它能够同时为多个用户以只读方式挂载。这意味着能够预先使用您的数据集填充卷，而后根据须要同时为多个 pod 并行提供。不幸的是，RBD 卷只能由单个用户以读写模式安装——不容许同时写入。
有关更多详细信息，请参阅 RBD示例。
scaleIO
ScaleIO 是一个基于软件的存储平台，可使用现有的硬件来建立可扩展的共享块网络存储集群。scaleIO 卷插件容许已部署的 pod 访问现有的 ScaleIO 卷（或者它能够为持久性卷声明动态调配新卷，请参阅 ScaleIO 持久卷）。
重要提示：您必须有一个已经配置好的 ScaleIO 集群，并和建立的卷一同运行，而后才能使用它们。
如下是使用 ScaleIO 的示例 pod 配置：
apiVersion: v1 kind: Pod metadata: name: pod-0 spec: containers: - image: k8s.gcr.io/test-webserver name: pod-0 volumeMounts: - mountPath: /test-pd name: vol-0 volumes: - name: vol-0 scaleIO: gateway: https://localhost:443/api system: scaleio protectionDomain: sd0 storagePool: sp1 volumeName: vol-0 secretRef: name: sio-secret fsType: xfs
有关更多详细信息，请参阅 ScaleIO 示例。
secret
secret 卷用于将敏感信息（如密码）传递到 pod。您能够将 secret 存储在 Kubernetes API 中，并将它们挂载为文件，以供 Pod 使用，而无需直接链接到 Kubernetes。 secret 卷由 tmpfs（一个 RAM 支持的文件系统）支持，因此它们永远不会写入非易失性存储器。
重要提示：您必须先在 Kubernetes API 中建立一个 secret，而后才能使用它。
Secret 在这里被更详细地描述。
storageOS
storageos 卷容许将现有的 StorageOS 卷挂载到容器中。
StorageOS 在 Kubernetes 环境中以容器方式运行，使本地或附加存储能够从 Kubernetes 集群中的任何节点访问。能够复制数据以防止节点故障。精简配置和压缩能够提升利用率并下降成本。
StorageOS 的核心是为容器提供块存储，能够经过文件系统访问。
StorageOS 容器须要 64 位 Linux，没有额外的依赖关系。可使用免费的开发者许可证。
重要提示：您必须在每一个要访问 StorageOS 卷的节点上运行 StorageOS 容器，或者为该池提供存储容量。相关的安装说明，请参阅 StorageOS文档。
apiVersion: v1 kind: Pod metadata: labels: name: redis role: master name: test-storageos-redis spec: containers: - name: master image: kubernetes/redis:v1 env: - name: MASTER value: "true" ports: - containerPort: 6379 volumeMounts: - mountPath: /redis-master-data name: redis-data volumes: - name: redis-data storageos: # The `redis-vol01` volume must already exist within StorageOS in the `default` namespace. volumeName: redis-vol01 fsType: ext4
有关更多信息，包括动态配置和持久化卷声明，请参阅 StorageOS 示例。
vsphereVolume
先决条件：配置了 vSphere Cloud Provider 的 Kubernetes。有关云提供商的配置，请参阅 vSphere 入门指南。
vsphereVolume 用于将 vSphere VMDK 卷挂载到 Pod 中。卷的内容在卸载时会被保留。支持 VMFS 和 VSAN 数据存储。
重要提示：在 Pod 中使用它以前，您必须使用如下一种方法建立 VMDK。
建立 VMDK 卷
选择如下方法之一来建立 VMDK。
首先进入 ESX，而后使用如下命令建立一个 VMDK：
vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk
使用下列命令建立一个 VMDK：
vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk
vSphere VMDK 示例配置
apiVersion: v1 kind: Pod metadata: name: test-vmdk spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /test-vmdk name: test-volume volumes: - name: test-volume # This VMDK volume must already exist. vsphereVolume: volumePath: "[DatastoreName] volumes/myDisk" fsType: ext4
更多的例子能够在这里找到。
使用 subPath
有时，在单个容器中共享一个卷用于多个用途是有用的。volumeMounts.subPath 属性可用于在引用的卷内而不是其根目录中指定子路径。
下面是一个使用单个共享卷的 LAMP 堆栈（Linux Apache Mysql PHP）的示例。 HTML 内容被映射到它的 html 目录，数据库将被存储在它的 mysql 目录中：
apiVersion: v1 kind: Pod metadata: name: my-lamp-site spec: containers: - name: mysql image: mysql env: - name: MYSQL_ROOT_PASSWORD value: "rootpasswd" volumeMounts: - mountPath: /var/lib/mysql name: site-data subPath: mysql - name: php image: php:7.0-apache volumeMounts: - mountPath: /var/www/html name: site-data subPath: html volumes: - name: site-data persistentVolumeClaim: claimName: my-lamp-site-data
资源
emptyDir 卷的存储介质（磁盘、SSD 等）由保存在 kubelet 根目录的文件系统的介质（一般是 /var/lib/kubelet）决定。 emptyDir 或 hostPath 卷可占用多少空间并无限制，容器之间或 Pod 之间也没有隔离。
在未来，咱们预计 emptyDir 和 hostPath 卷将可以使用 resource 规范请求必定的空间，并选择要使用的介质，适用于具备多种媒体类型的集群。
Out-of-Tree 卷插件
除了以前列出的卷类型以外，存储供应商能够建立自定义插件而不将其添加到 Kubernetes 存储库中。能够经过使用 FlexVolume 插件来实现。
FlexVolume使用户可以将供应商卷挂载到容器中。供应商插件是使用驱动程序实现的，该驱动程序支持由 FlexVolume API定义的一系列卷命令。驱动程序必须安装在每一个节点的预约义卷插件路径中。
更多细节能够在这里找到。
挂载传播
注意：挂载传播是 Kubernetes 1.8 中的一个 alpha 特性，在未来的版本中可能会从新设计甚至删除。
挂载传播容许将由容器挂载的卷共享到同一个 Pod 中的其余容器上，甚至是同一节点上的其余 Pod。
若是禁用 MountPropagation 功能，则不会传播 pod 中的卷挂载。也就是说，容器按照 Linux内核文档中所述的 private 挂载传播运行。
要启用此功能，请在 --feature-gates 命令行选项中指定 MountPropagation = true。启用时，容器的 volumeMounts 字段有一个新的 mountPropagation 子字段。它的值为：
HostToContainer：此卷挂载将接收全部后续挂载到此卷或其任何子目录的挂载。这是 MountPropagation 功能启用时的默认模式。
一样的，若是任何带有 Bidirectional 挂载传播的 pod 挂载到同一个卷上，带有 HostToContainer 挂载传播的容器将会看到它。
该模式等同于Linux内核文档中描述的 rslave 挂载传播。
Bidirectional卷挂载与HostToContainer挂载相同。另外，由容器建立的全部卷挂载将被传播回主机和全部使用相同卷的容器的全部容器。
此模式的一个典型用例是带有 Flex 卷驱动器或须要使用 HostPath 卷在主机上挂载某些内容的 pod。
该模式等同于 Linux内核文档中所述的 rshared 挂载传播。
当心：双向挂载传播多是危险的。它可能会损坏主机操做系统，所以只能在特权容器中使用。强烈建议熟悉 Linux 内核行为。另外，容器在 Pod 中建立的任何卷挂载必须在容器终止时销毁（卸载）。
参考
原文： https://jimmysong.io/posts/kubernetes-volumes-introduction/