概述
Volume是对各种存储资源的抽象、虚拟化。为管理、控制、使用存储资源提供统一接口。Openstack中的volume为虚拟机提供存储，Docker中的volume为容器提供存储。因为在kubernetes中可部署运行最小单位是pod ,所以kubernetes的volume为pod提供存储。当然在部署pod时可以不为其提供volume，pod中的容器使用所在节点的硬盘，能同时读写数据的地方称为可读写层。这种存储是容器级的临时存储，不是pod级。其生命周期与容器相同，如果容器crash后被重启，也就是旧容器被删除而新容器启动，则旧容器的可读写层与容器一起被删除，其上数据丢失。同理如果pod在节点之间迁移调度，容器的可读写层并不会迁移调度。因此，kubernetes需要提供pod级volume，本文中的volume特指kubernetes。
Volume类型
Volume是抽象概念，有很多种具体实现，每种实现各具目的、特点、特性。差不多什么东西都可以当成volume，类型如下：
awsElasticBlockStore
azureDisk
azureFile
cephfs
configMap
csi
downwardAPI
emptyDir
fc (fibre channel)
flocker
gcePersistentDisk
gitRepo (deprecated)
glusterfs
hostPath
iscsi
local
nfs
persistentVolumeClaim
projected
portworxVolume
quobyte
rbd
scaleIO
secret
storageos
vsphereVolume
这里不对以上所有类型一一介绍,只对目前可能会用到的本地磁盘存储和分布式存储做简单介绍说明
常见存储类型说明及示例
cephfs
cephfs是一款优秀、流行的云环境存储解决方案，原因是它开源、高可用、弹性伸缩，对操作系统、硬件无特殊要求，用户很容易搭建，使用它的节点也无特别要求。它具备awsElasticBlockStore陈述之所有特点，并且单个voluem可以被多个节点同时使用。用户首先搭建自己的cephfs环境，然后配置kubernetes集群与其对接，最后在pod中使用其提供的volume，详细参考这里。
configMap
用户首先创建configＭap并创建数据保存其中，此时数据保存在kubernetes的etcd数据库中，volume还不存在。当用户在pod中引用创建的configMap时，系统首先在节点上创建volume并将数据保存其中，这个volume占用的是节占的存储空间。此后就可以像使用普通volume一样使用它。
configMap是kubernetes中的一种对象类型，核心本质是以volume的方式将单独管理的配置信息传递给pod中的容器，并非用来存储持久化数据。详细参考这里。
downwardAPI
与configＭap类似，以volume的方式向pod中的容器传递信息。configMap中的信息由用户在创建对象时传递，而downwardAPI的信息就来自pod对象本身，downwardAPI不需要创建，它是pod Spec中的一个字段，内容指向pod对象本身的其它字段，如pod的metadata、image等信息。在创建pod时系统首先将指向的字段提取出来，然后创建volume并保存提取出来的字段并挂载，容器就可以读取这些字段了。
