1、存储卷:容器内的目录和宿主机的目录进行挂载
2、容器在系统上的生命周期是短暂的,delete,k8s用控制器创建的pod,delete相当于重启,容器的状态也会恢复到初始状态,一旦回到初始状态,所有的后天编辑的文件都会消失。
3、容器和节点之间创建一个可以持久化保存容器内文件的存储卷,即使容器被销毁、删除、重启,节点上的存储卷的数据依旧存在,后续也可以继续使用,可以继续将容器内目录和宿主机挂载,保存的数据继续使用
4、存储卷的类型
emptyDir: 容器内部共享存储,在k8s系统中,是一个pod当中的多个容器共享一个存储卷目录 ①emptyDir可以是pod当中容器在这个存储卷上读取和写入 ②emptyDir是不能挂载到节点的,随着pod的生命周期结束,emptyDir也会结束,数据也不会保留,不能做数据持久化 |
hostPath: 将容器内的挂载点和节点上的目录进行挂载,hostPath可以实现数据的持久化,pod被销毁,数据不会丢失。除非node节点被销毁,数据才会丢失 * hostPath这种挂载方式非常直接,但有一个重要的限制:hostPath 是特定于节点的,而不是集群范围的 * 面:污点设置为noexecute,节点上的pod会被驱逐,文件数据是否存在? ①pod被驱逐,并不是node节点被销毁,所有数据还保留在节点上 ②pod被驱逐(基于控制器创建的)会在其他节点重新部署,又会在其他节点生成一个新的存储卷,数据依然可以持久化 ③若存储卷类型为emptyDir,数据会丢失 |
NFS共享存储(推荐使用): 所有pod内的目录都和远程服务器上的nfs共享目录形成数据卷,所有的数据文件都保存在共享目录当中,集中管理、方便 |
5、emptyDir的实例
(1)创建挂载卷
(2)指定容器进入:kubectl exec -it nginx1-7b9b94c8b9-7j4tj -c nginx2 bash
①测试
(3)删除pod、存储卷也随之销毁
(4)查看pod内指定容器的日志:kubectl logs nginx1-7b57fbd6fb-9zvl7 -c nginx1
6、hostPath实例
7、NFS共享存储的实例
(1)创建共享目录
mkdir volumes
chmod 777 volumes/
vim /etc/exports
systemctl restart rpcbind
systemctl restart nfs
showmount -e
(2)配置yaml文件
(2)第一种:指定IP地址
①测试
(3)第二种:指定主机名
①所有节点配置主机映射
(4)删除deployment:kubectl delete -f test.yaml(删除基于yaml文件创建的)
8、PVC和PV(重点)
(1)PV(persistent volume):持久化存储卷 用来描述和定义一个存储卷,PV一般由运维人员定义 |
(2)PVC(persistent volume claim):持久化存储的请求 PVC实际上是用来描述或者声明希望使用什么样的PV来进行存储 |
(3)PVC和PV ①PVC和PV一一对应(描述、存储(大小)):静态请求、动态请求 ②PV和PVC都是虚拟化的概念,是k8s中抽象的、虚拟的存储资源 ③PVC——PV——nfs ④PV是集群当中的存储资源,PVC请求存储资源,也是对存储资源的一种检索(检查索引),选择一个最合适的PV来存储资源 ⑤当pod运行之后,通过PVC请求到了PV,除非pod被销毁,否则无法删除PVC |
(4)PV和PVC之间的生命周期管理: ①provisioning(配置)——PVC请求request——检索(找一个合适的PV)——PVC和PV绑定(binding)——使用——pod被删除——PV的releasing(释放)——recycling(回收) 配置:静态、动态 绑定:就是把PV分配给PVC 使用:就是pod通过PVC使用存储资源 释放:pod解除和挂载卷volume之间的关系,删除PVC 回收:保留PV,以供下一个PVC使用 |
PVC和PV之间的静态请求,一旦有上百个PVC,使用动态请求 |
(1)PV的状态
Available | 可用,而且没有被任何PVC绑定(可以被请求) |
Bound | 绑定,PV已经绑定到了PVC,绑定即使用 |
Released | 释放,PVC已经被删除了,但是PV的存储资源还没有被集群回收 |
Failed | 表示PV的资源回收失败,而且PV为不可用状态 |
(2)PV的读写方式(配置文件里是全称)
ReadWriteOnce(RWO) | 存储的PV可读可写,但是只能被单个pod挂载 |
ReadOnlyMany(ROX) | 存储的PV可以以只读的方式被多个pod挂载 |
ReadWriteMany(RWX) | 存储的PV可以以读写的方式被多个pod挂载 |
(3)PV的挂载方式(支持的读写方式)
nfs | 可以支持三种读写和挂载方式 |
hostpath | 只支持ReadWriteOnce,其他两个都不支持 |
ISCSI | 不支持ReadWriteMany |
①查看机器上所有SCSI的设备:lsscsi
②查看服务器是否有ISCSI设备:iscsiadm -m session -P 3
iscsiadm -m session -P 3 | |
iscsiadm | 查看服务器是否有ISCSI设备 |
-m session | 指定操作的会话模块,管理iscsi |
-P 3 | 显示详细信息的级别,级别就是3,显示详细信息 |
(4)集群回收PV资源的方式
Retain | 保留,pod和挂载点的数据不会被删除(默认策略) |
Recycle | 回收,PV上的数据会被删除,挂载点的数据也会被删除 |
Delete | 删除,解绑时会自动删除PV上的数据,本地硬盘不能使用,只有云平台(AWS、EBS、GCE)支持动态卷、可以使用,PV不再可用(云平台自己处理) |
9、静态请求
(1)创建nfs挂载目录
①节点查看nfs:showmount -e 20.0.0.72
(2)创建PV:一个yaml文件中定义多个类型
(3)定义PVC请求
(4)使用PV存储卷
①PVC发起请求,请求用哪个PV的存储,PV和物理存储做映射(挂载),物理设备提供存储卷
(5)删除PVC
①测试
kubectl delete deployments.apps nginx
kubectl delete pvc mypvc
②恢复PV的可用状态
(6)配置集群回收PV资源:Recycle
①persistentVolumeReclaimPolicy: Recycle
②删除,测试回收:PV上的数据会被删除,挂载点的数据也会被删除
(7)delete的PV回收方式
①删除测试:本地硬盘不支持delete,不会删除数据
(8)总结
k8s中存储卷的模式: | |
emptyDir | 容器内的存储卷,随着pod的销毁,empty也会被销毁,数据不保留 |
hostPath | 节点目录的存储卷,可以实现持久化存储,数据在每个节点上都有,不方便集中管理 |
nfs | 享目录存储卷,可以实现持久化,数据集中在一个目录,方便管理 |
PV和PVC: | |
(1)PVC请求,请求PV的存储(硬盘空间nfs) (2)nfs支持PVC的所有挂载方式和读写模式 (3)hostpath仅支持readwriteonce (4)PVC是以检索的方式找到匹配的PV资源 ①检索挂载方式和读写模式 ②检索PV能够提供的存储资源的大小 ③谁适合选谁 ④保留:默认可以不写 ⑤回收:自动回收,节点上的数据会被删除 ⑥删除:PV会变成failed模式,不可用,数据也会被删除 | |
静态的PV和PVC:双方指定好配置 ①运维负责PV:创建好持久化存储卷,声明好读写和挂载类型,以及可以提供的存储空间 ②开发负责PVC,运维负责和开发沟通好,期望的读写和挂载类型,以及存储空间 |
10、动态请求(基于nfs实现)
(1)发布PVC,自动生成PV,在共享服务器上直接生成挂载目录;PVC直接绑定和使用PV
①动态请求的默认回收策略:delete
(2)动态PV需要的组件
①卷插件(Provisioner):k8s本身支持的动态PV创建不包括nfs,要需要声明和安装一个外部插件(nfs使用的是nfs-client) | |
Provisioner | 存储分配器:动态创建PV,然后根据PVC的请求自动绑定和使用 |
②StorageClass:定义PV的属性、存储类型、大小、回收策略 |
(3)使用nfs实现动态PV,nfs支持的方式nfs-client,Provisioner适配nfs-client
动态请求的过程 |
provisioner卷插件(存储分配器):支持nfs、创建PV目录 storageclass:定义PV的属性 |
1、创建serviceAccount账户:管理NFS Provisioner插件在k8s集群中的权限 ①让卷插件provisioner能够在集群内部通信、获取资源、监听事件、创建、删除和更新PV |
2、基于Deployment来创建NFS Provisioner,由卷插件的pod动态创建PV |
3、创建StorageClass,负责建立PVC并调用NFS provisioner进行工作,并让PV与PVC建立关联 ①给PV赋予属性:PVC被删除之后PV的状态、PV的回收策略、动态扩缩容 |
4、创建PVC(声明期望的PV属性)和pod |
(4)第一步:创建nfs-client-Provisioner卷插件
①创建nfs共享目录
②创建serviceAccount账户:管理NFS Provisioner插件在k8s集群中的权限
NFS Provisioner:是一个插件,没有权限是无法在集群中获取k8s的消息。这个插件要有权限能够监听apiserver、获取(个体)、list(获取集群的列表资源)、create、delete、watch(监听事件) |
rbac:role-based access control(基础权限控制),定义角色在集群中可以使用的权限 |
vim nfs-client-rbac.yaml
kubectl apply -f nfs-client-rbac.yaml
(5)第二步:基于Deployment来创建NFS Provisioner(provisioner:创建PV)
①屏蔽self-link字段:vim /etc/kubernetes/manifests/kube-apiserver.yaml
1.20版本之后有一个新的机制: * selflink:api的资源对象之一,表示资源对象在集群当中自身的一个连接,self-link是一个唯一的标识符号,可以用于标识k8s集群当中每个资源的对象 * self-link的值是一个url,也是指向该资源对象在k8s中的api路径 * self-link的作用:更好的实现资源对象的查找和引用 |
kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
kubectl delete pod kube-apiserver -n kube-system
kubectl get pod -n kube-system
②基于deployment部署nfs-provisioner插件:vim nfs-client-provisioner.yaml
* nfs-provisioner的客户端,以pod的方式运行在集群中,监听k8s集群当中PV的请求,动态的创建与nfs服务器相关的PV * 容器内使用的配置,在nfs-provisioner当中定义好环境变量,传给容器 * 环境变量:storageclass的名称、nfs服务器的地址、nfs的目录 |
quay.io/external_storage/nfs-client-provisioner:latest
kubectl apply -f nfs-client-provisioner.yaml
kubectl get pod
(6)第三步:创建StorageClass,负责建立PVC并调用NFS provisioner进行预定的工作,并让PV与PVC建立关联
①vim nfs-client-storageclass.yaml
kubectl apply -f nfs-client-storageclass.yaml
kubectl get storageclasses.storage.k8s.io
kubectl get storageclasses.storage.k8s.io | |
NAME | storageclass的名称 |
PROVISIONER | 对应的创建PV的provisioner的插件 |
RECLAIMPOLICY | 回收策略,保留 |
VOLUMEBINDINGMODE | 卷绑定模式,immediate表示PVC请求创建PV时,系统会立即绑定一个可用的PV ②waitforfirstconsumer:第一个使用者出现之后再绑定PV |
ALLOWVOLUMEEXPANSION | true表示可以在运行时可以对PV进行扩容 |