Kubernetes 系列（七）：持久化存儲StorageClass

前面的課程中我們學習了 PV 和 PVC 的使用方法，但是前面的 PV 都是靜態的，什么意思？就是我要使用的一個 PVC 的話就必須手動去創建一個 PV，我們也說過這種方式在很大程度上並不能滿足我們的需求，比如我們有一個應用需要對存儲的並發度要求比較高，而另外一個應用對讀寫速度又要求比較高，特別是對於 StatefulSet 類型的應用簡單的來使用靜態的 PV 就很不合適了，這種情況下我們就需要用到動態 PV，也就是我們今天要講解的 StorageClass。

創建 Provisioner

要使用 StorageClass，我們就得安裝對應的自動配置程序，比如我們這里存儲后端使用的是 nfs，那么我們就需要使用到一個 nfs-client 的自動配置程序，我們也叫它 Provisioner，這個程序使用我們已經配置好的 nfs 服務器，來自動創建持久卷，也就是自動幫我們創建 PV。

• 自動創建的 PV 以${namespace}-${pvcName}-${pvName}這樣的命名格式創建在 NFS 服務器上的共享數據目錄中
• 而當這個 PV 被回收后會以archieved-${namespace}-${pvcName}-${pvName}這樣的命名格式存在 NFS 服務器上。

當然在部署nfs-client之前，我們需要先成功安裝上 nfs 服務器，前面的課程中我們已經過了，服務地址是1192.168.3.131，共享數據目錄是/data/k8s/，然后接下來我們部署 nfs-client 即可，我們也可以直接參考nfs-client 的文檔，進行安裝即可。

 

第一步：配置 Deployment，將里面的對應的參數替換成我們自己的 nfs 配置（nfs-client.yaml）

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs
            - name: NFS_SERVER
              value: 192.168.3.131
            - name: NFS_PATH
              value: /data/k8s
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.3.131
            path: /data/k8s

第二步：將環境變量 NFS_SERVER 和 NFS_PATH 替換，當然也包括下面的 nfs 配置，我們可以看到我們這里使用了一個名為 nfs-client-provisioner 的serviceAccount，所以我們也需要創建一個 sa，然后綁定上對應的權限：（nfs-client-sa.yaml）

我們這里新建的一個名為 nfs-client-provisioner 的ServiceAccount，然后綁定了一個名為 nfs-client-provisioner-runner 的ClusterRole，而該ClusterRole聲明了一些權限，其中就包括對persistentvolumes的增、刪、改、查等權限，所以我們可以利用該ServiceAccount來自動創建 PV。

第三步：nfs-client 的 Deployment 聲明完成后，我們就可以來創建一個StorageClass對象了：（nfs-client-class.yaml）

我們聲明了一個名為 course-nfs-storage 的StorageClass對象，注意下面的provisioner對應的值一定要和上面的Deployment下面的 PROVISIONER_NAME 這個環境變量的值一樣。

現在我們來創建這些資源對象吧：

kubectl create -f nfs-client.yaml
kubectl create -f nfs-client-sa.yaml
kubectl create -f nfs-client-class.yaml

創建完成后查看下資源狀態：

[root@localhost nfs]# kubectl get pods
NAME                                      READY   STATUS              RESTARTS   AGE
nfs-client-provisioner-5db79cb75f-nk952   0/1     ContainerCreating   0          12s

[root@localhost nfs]# kubectl get storageclass
NAME                 PROVISIONER      AGE
course-nfs-storage   fuseim.pri/ifs   31s
harbor-data          fuseim.pri/ifs   90d

新建 StorageClass

上面把StorageClass資源對象創建成功了，接下來我們來通過一個示例測試下動態 PV，首先創建一個 PVC 對象：(test-pvc.yaml)

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Mi

我們這里聲明了一個PVC對象，采用 ReadWriteMany 的訪問模式，請求 1Mi 的空間，但是我們可以看到上面的 PVC 文件我們沒有標識出任何和 StorageClass 相關聯的信息，那么如果我們現在直接創建這個 PVC 對象能夠自動綁定上合適的 PV 對象嗎？顯然是不能的(前提是沒有合適的 PV)，我們這里有兩種方法可以來利用上面我們創建的 StorageClass 對象來自動幫我們創建一個合適的 PV:

• 第一種方法：在這個PVC對象中添加一個聲明StorageClass對象的標識，這里我們可以利用一個annotations屬性來標識，如下

• kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: test-pvc
    annotations:
      volume.beta.kubernetes.io/storage-class: "course-nfs-storage"
  spec:
    accessModes:
    - ReadWriteMany
    resources:
      requests:
        storage: 1Mi

• 第二種方法：我們可以設置這個 course-nfs-storage 的 StorageClass 為 Kubernetes 的默認存儲后端，我們可以用kubectl patch命令來更新： yaml $ kubectl patch storageclass course-nfs-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

• 上面這兩種方法都是可以的，當然為了不影響系統的默認行為，我們這里還是采用第一種方法，直接創建即可：

上面這兩種方法都是可以的，當然為了不影響系統的默認行為，我們這里還是采用第一種方法，直接創建即可：

（注意網絡問題 這里需要拉取外網鏡像）

kubectl create -f test-pvc.yaml
persistentvolumeclaim "test-pvc" created
[root@localhost nfs]# kubectl get pvc
NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS         AGE
pvc-nfs    Bound    pv1                                        1Gi        RWO                                 12h
test-pvc   Bound    pvc-a7293619-bb8c-11e9-93e7-000c29ecf8a8   1Mi        RWX            course-nfs-storage   11h

我們可以看到一個名為 test-pvc 的 PVC 對象創建成功了，狀態已經是Bound了，是不是也產生了一個對應的VOLUME 對象，最重要的一欄是STORAGECLASS，現在是不是也有值了，就是我們剛剛創建的StorageClass對象 course-nfs-storage。

然后查看下 PV 對象呢：

[root@localhost nfs]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS         REASON   AGE
pvc-a7293619-bb8c-11e9-93e7-000c29ecf8a8   1Mi        RWX            Delete           Bound    default/test-pvc   course-nfs-storage            3m48s

可以看到是不是自動生成了一個關聯的 PV 對象，訪問模式是RWX，回收策略是 Delete，這個 PV 對象並不是我們手動創建的吧，這是通過我們上面的 StorageClass 對象自動創建的。這就是 StorageClass 的創建方法。

 

OK，到這里我們大體明白了StorageClass的作用，下一篇我們會實際把它利用起來。