首页 > 网站技巧 > 服务器 > 云和虚拟化 > 云其它 > k8s使用NFS为StorageClass提供动态存储

k8s如何使用NFS作为StorageClass提供动态存储

2024-09-30 10:32:11 作者：小马运维的一天

本文主要介绍了k8s中的StorageClass,包括其定义、引入的原因、实现方式、定义方法以及回收策略对数据的影响等,首先,StorageClass是在K8s集群中创建用于动态PV的管理,可以链接至不同的后端存储,对存储的请求可以指向StorageClass

一、概要

本文主要以下几方面介绍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。

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

k8s如何使用NFS作为StorageClass提供动态存储

一、概要

二、什么是StorageClass

三、为什么要引入StorageClass

四、StorageClass实现方式

五、定义StorageClass（NFS）

1.环境准备

2.创建NFS的sa及rbac

3.创建NFS资源的StroageClass

4.创建NFS provisioner

5.查看状态

6.创建测试pod验证

六、关于StorageClass回收策略对数据的影响

1.第一种配置

2.第二种配置

3.第三种配置

4第四种配置

七、设置默认的StorageClass

总结

您可能感兴趣的文章: