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

更新时间：2024年09月30日 10:33:46 作者：小马运维的一天

本文主要介绍了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内部实现安全的网络隔离方式
Kubernetes网络策略通过定义Pod之间的流量规则,实现安全隔离和最小权限访问,本文详细介绍了网络策略的基本概念、工作原理、配置方法及最佳实践,帮助构建更加安全的集群网络环境
2026-01-01
K8S Helm应用部署与依赖治理实战教程
文章阐述了Kubernetes部署中的三大挑战（环境配置漂移、版本回退失控、依赖治理低效）,并介绍Helm通过声明式模板、版本控制与依赖管理实现标准化配置、环境隔离和版本回滚,提升部署效率与可靠性,对K8S Helm应用部署相关知识感兴趣的朋友一起看看吧
2025-07-07
K8s中Pod处于Pending状态的八种原因分析
文章详细介绍了Pod处于Pending状态的八种常见原因,并提供了相应的排查和解决方法,这些原因包括资源不足、调度约束、存储依赖、镜像问题、配额限制、网络暗礁、系统级异常以及冷门陷阱,每种原因都附带了具体的诊断方法和解决建议,感兴趣的朋友一起看看吧
2025-02-02
MinIO使用基础教程(最新整理)
文章介绍了MinIO云存储服务的快速安装和使用,并通过SpringBoot实现文件上传和查询的功能,感兴趣的朋友跟随小编一起看看吧
2025-03-03
k8s+jenkins实现自动化部署应用至k8s集群方式
本文详细介绍了如何在Jenkins环境下配置和启动Jenkins服务,以及如何使用Jenkins进行自动化部署Nginx应用到Kubernetes集群,文章涵盖了从环境准备、项目配置、代码上传到部署和回滚的全过程,提供了一个完整的自动化部署解决方案
2026-03-03
k8s Ingress实现流量路由规则控制的定义格式类型
这篇文章主要为大家介绍了k8s Ingress 实现流量路由规则控制的定义格式及类型详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪
2023-04-04
K8S的dashboard使用token登录的操作流程
Dashboard 支持 Kubeconfig 和 Token 两种认证方式,这里测试 Token 认证方式登录,本文介绍K8S的dashboard如何使用token登录,感兴趣的朋友跟随小编一起看看吧
2024-06-06
IPVS下CoreDNS滚动更新解析失败原理探究
这篇文章主要为大家介绍了IPVS下CoreDNS滚动更新解析失败原理探究，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪
2023-03-03
RFO SIG之openEuler AWS AMI 制作详解
这篇文章主要为大家介绍了RFO SIG之openEuler AWS AMI 制作详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪
2022-10-10
K8S中应用无法获取用户真实ip问题排查过程
这篇文章主要介绍了K8S中应用无法获取用户真实ip问题排查过程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
2025-07-07