文章目录卷类型configmapemptydirhostpathnfspersistentvolumeclaimsecret持续卷模式访问模式类回收策略persistentvolumeclaims临时卷临时卷类型
缠上
kubernetes支持许多类型的卷，Pod可以同时使用任意数量的卷类型。
卷分为“临时卷”(ephemeral volume )和“永久卷”(persistent volume )。 临时卷类型的生命周期与Pod相同，持续卷可以独立于Pod的生命周期而存在，且长于Pod的生存期。 如果Pod不再存在，Kubernetes会销毁临时卷，但不会销毁永久卷。
卷的中心是一个目录，数据可能存储在Pod中容器可以访问的目录中。 使用的特定卷类型决定了目录的形成方式、使用什么介质存储数据以及存储在目录中的内容。
卷类型configMap configMap卷提供了将配置数据注入Pod的方法。 存储在ConfigMap对象中的数据由ConfigMap类型的卷引用，并由在Pod上运行的容器化APP应用程序使用。
当引用configMap对象时，可以在volume中按其名称进行引用。 您可以定制用于ConfigMap中特定条目的路径。 以下配置说明如何将名为log-config的ConfigMap挂载到名为configmap-Pod的pod上。
API version : v1 kind : pod元数据： name : config map-pod spec : containers :-name : testimage 3360 busyboxvolllon nt path :/etc/config volumes :-name : config-volconfigmap : name : log-config items 3360-key : log _ ley log_level条目中存储的所有内容都将挂载在Pod的/etc/config/log_level路径下。 请注意，该路径来自卷的mountPath和与log_level密钥相对应的path。
如果将emptyDirPod分配给节点，则会创建emptydir卷，并且该卷将在节点上运行pod时继续存在。 正如其名称所示，卷最初是空的。 Pod中的容器装载emptyDir卷的路径可以相同也可以不同，但这些容器可以读写emptyDir卷中的相同文件。 如果由于某种原因从节点中删除了Pod，则emptyDir卷中的数据也会永久删除。
emptyDir的几个用途：
缓存区域，如基于磁盘的合并排序。 为耗时的计算任务提供检查点，以便任务可以从崩溃前的状态重新开始执行。 当Web服务器容器服务数据时，保存内容管理器容器获取的文件。 通过将emptyDir.medium字段设置为“Memory”，可以指示Kubernetes装载基于ram的文件系统(tmpfs )。 请注意，tmpfs非常快，但与磁盘相同。 节点重新启动时会清除tmpfs，所有写入的文件都会计入允许的内存消耗，并受允许的内存限制约束。
配置示例：
API version 3360 v1 kind : pod metadata : name : test-PD spec : containers :-image 3360 k8s.gcr.io/test-web服务器name : test-containervolumemounts :-mount path :/cachename : cache-volume volumes :-name 33: hostpathhostpath卷将主机节点文件系统上的文件或目录装载到Pod上。
HostPath卷存在许多安全风险，建议您尽可能不要使用HostPath。 如果需要使用HostPath卷，则必须将其限制为所需的文件或目录，并以只读方式装载。
配置示例：
API version 3360 v1 kind : pod metadata : name : test-PD spec : containers :-image 3360 k8s.gcr.io/test-web servername : test-containervolumemounts :-mount path :/test-PD name 3360 test-volume volumes 3360-name
: /data # 此字段为可选 type: Directory nfsnfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 与 emptyDir不同的是， emptyDir会在删除 Pod 的同时也会被删除，nfs 卷的内容在删除 Pod 时会被保存，此时卷只是被卸载。 这意味着 nfs 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。
persistentVolumeClaimpersistentVolumeClaim 卷用来将持久卷（PersistentVolume） 挂载到 Pod 中。 PersistentVolumeClaim 是用户在不知道特定云环境细节的情况下"申领"持久存储的一种方法。
secretsecret 卷用来给 Pod 传递敏感信息，例如密码。你可以将 Secret 存储在 Kubernetes API 服务器上，然后以文件的形式挂在到 Pod 中，无需直接与 Kubernetes 耦合。 secret 卷由 tmpfs（基于 RAM 的文件系统）提供存储，因此它们永远不会被写入非易失性 （持久化的）存储器。
其他的卷类型在此不再一一列举，可自行参考[官方文档][https://kubernetes.io/zh/docs/concepts/storage/volumes/#volume-types]
持久卷持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者使用存储类（Storage Class）来动态供应。 持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样，也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。
示例：
apiVersion: v1kind: PersistentVolumemetadata: name: pv0003spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: slow mountOptions: - hard - nfsvers=4.1 nfs: path: /tmp server: 172.17.0.2 卷模式针对 PV 持久卷，Kubernetes 支持两种卷模式（volumeModes）：Filesystem（文件系统） 和 Block（块）。 volumeMode 是一个可选的 API 参数。 如果该参数被省略，默认的卷模式是 Filesystem。
volumeMode 属性设置为 Filesystem 的卷会被 Pod 挂载到某个目录。 如果卷的存储来自某块设备而该设备目前为空，Kuberneretes 会在第一次挂载卷之前在设备上创建文件系统。
你可以将 volumeMode 设置为 Block，以便将卷作为原始块设备来使用。 这类卷以块设备的方式交给 Pod 使用，其上没有任何文件系统。另外，Pod 中运行的应用必须知道如何处理原始块设备。
访问模式ReadWriteOnce：卷可以被一个节点以读写方式挂载。 ReadWriteOnce 访问模式也允许运行在同一节点上的多个 Pod 访问卷。
ReadOnlyMany：卷可以被多个节点以只读方式挂载。
ReadWriteMany：卷可以被多个节点以读写方式挂载。
ReadWriteOncePod：卷可以被单个 Pod 以读写方式挂载。
类每个 PV 可以属于某个类（Class），通过将其 storageClassName 属性设置为某个 StorageClass的名称来指定。 特定类的 PV 卷只能绑定到请求该类存储卷的 PVC 申领。 未设置 storageClassName 的 PV 卷没有类设定，只能绑定到那些没有指定特定 存储类的 PVC 申领。
回收策略回收策略：
Retain – 手动回收Recycle – 基本擦除 (rm -rf /thevolume/*)Delete – 诸如 AWS EBS、GCE PD、Azure Disk 或 OpenStack Cinder 卷这类关联存储资产也被删除目前，仅 NFS 和 HostPath 支持回收（Recycle）。 AWS EBS、GCE PD、Azure Disk 和 Cinder 卷都支持删除（Delete）。
PersistentVolumeClaims持久卷申领（PersistentVolumeClaim，PVC）表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式。
示例：
apiVersion: v1kind: PersistentVolumeClaimmetadata: name: myclaimspec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 8Gi storageClassName: slow selector: matchLabels: release: "stable" matchExpressions: - {key: environment, operator: In, values: [dev]}使用pvc作为卷：
apiVersion: v1kind: Podmetadata: name: mypodspec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName: myclaim持久化存储
临时卷有些应用程序需要额外的存储，但并不关心数据在重启后仍然可用，既是否被持久地保存。 例如，缓存服务经常受限于内存大小，将不常用的数据转移到比内存慢、但对总体性能的影响很小的存储中。
另有些应用程序需要以文件形式注入的只读数据，比如配置数据或密钥。
临时卷（Ephemeral Volumes） 就是为此类用例设计的。因为卷会遵从 Pod 的生命周期，与 Pod 一起创建和删除， 所以停止和重新启动 Pod 时，不会受持久卷在何处可用的限制。
临时卷在 Pod 规范中以内联方式定义，这简化了应用程序的部署和管理。
临时卷类型Kubernetes 为了不同的目的，支持几种不同类型的临时卷：
emptyDir： Pod 启动时为空，存储空间来自本地的 kubelet 根目录（通常是根磁盘）或内存configMap、 downwardAPI、 secret： 将不同类型的 Kubernetes 数据注入到 Pod 中CSI 临时卷： 类似于前面的卷类型，但由专门支持此特性的指定 CSI 驱动程序提供通用临时卷： 它可以由所有支持持久卷的存储驱动程序提供emptyDir、configMap、downwardAPI、secret 是作为 本地临时存储提供的。它们由各个节点上的 kubelet 管理。
CSI 临时卷（CSI ephemeral volumes）必须由第三方 CSI 存储驱动程序提供。从概念上讲，CSI 临时卷类似于 configMap、downwardAPI 和 secret 类型的卷： 其存储在每个节点本地管理，并在将 Pod 调度到节点后与其他本地资源一起创建。 在这个阶段，Kubernetes 没有重新调度 Pods 的概念。卷创建不太可能失败，否则 Pod 启动将会受阻。 特别是，这些卷不支持感知存储容量的 Pod 调度。 它们目前也没包括在 Pod 的存储资源使用限制中，因为 kubelet 只能对它自己管理的存储强制执行。
通用临时卷（Generic ephemeral volumes）可以由第三方 CSI 存储驱动程序提供，也可以由支持动态配置的任何其他存储驱动程序提供。 一些专门为 CSI 临时卷编写的 CSI 驱动程序，不支持动态供应：因此这些驱动程序不能用于通用临时卷。通用临时卷类似于 emptyDir 卷，因为它为每个 Pod 提供临时数据存放目录， 在最初制备完毕时一般为空。不过通用临时卷也有一些额外的功能特性：
存储可以是本地的，也可以是网络连接的。卷可以有固定的大小，pod不能超量使用。卷可能有一些初始数据，这取决于驱动程序和参数。当驱动程序支持，卷上的典型操作将被支持，包括 （快照、 克隆、 调整大小和 存储容量跟踪）。