emptyDir: 容器内部共享存储,在k8s系统中,是一个pod当中的多个容器共享一个存储卷目录 ①emptyDir可以是pod当中容器在这个存储卷上读取和写入 ②emptyDir是不能挂载到节点的,随着pod的生命周期结束,emptyDir也会结束,数据也不会保留,不能做数据持久化 |
hostPath: 将容器内的挂载点和节点上的目录进行挂载,hostPath可以实现数据的持久化,pod被销毁,数据不会丢失。除非node节点被销毁,数据才会丢失 * hostPath这种挂载方式非常直接,但有一个重要的限制:hostPath 是特定于节点的,而不是集群范围的 * 面:污点设置为noexecute,节点上的pod会被驱逐,文件数据是否存在? ①pod被驱逐,并不是node节点被销毁,所有数据还保留在节点上 ②pod被驱逐(基于控制器创建的)会在其他节点重新部署,又会在其他节点生成一个新的存储卷,数据依然可以持久化 ③若存储卷类型为emptyDir,数据会丢失 |
NFS共享存储(推荐使用): 所有pod内的目录都和远程服务器上的nfs共享目录形成数据卷,所有的数据文件都保存在共享目录当中,集中管理、方便 |
(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,使用动态请求 |
Available | 可用,而且没有被任何PVC绑定(可以被请求) |
Bound | 绑定,PV已经绑定到了PVC,绑定即使用 |
Released | 释放,PVC已经被删除了,但是PV的存储资源还没有被集群回收 |
Failed | 表示PV的资源回收失败,而且PV为不可用状态 |
ReadWriteOnce(RWO) | 存储的PV可读可写,但是只能被单个pod挂载 |
ReadOnlyMany(ROX) | 存储的PV可以以只读的方式被多个pod挂载 |
ReadWriteMany(RWX) | 存储的PV可以以读写的方式被多个pod挂载 |
nfs | 可以支持三种读写和挂载方式 |
hostpath | 只支持ReadWriteOnce,其他两个都不支持 |
ISCSI | 不支持ReadWriteMany |
iscsiadm -m session -P 3 | |
iscsiadm | 查看服务器是否有ISCSI设备 |
-m session | 指定操作的会话模块,管理iscsi |
-P 3 | 显示详细信息的级别,级别就是3,显示详细信息 |
Retain | 保留,pod和挂载点的数据不会被删除(默认策略) |
Recycle | 回收,PV上的数据会被删除,挂载点的数据也会被删除 |
Delete | 删除,解绑时会自动删除PV上的数据,本地硬盘不能使用,只有云平台(AWS、EBS、GCE)支持动态卷、可以使用,PV不再可用(云平台自己处理) |
(6)配置集群回收PV资源:Recycle
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,运维负责和开发沟通好,期望的读写和挂载类型,以及存储空间 |
①卷插件(Provisioner):k8s本身支持的动态PV创建不包括nfs,要需要声明和安装一个外部插件(nfs使用的是nfs-client) | |
Provisioner | 存储分配器:动态创建PV,然后根据PVC的请求自动绑定和使用 |
②StorageClass:定义PV的属性、存储类型、大小、回收策略 |
动态请求的过程 |
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 |
NFS Provisioner:是一个插件,没有权限是无法在集群中获取k8s的消息。这个插件要有权限能够监听apiserver、获取(个体)、list(获取集群的列表资源)、create、delete、watch(监听事件) |
rbac:role-based access control(基础权限控制),定义角色在集群中可以使用的权限 |
1.20版本之后有一个新的机制: * selflink:api的资源对象之一,表示资源对象在集群当中自身的一个连接,self-link是一个唯一的标识符号,可以用于标识k8s集群当中每个资源的对象 * self-link的值是一个url,也是指向该资源对象在k8s中的api路径 * self-link的作用:更好的实现资源对象的查找和引用 |
* nfs-provisioner的客户端,以pod的方式运行在集群中,监听k8s集群当中PV的请求,动态的创建与nfs服务器相关的PV * 容器内使用的配置,在nfs-provisioner当中定义好环境变量,传给容器 * 环境变量:storageclass的名称、nfs服务器的地址、nfs的目录 |
kubectl get storageclasses.storage.k8s.io | |
NAME | storageclass的名称 |
PROVISIONER | 对应的创建PV的provisioner的插件 |
RECLAIMPOLICY | 回收策略,保留 |
VOLUMEBINDINGMODE | 卷绑定模式,immediate表示PVC请求创建PV时,系统会立即绑定一个可用的PV ②waitforfirstconsumer:第一个使用者出现之后再绑定PV |
ALLOWVOLUMEEXPANSION | true表示可以在运行时可以对PV进行扩容 |