摘要：作者，高級軟件工程師實施的容器存儲接口已在版本中升級為。功能受棄用政策保護。隨著容器存儲接口的采用，卷層變得真正可擴展。年中國論壇提案征集現已開放論壇讓用戶開發人員從業人員匯聚一堂，面對面進行交流合作。

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

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

GA里程碑表明Kubernetes用戶可能依賴于該功能及其API，而不必擔心將來回歸（regression）導致的向后不兼容的更改。GA功能受Kubernetes棄用（deprecation）政策保護。

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

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

隨著升級到GA，Kubernetes對CSI的實施引入了以下變化：

Kubernetes現在與CSI spec v1.0和v0.3兼容（而不是CSI spec v0.2）。

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。

對如何在Kubernetes上部署，或管理現有CSI驅動程序感興趣的Kubernetes用戶，應該查看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

你可以在任何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實施設計文檔和文檔。

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。有關詳細信息，請參閱設計文檔。

CSI的GA實施具有以下限制：

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

致力于移動Kubernetes CSI的alpha功能到beta：

Raw block volumes

拓撲感知。Kubernetes理解和影響CSI卷的配置位置（zone可用區，region地域等）的能力。

取決于CSI CRD的功能（例如“跳過附加”和“掛載時的Pod信息”）。

卷快照

努力完成對本地短暫卷的支持。

將遠程持久性樹內卷插件遷移到CSI。

Slack頻道wg-csi和谷歌討論區kubernetes-sig-storage-wg-csi，以及任何標準的SIG存儲通信渠道都是接觸SIG存儲團隊的絕佳媒介。

像Kubernetes一樣，這個項目是許多來自不同背景的貢獻者共同努力的結果。我們非常感謝本季度主動幫助項目達成GA的新貢獻者：

Saad Ali (saad-ali)

Michelle Au (msau42)

Serguei Bezverkhi (sbezverk)

Masaki Kimura (mkimuram)

Patrick Ohly (pohly)

Luis Pabón (lpabon)

Jan ?afránek (jsafrane)

Vladimir Vivien (vladimirvivien)

Cheng Xing (verult)

Xing Yang (xing-yang)

David Zhu (davidz627)

如果你有興趣參與CSI或Kubernetes存儲系統的任何部分的設計和開發，請加入Kubernetes存儲特別興趣小組（SIG）。我們正在快速成長，一直歡迎新的貢獻者。

2019年KubeCon + CloudNativeCon中國論壇提案征集（CFP）現已開放

KubeCon + CloudNativeCon 論壇讓用戶、開發人員、從業人員匯聚一堂，面對面進行交流合作。與會人員有 Kubernetes、Prometheus 及其他云原生計算基金會 (CNCF) 主辦項目的領導，和我們一同探討云原生生態系統發展方向。

2019年中國開源峰會提案征集（CFP）現已開放

在中國開源峰會上，與會者將共同合作及共享信息，了解最新和最有趣的開源技術，包括 Linux、容器、云技術、網絡、微服務等；并獲得如何在開源社區中導向和引領的信息。

大會日期：

提案征集截止日期：太平洋標準時間 2 月 15 日，星期五，晚上 11:59

提案征集通知日期：2019 年 4 月 1 日

會議日程通告日期：2019 年 4 月 3 日

幻燈片提交截止日期：6 月 17 日，星期一

會議活動舉辦日期：2019 年 6 月 24 至 26 日

2019年KubeCon + CloudNativeCon + Open Source Summit China贊助方案出爐啦