Kubernetes的容器存儲接口（CSI）GA了

時間 2019-11-16

標籤 kubernetes 容器存儲接口 csi 简体版

原文原文鏈接

做者：Saad Ali，Google高級軟件工程師html

Kubernetes實施的容器存儲接口（CSI）已在Kubernetes v1.13版本中升級爲GA。CSI的支持在Kubernetes v1.9版本中做爲alpha引入，並在Kubernetes v1.10版本中升級爲beta。node

GA里程碑代表Kubernetes用戶可能依賴於該功能及其API，而沒必要擔憂未來回歸（regression）致使的向後不兼容的更改。GA功能受Kubernetes棄用（deprecation）政策保護。linux

爲什麼選擇CSI？

雖然在CSI以前，Kubernetes提供了一個功能強大的卷插件系統，可是在Kubernetes添加對新卷插件的支持是一項挑戰：卷插件是「樹內」（「in-tree」），這意味着他們的代碼是核心Kubernetes代碼的一部分，並隨核心Kubernetes一塊兒提供二進制文件。但願向Kubernetes添加對其存儲系統的支持（或修復現有卷插件中的錯誤）的供應商被迫與Kubernetes發佈流程保持一致。此外，第三方存儲代碼致使核心Kubernetes二進制文件中的可靠性和安全性問題，代碼一般很難（在某些狀況下不可能）讓Kubernetes維護者進行測試和維護。nginx

CSI是做爲將任意塊和文件存儲存儲系統暴露於容器編排系統（CO）上，如Kubernetes，的容器化工做負載的標準而開發的。隨着容器存儲接口的採用，Kubernetes卷層變得真正可擴展。使用CSI，第三方存儲供應商能夠編寫和部署插件，在Kubernetes中暴露新的存儲系統，而無需觸及核心Kubernetes代碼。這爲Kubernetes用戶提供了更多存儲選項，使系統更加安全可靠。git

新的改變？

隨着升級到GA，Kubernetes對CSI的實施引入瞭如下變化：github

Kubernetes如今與CSI spec v1.0和v0.3兼容（而不是CSI spec v0.2）。api
- CSI spec v0.3和v1.0之間存在重大變化，但Kubernetes v1.13支持這兩個版本，所以任何一個版本都適用於Kubernetes v1.13。
- 請注意，隨着CSI 1.0 API的發佈，使用0.3或更老版本CSI API的CSI驅動程序被棄用（deprecated），並計劃在Kubernetes v1.15中刪除。
- CSI spec v0.2和v0.3之間沒有重大變化，所以v0.2驅動程序也應該與Kubernetes v1.10.0+一塊兒使用。
- CSI規範v0.1和v0.2之間存在重大變化，所以在使用Kubernetes v1.10.0+以前，必須將實現很是舊的CSI 0.1驅動程序更新爲至少0.2兼容。
Kubernetes VolumeAttachment對象（在v1.9 storage v1alpha1 group引入，並在v1.10中添加到v1beta1 group）在v1.13已添加到的storage v1 group。
Kubernetes CSIPersistentVolumeSource卷類型已升級爲GA。
Kubelet設備插件註冊機制，即kubelet發現新CSI驅動程序的方式，已在Kubernetes v1.13中提高爲GA。

如何部署CSI驅動程序？

對如何在Kubernetes上部署，或管理現有CSI驅動程序感興趣的Kubernetes用戶，應該查看CSI驅動程序做者提供的文檔。安全

如何使用CSI卷？

假設CSI存儲插件已部署在Kubernetes集羣上，用戶能夠經過熟悉的Kubernetes存儲API對象使用CSI卷：PersistentVolumeClaims，PersistentVolumes和StorageClasses。文檔在這裏。服務器

雖然Kubernetes實施CSI是Kubernetes v1.13中的GA功能，但它可能須要如下標誌：網絡

API服務器二進制文件和kubelet二進制文件：
- --allow-privileged=true
- 大多數CSI插件都須要雙向安裝傳播（bidirectional mount propagation），只能在特權(privileged)pod啓用。只有在此標誌設置爲true的羣集上才容許使用特權pod，這是某些環境（如GCE，GKE和kubeadm）的默認設置。

動態配置

你能夠經過建立指向CSI插件的StorageClass，爲支持動態配置（dynamic provisioning）的CSI Storage插件啓用卷的自動建立/刪除（creation/deletion）。

例如，如下StorageClass經過名爲「csi-driver.example.com」的CSI卷插件，動態建立「fast-storage」卷。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast-storage
provisioner: csi-driver.example.com
parameters:
  type: pd-ssd
  csi.storage.k8s.io/provisioner-secret-name: mysecret
  csi.storage.k8s.io/provisioner-secret-namespace: mynamespace

GA的新功能，CSI的external-provisioner外部配置商（v1.0.1+）保留以csi.storage.k8s.io/爲前綴的參數鍵。若是密鑰（key）不對應於一組已知密鑰，則簡單地忽略這些值（而且不將其傳遞給CSI驅動程序）。CSI外部配置商v1.0.1也支持舊的祕密參數密鑰（csiProvisionerSecretName，csiProvisionerSecretNamespace等），但被棄用（deprecated），可能會在CSI外部配置商的將來版本中刪除。

動態配置由PersistentVolumeClaim對象的建立觸發。例如，如下PersistentVolumeClaim使用上面的StorageClass觸發動態配置。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-request-for-storage
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: fast-storage

調用卷配置時，參數類型：pd-ssd和祕密經過CreateVolume調用，遞給CSI插件csi-driver.example.com。做爲響應，外部卷插件提供新卷，而後自動建立PersistentVolume對象以表示新卷。而後，Kubernetes將新的PersistentVolume對象綁定到PersistentVolumeClaim，使其可使用。

若是快速存儲（fast-storage）StorageClass標記爲「default」，則不須要在PersistentVolumeClaim中包含storageClassName，默認狀況下將使用它。

預先配置的卷

你能夠經過手動建立PersistentVolume對象來表示現有卷，從而在Kubernetes中暴露預先存在的卷。例如，如下PersistentVolume暴露名爲「existingVolumeName」的卷，該卷屬於名爲「csi-driver.example.com」的CSI存儲插件。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-manually-created-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: csi-driver.example.com
    volumeHandle: existingVolumeName
    readOnly: false
    fsType: ext4
    volumeAttributes:
      foo: bar
    controllerPublishSecretRef:
      name: mysecret1
      namespace: mynamespace
    nodeStageSecretRef:
      name: mysecret2
      namespace: mynamespace
    nodePublishSecretRef
      name: mysecret3
      namespace: mynamespace

鏈接（Attaching）和安裝（Mounting）

你能夠在任何pod或pod模板中引用綁定到CSI卷的PersistentVolumeClaim。

kind: Pod
apiVersion: v1
metadata:
  name: my-pod
spec:
  containers:
    - name: my-frontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: my-csi-volume
  volumes:
    - name: my-csi-volume
      persistentVolumeClaim:
        claimName: my-request-for-storage

當引用CSI卷的pod被調度時，Kubernetes將針對外部CSI插件（ControllerPublishVolume、NodeStageVolume、NodePublishVolume等）觸發相應的操做，以確保指定的卷被鏈接（attached）和安裝（mounted），並準備好給pod裏的容器使用。

有關詳細信息，請參閱CSI實施設計文檔和文檔。

如何編寫CSI驅動程序？

kubernetes-csi網站詳細介紹瞭如何在Kubernetes上開發、部署和測試CSI驅動程序。通常而言，CSI驅動程序應與Kubernetes一塊兒部署如下側車/輔助（sidercar/helper）容器：

external-attacher
- 觀察Kubernetes VolumeAttachment對象，並觸發針對CSI端點的ControllerPublish和ControllerUnpublish操做。
external-provisioner
- 觀察Kubernetes PersistentVolumeClaim對象，並觸發針對CSI端點的CreateVolume和DeleteVolume操做。
node-driver-registrar
- 經過Kubelet設備插件機制，使用kubelet註冊CSI驅動程序。
cluster-driver-registrar (Alpha)
- 經過建立CSIDriver對象，向Kubernetes集羣註冊CSI驅動程序，該對象使驅動程序可以自定義Kubernetes與其交互的方式。
external-snapshotter (Alpha)
- 觀察Kubernetes VolumeSnapshot CRD對象，並觸發針對CSI端點的CreateSnapshot和DeleteSnapshot操做。
livenessprobe
- 能夠包含在CSI插件pod中，以啓用Kubernetes Liveness Probe機制。

存儲供應商可使用這些組件爲其插件構建Kubernetes部署，而他們的CSI驅動程序徹底不需知道Kubernetes。

CSI驅動程序列表

CSI驅動程序由第三方開發和維護。你能夠在此處找到CSI驅動程序的列表。

樹內（in-tree）卷插件怎麼樣？

有計劃將大多數持久的遠程樹內卷插件遷移到CSI。有關詳細信息，請參閱設計文檔。

GA的限制

CSI的GA實施具備如下限制：

短暫（Ephemeral）的本地卷必須建立PVC（不支持pod內聯引用CSI卷）。

下一步？

致力於移動Kubernetes CSI的alpha功能到beta：
- Raw block volumes
- 拓撲感知。Kubernetes理解和影響CSI卷的配置位置（zone可用區，region地域等）的能力。
- 取決於CSI CRD的功能（例如「跳過附加」和「掛載時的Pod信息」）。
- 卷快照
努力完成對本地短暫卷的支持。
將遠程持久性樹內卷插件遷移到CSI。