CSI - Container Storage Interface(容器存儲接口)
CSI 代表容器存儲接口,CSI 試圖建立一個行業標准接口的規范,借助 CSI 容器編排系統(CO)可以將任意存儲系統暴露給自己的容器工作負載。有關詳細信息,請查看設計方案。
csi
卷類型是一種 out-tree(即跟其它存儲插件在同一個代碼路徑下,隨 Kubernetes 的代碼同時編譯的) 的 CSI 卷插件,用於 Pod 與在同一節點上運行的外部 CSI 卷驅動程序交互。部署 CSI 兼容卷驅動后,用戶可以使用 csi
作為卷類型來掛載驅動提供的存儲。
CSI 持久化卷支持是在 Kubernetes v1.9 中引入的,作為一個 alpha 特性,必須由集群管理員明確啟用。換句話說,集群管理員需要在 apiserver、controller-manager 和 kubelet 組件的 “--feature-gates =
” 標志中加上 “CSIPersistentVolume = true
”。
CSI 持久化卷具有以下字段可供用戶指定:
driver
:一個字符串值,指定要使用的卷驅動程序的名稱。必須少於 63 個字符,並以一個字符開頭。驅動程序名稱可以包含 “。”、“ - ”、“_” 或數字。volumeHandle
:一個字符串值,唯一標識從 CSI 卷插件的CreateVolume
調用返回的卷名。隨后在卷驅動程序的所有后續調用中使用卷句柄來引用該卷。readOnly
:一個可選的布爾值,指示卷是否被發布為只讀。默認是 false。
使用說明
下面將介紹如何使用 CSI。
動態配置
可以通過為 CSI 創建插件 StorageClass
來支持動態配置的 CSI Storage 插件啟用自動創建/刪除 。
例如,以下 StorageClass
允許通過名為 com.example.team/csi-driver
的 CSI Volume Plugin 動態創建 “fast-storage” Volume。
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: fast-storage provisioner: com.example.team/csi-driver parameters: type: pd-ssd
要觸發動態配置,請創建一個PersistentVolumeClaim
對象。例如,下面的 PersistentVolumeClaim 可以使用上面的 StorageClass 觸發動態配置。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-request-for-storage spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi storageClassName: fast-storage
當動態創建 Volume 時,通過 CreateVolume 調用,將參數type:pd-ssd
傳遞給 CSI 插件com.example.team/csi-driver
。作為響應,外部 Volume 插件會創建一個新 Volume,然后自動創建一個PersistentVolume
對象來對應前面的 PVC 。然后,Kubernetes 會將新的PersistentVolume
對象綁定到PersistentVolumeClaim
,使其可以使用。
如果 fast-storage
StorageClass 被標記為默認值,則不需要在 PersistentVolumeClaim
中包含 StorageClassName,它將被默認使用。
預配置 Volume
您可以通過手動創建一個 PersistentVolume
對象來展示現有 Volumes,從而在 Kubernetes 中暴露預先存在的 Volume。例如,暴露屬於 com.example.team/csi-driver
這個 CSI 插件的 existingVolumeName Volume
:
apiVersion: v1 kind: PersistentVolume metadata: name: my-manually-created-pv spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain csi: driver: com.example.team/csi-driver volumeHandle: existingVolumeName readOnly: false
附着和掛載
您可以在任何的 pod 或者 pod 的 template 中引用綁定到 CSI volume 上的 PersistentVolumeClaim
。
kind: Pod apiVersion: v1 metadata: name: my-pod spec: containers: - name: my-frontend image: dockerfile/nginx volumeMounts: - mountPath: "/var/www/html" name: my-csi-volume volumes: - name: my-csi-volume persistentVolumeClaim: claimName: my-request-for-storage
當一個引用了 CSI Volume 的 pod 被調度時, Kubernetes 將針對外部 CSI 插件進行相應的操作,以確保特定的 Volume 被 attached、mounted, 並且能被 pod 中的容器使用。
關於 CSI 實現的詳細信息請參考設計文檔。
創建 CSI 驅動
Kubernetes 盡可能少地指定 CSI Volume 驅動程序的打包和部署規范。這里記錄了在 Kubernetes 上部署 CSI Volume 驅動程序的最低要求。
最低要求文件還包含概述部分,提供了在 Kubernetes 上部署任意容器化 CSI 驅動程序的建議機制。存儲提供商可以運用這個機制來簡化 Kubernetes 上容器式 CSI 兼容 Volume 驅動程序的部署。
作為推薦部署的一部分,Kubernetes 團隊提供以下 sidecar(輔助)容器:
-
可監聽 Kubernetes VolumeAttachment 對象並觸發 ControllerPublish 和 ControllerUnPublish 操作的 sidecar 容器,通過 CSI endpoint 觸發 ;
-
監聽 Kubernetes PersistentVolumeClaim 對象的 sidecar 容器,並觸發對 CSI 端點的 CreateVolume 和DeleteVolume 操作;
-
Driver-registrar(DEPRECATED)
使用 Kubelet(將來)注冊 CSI 驅動程序的 sidecar 容器,並將
NodeId
(通過GetNodeID
調用檢索到 CSI endpoint)添加到 Kubernetes Node API 對象的 annotation 里面。 -
創建 CSIDriver 這個集群范圍的 CRD 對象。
-
替代 Driver-registrar。
存儲供應商完全可以使用這些組件來為其插件構建 Kubernetes Deployment,同時讓它們的 CSI 驅動程序完全意識不到 Kubernetes 的存在。
另外 CSI 驅動完全是由第三方存儲供應商自己維護的,在 kubernetes 1.9 版本中 CSI 還處於 alpha 版本。