K8S實戰(十七)| 經過 StorageClass 實現動態卷供應

前言

StorageClass 至關於一個建立 PV 的模板,用戶經過 PVC 申請存儲卷,StorageClass 經過模板自動建立 PV,而後和 PVC 進行綁定。html

更新歷史

啓用動態卷供應

建立 StorageClass 對象便可,即建立了模板。linux

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
---  
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

以上文件建立了兩種不一樣類型的 StorageClass,用戶根據本身需求經過 PVC 申請便可。api

使用動態卷供應

用戶經過 PVC 來申請。微信

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast
  resources:
    requests:
      storage: 30Gi

以上文件說明該 PVC 向 storageClassName 爲 fast 的存儲類申請卷,將會獲得一個 PV 來與該 PVC 進行綁定。spa

實踐

《K8S實戰(六)| 配置NFS動態卷提供持久化存儲》 https://blog.zuolinux.com/2020/06/10/nfs-client-provisioner.htmlcode

回收策略

由 StorageClass 動態建立的 PersistentVolume 會在類的 reclaimPolicy 字段中指定回收策略,能夠是 Delete 或者 Retain。htm

若是 StorageClass 對象被建立時沒有指定 reclaimPolicy,它將默認爲 Delete。意味着 PV 被刪除後,原始數據也會被刪除。對象

建議設置爲 Retain。blog

默認 StorageClass

查看當前的默認 StorageClassrem

# kubectl get sc
NAME                            PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage (default)   fuseim.pri/ifs   Delete          Immediate           false                  9m46s

標記默認的 StorageClass 爲非默認

kubectl patch storageclass 目前的默認storageclass名稱 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

標記一個普通 sc 爲默認

kubectl patch storageclass storageclass名稱 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

結束語

StorageClass 對象並非爲了自動建立 PV 而創建的,因此在靜態建立機制和動態建立機制中都應該存在該參數。

若是 PVC 中沒有指定 storageClassName,那麼:

  1. 若是集羣已經開啓了名叫 DefaultStorageClass 的 Admission Plugin,該 Plugin 會爲 PVC 和 PV 自動添加一個默認的 StorageClass。
  2. 若是沒有該 Plugin,PVC 的 storageClassName 的值是 "",它只能跟 storageClassName 是 "" 的 PV 進行綁定。

聯繫我

微信公衆號:zuolinux_com

微信掃碼關注

相關文章
相關標籤/搜索