Kubernetes的容器儲存介面（CSI）GA了
作者：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？
雖然在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。
如何部署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驅動程式？
kubernetes-csi網站 詳細介紹瞭如何在Kubernetes上開發、部署和測試CSI驅動程式。一般而言，CSI驅動程式應與Kubernetes一起部署以下側車/輔助（sidercar/helper）容器：
-
- 觀察Kubernetes VolumeAttachment物件，並觸發針對CSI端點的ControllerPublish和ControllerUnpublish操作。
-
- 觀察Kubernetes PersistentVolumeClaim物件，並觸發針對CSI端點的CreateVolume和DeleteVolume操作。
-
- 通過Kubelet裝置外掛機制，使用 kubelet註冊CSI驅動程式 。
-
cluster-driver-registrar (Alpha)
- 通過建立CSIDriver物件，向Kubernetes叢集註冊CSI驅動程式，該物件使驅動程式能夠自定義Kubernetes與其互動的方式。
-
external-snapshotter (Alpha)
- 觀察Kubernetes VolumeSnapshot CRD物件，並觸發針對CSI端點的CreateSnapshot和DeleteSnapshot操作。
-
- 可以包含在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。
怎樣參與？
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) 主辦專案的領導，和我們一同探討雲原生生態系統發展方向。
在中國開源峰會上，與會者將共同合作及共享資訊，瞭解最新和最有趣的開源技術，包括 Linux、容器、雲技術、網路、微服務等；並獲得如何在開源社群中導向和引領的資訊。
大會日期：
- 提案徵集截止日期：太平洋標準時間 2 月 15 日，星期五，晚上 11:59
- 提案徵集通知日期：2019 年 4 月 1 日
- 會議日程通告日期：2019 年 4 月 3 日
- 幻燈片提交截止日期：6 月 17 日，星期一
- 會議活動舉辦日期：2019 年 6 月 24 至 26 日
2019年KubeCon + CloudNativeCon + Open Source Summit China贊助方案出爐啦