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