K8S部署nfs-client-provisioner实现PV自动供给

0x00 介绍

1、NFS-Subdir-External-Provisioner

在Kubernetes中，一个PersistentVolume（PV）只能绑定到一个PersistentVolumeClaim（PVC）。PV和PVC之间是一对一的关系，每个PVC只能绑定到一个PV。
使用支持动态PV和PVC创建的存储插件，您可以为每个PVC动态创建一个独立的PV。这样，每个PVC都有自己的PV，但它们可以共享相同的存储资源。
部署 NFS-Subdir-External-Provisioner 提供动态分配卷，NFS-Subdir-External-Provisioner是一个自动配置卷程序，它使用现有的和已配置的 NFS 服务器来支持通过持久卷声明动态配置 Kubernetes 持久卷。 持久卷被配置为：${namespace}-${pvcName}-${pvName}。 此组件是对 nfs-client-provisioner 的扩展，nfs-client-provisioner 已经不提供更新，且 nfs-client-provisioner 的 Github 仓库已经迁移到 NFS-Subdir-External-Provisioner 的仓库。 GitHub 地址：https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

2、StorageClass

StorageClass充当PV和PVC之间的中间层，它定义了如何动态创建PersistentVolume（PV）。当您创建一个PVC并指定一个StorageClass时，Kubernetes会根据该StorageClass的定义自动创建一个符合要求的PV来满足PVC的需求。可以将StorageClass理解为一种存储资源的池。当您创建一个PVC并指定了某个StorageClass时，Kubernetes会根据该StorageClass的定义来动态创建一个PV，并将其绑定到该PVC上。

0x01 部署 nfs-client-provisioner

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: kube-system
---
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: kube-system
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: kube-system
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
  # replace with namespace where provisioner is deployed
  namespace: kube-system
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: kube-system
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-client-provisioner
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: registry.cn-beijing.aliyuncs.com/mydlq/nfs-subdir-external-provisioner:v4.0.0
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: nfs-client # nfs-provisioner的名称，以后设置的storageclass要和这个保持一致
            - name: NFS_SERVER
              value: 172.30.82.223 # NFS服务器地址，和 volumes 保持一致
            - name: NFS_PATH
              value: /nfs/k8s  # nfs服务器共享地址
      volumes:
        - name: nfs-client-root
          nfs:
            server: 172.30.82.223  # nfs服务器的地址
            path: /nfs/k8s   # nfs服务器共享地址

0x02 创建NFS StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storage
  annotations:
    storageclass.kubernetes.io/is-default-class: "true" # 设置为默认的storageclass
provisioner: nfs-client # 动态卷分配者名称，必须和上面创建的"provisioner"变量中设置的Name一致
parameters:
  archiveOnDelete: "true" # 设置为"false"时删除PVC不会保留数据，"true"则保留数据

0x03 创建pod与pvc进行测试

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-pvc
spec:
  storageClassName: nfs-storage # 需要与上面创建的storageclass的名称一致
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi
---
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
    - name: test-container
      restartPolicy: "Never"
      image: busybox:latest
      command:
        - "/bin/sh"
        - "-c"
        - "touch /mnt/SUCCESS && exit 0 || exit 1" # 创建一个名称为"SUCCESS"的文件
      args: []
      volumeMounts:
        - name: nfs-pvc
          mountPath: "/mnt"
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: test-pvc

删除PVC需谨慎
可以看到已经生成 SUCCESS 该文件，并且可知通过 NFS Provisioner 创建的目录命名方式为"namespace名称-pvc名称-pv名称"，pv 名称是随机 字符串，所以每次只要不删除 PVC，那么 Kubernetes 中的与存储绑定将不会丢失，要是删除 PVC 也就意味着删除了绑定的文件夹，下次就算重 新创建相同名称的 PVC，生成的文件夹名称也不会一致，因为 PV 名是随机生成的字符串，而文件夹命名又跟 PV 有关,所以删除 PVC 需谨慎。