创建pv时,先要创建各种固定大小的PV,而这些PV都是手动创建的,当业务量上来时,需要创建很多的PV,过程非常麻烦。
而且开发人员在申请PVC资源时,还不一定有匹配条件的PV可用,这又带来了新的问题。
于是Kubernetes提供了StorageClass来动态创建PV,StorageClass大大简化了PV的创建过程。
当申请PVC资源时, 如果匹配到满足条件的StorageClass,还会自动为PVC创建对应大小的 PV并进行绑定。
下面就来仔细讲讲现在如何一步步的通过创建StorageClass动态创建PV从而实现持久化存储的。
Kubernetes是分布式容器集群,如何在多个Pod之间或多 个Node之间进行数据存储和共享是非常重要的问题。
Kubernetes引入了网络存储卷,它支持为数众多的云提供商的产品和网络存储方案,如 NFS/iSCSI/GlusterFS/RDB/azureDisk/flocker等
网络存储卷还能够 满足持久化数据的要求,这些数据将永久保存。
网络存储卷是集成各种第三方的存储系统,不同的服务商提供的配置有一些不同,NFS只是其中一种。
资源有限,此处我选择了master作为NFS服务器





注意:如果使用云服务器,需要开放一下端口,否则客户端连接不上。使用:rpcinfo -p 查看需要开放的端口。注意有tcp和udp:

如果出现clnt_create: RPC: Port mapper failure - Timed out,使用云服务的话大概率是接口没开放。
Kubernetes支持为数众多的 云提供商和网络存储方案,如 NFS/iSCSI/GlusterFS/RDB/azureDisk/flocker等。但因为网络存储卷 通常是集成各种第三方的存储系统,所以在配置上各有差别。
不同的存储的配置参数不太一样,这些参数应该是存储管理员关注的,而非开发人员,Kubernetes提供了3种基于存储的抽象对象—— PersistentVolume(PV)、StorageClass和 PersistentVolumeClaim(PVC),以支持基础设施和应用之间的分离。
存储管理人员设置 PV或StorageClass,并在里面配置存储系统和参数
开发人员只 需要创建PVC来申请指定空间的资源以存储与共享数据即可,无须再关 注存储的具体实现和操作。
当删除PVC时,它写入具体存储资源中的数据可以根据回收策略自动清理。
PV表示持久存储卷,定义了Kubernetes集群中可用的存储资源, 其中包含存储资源实现的细节,如包含如何使用 NFS/iSCSI/GlusterFS/RDB/azureDisk/flocker 等资源的具体设置。
PVC表示持久存储卷的申请,是由用户发起的对存储资源的请求。 申请中只包含请求资源的大小和读写访问模式,无须关注具体的资源 实现细节,Kubernetes会自动为其绑定符合条件的PV
StorageClass是通过存储分配器(provisioner)来动态分配PV 的,但是Kubernetes官方内置的存储分配器并不支持NFS,所以需要额外安装NFS存储分配器。
在node节点创建nfs-client-provisioner-authority.yaml文件
apiVersion: v1kind: ServiceAccountmetadata: name: nfs-client-provisioner namespace: default---kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata: name: nfs-client-provisioner-runnerrules: - 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: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: run-nfs-client-provisionersubjects: - kind: ServiceAccount name: nfs-client-provisioner # replace with namespace where provisioner is deployed namespace: defaultroleRef: kind: ClusterRole name: nfs-client-provisioner-runner apiGroup: rbac.authorization.k8s.io---kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: name: leader-locking-nfs-client-provisioner namespace: defaultrules: - apiGroups: [""] resources: ["endpoints"] verbs: ["get", "list", "watch", "create", "update", "patch"]---kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: leader-locking-nfs-client-provisioner namespace: defaultsubjects: - kind: ServiceAccount name: nfs-client-provisioner namespace: defaultroleRef: kind: Role name: leader-locking-nfs-client-provisioner apiGroup: rbac.authorization.k8s.io
apiVersion: apps/v1kind: Deploymentmetadata: name: nfs-client-provisioner labels: app: nfs-client-provisioner namespace: defaultspec: replicas: 1 strategy: type: Recreate selector: matchLabels: app: nfs-client-provisioner template: metadata: labels: app: nfs-client-provisioner spec: serviceAccountName: nfs-client-provisioner containers: - name: nfs-client-provisioner image: quay.io/external_storage/nfs-client-provisioner:latest volumeMounts: - name: nfs-client-root mountPath: /persistentvolumes env: - name: PROVISIONER_NAME # 存储分配器的默认名称 value: fuseim.pri/ifs - name: NFS_SERVER # NFS服务器地址 value: xx.xx.236.113 - name: NFS_PATH # NFS共享目录地址 value: /data/k8snfs volumes: - name: nfs-client-root nfs: server: xx.xx.236.113 # NFS服务器地址 path: /data/k8snfs # NFS共享目录

apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: managed-nfs-storage # StorageClass名称 # 存储分配器名称provisioner: fuseim.pri/ifs # 对应“nfs-client-provisioner.yaml”文件中env.PROVISIONER_NAME.value # 允许pvc创建后扩容allowVolumeExpansion: Trueparameters: archiveOnDelete: "false" # 资源删除策略,“true”表示删除PVC时,同时删除绑定的PV,false删除PVC时,对应的PV不会删除
apiVersion: v1kind: PersistentVolumeClaimmetadata: name: testpvcspec: accessModes: - ReadWriteMany storageClassName: "managed-nfs-storage" resources: requests: storage: 500Mi
此时发现,pvc一直是pending状态,并没有默认分配PV。 分析,可能是存储分配器除了问题
selfLink was empty 在k8s集群 v1.20之前都存在,在v1.20之后被删除,需要在/etc/kubernetes/manifests/kube-apiserver.yaml 添加参数 - --feature-gates=RemoveSelfLink=false
如下所示:

稍等一会,再进行查看PV和PVC
可以看到PV已经被自动创建,且PV,PVC的状态已经均为绑定状态。

本文参考博客:https://blog.csdn.net/zhang19903848257/article/details/125887017