本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 的容器儲存介面（CSI）進入 Beta 階段

Kubernetes Logo CSI Logo

Kubernetes 的容器儲存介面 (CSI) 實現在 Kubernetes v1.10 中已進入 Beta 階段。CSI 在 Kubernetes v1.9 中 作為 Alpha 版本引入。

Kubernetes 功能通常作為 Alpha 版本引入，並在隨後的 Kubernetes 版本中移至 Beta 階段（最終移至穩定版/GA）。此過程允許 Kubernetes 開發人員獲取反饋、發現和修復問題、迭代設計並交付高質量的生產級功能。

為什麼要在 Kubernetes 中引入容器儲存介面？

儘管 Kubernetes 已經提供了一個強大的卷外掛系統，可以輕鬆使用不同型別的塊儲存和檔案儲存，但新增對新卷外掛的支援一直具有挑戰性。由於卷外掛目前是“樹內”的——卷外掛是核心 Kubernetes 程式碼的一部分並隨核心 Kubernetes 二進位制檔案一起釋出——因此希望向 Kubernetes 新增對其儲存系統支援的供應商（甚至修復現有卷外掛中的錯誤）必須與 Kubernetes 釋出流程保持一致。

透過採用容器儲存介面，Kubernetes 卷層變得真正可擴充套件。第三方儲存開發人員現在可以編寫和部署卷外掛，在 Kubernetes 中公開新的儲存系統，而無需觸及核心 Kubernetes 程式碼。這將為支援 Kubernetes 使用者有狀態容器化工作負載的儲存提供更多選擇。

Beta 版有哪些新功能？

隨著升級到 Beta 版，CSI 現在預設在標準 Kubernetes 部署上啟用，而不是選擇性加入。

Kubernetes CSI 實現進入 Beta 階段還意味著：

  • Kubernetes 與 CSI 規範的 v0.2 版本相容（而非 v0.1 版本）。
    • CSI 規範 v0.1 和 v0.2 之間存在破壞性更改，因此現有 CSI 驅動程式必須更新為 0.2 相容，然後才能與 Kubernetes 1.10.0+ 一起使用。
  • 掛載傳播（一種允許容器和主機之間雙向掛載的功能，容器化 CSI 驅動程式的要求）也已進入 Beta 階段。
  • Kubernetes VolumeAttachment 物件（在 v1.9 中引入，屬於 storage v1alpha1 組）已新增到 storage v1beta1 組。
  • Kubernetes CSIPersistentVolumeSource 物件已升級到 Beta 版。已將 VolumeAttributes 欄位新增到 Kubernetes CSIPersistentVolumeSource 物件（在 Alpha 版本中，此欄位透過註釋傳遞）。
  • 節點授權器已更新，以限制 kubelet 對 VolumeAttachment 物件的訪問。
  • Kubernetes CSIPersistentVolumeSource 物件和 CSI 外部供應器已修改，以允許將秘密傳遞給 CSI 卷外掛。
  • Kubernetes CSIPersistentVolumeSource 已修改，以允許傳入檔案系統型別（以前總是假定為 ext4）。
  • 已向 CSI 規範添加了一個新的可選呼叫 NodeStageVolume，並且 Kubernetes CSI 卷外掛已修改，以在 MountDevice 期間呼叫 NodeStageVolume（在 Alpha 版本中，此步驟是一個空操作）。

如何在 Kubernetes 叢集上部署 CSI 驅動程式？

CSI 外掛作者必須提供自己的說明，以指導如何在 Kubernetes 上部署其外掛。

Kubernetes-CSI 實現團隊建立了一個示例 hostpath CSI 驅動程式。該示例大致展示了 CSI 驅動程式的部署過程。然而，生產驅動程式將透過 DaemonSet 部署節點元件，並透過 StatefulSet 部署控制器元件，而不是單個 Pod（例如，請參閱 GCE PD 驅動程式的部署檔案）。

如何在 Kubernetes Pod 中使用 CSI 卷？

假設 CSI 儲存外掛已部署在您的叢集上，您可以透過熟悉的 Kubernetes 儲存原語來使用它：`PersistentVolumeClaims`、`PersistentVolumes` 和 `StorageClasses`。

CSI 是 Kubernetes v1.10 中的 Beta 功能。儘管預設啟用，但它可能需要以下標誌

  • API 伺服器二進位制檔案和 kubelet 二進位制檔案
    • --allow-privileged=true
      • 大多數 CSI 外掛將需要雙向掛載傳播，這隻能為特權 Pod 啟用。特權 Pod 僅在設定此標誌為 true 的叢集上允許（這在某些環境（如 GCE、GKE 和 kubeadm）中是預設設定）。

動態配置

您可以透過建立一個指向 CSI 外掛的 StorageClass，為支援動態預配的 CSI 儲存外掛啟用卷的自動建立/刪除。

例如，以下 StorageClass 啟用名為“com.example.csi-driver”的 CSI 卷外掛動態建立“fast-storage”卷。

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

對於 Beta 版新增功能，預設 CSI 外部供應器保留引數鍵 csiProvisionerSecretName 和 csiProvisionerSecretNamespace。如果指定，它將獲取秘密並在預配期間將其傳遞給 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 外掛 `com.example.csi-driver`。作為響應，外部卷外掛預配一個新卷，然後自動建立一個 `PersistentVolume` 物件來表示新卷。Kubernetes 然後將新的 `PersistentVolume` 物件繫結到 `PersistentVolumeClaim`，使其準備好使用。

如果 fast-storage StorageClass 被標記為“default”，則無需在 PersistentVolumeClaim 中包含 storageClassName，它將預設使用。

預先配置的卷

您始終可以透過手動建立一個 PersistentVolume 物件來表示現有卷，從而在 Kubernetes 中公開預先存在的卷。例如，以下 PersistentVolume 公開一個名為“existingVolumeName”的卷，該卷屬於名為“com.example.csi-driver”的 CSI 儲存外掛。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-manually-created-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: com.example.csi-driver
    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` 等），以確保指定的卷被附加、掛載並可供 Pod 中的容器使用。

更多詳情請參閱 CSI 實現設計文件和文件。

如何編寫 CSI 驅動程式？

Kubernetes 上的 CSI 卷驅動程式部署必須滿足一些最低要求。

最低要求文件還概述了在 Kubernetes 上部署任意容器化 CSI 驅動程式的建議機制。儲存提供商可以使用此機制來簡化在 Kubernetes 上部署容器化 CSI 相容卷驅動程式。

作為建議部署過程的一部分，Kubernetes 團隊提供以下 sidecar（輔助）容器

儲存供應商可以使用這些元件為其外掛構建 Kubernetes 部署，同時使其 CSI 驅動程式完全不瞭解 Kubernetes。

在哪裡可以找到 CSI 驅動程式？

CSI 驅動程式由第三方開發和維護。您可以找到一些示例和生產 CSI 驅動程式的非詳盡列表。

FlexVolumes 怎麼樣？

正如Alpha 版本部落格文章中所述，FlexVolume 外掛是早期嘗試使 Kubernetes 卷外掛系統可擴充套件的方法。儘管它使第三方儲存供應商能夠編寫“樹外”驅動程式，但由於它是一個基於 exec 的 API，FlexVolumes 要求將第三方驅動程式二進位制檔案（或指令碼）複製到每個節點（在某些情況下，還有主節點）機器根檔案系統上的一個特殊外掛目錄中。這需要叢集管理員對每個節點的主機檔案系統具有寫訪問許可權，並且需要一些外部機制來確保如果驅動程式檔案被刪除，它會被重新建立，僅僅是為了部署一個卷外掛。

除了部署困難之外，Flex 也未能解決外掛依賴性問題：卷外掛往往有許多外部要求（例如，對掛載和檔案系統工具的要求）。這些依賴項被假定在底層主機作業系統上可用，但事實往往並非如此。

CSI 解決了這些問題，它不僅使儲存外掛能夠在樹外開發，而且能夠容器化並透過標準 Kubernetes 原語進行部署。

如果您仍然對樹內卷、CSI 和 Flex 之間的區別有疑問，請參閱卷外掛 FAQ。

樹內卷外掛會怎麼樣？

一旦 CSI 達到穩定狀態，我們計劃將大多數樹內卷外掛遷移到 CSI。請繼續關注 Kubernetes CSI 實現接近穩定版的更多詳細資訊。

Beta 版有哪些限制？

CSI 的 Beta 版實現有以下限制：

  • 不支援塊卷；僅支援檔案。
  • CSI 驅動程式必須與提供的 external-attacher sidecar 外掛一起部署，即使它們沒有實現 ControllerPublishVolume。
  • CSI 卷不支援拓撲感知，包括與 Kubernetes 排程器共享卷預置位置（區域、地域等）資訊以使其做出更智慧的排程決策的能力，以及 Kubernetes 排程器或叢集管理員或應用程式開發人員指定卷應預置位置的能力。
  • driver-registrar 需要修改所有 Kubernetes 節點 API 物件的許可權，這可能導致受損節點獲得相同許可權。

下一步是什麼？

根據反饋和採用情況，Kubernetes 團隊計劃在 1.12 版本中將 CSI 實現推向 GA。

團隊鼓勵儲存供應商開始開發 CSI 驅動程式，將其部署在 Kubernetes 上，並透過 Kubernetes Slack 頻道 wg-csi、Google 群組 kubernetes-sig-storage-wg-csi 或任何標準SIG 儲存通訊渠道與團隊分享反饋。

我如何參與？

這個專案，和所有 Kubernetes 專案一樣，是許多來自不同背景的貢獻者共同努力的結果。

除了自 Alpha 版本以來一直致力於 Kubernetes CSI 實現的貢獻者之外

我們非常感謝本季度為幫助專案達到 Beta 階段而站出來的新貢獻者

如果您有興趣參與 CSI 或 Kubernetes 儲存系統任何部分的設計和開發，請加入 Kubernetes 儲存特別興趣小組 (SIG)。我們正在迅速發展，並始終歡迎新的貢獻者。