kubernetes存储入门
目录
一:Volume的概念
二:Volume 的类型
三:通过 emptyDir 共享数据
1:编写emptyDir的Deployment 文件
2:部署该Deployment
3:查看部署结果
4:登录Pod中的第一个容器
5:登录第Pod中的第二个容器查看/mnt 下的文件
6:删除此 Pod
四:使用HostPath挂载宿主机文件
1:编写Deployment文件,实现HostPath挂载
2:创建此 Pod
3:查看创建结果
4:删除
五:挂载 NFS至容器
1:安装 NFS
2:设置共享目录(在NFS服务器上)
3开启 nfs(在NFS服务器上)
4:编写Deployment文件,挂载NFS
5:部署此Pod
6:查看部署结果
7:登录容器查看挂载结果
六:PersistentVolume (PV,持久卷)
2:PV访问策略
3: PV的配置方式
(1)静态配置
(2)动态配置
4:基于HostPath的PV
(1)在所有node节点创建主机目录
(2)编辑hostpath的yaml 文件
4:基于NFS的PV
(1)提前安装好nfs服务
(2)创建一个基于NFS的PV
创建PV:
查看PV 创建结果:
七:PersistentVolumeClaim(PVC,持久卷声明)
1:PVC的创建
(1)为hostpath类型的PV创建PVC
(2)为NFS类型的PV创建 PVC
2:PVC的使用
(1)创建pod,绑定hostpath的PV
(2)创建pod,绑定NFS的PV
一:Volume的概念
对于大多数的项目而言,数据文件的存储是非常常见的需求,比如存储用户上传的头像、文件以及数
据库的数据。在Kubernetes中,由于应用的部署具有高度的可扩展性和编排能力(不像传统架构部署在
固定的位置),因此把数据存放在容器中是非常不可取的,这样也无法保障数据的安全。
我们应该把有状态的应用变成无状态的应用,意思是指把数据从应用中剥离出来,把产生的数据文件
或者缓存的信息都放在云端,比如常用的NFS(生产环境中不建议使用,因为存在单点故障,推荐使用分
布式的存储或者公有云的NAS服务)、Ceph、GlusterFS、Minio等。
在传统的架构中,如果要使用这些存储,需要提前在宿主机挂载,然后程序才能访问,在实际使用时,
经常碰到新加节点忘记挂载存储导致的一系列问题。而Kubernetes在设计之初就考虑了这些问题,并抽
象出Volume的概念用于解决数据存储的问题。
在容器中的磁盘文件是短暂的,当容器崩溃时,Kubect1会重新启动容器,但是容器运行时产生的数
据文件都会丢失,之后容器会以干净的状态启动。另外,当一个Pod运行多个容器时,各个容器可能需要
共享一些文件,诸如此类的需求都可以使用Volume解决。
郑
Docker 也有卷的概念,但是在Docker中,卷只是磁盘上或另一个容器中的目录,其生命周期不受管
理。虽然Docker已经提供了卷驱动程序,但是功能非常有限,例如从 Docker1.7版本开始,每个容器
只允许一个卷驱动程序,并且无法将一些特殊的参数传递给后端存储。
另一方面,Kubernetes 卷具有明确的生命周期,与使用他的Pod相同,因此在Kubernetes中的卷
可以比Pod中运行的任何容器的生命周期都长,并且可以在容器重启或者销毁之后保留数据。Kubernetes
支持多种类型的卷,并且Pod可以同时使用任意数量的卷。
从本质上讲,和虚拟机或者物理机一样,卷被挂载后,在容器中也只是一个目录,可能包含一些数据,
Pod中的容器也可以对其进行增删改查操作,使用方式和裸机挂载几乎没有区别。要使用卷也非常简单,
和其他参数类似,Pod只需要通过.spec.volumes 字段指定为Pod提供的卷,然后在容器中配置块,使
用.spec.containers.volumeMounts 字段指定卷的挂载目录即可。
二:Volume 的类型
在传统架构中,企业内可能有自己的存储平台,比如NFS、Ceph、GlusterFS、Minio等。如果所在
的环境在公有云,也可以使用公有云提供的NAS、对象存储等。在Kubernetes中,Volume也支持配置
这些存储,用于挂载到Pod中实现数据的持久化。Kubernetes Volume支持的卷的类型有很多。
以下为常见的卷:
CephFS
GlusterFS
ISCSI
Cinder
NFS
RBD
HostPath
当然也支持一些Kubernetes 独有的类型:
> ConfigMap:用于存储配置文件
> Secret:用于存储敏感数据
> EmptyDir:用于一个Pod内多个容器的数据共享
PersistentVolumeClaim:对PersistentVolume 的申请
三:通过 emptyDir 共享数据
emptyDir是一个特殊的Volume类型,与上述Volume不同的是,如果删除Pod,EmptyDir卷中的
数据也将被删除,所以一般emptyDir用于Pod中不同容器共享数据,比如一个Pod存在两个容器A和容
器B,容器A需要使用容器B产生的数据,此时可以采用emptyDir共享数据,类似的使用如Filebeat
收集容器内程序产生的日志。
使用emptyDir卷时,直接指定emptyDir为{}即可
1:编写emptyDir的Deployment 文件
[root@k8s-master ~]# cat << EOF>nginx-empty.yaml
apiVersion: apps/v1kind: Deploymentmetadata:labels:app: nginxname: nginxnamespace: defaultspec:replicas: 1selector:matchLabels:
app: nginxtemplate:metadata:labels:app: nginxspec:containers:- image: nginx:1.7.9imagePullPolicy: IfNotPresentname: nginx01volumeMounts:mountPath: /optname: share-volume- image: nginx:1.7.9imagePullPolicy: IfNotPresentname: nginx02command:- sh- sleep 3600volumeMounts :- mountPath: /mntname: share-volumevolumes :
- name: share-volumeemptyDir: {}#medium: Memory
volumeMounts:
- mountPath: /mnt
name:share-volume##容器定义部分的卷挂载名称,此处的名称引用了volumes对应的名称
volumes:
- name: share-volume
##共享存储卷的名称
此案例会将nginx01中/opt中的数据,共享给nginx02中的/mnt目录
此部署文件创建一个Deployment,采用spec.volume字段配置了一个名字为share-volume、类型
为emptyDir的volume,同时里面包含两个容器nginx01和nginx02,并将该volume挂载到了/opt和
/mnt目录下,此时/opt和/mnt目录的数据就实现了共享。
默认情况下,emptyDir支持节点上的任何介质,可以使SSD、磁盘或是网络存储,具体取决于自身
环境。可以将emptyDir.medium字段设置为Memory,让Kubernetes使用tmpfs(内存支持的文件系统),
虽然tmpfs非常快,但是在节点重启时,数据同样会被清除,并且设置的大小会被记入Container的内
存限制中。
2:部署该Deployment
[root@k8s-master ~]# kubectl create -f nginx-empty.yaml
3:查看部署结果
[root@k8s-master ~]# kubectl get pod
4:登录Pod中的第一个容器
[root@k8s-master ~]# kubectl exec -ti nginx-6fffbd7c7b-jrw7f -c nginx01 -- sh
备注:
在该容器中的/opt下创建一个文件,并到第二个容器中查看,是否是共享的目录
5:登录第Pod中的第二个容器查看/mnt 下的文件
[root@k8s-master ~]# kubectl exec -ti nginx-6fffbd7c7b-jrw7f -c nginx02 -- sh
注意
登录伤处后,此处可以使用date命令查看容器中的时间,会发现时间是不对的。是因为时区的问题,容
器内使用的不是亚洲上海市区。导致时间不对。
6:删除此 Pod
[root@k8s-master ~]# kubectl delete -f nginx-empty.yaml
四:使用HostPath挂载宿主机文件
HostPath卷可以将节点上的文件或目录挂载到Pod上,用于实现Pod和宿主机之间的数据共享,常
用的示例有挂载宿主机的时区至Pod,或者将Pod的日志文件挂载到宿主机等。
1:编写Deployment文件,实现HostPath挂载
以下为使用HostPath卷的示例,实现将主机的/etc/localtime文件挂载到Pod的/etc/localtime
apiVersion: apps/v1kind: Deploymentmetadata:labels:
spec:replicas: 1selector:matchLabels:app: nginxtemplate:metadata:labels:spec:image: nginx:1.7.9imagePullPolicy: IfNotPresentname: nginxvolumeMounts:/etc/localtimename: timezone-time- mountPath:volumes :- name: timezone-timehostPath:/etc/localtimetype: Filepath:2:创建此 Pod
[root@k8s-master ~]# kubectl create -f nginx-hostPath.yaml
3:查看创建结果
[root@k8s-master ~]# kubectl get pod
[root@k8s-master ~]# kubectl exec -ti nginx-5c9b77966c-jrw7f -c nginx -- sh
# date
在配置HostPath时,有一个type参数,用于表达不同的挂载类型,HostPath卷常用的类型有:
> type为空字符串:默认选项,在挂载HostPath卷之前不会有任何检查
> DirectoryOrCreate:如果给定的path不存在任何东西,那么将根据需要创建一个权限为
0755的空目录,和kubelet具有相同的组和权限
> Directory:目录必须存在于给定的路径下
> FileOrCreate:如果给定的路径不存在任何内容,则会根据需要创建一个空文件,权限设
置为0644,和kubelet具有相同的组和所有权
File:文件,必须存在于给定的路径中
Socket:UNIX 套接字,必须存在于给定的路径中
CharDevice:字符设备,必须存在于给定的路径中
BlockDevice:块设备,必须存在于给定的路径中
4:删除
[root@k8s-master ~]# kubectl delete -f nginx-hostPath.yaml
五:挂载 NFS至容器
1:安装 NFS
在所有的Kubernetes 节点都要安装
[root@k8s-master ~]# yum -y install nfs-utils
2:设置共享目录(在NFS服务器上)
[root@k8s-master ~]# mkdir /opt/wwwroot
[root@k8s-master ~]# echo "This is my test file">/opt/wwwroot/index.html
[root@k8s-master ~]# vim /etc/exports
/opt/wwwroot 192.168.10.0/24(rw,sync,no_root_squash)
3开启 nfs(在NFS服务器上)
[root@k8s-master ~]# systemctl start nfs
[root@k8s-master ~]# systemctl start rpcbind
4:编写Deployment文件,挂载NFS
[root@k8s-master ~]# cat << EOF>nginx-nfsVolume.yamlapiVersion: apps/v1kind: Deploymentmetadata:labels:app: nginxname: nginx
matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:郑volumeMounts:mountPath: /usr/share/nginx/htmlname: nfs-volumevolumes :- name: nfs-volumenfs:server: 192.168.10.101path: /opt/wwwroot5:部署此Pod
[root@k8s-master ~]# kubectl create -f nginx-nfsVolume.yaml
6:查看部署结果
[root@k8s-master ~]# kubectl get pod
7:登录容器查看挂载结果
[root@k8s-master ~]# kubectl exec -ti nginx-fbd476c4c-zscq9 -c nginx -- bash
六:PersistentVolume (PV,持久卷)
虽然volume已经可以接入大部分存储后端,但是实际使用时还有诸多的问题。比如:
> 当某个数据卷不再被挂载使用时,里面的数据如何处理?
> 如果想要实现只读挂载,要如何处理?
> 如果想要只能有一个Pod挂载,要如何处理?
如上所述,对于很多复杂的需求,volume可能难以实现,并且无法对存储的生命周期进行管理。另
一个很大的问题是,在企业内使用kubernetes的不仅仅是kubernetes管理员,可能还有开发人员、测
试人员以及初学kubernetes的技术人员,对于kubernetes的volume或者相关存储平台的配置参数并
不了解,所以无法自行完成存储的配置。
郑州子
为此,kubernetes 引入了两个新的API资源:PersistentVolume(持久卷,简称PV)和
PersistentVolumeClaim(持久卷声明,简称PVC)。
PV是kubernetes 管理员设置的存储,PVC是对PV的请求,标识需要什么类型的PV。他们同样是集
群中的一类资源,但其生命周期比较独立,管理员可以单独对PV进行增删改查,不受Pod的影响,生命
周期可能比挂载它的其他资源还要长。如果一个kubernetes集群的使用者并非只有kubernetes管理员,
那么可以通过提前创建PV,用以解决对存储概念不是很了解的技术人员对存储的需求。和单独配置volume
类似,PV也可以使用NFS、GFS、CEPH等常见的存储后端,并且可以提供更为高级的配置,比如访问模式、
空间大小以及回收策略等。目前PV的提供方式有两种:静态或动态。静态PV由管理员提前创建,动态
PV无需提前创建。
1:PV回收策略
当用户使用完卷时,可以从API中删除PVC对象,从而允许回收资源。回收策略会告诉PV如何处理
改卷。目前回收策略可以设置为Retain、Recycle和Delete。静态PV默认的为Retain,动态PV默认
为Delete。
面始区小小一眼新的
独配置 volume
.比如访问模式
Prthstsn
Retain:保留,该策略允许手动回收资源,当删除PVC时,PV仍然存在,PV中的数据也存在。volume
被视为已释放,管理员可以手动回收卷。
Recycle:回收,如果volume插件支持,Recycle策略会对卷执行rm -rf清理该PV,卷中的数据
已经没了,但卷还在,使其可用于下一个新的PVC,但是本策略将会被弃用,目前只有NFS和HostPath
支持该策略。
Delete:删除,如果volume插件支持,删除PVC时会同时删除PV,PV中的数据自然也就没了。动
态卷默认为Delete,目前支持Delete的存储后端包括AWS EBS、GCE PD、Azure Disk、OpenStack
Cinder等。
2:PV访问策略
在实际使用PV时,可能针对不同的应用会有不同的访问策略,比如某类Pod可以读写,某类Pod只
能读,或者需要配置是否可以被多个不同的Pod同时读写等,此时可以使用PV的访问策略进行简单控制,
目前支持的访问策略如下:
ReadwriteOnce:单路可读可写,可以被单节点以读写模式挂载,命令行中可以被缩写橙RWO。
ReadOnlyMany:多路只读,可以被多节点以只读模式挂载,命令行中可以被缩写为ROX。
ReadWriteMany:多路可读可写,可以被多个节点以读写模式挂载,命令行中可以被缩写为RWX。
ReadwriteOncePod:单节点只读(1.22+),只能被一个Pod以读写的模式挂载,命令行中可以被
缩写为RWOP。
虽然PV在创建时可以指定不同的访问策略,但是也要后端的存储支持才行。比如一般情况下,大部
分块存储是不支持ReadWriteMany的。
在企业内,可能存储很多不同类型的存储,比如NFS、Ceph、GlusterFS等,针对不同类型的后端存
储具有不同的配置方式,这也是对集群管理员的一种挑战,因为集群管理员需要对每种存储都要有所了解。
3: PV的配置方式
(1)静态配置
静态配置是手动创建PV并定义其属性,例如容量、访问模式、存储后端等。在这种情况下,Kubernetes
管理员负责管理和配置PV,然后应用程序可以使用这些PV。静态配置通常用于一些固定的存储后端,如NFS.
(2)动态配置
动态配置允许Kubernetes集群根据PVC的需求自动创建PV,在这种情况下,管理员只需为存储后
端配置StorageClass,然后应用程序就可以通过PVC请求存储。Kubernetes 将自动创建与PVC匹配的
PV,并将其绑定到PVC上。这种方法使得存储管理更加灵活和可扩展,允许管理员在集群中动态添加、删
除、和管理存储资源
4:基于HostPath的PV
可以创建一个基于HostPath的PV,和配置NFS的PV类似,只需要配置hostPath字段即可,其它
配置基本一致。
(1)在所有node节点创建主机目录
[root@k8s-master ~]# mkdir /mnt/data
(2)编辑hostpath的yaml 文件
[root@k8s-master ~]# cat << EOF>hostpath-pv.yamlkind: PersistentVolumeapiVersion: v1metadata:name: mypv-hostpathlabels:type: localspec:storageClassName: pv-hostpathcapacity:storage: 10GiaccessModes :- ReadWriteOncehostPath:path："/mnt/data"hostPath:宿主机的路径,使用hostPath类型需要固定Pod所在的节点,防止Pod 漂移造成数据
丢失。
storageClassName 是一个用于标识StorageClass对象名称的标签。当你创建或配置
PersistentVolumeClaim(PVC)时,可以指定storageClassName来告诉Kubernetes 你希望使
用哪个StorageClass 来配置存储。
[root@k8s-master ~]# kubectl create -f hostpath-pv.yaml
[root@k8s-master ~]# kubectl get pv
4:基于NFS的PV
(1)提前安装好nfs服务
可以使用上一个案例中安装好的NFS。
或重新安装一台,步骤如下:
提前安装好nfs服务,192.168.10.101是nfs服务器,也可以是任意一台提供了NFS服务的主机。
客户端需要在所有的Kubernetes 节点安装
yum -y install nfs-utils
mkdir /opt/wwwroot
echo "This is my test file">/opt/wwwroot/index.html
vim /etc/exports
systemctl start nfs
systemctl start rpcbind
(2)创建一个基于NFS的PV
PV 目前没有NameSpace隔离,不需要指定命名空间,在任意命名空间下创建的PV均可以在其他
NameSpace 使用
[root@k8s-master ~]# cat << EOF> nfs-pv.yaml
kind: PersistentVolumemetadata:name: mypv-nfsspec:capacity:storage: 5GivolumeMode: FilesystemaccessModes :- ReadWriteOncepersistentVolumeReclaimPolicy: RecyclestorageClassName: pv-nfsmountOptions:hard- nfsvers=4.1nfs:path: /opt/wwwroot/server: 192.168.10.101备注:
capacity:容量配置
volumeMode:卷的模式,目前支持Filesystem(文件系统)和Block(块),其中Block类型需
要后端存储支持,默认为文件系统。
accessModes:该PV的访问模式
storageClassName:PV的类,一个特定类型的PV只能绑定到特定类别的PVC。
persistentVolumeReclaimPolicy:回收策略
mountoption:非必要,新版本中已经弃用
nfs:NFS服务配置,包括以下两个选项
path:NFS 上的共享目录
server:NFS的IP地址
创建PV:
[root@k8s-master ~]# kubectl create -f nfs-pv.yaml
查看PV 创建结果:
[root@k8s-master ~]# kubectl get pv
七:PersistentVolumeClaim(PVC,持久卷声明)
当 kubernetes 管理员提前创建好了PV,我们又应该如何使用它呢?
这里介绍kubernetes 的另一个概念PersistentVolumeClaim(简称PVC)。PVC是其他技术人员
17
在 kubernetes上对存储的申请,他可以标明一个程序需要用到什么样的后端存储、多大的空间以及什么
访问模式进行挂载。这一点和Pod的QoS配置类似,Pod消耗节点资源,PVC消耗PV资源,Pod可以请
求特定级别的资源(CPU和内存),PVC可以请求特定的大小和访问模式的PV。例如申请一个大小为5G
且只能被一个Pod只读访问的存储。
在实际使用时,虽然用户通过PVC获取存储支持,但是用户可能需要具有不同性质的PV来解决不同
的问题,比如使用SSD硬盘来提高性能。所以集群管理员需要根据不同的存储后端来提供各种PV,而不
仅仅是大小和访问模式的区别,并且无须让用户了解这些卷的具体实现方式和存储类型,打扫了存储的解
耦,降低了存储使用的复杂度。
接下来我们来看看如何让PVC和前面创建的PV绑定。PVC和PV进行绑定的前提条件是一些参数必须
匹配,比如accessModes、storageClassName、volumeMode 都需要相同,并且PVC的storage需要小
1:PVC的创建
(1)为hostpath类型的PV创建PVC
[root@k8s-master ~]# vim pvc-hostpath.yamlkind: PersistentVolumeClaimapiVersion: v1metadata:name: mypvc-hostpathspec:storageClassName: pv-hostpath- ReadWriteOnceresources:requests:storage: 3Gi注意:
storageClassName:存储类名称需要和对应的PV中的名称一致,PV和PVC进行绑定并非是
名字相同,而是StorageClassName相同且其他参数一致才可以进行绑定。
[root@k8s-master ~]# kubectl create -f pvc-hostpath.yaml
[root@k8s-master ~]# kubectl get pvc
(2)为NFS类型的PV创建 PVC
[root@k8s-master ~]# cat pvc-nfs. yamlkind: PersistentVolumeClaimapiVersion: v1metadata:name: mypvc-nfsspec:storageClassName: pv-nfsaccessModes :- ReadWriteOnceresources:requests:storage: 3Gi注意:
storageClassName:存储类名称需要和对应的PV中的名称一致
[root@k8s-master ~]# kubectl create -f pvc-nfs.yaml
[root@k8s-master ~]# kubectl get pvc
从上述两个简单的例子可以看出,PVC的定义和后端存储并没有关系。对于有存储需求的技
术人员,直接定义PVC即可绑定一块PV,之后就可以供Pod使用,而不用去关心具体的实现细节,
大大降低了存储的复杂度。接下来我们看一下PVC如何提供给Pod使用。
2:PVC的使用
上述创建了PV,并使用PVC与其绑定,现在还差一步就能让程序使用这块存储,那就是将PVC挂载
到Pod。和之前的挂载方式类似,PVC的挂载也是通过volumes 字段进行配置的,只不过之前需要根据不
同的存储后端填写很多复杂的参数’而使用PVC进行挂载时,只填写PVC的名字即可,不需要再关心任何
的存储细节,这样即使不是Kubemetes管理员,不懂存储的其他技术人员想要使用存储,也可以非常简
单地进行配置和使用。比如我们将之前创建的hostPath类型的PVC挂载到Pod中,可以看到只需要配置
一个PersistentVolumeClaim类型的volumes,claimName配置为PVC的名称即可:
(1)创建pod,绑定hostpath的PV
[root@k8s-master ~]# cat pvc-pv-pod-hostpath.yamlkind: PodapiVersion: v1metadata:name: hostpath-pv-podspec:volumes:- name: task-pv-storagepersistentVolumeClaim:claimName: mypvc-hostpathcontainers:- name: task-pv-containerimage: nginx:1.7.9ports:- containerPort: 80name: "http-server"volumeMounts:- mountPath: "/usr/share/nginx/html"name: task-pv-storage备注:
claimName:mypvc-hostpath是基于hastpath创建的PVC的名字
[root@k8s-master ~]# kubectl create -f pvc-pv-pod-hostpath.yaml
[root@k8s-master ~]# ku get pod -o wide
[root@k8s-node01~]# cd /mnt/data/
[root@k8s-node01 data]# touch aaa. txt
[root@k8s-master ~]# ku exec -it hostpath-pv-pod -- bash
root@hostpath-pv-pod:/# ls /usr/share/nginx/html/
(2)创建pod,绑定NFS的PV
[root@k8s-master ~]# cat pvc-pv-pod-nfs.yamlkind: PodapiVersion: v1metadata:name: pvc-nfsspec:volumes:- name: pvc-nfs01persistentVolumeClaim:claimName: mypvc-nfscontainers:- name: task-pv-containerimage: nginx:1.7.9ports:- containerPort: 80name: "http-server"volumeMounts:- mountPath: "/usr/share/nginx/html"name: pvc-nfs01备注:
claimName:mypvc-nfs 是基于NFS创建的PVC的名字
[root@k8s-master ~]# kubectl create -f pvc-pv-pod-nfs.yaml
[root@k8s-master ~]# ku get pod
[root@k8s-master ~]# ku exec -it pvc-nfs -- bash
root@pvc-nfs:/# ls /usr/share/nginx/html/