在docker和K8S中都存在容器是有生命周期的，因此数据卷可以实现数据持久化。
数据卷解决的主要问题：
1.数据持久性：当我们写入数据时，文件都是暂时性的存在，当容器崩溃后，host就会将这个容器杀死，然后重新从镜像创建容器，数据就会丢失。
2.数据共享：在同一个Pod中运行容器，会存在共享文件的需求。
数据卷的类型：
1.emptyDir
emptyDir数据卷类似于docker数据持久化的docker manager volume，该数据卷初分配时，是一个空目录，同一个Pod中的容器可以对该容器中的目录具有执行读写操作，并且共享数据。
场景特点：一个相同的pod，不同的容器，共享数据卷
如果容器被删除，数据仍然存在，如果Pod被删除，数据也会被删除
测试：
**vim emptyDir.yaml**
apiVersion: v1
kind: Pod
metadata:
name: producer-consumer
spec:
containers:
- image: busybox
name: producer
volumeMounts:
- mountPath: /producer_dir#这里的路径指的是容器内的路径
name: shared-volume#指定本地的目录名
args:#定义容器运行后，会进行的操作
- /bin/sh
- -c
- echo "hello k8s" > /producer_dir/hello; sleep 30000
- image: busybox
name: consumer
volumeMounts:
- mountPath: /consumer_dir
name: shared-volume
args:
- /bin/sh
- -c
- cat /consumer_dir/hello; sleep 30000
volumes:
- name: shared-volume#这里的值需要与上面Pod的mountPath的name值对应
emptyDir: {}#定义数据持久化的类型，即表示空目录kubectl apply -f emptyDir.yaml #执行文件
docker inspect （查看容器的详细信息）：Mount挂载点
可以进入目录在宿主机查看数据。
kubectl get pod -o wide （-w):可以详细的查看pod信息
加上-w：可以实时查看。并且知道容器运行在那个节点。
kubectl logs {pod名} consumer可以查看目录中的数据。
根据测试可以查看节点上的容器，挂载目录是否相同。相同则环境正确。可以删除容器查看数据是否丢失，在删除master节点pod查看数据是否还在。
根据测试，emptyDir数据持久化一般只能作为临时存储使用。
2.hostPath Volume
1》将Pod所在节点的文件系统上某一个文件或目录挂载进容器内。
2》类似于docker数据持久化的bind mount。如果Pod被删除，数据会保留。相比较emptyDir要好一些，不过一但host崩溃，hostPath也无法访问了。
3》使用这种数据持久化的场景不多，因为会增加Pod与节点之间的耦合性。
3.Persistent Volume ：pv （持久卷） 提前做好的，数据持久化的存放目录。
persistentVolumeClaim： PVC （持久卷使用声明 | 申请）
pvc是用户存储的请求。类似于pod。pod消耗节点资源，pvc消耗存储资源。pod可以请求特定级别的资源（cpu，内存）。pvc根据权限可以请求特定的大小和访问模式。基于NFS服务来做PV：
安装NFS服务及rpcbind服务：
1.[[email protected]?yaml]#?yum?install?-y?nfs-utils?rpcbind??#这里注意三台都要安装NFS服务。
2.[[email protected]?yaml]#?vim?/etc/exports??
文件中添加/nfsdata??*(rw,sync,no_root_squash)??
4.[[email protected]?yaml]#?mkdir?/nfsdata??
5.[[email protected]?yaml]#?systemctl?start?rpcbind??
6.[[email protected]?yaml]#?systemctl?start?nfs-server.service???
7.[[email protected]?yaml]#?showmount?-e??
Export?list?for?master:??
/nfsdata?*??创建PV资源对象：
vim nfs-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: test
spec:
capacity:#给予的容量大小
storage: 1Gi
accessModes:#PV支持的访问模式
- ReadWriteOnce#这里表示只能以读写的方式挂载到单个节点
persistentVolumeReclaimPolicy: Recycle#pv的回收策略：表示自动清楚数据
storageClassName: nfs#定义的存储类名字
nfs:#这里要和上面定义的存储类名字一致
path: /nfsdata/pv1#指定NFS的目录
server: 192.168.1.1#指定NFS服务器的IP执行nfs-pv.yaml文件：
**`?kubectl?apply?-f?nfs-pv.yaml??`?**
persistentvolume/test?created??
**`?kubectl?get?pv??`**
NAME??????CAPACITY???ACCESS?MODES???RECLAIM?POLICY???STATUS??????CLAIM???STORAGECLASS???REASON???AGE??
test???1Gi????????RWO????????????Recycle?????????**?Available?**??????????nfs?????????????????????7s??
**这里注意STATUS状态为Available才能够使用。**pv支持的访问模式：
ReadWriteOnce：访问模式为只能以读写的方式挂载到单个节点
ReadWriteMany：访问模式为只能以读写的方式挂载到多个节点
ReadOnlyMany：访问模式为只能以只读的方式挂载到多个节点
PV存储空间的回收策略：
Recycle：自动清除数据。
Retain：需要管理员手动回收。
Delete：云存储专用。
PV和PVC相互的关联：通过的是storageClassName与accessModes
创建PVC：
vim nfs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test
spec:
accessModes:
- ReadWriteOnce#定义访问模式，这里必须与Pv定义一致
resources:
requests:
storage: 1Gi#请求容量的大小
storageClassName: nfs#存储类的名字，必须与pv定义的一致。运行，并查看PVC和PV：
kubectl?apply?-f?nfs-pvc.yaml???
关联后会看见，Bound：
原文地址：https://blog.51cto.com/13911055/2471235