K8s存儲架構及插件使用

作者：移動Labs 2022-06-14 07:56:15

容器內部存儲的生命周期是短暫的，會隨著容器環境的銷毀而銷毀，具有不穩定性。如果多個容器希望共享同?份存儲，則僅僅依賴容器本身是很難實現的。

作者｜中國移動云能力中心PaaS產品部王琦

01引言

在Kubernetes系統中，容器應用所需的存儲資源被抽象為存儲卷（Volume），并以此概念來解決“容器存儲所面臨”的問題。

Volume是與Pod綁定的（獨立于容器）與Pod具有相同生命周期的資源對象。我們可以將Volume的內容理解為?錄或?件，容器如需使?某個Volume，則僅需設置volumeMounts將?個或多個Volume掛載為容器中的?錄或?件，即可訪問Volume中的數據。Volume具體是什么類型，以及由哪個系統提供，對容器應?來說是透明的。

Kubernetes?前?持的Volume類型包括Kubernetes的內部資源對象類型（In-Tree）、開源共享存儲等（Out-of-Tree）類型的存儲服務。

02Kubernetes存儲體系架構

2.1 Kubernetes存儲基礎知識

PV（Persistent Volume）：存儲資源的定義，主要涉及存儲能力、訪問模式、存儲類型、回收策略、后端存儲類型等關鍵信息的設置；

圖 PV狀態流程

PVC（Persistent Volume Claim）：用戶對存儲資源的需求申請，主要涉及存儲空間請求、訪問模式、PV選擇條件和存儲類別等信息的設置；

圖PVC狀態流程

SC（Storage Class）：存儲資源的抽象定義，對用戶設置的PVC申請屏蔽后端存儲的細節，一方面減少了用戶對于存儲資源細節的關注，另一方面減輕了管理員手工管理PV的壓力，轉由系統自動完成PV的創建和綁定，實現動態的資源供應。SC資源對象的定義主要包括名稱、后端存儲的提供者及相關參數配置和回收策略。

2.2 Kubernetes存儲總體架構

圖 Kubernetes存儲架構

PV Controller：管理卷的整個生命周期，控制PVC和PV進行綁定，執行卷的Provision或Delete操作；
AD Controller：執行卷的Attach或Detach，并將卷掛接到目標節點；
Volume Manager：執行卷的Mount或Unmount，以及共享目錄掛載、卷格式化等操作；
Volume Plugin：擴展卷存儲管理的能力，將第三方存儲插件能力集成進Kubernetes存儲系統，是卷管理能力的具體實現；
Scheduler：負責將待調度的Pod按照特定的調度算法和調度策略綁定到集群中某個合適的Node上，并將綁定信息寫入etcd。

2.3 Kubernetes存儲機制概述

圖 Kubernetes持久化存儲流程

1）Provision/Delete階段：

用戶創建一個包含PVC的Pod；

PV Controller通過持續監聽ApiServer，發現PVC處于待綁定的狀態，隨即調用Volume Plugin創建存儲卷，并在創建成功后將PV與PVC進行綁定；

2）Attach/Detach階段：

Scheduler根據Pod和PV的配置、節點目前的狀態等信息，將Pod調度到Worker節點的Node上；
AD Controller發現Pod和PVC處于待掛載狀態，調用Volume Plugin實現存儲設備（卷）掛接到目標節點；

3）Mount/Unmount階段：

Worker節點上的Kubelet（Volume Manager）在卷掛載完成后，通過Volume Plugin將設備掛載到指定目錄；
Kubelet在被告知掛載目錄準備好后，啟動Pod中的容器，使用Docker -v的方式將存儲設備，也就是已經掛載到本地的卷映射到容器中供Pod使用。

2.4 Kubernetes存儲插件

Kubernetes在默認情況下提供了主流的存儲卷接入方案，可通過命令“kubectl explain pod.spec.volumes”查看Pod支持的所有存儲卷。同時，也提供了一種基于插件的存儲管理機制，根據概述可知PV Controller、AD Controller和Volume Manager均通過調用Volume Plugin的功能接口去執行存儲卷管理相關Provision、Attach操作。因此，操作的具體實現其實都取決于插件中的接口邏輯。Volume Plugin可以允許除默認類型外的其他存儲服務接入到Kubernetes系統中，主要分為In-Tree和Out-of-Tree兩類：

In-Tree類存儲服務實現的源碼都在Kubernetes主干代碼庫中，優勢在于和Kubernetes一起發布、管理和迭代，相對穩定。但也因此存在更新迭代速度慢、靈活性較差的問題，屬于緊耦合的開發模式；
Out-of-Tree類存儲服務通過擴展Volume Plugin獨立于Kubernetes外，存儲提供方只需基于Kubernetes容器對接的存儲接口標準進行存儲插件的實現，就能使用Kubernetes的原生機制為容器提供存儲服務。而存儲提供方的代碼則可與Kubernetes代碼徹底解耦，部署也與Kubernetes核心組件分離。

在Kubernetes中，存儲插件的開發方式有Flexvolume和CSI兩種，接下來通過原理和案例演示的方式做進一步介紹。

03Felxvolume原理及案例演示

3.1 Flexvolume簡介

Flexvolume提供了一種擴展Volume Plugin的方式，用戶可以自定義自己的存儲插件，實現Attach、Mount等功能接口。比如AD Controller調用插件實現Attach操作時，會首先調用Flexvolume中的Attach接口。Flexvolume是可被Kubelet驅動的可執行二進制文件，該文件需要實現Flexvolume的相關接口，每一次調用相當于執行一次shell腳本，然后返回JSON格式的數據，因此其不是一個常駐內存的守護進程。Flexvolume存儲插件默認的存放位置是：/usr/libexec/kubernetes/kubelet-plugins/volume/exec/<vendor~driver>/<driver>，Volume plugin組件會不斷watch這個目錄來實現插件提供的增刪等功能。其中，vendor~driver的名字和Pod中flexVolume.driver的字段名相對應，vendor部分可自定義。

3.2 Flexvolume接口定義

Flexvolume接口可以根據需求自定義的實現，比如使用NFS文件存儲，因為不存在存儲卷的掛接操作，因此不需要實現Attach、Detach相關接口，只需將接口返回結果定義成{"status":"Not supported","message":"error message"} 即可。以下列舉Flexvolume部分接口：

3.3 Flexvolume案例演示

演示前提條件：Kubernetes集群已具備NFS存儲服務，并且NFS共享目錄已設置，jq工具已安裝。

# mkdir -p /root/wq/nfs //設置共享目錄
# chmod 755  /root/wq/nfs
# vim /etc/exports //配置NFS，寫入/root/wq/nfs *(rw,sync,no_root_squash)設置權限
# yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
# yum install jq -y //安裝jq工具
# systemctl restart rpcbind.service
# systemctl enable rpcbind.service
# systemctl restart nfs.service
# systemctl enable nfs.service //重啟RPC和NFS，使配置生效

演示案例使用Kubernetes官方給出的一個基于NFS文件存儲的Flexvolume插件示例，腳本鏈接：https://github.com/kubernetes/examples/blob/master/staging/volumes/flexvolume/nfs。根據下圖所示，在Flexvolume存儲插件默認的存放位置新建插件目錄wq-nfs，將腳本放置目錄下，并賦予文件可執行權限。

然后部署一個Pod到指定節點，并使用Flexvolume的方式對容器中的數據進行持久化存儲，詳細yaml文件內容如下。

apiVersion: v1
kind: Pod
metadata:
  name: k8s-flexvolume  #應用名稱
  namespace: flexvolume  #指定應用所在命名空間
spec:
  nodeSelector:
    kubernetes.io/hostname: kcs-ks-qq-m-snqnq  #指定應用部署節點
  volumes:
  - name: f-volume
    flexVolume:
      driver: "wq/nfs"  #存儲插件定義，用于在默認插件存儲位置查詢可執行文件
      fsType: "nfs"  #定義存儲系統類型
      options:  #定義存儲服務所需相關參數
        server: "192.168.2.49"
        share: "/root/wq/nfs"  #指定共享存儲目錄
  containers:
  - name: nginx-proxy
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: f-volume
      subPath: subfv
      mountPath: /usr/share/nginx

通過查看Pod本地持久化目錄是否已被掛載到了NFS存儲系統上，可以得知Flexvolume插件是否正常運行。在NFS共享目錄下新建文本文件，并寫入一些內容，然后進入Pod查看新建文件和寫入內容是否已同步，即可進一步驗證存儲是否掛載成功，詳細操作如下圖所示。

04CSI原理及案例演示

4.1 CSI簡介

CSI是容器存儲接口Container Storage Interface的簡稱，作用是為了能在容器編排引擎和存儲系統之間建立一套標準的存儲調用接口，進而通過該接口為容器編排引擎提供存儲服務。

圖 CSI插件設計架構

4.2 CSI存儲體系及接口定義

CSI存儲體系主要由兩部分組成：External Components和Custom Components。

External Components（Kubernetes外部組件）：主要包含Driver Registrar、External Attacher、External Provisioner三個部分，這三個組件源自Kubernetes原本的in-tree存儲體系，可以理解為Kubernetes的一個外部Controller，負責Watch Kubernetes的API資源對象，然后根據監聽到的狀態調用Custom Components實現存儲管理和操作。

Driver Registrar：CSI Node-Driver-Registrar是一個Sidecar容器，用于從CSI driver獲取驅動程序信息（使用NodeGetInfo），并使用Kubelet插件注冊機制在該節點上的 Kubelet中對其進行注冊。
External Attacher：用于監聽Kubernetes VolumeAttachment對象，并針對驅動程序端點觸發CSI ControllerPublish和ControllerUnpublish操作。
External Provisioner：監聽Kubernetes中的PVC對象，調用CSI對應的創建、刪除等Volume操作。

?注：External Components目前仍由Kubernetes團隊維護，插件開發者無需關心其實現細節。

Custom Components（CSI存儲插件）：主要包含CSI Identity、CSI Controller、CSI Node三個部分，是需要開發者通過編碼來實現的，并以gRPC的方式對外提供服務。

CSI Identity：用于對外暴露這個插件本身的信息，確保插件的健康狀態。

service Identity {
    // 返回插件的名稱和版本
    rpc GetPluginInfo(GetPluginInfoRequest)
        returns (GetPluginInfoResponse) {}
// 返回插件具備所有功能
rpc GetPluginCapabilities(GetPluginCapabilitiesRequest)
        returns (GetPluginCapabilitiesResponse) {}
    // 檢測插件的健康狀態，是否正在運行
    rpc Probe (ProbeRequest)
        returns (ProbeResponse) {}
}

CSI Controller：用于實現Volume管理流程中Provision和Attach階段操作，比如創建和刪除Volume、對Volume進行Attach/Detach（Publish/UnPublish）操作等。CSI Controller里定義的所有服務都有一個共同特點，那就是無需在宿主機上進行操作。

service Controller {
  // 創建存儲卷
  rpc CreateVolume (CreateVolumeRequest)
    returns (CreateVolumeResponse) {}
  // 刪除存儲卷
  rpc DeleteVolume (DeleteVolumeRequest)
    returns (DeleteVolumeResponse) {}
  // Attach卷，即將存儲介質掛接到目標節點
  rpc ControllerPublishVolume (ControllerPublishVolumeRequest)
    returns (ControllerPublishVolumeResponse) {}
  // Unattach卷
  rpc ControllerUnpublishVolume (ControllerUnpublishVolumeRequest)
    returns (ControllerUnpublishVolumeResponse) {}
  // 返回存儲卷具備的功能，比如是否支持掛載到多個節點上等
  rpc ValidateVolumeCapabilities (ValidateVolumeCapabilitiesRequest)
    returns (ValidateVolumeCapabilitiesResponse) {}
  // 返回所有可用存儲卷
  rpc ListVolumes (ListVolumesRequest)
    returns (ListVolumesResponse) {}
  // 返回存儲資源池的可用空間大小
  rpc GetCapacity (GetCapacityRequest)
    returns (GetCapacityResponse) {}
  // 返回controller插件具備的功能，比如是否支持Snapshot功能等
  rpc ControllerGetCapabilities (ControllerGetCapabilitiesRequest)
    returns (ControllerGetCapabilitiesResponse) {}
  // 創建快照
  rpc CreateSnapshot (CreateSnapshotRequest)
    returns (CreateSnapshotResponse) {}
  // 刪除快照
  rpc DeleteSnapshot (DeleteSnapshotRequest)
    returns (DeleteSnapshotResponse) {}
  // 列出快照
  rpc ListSnapshots (ListSnapshotsRequest)
    returns (ListSnapshotsResponse) {}
  // 擴容
  rpc ControllerExpandVolume (ControllerExpandVolumeRequest)
    returns (ControllerExpandVolumeResponse) {}
}

CSI Node：用于控制Kubernetes節點上Volume的相關功能操作。Volume在節點的Mount過程被分為NodeStageVolume和NodePublishVolume兩個階段，前者針對塊存儲類型將存儲設備格式化后，先掛載到節點的一個全局的臨時目錄，之后再調用NodePublishVolume接口將目錄掛載進Pod中指定的目錄上。

service Node {
  // 在Kubernetes節點上格式化存儲卷，并將其掛載到一個全局的臨時目錄
  rpc NodeStageVolume (NodeStageVolumeRequest)
    returns (NodeStageVolumeResponse) {}
  // NodeStageVolume的逆操作，將存儲卷從臨時目錄卸載掉
  rpc NodeUnstageVolume (NodeUnstageVolumeRequest)
    returns (NodeUnstageVolumeResponse) {}
  // 將存儲卷從全局的臨時目錄掛載到指定的目標目錄（Pod內的目錄）
  rpc NodePublishVolume (NodePublishVolumeRequest)
    returns (NodePublishVolumeResponse) {}
  // NodePublishVolume的逆操作，將存儲卷從Pod目錄卸載掉
  rpc NodeUnpublishVolume (NodeUnpublishVolumeRequest)
    returns (NodeUnpublishVolumeResponse) {}
  // 返回可用于該卷的卷容量統計信息
  rpc NodeGetVolumeStats (NodeGetVolumeStatsRequest)
    returns (NodeGetVolumeStatsResponse) {}
  //  Kubernetes節點上執行卷擴容
  rpc NodeExpandVolume(NodeExpandVolumeRequest)
    returns (NodeExpandVolumeResponse) {}
  // 返回節點插件具備的所有功能，比如是否支持Stage/Unstage功能
  rpc NodeGetCapabilities (NodeGetCapabilitiesRequest)
    returns (NodeGetCapabilitiesResponse) {}
  // 返回節點的一些信息
  rpc NodeGetInfo (NodeGetInfoRequest)
    returns (NodeGetInfoResponse) {}
}

4.3 CSI案例演示

演示前提條件：Kubernetes集群中已安裝NFS相關的CSI驅動，用于實踐通過CSI的方式使用NFS文件存儲。Kubernetes官方有一個基于CSI驅動實現NFS存儲的項目可以用于初次實踐，鏈接如下：https://github.com/kubernetes-csi/csi-driver-nfs，同時提供以下兩種安裝部署方式。?

l 遠程安裝：通過以下命令訪問Github一鍵安裝。
# curl -skSL https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/v3.1.0/deploy/install-driver.sh | bash -s v3.1.0 -- //本次示例安裝csi-driver-nfs版本為v3.1.0，也可安裝其他版本
l 本地安裝：通過將項目Clone到本地，再執行安裝腳本方式進行安裝。
# git clone https://github.com/kubernetes-csi/csi-driver-nfs.git
# cd csi-driver-nfs
# ./deploy/install-driver.sh v3.1.0 local

?運行腳本后，可通過命令”kubectl -n kube-system get pod -o wide -l app=csi-nfs-controller”和”kubectl -n kube-system get pod -o wide -l app=csi-nfs-node”查看Pod狀態，如下所示則表示已安裝完畢。可以注意到，csi-nfs-node會以DaemonSet的方式在每個節點上運行，并執行存儲卷的Mount/Unmount操作。

csi-driver-nfs安裝完成后，就可以通過”spec.csi.driver”的規范來調用驅動使用NFS存儲。下面我們先通過Static Volume Provisioning，也就是靜態PV的供應方式調用CSI驅動創建PV。然后通過PVC使用這個PV，完成PVC和PV的綁定操作。

# Static Volume Provisioning創建PV所用yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-csi-nfs
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  mountOptions:
    - hard
    - nfsvers=4.1
  csi:
    driver: nfs.csi.k8s.io
    readOnly: false
    volumeHandle: unique-volumeid
    volumeAttributes:
      server: 192.168.2.49
      share: /root/wq/nfs

# Static Volume Provisioning創建PVC所用yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-csi-nfs
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  volumeName: pv-csi-nfs # 指定需要使用的PV
  storageClassName: ""

實際操作過程如下圖所示。可以看到，通過CSI驅動，PV創建成功并已處于可使用的狀態。此時，便可通過PVC使用這個PV，PVC在創建后會與PV進行綁定，綁定成功后PV的狀態也會發生改變。

接下來，我們再通過Dynamic Volume Provisioning，動態PV的供應方式做進一步的演示。該方式相比Static Volume Provisioning，集群管理員無需再預先分配PV，而只是創建一個SC模板文件，用戶在通過PVC使用PV時，無需再關心PV所需的參數細節，因為這些信息已經預先設置到了SC里。?

# Dynamic Volume Provisioning創建SC所用yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-csi-nfs
provisioner: nfs.csi.k8s.io
parameters:
  server: 192.168.2.49
  share: /root/wq/nfs
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - hard
  - nfsvers=4.1

# Dynamic Volume Provisioning創建PVC所用yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-sc-csi-nfs
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  storageClassName: sc-csi-nfs

實際操作過程如下圖所示。可以看到，SC、PVC創建成功，PVC通過SC調用CSI驅動自動生成了PV（pvc-4c45d45b-ec52-4276-9cbd-589964da73b3），并最終與PVC完成了綁定。

05總結

本文介紹了Kubernetes存儲架構及插件的使用，主要包括以下三部分內容：

第一部分介紹了Kubernetes存儲的基本知識、總體架構、存儲機制概述以及存儲插件的概念；
第二部分對FlexVolume進行了介紹，描述了其用于開發的接口定義，并通過一個實際的例子演示了Flexvolume的使用方法；
第三部分對CSI進行了介紹，解析了其存儲體系結構以及開發接口定義，最后通過實際的例子演示了如何通過CSI插件以靜態或者動態的方式使用PV進行存儲。?

責任編輯：未麗燕來源：移動Labs