1.Kubernetes StorageClass 介紹

Kubernetes 叢集儲存 PV 支援 Static 靜態配置以及 Dynamic 動態配置，動態卷配置 (Dynamic provisioning) 可以根據需要動態的建立儲存卷。靜態配置方式，叢集管理員必須手動呼叫雲/儲存服務提供商的介面來配置新的固定大小的 Image 儲存卷，然後建立 PV 物件以在 Kubernetes 中請求分配使用它們。通過動態卷配置，能自動化完成以上兩步驟，它無須叢集管理員預先配置儲存資源，而是使用 StorageClass 物件指定的供應商來動態配置儲存資源。

2.建立StorageClass

StorageClass 物件支援多種型別的儲存卷外掛來提供 PV，從 Storage Classes 官方文件 provisioner 部分可以看到，它目前支援很多種儲存卷型別，其中就有我們熟悉的 Ceph RBD 型別。

AWSElasticBlockStore
AzureFile
AzureDisk
Cinder
Flocker
GCEPersistentDisk
Glusterfs
PhotonPersistentDisk
Quobyte
RBD
VsphereVolume
PortworxVolume
ScaleIO
StorageOS

當然除了上述 k8s 內部支援類別

正式開始之前要提一下，通過前邊兩篇文章 初試 Kubernetes 叢集使用 Ceph RBD 塊儲存 和 初試 Kubernetes 叢集使用 CephFS 檔案儲存 的介紹，我們知道，k8s 不支援跨節點掛載同一 Ceph RBD，支援跨節點掛載 CephFS，讓所有的任務都排程到指定node上執行，來保證針對 RBD 的操作在同一節點上。同時既然是動態配置儲存資源，意思就是我們不需要提前建立好指定大小的 Image 了，而是動態建立它，所以這裡只需要參照 初試 Centos7 上 Ceph 儲存叢集搭建搭建好 Ceph 儲存叢集即可，不需要進行 RBD 操作。

2.1 建立 ceph-secret-admin

我們知道 Ceph 儲存叢集預設是開啟了 cephx 認證的，所以我們可以建立一個名稱為 ceph-secret-admin 的 secret 物件，用於 k8s volume 外掛通過 cephx 認證訪問 ceph 儲存叢集。首先獲取並 base64 生成一下 k8s secret 認證 key，然後建立 ceph-secret-admin.yaml 檔案，key 值替換一下。

獲取並 base64 生成 k8s secret 認證 key

$ ceph auth get-key client.admin | base64
QVFCS3FYSmFRa05wSEJBQWxIRkgrR1NMQ1B3TzNXS2V2YUlMVkE9PQ==

建立名稱為 ceph-secret-admin 的 Secret
ceph-secret-admin.yaml檔案如下：

apiVersion: v1
kind: Secret
metadata:
  name: ceph-secret-admin
  namespace: kube-system
type: "kubernetes.io/rbd"  
data:
  key: QVFCS3FYSmFRa05wSEJBQWxIRkgrR1NMQ1B3TzNXS2V2YUlMVkE9PQ==

2.2 建立 rbd-storage-class

通過 StorageClass RBD Config Example 官方示例程式碼，我們可以看到如下資訊。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
provisioner: kubernetes.io/rbd
parameters:
  monitors: 10.16.153.105:6789
  adminId: admin
  adminSecretName: ceph-secret
  adminSecretNamespace: kube-system
  pool: kube
  userId: kube
  userSecretName: ceph-secret-user
  fsType: ext4
  imageFormat: "2"
  imageFeatures: "layering"

這裡每個欄位我就不一一解釋了，其中有幾個欄位要說明一下：

• provisioner: 該欄位指定使用儲存卷型別為 kubernetes.io/rbd，注意 kubernetes.io/ 開頭為 k8s 內部支援的儲存提供者，不同的儲存卷提供者型別這裡要修改成對應的值。
• adminId | userId: 這裡需要指定兩種 Ceph 角色 admin 和其他 user，admin 角色預設已經有了，其他 user 可以去 Ceph 叢集建立一個並賦對應許可權值，如果不建立，也可以都指定為 admin。
• adminSecretName: 為上邊建立的 Ceph 管理員 admin 使用的 ceph-secret-admin。secret中必須要有“kubernetes.io/rbd”這個type。
• adminSecretNamespace 管理員 secret 使用的名稱空間，預設 default。
• imageFormat: Ceph RBD image format, “1” or “2”. Default is “1”.
  
  • 經過檢視ceph文件rbd 塊映象有支援兩種格式： --image-format format-id,format-id取值為1或2，預設為 2。
    – format 1 - 新建 rbd 映像時使用最初的格式。此格式相容所有版本的 librbd 和核心模組，但是不支援較新的功能，像克隆。
    – format 2 - 使用第二版 rbd 格式， librbd 和 3.11 版以上核心模組才支援（除非是分拆的模組）。此格式增加了克隆支援，使得擴充套件更容易，還允許以後增加新功能。
• imageFeatures: This parameter is optional and should only be used if you set imageFormat to “2”. Currently supported features are layering only. Default is “”, and no features are turned on.

參照上邊示例，我們建立一個 rbd-storage-class.yaml 檔案如下。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rbd
provisioner: kubernetes.io/rbd
parameters:
  monitors: 10.142.21.21:6789,10.142.21.22:6789,10.142.21.23:6789
  adminId: admin
  adminSecretName: ceph-secret-admin
  adminSecretNamespace: kube-system
  pool: rbd
  userId: admin
  userSecretName: ceph-secret-admin
  fsType: ext4
  imageFormat: "1"

說明：

然後我們建立一下名稱為 rbd 型別為 rbd 的 storage-class 看下:

$ kubectl create -f rbd-storage-class.yaml 
storageclass "rbd" created
$ kubectl get storageclass
NAME      TYPE
rbd       kubernetes.io/rbd

3. 建立 pvc

現在 storageClass 已經建立好了，這裡跟之前的區別就是，不需要建立 PV 和提前建立好指定大小的 Image，只需要建立 PVC 時請求指定儲存大小就行，k8s 會根據請求儲存大小和型別動態建立並分配，是不是很方便。那麼我們就來建立一個 PVC 申請 1G 儲存空間，新建 rbd-pvc.yaml 檔案如下。

$ vim rbd-pv.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: rbd-pvc1
  namespace: kube-system
spec:
  storageClassName: rbd
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

注意：
這裡要使用 storageClassName: rbd 指明我們使用的 storageClass 為前面建立的 rbd。accessModes 指定模型為 ReadWriteOnce rbd 只支援 ReadWriteOnce 和 ReadOnlyMany，因為下邊有寫入操作，所以這裡使用 ReadWriteOnce 即可。

然後建立一個PVC:

$ kubectl create -f rbd-pvc.yaml 
    persistentvolumeclaim "rbd-pvc1" created

$ kubectl get pvc -n kube-system
NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS         AGE   
rbd-pvc1    Bound     pvc-b9ecad19-07bc-11e8-a9ca-00505694eb6a   1Gi        RWO           rbd                  2m

還自動創建出pv:
kubectl get pv
NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                                           STORAGECLASS               REASON    AGE
pvc-b9ecad19-07bc-11e8-a9ca-00505694eb6a   1Gi        RWO           Delete          Bound     kube-system/rbd-pvc1                            rbd                                  5m

用rbd命令檢視：

我們會發現，沒有提前建立好 1G 大小的 rbd image，而是建立 PVC 時申請了 1G 儲存，k8s 就自動建立好了指定大小的 Image。

此時相當於執行了rbd create，還沒有把這個image 對映到核心，並格式化為塊裝置。

4. 建立應用

這一步相當於在pod所在的節點執行了rbd map、mkfs、mount

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-use-rbd
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.11.4-alpine
        imagePullPolicy: IfNotPresent
        name: nginx-use-rbd
        volumeMounts:
        - mountPath: /test
          name: rbd-pvc
      volumes:
      - name: rbd-pvc
        persistentVolumeClaim:
          claimName: rbd-pvc1
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-use-rbd
  namespace: default
spec:
  type: NodePort
  ports:
  - name: nginx-use-rbd
    port: 80
    targetPort: 80
    nodePort: 30099
  selector:
    app: nginx

建立成功後在kubelet日誌中看到如下內容：

df -h 可以看到盤掛載上來了：

dmesg | tail可以看到：

並掛載到容器內部，太方便了有木有！ 同時，我們看到預設使用的 format 為 1，這裡也可以指定格式為 2（需要高版本的ceph和rbd支援），然後可以在 rbd-storage-class.yaml 中指定 imageFormat: “2”，同時還可以指定 imageFeatures: layering 等等。

最後，要提一下的是，如果我們使用動態配置的卷，則預設的回收策略為 “刪除”。這意味著，在預設的情況下，當 PVC 被刪除時，基礎的 PV 和對應的儲存也會被刪除。如果需要保留儲存在捲上的資料，則必須在 PV 被設定之後將回收策略從 delete 更改為 retain。可以通過修改 PV 物件中的 persistentVolumeReclaimPolicy 欄位的值來修改 PV 的回收策略。

5. 問題

• ceph-rbd的ReadWriteOnce問題

  ceph-rbd只支援RWO和RWM，也就是說寫資料的話rbd只能掛給一個node，當一個應用只有一個pod例項的時候還好，當有多個pod例項的時候就要求這些例項一定要起在同一個節點上。實驗發現，建立多例項應用不做啥約束的話，k8s的排程系統並不會根據這個應用所掛載的pvc型別是RWO而給你去把所有pod例項排程到同一個節點，最終結果甚至會一個pod也建立不出來，這個issue：https://github.com/kubernetes/kubernetes/issues/26567

參考：