4.1 什么是数据卷
Pod本身具有生命周期，这就带了一系列的问题，
- 当一个容器损坏之后，
kubelet会重启这个容器，但是文件会丢失-这个容器会是一个全新的状态； - 当很多容器在同一
Pod中运行的时候，很多时候需要数据文件的共享。
Docker支持配置容器使用存储卷将数据持久存储于容器自身文件系统之外的存储空间之中，它们可以是节点文件系统或网络文件系统之上的存储空间。相应的，kubernetes也支持类似的存储卷功能，不过，其存储卷是与Pod资源绑定而非容器。
4.1.1 存储卷概述
简单来说，存储卷是定义在Pod资源之上、可被其内部的所有容器挂载的共享目录，它关联至某外部的存储设备之上的存储空间，从而独立于容器自身的文件系统，而数据是否具有持久能力取决于存储卷自身是否支持持久机制。Pod、容器与存储卷的关系图如下。
4.1.2 存储卷类型
Kubernetes支持非常丰富的存储卷类型，包括本地存储（节点）和网络存储系统中的诸多存储机制，还支持Secret和ConfigMap这样的特殊存储资源。
例如，关联节点本地的存储目录与关联GlusterFS存储系统所需要的配置参数差异巨大，因此指定存储卷类型时也就限定了其关联到的后端存储设备。通过命令# kubectl explain pod.spec可以查看当前kubernetes版本支持的存储卷类型。常用类型如下：
4.1.2.1 非持久性存储
- emptyDir
- hostPath
4.1.2.2 网络连接性存储
- SAN：iscsi
- NFS：nfs、cfs
4.1.2.3 分布式存储
- glusterfs、cephfs、rbd
4.1.2.4 云端存储
- awsElasticBlockStore、azureDisk、gitRepo
4.2 emptydir
emptyDir存储卷是Pod对象生命周期中的一个临时目录，类似于Docker上的“docker 挂载卷”，在Pod对象启动时即被创建，而在Pod对象被移除时会被一并删除（永久删除）。
当pod的存储方案设定为emptydir的时候，pod启动时，就会在pod所在节点的磁盘空间开辟出一块空卷，最开始里面是什么都没有的，pod启动后容器产生的数据会存放到那个空卷中，空卷变成了一个临时卷供pod内的容器读取和写入数据，一旦pod容器消失，节点上开辟出的这个临时卷就会随着pod的销毁而销毁
注意：一个容器崩溃了不会导致数据的丢失，因为容器的崩溃并不移除Pod。
4.2.1 使用场景
一般来说
emptydir的用途都是用来充当临时存储空间，例如一些不需要数据持久化的微服务，我们都可以用emptydir来当做微服务pod的存储方案
- 充当临时存储空间，当pod内容器产生的数据不需要做持久化存储的时候用emptydir
- 设制检查点以从崩溃事件中恢复未执行完毕的长计算
4.2.2 使用示例
4.2.2.1 案例说明
这里定义了一个deploy资源对象（vol-emptydir-deploy），在其内部定义了两个容器，其中一个容器是辅助容器sidecar，每隔10秒生成一行信息追加到index.html文件中；
另一个是nginx容器，将存储卷挂载到站点家目录。然后访问nginx的html页面验证两个容器之间挂载的emptyDir实现共享。
# 创建资源清单
vi vol-emptydir-deploy.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: vol-emptydir-deploy
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
volumes: #定义存储卷
- name: html #定义存储卷的名称
emptyDir: {} #定义存储卷的类型
containers:
- name: nginx
image: nginx:1.12
ports:
- containerPort: 80
volumeMounts: #在容器中定义挂载存储卷的名和路径
- name: html
mountPath: /usr/share/nginx/html
- name: sidecar
image: alpine
volumeMounts: #在容器中定义挂载存储卷的名和路径
- name: html
mountPath: /html
command: ["/bin/sh", "-c"]
args:
- while true; do
echo $(hostname) $(date) >> /html/index.html;
sleep 10;
done
# 创建deploy
kubectl apply -f vol-emptydir-deploy.yml
kubectl get pods -o wide
# 访问测试
curl 10.244.1.16
我们发现nginx可以共享来自sidecar的数据4.2.3 测试存储卷
4.2.3.1 登录sidecar
登录
sidecar，并查看目录文件
kubectl exec vol-emptydir-deploy-86cd768757-5mtzx -c sidecar -it -- /bin/sh
在改容器中写入文件
echo "hello world" > hello
4.2.3.2 登录nginx
再打开一个窗口登录
nginx，查看hello文件是否存在
kubectl exec vol-emptydir-deploy-86cd768757-5mtzx -c nginx -it -- /bin/sh
删除hello文件
rm -rf hello
在sidecar中查看文件时已经删除了
4.2.4 测试文件持久性
4.2.4.1 登录sidecar
登录sidecar并在html中写入一段文件
kubectl exec vol-emptydir-deploy-86cd768757-5mtzx -c sidecar -it -- /bin/sh
echo "This is a text to test whether the pod is persistent" > /html/index.html
4.2.4.2 访问测试
curl 10.244.1.16
4.2.4.3 删除Pod
手动删除容器模拟容器销毁，用于是pod是被控制器管理的，删除后会被重建新的pod
kubectl delete pod vol-emptydir-deploy-86cd768757-5mtzx
我们发现销毁pod后新建的pod转移到node2节点了，并且pod名称也改变了
4.2.4.4 访问测试
curl 10.244.2.22
这时候在看我们之前写入的文字不见了
4.3 hostpath
hostPath类型的存储卷是指将工作节点上的某文件系统的目录或文件挂载于Pod中的一种存储卷，独立于Pod资源的生命周期，具有持久性，在Pod删除时，数据不会丢失。
hostPath类型则是映射node文件系统中的文件或者目录到pod里，在使用hostPath类型的存储卷时，也可以设置type字段，支持的类型有文件、目录、File、Socket、CharDevice和BlockDevice。
其实这个功能就相当于docker中的-v 目录映射，只不过在k8s中的时候，pod会漂移，当pod漂移到其他node节点的时候，pod不会跨节点的去读取目录。所以说hostpath只能算一种半持久化的存储方式
4.3.1 使用场景
- 当运行的容器需要访问Docker内部结构时，如使用hostPath映射/var/lib/docker到容器；
- 当在容器中运行Advisor时，可以使用hostPath映射/dev/cgroups到容器中；
4.3.2 使用示例
4.3.2.1 案例说明
这里定义了一个deploy资源对象（vol-hostpath-deploy），在其内部定义了一个容器，将nginx的html文件映射到外部，我们外面给html写入文件，访问nginx来验证是否能够访问。
4.3.2.2 创建资源清单
vi vol-hostpath-deploy.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: vol-hostpath-deploy
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
volumes: #定义存储卷
- name: html # 定义存储名称
hostPath: # 定义存储类型
path: /tmp/k8s/data/volumn1 # 宿主机存储路径
type: DirectoryOrCreate # 不存在路径创建路径
containers:
- name: nginx
image: nginx:1.12
ports:
- containerPort: 80
volumeMounts: #在容器中定义挂载存储卷的名和路径
- name: html
mountPath: /usr/share/nginx/html
4.3.2.3 创建deploy
kubectl apply -f vol-hostpath-deploy.yml
kubectl get pods -o wide
4.3.2.4 写入文件
查看pod发现pod在node1节点，登录node1节点写入文件
cd /tmp/k8s/data/volumn1/
echo "This is a text to test whether the pod is persistent" > index.html
4.3.2.5 访问测试
curl 10.244.1.17
4.3.3测试存储卷
4.3.3.1 登录nginx
kubectl exec vol-emptydir-deploy-86cd768757-5mtzx -c nginx -it -- /bin/sh
cd /usr/share/nginx/html
cat index.html
echo "hello hostpath" > hello
4.3.3.2 登录宿主机查看
登录pod所在的节点的宿主机目录查看文件是否存在
cat hello
发现写入的文件是存在的4.3.4 测试文件持久性
4.3.4.1 删除Pod
手动删除容器模拟容器销毁，用于是pod是被控制器管理的，删除后会被重建新的pod
kubectl delete pod vol-hostpath-deploy-595699bdb4-4m8s4
4.3.4.2 访问测试
我们知道hostpath是在宿主机创建文件的，现在我们发现pod漂移到了node2节点，我们尝试访问，并登录容器查看
curl 10.244.2.23
发现文件不存在符合我们的预期
4.3.4.1 再次删除容器
因为上一次删除漂移到了node2,我们再次删除让其漂移到node1
kubectl delete pod vol-hostpath-deploy-595699bdb4-gd8sw
4.3.4.4 访问测试
curl 10.244.1.18
4.3.4.5 总结
可以发现容器被删除后，新建的pod也可以看到我们映射的目录，我们写入的文件是存在的
这有个缺点就是不能够跨容器去读取数据，如果删除后的pod被调度到其他节点的话，原来的数据也就没有了，如果能不受节点的影响，并且挂载的数据不会随生命周期的结束而结束，我们应该怎么解决呢？我们可以采用NFS的方式进行存储