【Linux39-11】Kubernetes存储之StorageClass与动态pv

1. StorageClass 简介

StirageClass官方文档

StorageClass提供了一种描述存储类（class）的方法，不同的class可能会映射到不同的服务质量等级和备份策略或其他策略等。

每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段， 这些字段会在StorageClass需要动态分配 PersistentVolume 时会使用到。

StorageClass的属性：

• Provisioner（存储分配器）：用来决定使用哪个卷插件分配PV，该字段必须指定。可以指定内部分配器，也可以指定外部分配器。外部分配器的代码地址为：kubernetes-incubator/external-storage，其中包括NFS和Ceph等。
• Reclaim Policy（回收策略）：通过reclaimPolicy字段指定创建的Persistent Volume的回收策略，回收策略包括：Delete 或者 Retain，没有指定默认为Delete。
• 允许卷扩展：PersistentVolume 可以配置为可扩展。将此功能设置为 true 时，允许用户通过编辑相应的 PVC 对象来调整卷大小。当下层 StorageClass 的 allowVolumeExpansion 字段设置为 true 时，以下类型的卷支持卷扩展。此功能仅可用于扩容卷，不能用于缩小卷（具体查看官方文档）
• 更多属性查看官方文档
  
  

2. 动态卷

动态卷供应的实现基于 storage.k8s.io API 组中的 StorageClass API 对象。 集群管理员可以根据需要定义多个 StorageClass 对象，每个对象指定一个卷插件（又名 provisioner）， 卷插件向卷供应商提供在创建卷时需要的数据卷信息及相关参数。

集群管理员可以在集群中定义和公开多种存储（来自相同或不同的存储系统），每种都具有自定义参数集。 该设计也确保终端用户不必担心存储供应的复杂性和细微差别，但仍然能够从多个存储选项中进行选择。

3. NFS Client Provisioner

NFS Client Provisioner是一个automatic provisioner，使用NFS作为存储，自动创建PV和对应的PVC，本身不提供NFS存储，需要外部先有一套NFS存储服务。

• PV以 ${namespace}−${pvcName}-${pvName}的命名格式提供（在NFS服务器上）
• PV回收的时候以 archieved-${namespace}-${pvcName}-${pvName} 的命名格式（在NFS服务器上）
  
  

nfs-client-provisioner 源码地址：

• 旧：https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client（不再更新）
• 新：https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner
  
  

4. 创建nfs类型的动态pv

nfs服务器：192.168.17.250
master：server2
node：server3，server4

部署文档借鉴：https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

镜像支持：heegor/nfs-subdir-external-provisioner:v4.0.0

1）创建目录 nfs-client

2）创建命名空间

kubectl create namespace nfs-client-provisioner

3）配置角色授权+部署NFS Client Provisioner+创建 sc

# nfs-client-provisioner.yaml 
# 配置角色授权
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
---
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: nfs-client-provisioner
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: nfs-client-provisioner
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: nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: nfs-client-provisioner
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io
# 部署NFS Client Provisioner
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
spec:
  replicas: 1
  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: heegor/nfs-subdir-external-provisioner:v4.0.0
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner  # 分配器名称
            - name: NFS_SERVER
              value: 192.168.17.250 # nfs服务器
            - name: NFS_PATH
              value: /nfsdata # nfs服务器挂载路径
      volumes: # nfs卷
        - name: nfs-client-root
          nfs:
            server: 192.168.17.250
            path: /nfsdata
# 创建 NFS SotageClass
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage # SotageClass的名称
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # 分配器的名称
parameters:
  archiveOnDelete: "false" #删除后不会对数据进行打包，true会打包

4）创建 pvc 及 pod（测试）：发现pvc已经与创建好的pv绑定

# pvc.yaml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim
spec:
  storageClassName: managed-nfs-storage
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
---
kind: Pod
apiVersion: v1
metadata:
  name: test-pod
spec:
  containers:
  - name: test-pod
    image: myapp:v1
    volumeMounts:
      - name: nfs-pvc
        mountPath: "/usr/share/nginx/html"
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: test-claim

5）在nfs服务器共享目录下创建测试页

6）测试

7）测试动态：在共享文件修改测试页内容，立即访问pod，动态测试成功！

5. 使用默认StorageClass

1）创建未指定sc的pvc：发现此pvc状态一直为pending悬决

#  pvc2.yml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim-2
spec:
  # storageClassName: managed-nfs-storage
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 5Gi

2）修改之前创建的sc为默认sc

kubectl patch storageclasses <你的sc的名称> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

3）重新创建未指定sc的pvc，发现自动回绑定默认sc