一、概要
本文主要以下几方面介绍k8s中的StorageClass:
- 什么是StorageClass
- 为什么要引入StorageClass
- StorageClass实现方式
- 定义StorageClass(NFS)
- 关于StorageClass回收策略对数据的影响
- 设置默认的StorageClass
二、什么是StorageClass
存储类,在K8s集群中创建用于动态PV的管理,可以链接至不同的后端存储,比如Ceph、GlusterFS、NFS等。之后对存储的请求可以指向StorageClass,然后StorageClass会自动的创建、删除PV。
每个 StorageClass 都包含provisioner、parameters和reclaimPolicy字段, 这些字段会在 StorageClass 需要动态制备 PersistentVolume 以满足 PersistentVolumeClaim (PVC) 时使用到。
StorageClass可以定义以下属性:
- volumeBindingMode:指定持久卷绑定模式,可以是"Immediate"或"WaitForFirstConsumer"。"Immediate"表示持久卷将立即绑定到声明的请求,而"WaitForFirstConsumer"表示持久卷将等待第一个消费者使用它之前才进行绑定
- provisioner:指定用于创建持久卷的存储提供商。不同的存储提供商可能具有不同的实现和配置要求
- parameters:存储提供商特定的参数,用于配置持久卷的创建和属性。例如,可以指定存储容量、存储类别、访问模式等
- reclaimPolicy:指定在释放持久卷时应如何处理底层存储资源。可以选择"Retain"(保留)、"Delete"(删除)或"Recycle"(回收)
- MountOptions:通过StorageClass动态创建的PV可以使用MountOptions指定挂载参数。如果指定的卷插件不支持指定的挂载选项,就不会被创建成功,因此在设置时需要进行确认。
- AllowVolumeExpansion:是否允许对PV进行扩容,需要后端存储支持,一般不推荐进行缩容
注意:StorageClass 对象的命名很重要,用户使用这个命名来请求生成一个特定的类。 当创建 StorageClass 对象时,管理员设置 StorageClass 对象的命名和其他参数,一旦创建了对象就不能再对其更新。
三、为什么要引入StorageClass
虽然使用PV和PVC能屏蔽一些存储使用上的细节,降低了存储使用的复杂度,但是也会有另一个问题无法解决。当公司Kubernetes集群很多,并且使用它们的技术人员过多时,对于PV的创建是一个很耗时、耗力的工作,并且达到一定规模后,过多的PV将难以维护。所以就需要某种机制用于自动管理PV的生命周期,比如创建、删除、自动扩容等,于是Kubernetes就设计了一个名为StorageClass(缩写为SC,没有命名空间隔离性)的东西,通过它可以动态管理集群中的PV,这样Kubernetes管理员就无须浪费大量的时间在PV的管理中。
在Kubernetes中,管理员可以只创建StorageClass“链接”到后端不同的存储,比如Ceph、GlusterFS、OpenStack的Cinder、其他公有云提供的存储等,之后有存储需求的技术人员,创建一个PVC指向对应的StorageClass即可,StorageClass会自动创建PV供Pod使用,也可以使用StatefulSet的volumeClaimTemplate自动分别为每个Pod申请一个PVC。
四、StorageClass实现方式
StorageClass的实现方式取决于Kubernetes集群所使用的存储插件和存储提供商。不同的存储插件和提供商可能有不同的实现细节和配置要求。
针对不同厂商的存储管理,k8s编写相应的代码。而不同厂商为了适配k8s,都会提供一个驱动(CSI或者Fiex Volume)安装到k8s集群中,然后StorageClass只需要配置该驱动即可,驱动器会代替StorageClass管理存储。
每个 StorageClass 都有一个制备器(Provisioner),用来决定使用哪个卷插件制备 PV。 该字段必须指定。
五、定义StorageClass(NFS)
下面演示一个基本的StorageClass配置,使用nfs作为后端存储,NFS类型的sc只建议在测试环境使用,因为NFS存在性能瓶颈及单点故障问题,生产环境推荐使用分布式存储。
1.环境准备
主机IP | 用途 | 版本 | 安装方式 | 备注 |
---|---|---|---|---|
10.3.248.136 | k8s-master | v1.24.4 | 二进制 | 安装了nfs-until |
10.3.248.143 | k8s-node01 | v1.24.4 | 二进制 | 安装了nfs-until |
10.3.248.144 | k8s-node02 | v1.24.4 | 二进制 | 安装了nfs-until |
10.3.248.134 | NFS-SERVER |
2.创建NFS的sa及rbac
vim nfs-rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: 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: ServiceAccount
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: default
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: 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 deployed
namespace: 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: ServiceAccount
name: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: default
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io
创建
kubectl apply -f nfs-rbac.yaml
3.创建NFS资源的StroageClass
vim nfs-storageClass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-nfs-storage
provisioner: test-nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:
# archiveOnDelete: "false"
# archiveOnDelete: "true"
创建
kubectl apply -f nfs-storageClass.yaml
4.创建NFS provisioner
vim nfs-provisioner.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
labels:
app: nfs-client-provisioner
# replace with namespace where provisioner is deployed
namespace: default #与RBAC文件中的namespace保持一致
spec:
replicas: 1
selector:
matchLabels:
app: nfs-client-provisioner
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: registry.cn-hangzhou.aliyuncs.com/k8s_study_rfb/nfs-subdir-external-provisioner:v4.0.0
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: test-nfs-storage #provisioner名称,请确保该名称与 nfs-StorageClass.yaml文件中的provisioner名称保持一致
- name: NFS_SERVER
value: 10.3.248.134 #NFS Server IP地址
- name: NFS_PATH
value: "/data/k8s" #NFS挂载卷
volumes:
- name: nfs-client-root
nfs:
server: 10.3.248.134 #NFS Server IP地址
path: "/data/k8s" #NFS 挂载卷
创建
kubectl apply -f nfs-provisioner.yaml
5.查看状态
# kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
managed-nfs-storage test-nfs-storage Retain Immediate false 13d
6.创建测试pod验证
创建pvc链接至nfs的的storgeClass
vim pvc-claim.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: test-claim
annotations:
#与nfs-storageClass.yaml metadata.name保持一致
volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
storageClassName: "managed-nfs-storage"
accessModes:
- ReadWriteMany
#- ReadWriteOnce
resources:
requests:
storage: 1Gi
创建并查看PVC:要确保状态为Bound,如果为pending,肯定是有问题 ,需要进一步检查原因
# kubectl apply -f pvc-claim.yaml
# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
test-claim Bound pvc-ae9942dc-73ea-4cea-ab1b-f26baf0b61f9 1Gi RWX managed-nfs-storage 4m20s
创建pod
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-pvc
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: 10.3.248.134:10080/k8s/nginx:1.25.2
ports:
- containerPort: 80
volumeMounts:
- mountPath: /usr/share/nginx/html
name: nfs-pvc-claim
volumes:
- name: nfs-pvc-claim # name of volume
persistentVolumeClaim:
claimName: test-claim # name of pvc
创建
kubectl apply -f pvc-nginx.yaml
进入pod创建一个文件
# kubectl get pod
NAME READY STATUS RESTARTS AGE
nfs-client-provisioner-5d5f87db5b-v5r2r 1/1 Running 0 3d23h
nginx-deployment-pvc-7774b9d564-rnwl2 1/1 Running 0 3m2s
# kubectl exec -it nginx-deployment-pvc-7774b9d564-rnwl2 -- bash
root@nginx-deployment-pvc-7774b9d564-rnwl2:/# cd /usr/share/nginx/html/
root@nginx-deployment-pvc-7774b9d564-rnwl2:/usr/share/nginx/html# echo "Hello NFS StorgeClass" >index.html
root@nginx-deployment-pvc-7774b9d564-rnwl2:/usr/share/nginx/html#
exit
访问nginx的pod
# kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nfs-client-provisioner-5d5f87db5b-v5r2r 1/1 Running 0 3d23h 172.16.178.203 mongodb <none> <none>
nginx-deployment-pvc-7774b9d564-rnwl2 1/1 Running 0 5m46s 172.16.178.212 mongodb <none> <none>
# curl 172.16.178.212
Hello NFS StorgeClass
删除pod再次访问
# kubectl delete pod nginx-deployment-pvc-7774b9d564-rnwl2
pod "nginx-deployment-pvc-7774b9d564-rnwl2" deleted
# kubectl get pod -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nfs-client-provisioner-5d5f87db5b-v5r2r 1/1 Running 0 4d 172.16.178.203 mongodb <none> <none>
nginx-deployment-pvc-7774b9d564-2gmfk 1/1 Running 0 26s 172.28.82.243 k8s-master <none> <none>
# curl 172.28.82.243
Hello NFS StorgeClass
此时我们可以发现进入pod创建的文件已经持久化存储了,即使删除了pod文件不会丢失。
六、关于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被删除后数据依然保留
七、设置默认的StorageClass
官网地址改变默认 StorageClass | Kubernetes
kubectl patch命令
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
这里的standard
是你选择的 StorageClass 的名字。
注意:最多只能有一个 StorageClass 能够被标记为默认。 如果它们中有两个或多个被标记为默认,Kubernetes 将忽略这个注解, 也就是它将表现为没有默认 StorageClass。