NFS动态分配PV理解
一、什么是StorageClass
Kubernetes提供了一套可以自动创建PV的机制,即:Dynamic Provisioning.而这个机制的核心在于:StorageClass这个API对象.StorageClass对象会定义下面两部分内容:
1,PV的属性.比如,存储类型,Volume的大小等.
2,创建这种PV需要用到的存储插件
有了这两个信息之后,Kubernetes就能够根据用户提交的PVC,找到一个对应的StorageClass,之后Kubernetes就会调用该StorageClass声明的存储插件,进而创建出需要的PV.
但是其实使用起来是一件很简单的事情,你只需要根据自己的需求,编写YAML文件即可,然后使用kubectl create命令执行即可
二、为什么需要StorageClass
在一个大规模的Kubernetes集群里,可能有成千上万个PVC,这就意味着运维人员必须实现创建出这个多个PV,此外,随着项目的需要,会有新的PVC不断被提交,那么运维人员就需要不断的添加新的,满足要求的PV,否则新的Pod就会因为PVC绑定不到PV而导致创建失败.而且通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求
而且不同的应用程序对于存储性能的要求可能也不尽相同,比如读写速度、并发性能等,为了解决这一问题,Kubernetes 又为我们引入了一个新的资源对象:StorageClass,通过 StorageClass 的定义,管理员可以将存储资源定义为某种类型的资源,比如快速存储、慢速存储等,用户根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了,这样就可以根据应用的特性去申请合适的存储资源了。
三、StorageClass运行原理及部署流程
要使用 StorageClass,我们就得安装对应的自动配置程序,比如我们这里存储后端使用的是 nfs,那么我们就需要使用到一个 nfs-client 的自动配置程序,我们也叫它 Provisioner,这个程序使用我们已经配置好的 nfs 服务器,来自动创建持久卷,也就是自动帮我们创建 PV。
1.自动创建的 PV 以${namespace}-${pvcName}-${pvName}这样的命名格式创建在 NFS 服务器上的共享数据目录中
2.而当这个 PV 被回收后会以archieved-${namespace}-${pvcName}-${pvName}这样的命名格式存在 NFS 服务器上。
1.原理及部署流程说明
详细的运作流程可以参考下图:
搭建StorageClass+NFS,大致有以下几个步骤:
1.创建一个可用的NFS Serve
2.创建Service Account.这是用来管控NFS provisioner在k8s集群中运行的权限
3.创建StorageClass.负责建立PVC并调用NFS provisioner进行预定的工作,并让PV与PVC建立管理
4.创建NFS provisioner.有两个功能,一个是在NFS共享目录下创建挂载点(volume),另一个则是建了PV并将PV与NFS的挂载点建立关联
四、创建StorageClass
1.创建NFS共享服务
该步骤比较简单不在赘述,大家可以自行百度搭建
当前环境NFS server及共享目录信息
IP: 172.16.155.227
Export PATH: /data/volumes/
2.使用以下文档配置account及相关权限
rbac.yaml: #唯一需要修改的地方只有namespace,根据实际情况定义
apiVersion: v1
kind: ServiceAccount
metadata:name: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default #根据实际环境设定namespace,下面类同
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: nfs-client-provisioner-runner
rules:- apiGroups: [""]resources: ["persistentvolumes"]verbs: ["get", "list", "watch", "create", "delete"]- apiGroups: [""]resources: ["persistentvolumeclaims"]verbs: ["get", "list", "watch", "update"]- apiGroups: ["storage.k8s.io"]resources: ["storageclasses"]verbs: ["get", "list", "watch"]- apiGroups: [""]resources: ["events"]verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: run-nfs-client-provisioner
subjects:- kind: ServiceAccountname: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default
roleRef:kind: ClusterRolename: nfs-client-provisioner-runnerapiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: leader-locking-nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default
rules:- apiGroups: [""]resources: ["endpoints"]verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: leader-locking-nfs-client-provisioner
subjects:- kind: ServiceAccountname: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default
roleRef:kind: Rolename: leader-locking-nfs-client-provisionerapiGroup: rbac.authorization.k8s.io
3.创建NFS资源的StorageClass
nfs-StorageClass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: managed-nfs-storage
provisioner: qgg-nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:archiveOnDelete: "false"
4.创建NFS provisioner
nfs-provisioner.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nfs-client-provisionerlabels:app: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default #与RBAC文件中的namespace保持一致
spec:replicas: 1selector:matchLabels:app: nfs-client-provisionerstrategy:type: Recreateselector:matchLabels:app: nfs-client-provisionertemplate:metadata:labels:app: nfs-client-provisionerspec:serviceAccountName: nfs-client-provisionercontainers:- name: nfs-client-provisionerimage: quay.io/external_storage/nfs-client-provisioner:latestvolumeMounts:- name: nfs-client-rootmountPath: /persistentvolumesenv:- name: PROVISIONER_NAMEvalue: qgg-nfs-storage #provisioner名称,请确保该名称与 nfs-StorageClass.yaml文件中的provisioner名称保持一致- name: NFS_SERVERvalue: 172.16.155.227 #NFS Server IP地址- name: NFS_PATH value: /data/volumes #NFS挂载卷volumes:- name: nfs-client-rootnfs:server: 172.16.155.227 #NFS Server IP地址path: /data/volumes #NFS 挂载卷
五、创建测试pod,检查是否部署成功
1.Pod+PVC
创建PVC
test-claim.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: test-claimannotations:volume.beta.kubernetes.io/storage-class: "managed-nfs-storage" #与nfs-StorageClass.yaml metadata.name保持一致
spec:accessModes:- ReadWriteManyresources:requests:storage: 1Mi
确保PVC状态为Bound
[root@k8s-master-155-221 deploy]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
test-claim Bound pvc-aae2b7fa-377b-11ea-87ad-525400512eca 1Mi RWX managed-nfs-storage 2m48s
[root@k8s-master-155-221 deploy]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-aae2b7fa-377b-11ea-87ad-525400512eca 1Mi RWX Delete Bound default/test-claim managed-nfs-storage 4m13s
创建测试pod,查看是否可以正常挂载
test-pod.yaml
kind: Pod
apiVersion: v1
metadata:name: test-pod
spec:containers:- name: test-podimage: busybox:1.24command:- "/bin/sh"args:- "-c"- "touch /mnt/SUCCESS && exit 0 || exit 1" #创建一个SUCCESS文件后退出volumeMounts:- name: nfs-pvcmountPath: "/mnt"restartPolicy: "Never"volumes:- name: nfs-pvcpersistentVolumeClaim:claimName: test-claim #与PVC名称保持一致
检查结果:
[root@nginx-keepalived-155-227 ~]# ll /data/volumes/default-test-claim-pvc-aae2b7fa-377b-11ea-87ad-525400512eca/ #文件规则是按照${namespace}-${pvcName}-${pvName}创建的
总用量 0
-rw-r--r-- 1 root root 0 2020-01-15 17:51 SUCCESS #下面有一个 SUCCESS 的文件,证明我们上面的验证是成功
2.StateFulDet+volumeClaimTemplates自动创建PV
创建无头服务及statefulset
nginx-statefulset.yaml
---
apiVersion: v1
kind: Service
metadata:name: nginx-headlesslabels:app: nginx
spec:ports:- port: 80name: webclusterIP: None #注意此处的值,None表示无头服务selector:app: nginx
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:name: web
spec:serviceName: "nginx"replicas: 2 #两个副本template:metadata:labels:app: nginxspec:containers:- name: nginximage: ikubernetes/myapp:v1ports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: wwwannotations:volume.beta.kubernetes.io/storage-class: "managed-nfs-storage" #managed-nfs-storage为我们创建的storage-class名称spec:accessModes: [ "ReadWriteOnce" ]resources:requests:storage: 1Gi
检查结果:
集群节点上
[root@k8s-master-155-221 classStorage]#kubectl delete -f nginx-statefulset.yaml
[root@k8s-master-155-221 classStorage]# kubectl get pods -l app=nginx #检查pod状态
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 115m
web-1 1/1 Running 0 114m
[root@k8s-master-155-221 classStorage]# kubectl get pvc #查看PVC
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
test-claim Bound pvc-aae2b7fa-377b-11ea-87ad-525400512eca 1Mi RWX managed-nfs-storage 19h
www-web-0 Bound pvc-4d7e342a-3810-11ea-87ad-525400512eca 1Gi RWO managed-nfs-storage 115m
www-web-1 Bound pvc-5431c8ba-3810-11ea-87ad-525400512eca 1Gi RWO managed-nfs-storage 115m
[root@k8s-master-155-221 classStorage]# kubectl get pv #查看PV
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-4d7e342a-3810-11ea-87ad-525400512eca 1Gi RWO Delete Bound default/www-web-0 managed-nfs-storage 115m
pvc-5431c8ba-3810-11ea-87ad-525400512eca 1Gi RWO Delete Bound default/www-web-1 managed-nfs-storage 115m
pvc-aae2b7fa-377b-11ea-87ad-525400512eca 1Mi RWX Delete Bound default/test-claim managed-nfs-storage 19h
NFS Server上:
[root@nginx-keepalived-155-227 ~]# cd /data/volumes/
[root@nginx-keepalived-155-227 volumes]# ll #注意目录的命名格式
总用量 0
drwxrwxrwx 2 root root 21 2020-01-15 17:51 default-test-claim-pvc-aae2b7fa-377b-11ea-87ad-525400512eca
drwxrwxrwx 2 root root 6 2020-01-16 11:28 default-www-web-0-pvc-4d7e342a-3810-11ea-87ad-525400512eca
drwxrwxrwx 2 root root 6 2020-01-16 11:28 default-www-web-1-pvc-5431c8ba-3810-11ea-87ad-525400512eca
[root@nginx-keepalived-155-227 volumes]# echo "web-00" > default-www-web-0-pvc-4d7e342a-3810-11ea-87ad-525400512eca/index.html #分别创建不同的index文件
[root@nginx-keepalived-155-227 volumes]# echo "web-01" > default-www-web-1-pvc-5431c8ba-3810-11ea-87ad-525400512eca/index.html
集群任意节点上:
[root@k8s-master-155-221 classStorage]# kubectl exec -it pod-cm-1 -- /bin/sh #进入集群中任意pod中,解析nginx-headless 服务/ # nslookup nginx-headless
nslookup: can't resolve '(null)': Name does not resolveName: nginx-headless
Address 1: 172.17.136.7 172-17-136-7.nginx-headless.default.svc.cluster.local #可以看到有两个地址
Address 2: 172.17.248.5 172-17-248-5.nginx-headless.default.svc.cluster.local
[root@k8s-master-155-221 classStorage]# curl 172.17.248.5 #分别访问一下查看结果
web-00
[root@k8s-master-155-221 classStorage]# curl 172.17.136.7
web-01
#对于statefulset我们可以通过添加/删除pod副本的数量,观察PV/PVC的状态及变化.
六、关于StorageClass回收策略对数据的影响
1.第一种配置
archiveOnDelete: "false" reclaimPolicy: Delete #默认没有配置,默认值为Delete
测试结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
3.删除PVC后,PV被删除且NFS Server对应数据被删除
2.第二种配置
archiveOnDelete: "false" reclaimPolicy: Retain
测试结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
3.删除PVC后,PV不会别删除,且状态由Bound变为Released,NFS Server对应数据被保留
4.重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中
3.第三种配置
archiveOnDelete: "ture" reclaimPolicy: Retain
结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
3.删除PVC后,PV不会别删除,且状态由Bound变为Released,NFS Server对应数据被保留
4.重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中
4.第四种配置
archiveOnDelete: "ture" reclaimPolicy: Delete
结果:
1.pod删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
2.sc删除重建后数据依然存在,旧pod名称及数据依然保留给新pod使用
3.删除PVC后,PV不会别删除,且状态由Bound变为Released,NFS Server对应数据被保留
4.重建sc后,新建PVC会绑定新的pv,旧数据可以通过拷贝到新的PV中
总结:除以第一种配置外,其他三种配置在PV/PVC被删除后数据依然保留
七、常见问题
1.如何设置默认的StorageClass
我们可以用 kubectl patch 命令来更新:
[root@k8s-master-155-221 classStorage]# kubectl get sc #查看当前sc
NAME PROVISIONER AGE
managed-nfs-storage qgg-nfs-storage 20h
[root@k8s-master-155-221 classStorage]# kubectl patch storageclass managed-nfs-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' #设置managed-nfs-storage为默认后端存储
storageclass.storage.k8s.io/managed-nfs-storage patched
[root@k8s-master-155-221 classStorage]# kubectl get sc #再次查看,注意是否有default标识
NAME PROVISIONER AGE
managed-nfs-storage (default) qgg-nfs-storage 20h
[root@k8s-master-155-221 deploy]# kubectl patch storageclass managed-nfs-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' #取消默认存储后端
storageclass.storage.k8s.io/managed-nfs-storage patched
[root@k8s-master-155-221 deploy]# kubectl get sc
NAME PROVISIONER AGE
managed-nfs-storage qgg-nfs-storage 20h
YAML文件
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: managed-nfs-storageannotations:"storageclass.kubernetes.io/is-default-class": "true" #添加此注释
provisioner: qgg-nfs-storage #or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:archiveOnDelete: "false"
2.如何使用默认的StorageClass
如果集群有一个默认的StorageClass能够满足我们的需求,那么剩下所有需要做的就是创建PersistentVolumeClaim(PVC),剩下的都有默认的动态配置搞定,包括无需去指定storageClassName:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: mypvcnamespace: testns
spec:accessModes:- ReadWriteOnceresources:requests:storage: 10Gi
3.修改默回收策略(默认为Delete)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: managed-nfs-storageannotations:
provisioner: qgg-nfs-storage #or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:archiveOnDelete: "ture" #暂时不清楚该值对回收策略产生什么影响
reclaimPolicy: Retain #只有NFS 和hostPth支持两种回收策略
4.能过删除/关闭默认的StorageClass
不能删除默认的StorageClass,因为它是作为集群的add-on安装的,如果它被删除,会被重新安装。
当然,可以停掉默认的StorageClass行为,通过删除annotation:storageclass.beta.kubernetes.io/is-default-class,或者设置为false。
如果没有StorageClass对象标记默认的annotation,那么PersistentVolumeClaim对象(在不指定StorageClass情况下)将不自动触发动态配置。相反,它们将回到绑定可用的*PersistentVolume(PV)*的状态。
5.当删除PersistentVolumeClaim(PVC)会发生什么
如果一个卷是动态配置的卷,则默认的回收策略为“删除”。这意味着,在默认的情况下,当PVC被删除时,基础的PV和对应的存储也会被删除。如果需要保留存储在卷上的数据,则必须在PV被设置之后将回收策略从delete更改为retain。
参考文档:https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client
NFS动态分配PV理解相关推荐
- kubernetes存储系统介绍(Volume、PV、dynamic provisioning,阿里云服务器nfs创建pv,hostpath创建pv)
全栈工程师开发手册 (作者:栾鹏) 架构系列文章 K8S存储系统 K8S的存储系统从基础到高级又大致分为三个层次:普通Volume,Persistent Volume 和动态存储供应(dynamic ...
- k8s挂载nfs创建pv
K8S创建pv 一.安装nfs 二.创建StorageClass 三.创建pv 一.安装nfs 1.关闭防火墙和selinux 2.安装nfs服务端: yum install nfs-utils rp ...
- 企业项目实战k8s篇(十)Volumes配置管理
Volumes配置管理 一.Volumes概述 二.emptyDir卷 三.hostPath 卷 1.查看pod调度节点是否创建相关目录 2.nfs 四.PersistentVolume持久卷 1.P ...
- Kubernetes Volume及其类型(NFS、SAN) - PV - PVC - PV与PVC与Pod的关系
目录 volume 卷 官方文档:卷 | Kubernetes 一.emptyDir(临时卷) 二.hostPath卷 type字段参数 hostPath 实验: 三.第3方提供的存储卷(百度云.阿里 ...
- 使用nfs为k8s提供pv动态供给存储
环境:k8s一主两从 k8s version: 1.20.2 k8s-master: 192.168.31.200 k8s-node1: 192.168.31.201 k8s-node2: 192.1 ...
- kubernetes 磁盘、PV、PVC
6.1.介绍卷 6.1.1.卷的类型 emptyDir-用于存储临时数据的简单空目录 hostPath-用于将目录从工作节点的文件系统挂载到pod nfs-挂载到pod中的NFS共享卷. 还有其他的如 ...
- PV、PVC、StorageClass详解
1.PV PV全称叫做Persistent Volume,持久化存储卷.它是用来描述或者说用来定义一个存储卷的,这个通常都是有运维或者数据存储工程师来定义.可以理解为是一个网络存储,就是一个实实在在的 ...
- K8S 配置 storageclass 使用 nfs 动态申领本地磁盘空间
系列文章目录 第一章:✨ k8s入门:裸机部署 k8s 集群 第二章:✨ k8s入门:部署应用到 k8s 集群 第三章:✨ k8s入门:service 简单使用 第四章:✨ k8s入门:Statefu ...
- 回收 PV - 每天5分钟玩转 Docker 容器技术(152)
当 PV 不再需要时,可通过删除 PVC 回收. 当 PVC mypvc1 被删除后,我们发现 Kubernetes 启动了一个新 Pod recycler-for-mypv1,这个 Pod 的作用就 ...
最新文章
- 首次用Intellij IDEA打开别人的项目,如何配置Tomcat服务器?
- 恢复Opera11.50地址栏的下拉列表按钮
- 首发|机器学习未来十年:你需要把握的趋势和热点
- springcloud学之前需要掌握什么_学国画之前我们需要准备什么?
- boost::distance用法的测试程序
- 类似ajax封装函数,JS 封装一个async式的AJAX函数
- #20165323 Java实验四 Android程序设计
- dll domodal运行时异常_解决装备疑难,计算机丢失***.dll文件方法「设计画圈」
- 第 89 章 Hardware
- 云中漫步——迎接云计算时代的到来
- 【零基础】PostgreSQL从入门到精通
- java系统过载保护_浅谈过载保护
- s8 android调用相机,android-扎根的Galaxy S8上的设备所有者
- apidoc生成文档时报错
- Android Studio 3.0 正式版本 发行说明 (翻译)
- springboot设置首页
- dbg 寻找main函数
- 晒晒我的厨艺修炼成果
- 运维常见服务安全漏洞修复建议
- 关于AI自动写作的资料