在k8s中使用NFS作为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.136k8s-masterv1.24.4二进制安装了nfs-until
10.3.248.143k8s-node01v1.24.4二进制安装了nfs-until
10.3.248.144k8s-node02v1.24.4二进制安装了nfs-until
10.3.248.134NFS-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。

  • 26
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
首先,你需要安装一个 NFS 服务器,并且在 Kubernetes 集群安装一个 NFS 客户端。 然后,你可以按照以下步骤创建一个动态 NFS 存储的 PV: 1. 创建一个 NFS 存储类: ``` apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: nfs-storage provisioner: my-nfs-provisioner ``` 其,`provisioner` 是你的 NFS 存储服务提供动态卷插件的名称。这个名称需要在你的 Kubernetes 集群注册过。 2. 创建一个 PVC: ``` apiVersion: v1 kind: PersistentVolumeClaim metadata: name: nfs-pvc spec: accessModes: - ReadWriteMany storageClassName: nfs-storage resources: requests: storage: 1Gi ``` 在这个 PVC ,`accessModes` 指定了多个 Pod 可以同时读写这个 PV,`storageClassName` 指定了使用存储类,`resources.requests.storage` 指定了这个 PV 的大小。 3. 创建一个 Pod 并挂载这个 PVC: ``` apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: nginx volumeMounts: - name: nfs-volume mountPath: /mnt/nfs volumes: - name: nfs-volume persistentVolumeClaim: claimName: nfs-pvc ``` 在这个 Pod ,`volumeMounts` 指定了挂载的路径,`volumes` 通过 `persistentVolumeClaim.claimName` 指定了要使用的 PVC。 完成以上步骤后,Kubernetes 会自动创建一个 NFS 存储的 PV,并且将其绑定到这个 PVC 上。当这个 PVC 被挂载到一个 Pod 时,Kubernetes 会自动将这个 PV 挂载到这个 Pod
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值