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

Kubernetes 的容器儲存介面（CSI）GA

作者：Saad Ali (Google) |

Kubernetes Logo CSI Logo

Kubernetes 的 容器儲存介面 (CSI) 實現已在 Kubernetes v1.13 版本中提升至 GA（通用可用）。CSI 的支援在 Kubernetes v1.9 版本中作為 alpha 引入，並在 Kubernetes v1.10 版本中提升至 beta。

GA 里程碑表示 Kubernetes 使用者可以依賴該功能及其 API，而不必擔心未來出現不向後相容的更改導致退步。GA 功能受 Kubernetes 棄用策略的保護。

為什麼選擇 CSI？

儘管在 CSI 之前，Kubernetes 提供了一個強大的卷外掛系統，但向 Kubernetes 新增對新卷外掛的支援仍具有挑戰性：卷外掛是“樹內”的，這意味著它們的程式碼是 Kubernetes 核心程式碼的一部分，並隨 Kubernetes 核心二進位制檔案一起釋出——希望向 Kubernetes 新增對其儲存系統支援的供應商（甚至修復現有卷外掛中的錯誤）被迫與 Kubernetes 釋出流程保持一致。此外，第三方儲存程式碼導致核心 Kubernetes 二進位制檔案出現可靠性和安全問題，而且 Kubernetes 維護者通常難以（在某些情況下甚至不可能）測試和維護這些程式碼。

CSI 被開發為一種標準，用於將任意塊和檔案儲存系統暴露給 Kubernetes 等容器編排系統 (CO) 上的容器化工作負載。隨著容器儲存介面的採用，Kubernetes 卷層變得真正可擴充套件。使用 CSI，第三方儲存提供商可以編寫和部署外掛，在 Kubernetes 中暴露新的儲存系統，而無需觸及 Kubernetes 核心程式碼。這為 Kubernetes 使用者提供了更多儲存選項，並使系統更安全可靠。

有什麼新內容？

隨著提升至 GA，CSI 的 Kubernetes 實現引入了以下更改：

  • Kubernetes 現在相容 CSI 規範 v1.0 和 v0.3（而不是 CSI 規範 v0.2）。
    • CSI 規範 v0.3.0 和 v1.0.0 之間存在不相容的更改，但 Kubernetes v1.13 支援這兩個版本，因此任一版本都將與 Kubernetes v1.13 配合使用。
    • 請注意，隨著 CSI 1.0 API 的釋出，對使用 CSI 0.3 及更早版本的 CSI API 的 CSI 驅動程式的支援已棄用，並計劃在 Kubernetes v1.15 中移除。
    • CSI 規範 v0.2 和 v0.3 之間沒有不相容的更改，因此 v0.2 驅動程式也應與 Kubernetes v1.10.0+ 配合使用。
    • CSI 規範 v0.1 和 v0.2 之間存在不相容的更改，因此實現 CSI 0.1 的非常舊的驅動程式必須更新到至少 0.2 相容，才能與 Kubernetes v1.10.0+ 配合使用。
  • Kubernetes VolumeAttachment 物件（在 v1.9 中在 storage v1alpha1 組中引入，並在 v1.10 中新增到 v1beta1 組）已在 v1.13 中新增到 storage v1 組。
  • Kubernetes CSIPersistentVolumeSource 卷型別已提升至 GA。
  • Kubelet 裝置外掛註冊機制（kubelet 發現新 CSI 驅動程式的方式）已在 Kubernetes v1.13 中提升至 GA。

如何部署 CSI 驅動程式？

對如何在 Kubernetes 上部署或管理現有 CSI 驅動程式感興趣的 Kubernetes 使用者應查閱 CSI 驅動程式作者提供的文件。

如何使用 CSI 卷？

假設 CSI 儲存外掛已部署在 Kubernetes 叢集上，使用者可以透過熟悉的 Kubernetes 儲存 API 物件使用 CSI 卷：PersistentVolumeClaims、PersistentVolumes 和 StorageClasses。文件在此處。

儘管 CSI 的 Kubernetes 實現是 Kubernetes v1.13 中的 GA 功能，但它可能需要以下標誌

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

動態配置

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

例如，以下 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 外部供應器 (v1.0.1+) 保留以 csi.storage.k8s.io/ 為字首的引數鍵。如果這些鍵不對應一組已知的鍵，則這些值將被簡單地忽略（並且不傳遞給 CSI 驅動程式）。舊的秘密引數鍵（csiProvisionerSecretName、csiProvisionerSecretNamespace 等）也受 CSI 外部供應器 v1.0.1 支援，但已棄用，並可能在 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 被標記為“預設”，則無需在 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 等），以確保指定的卷已附加、掛載並可供 Pod 中的容器使用。

欲瞭解更多詳情，請參閱 CSI 實現的設計文件和文件。

如何編寫 CSI 驅動程式？

kubernetes-csi 網站詳細介紹瞭如何在 Kubernetes 上開發、部署和測試 CSI 驅動程式。通常，CSI 驅動程式應與以下 sidecar（輔助）容器一起部署在 Kubernetes 上：

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

CSI 驅動程式列表

CSI 驅動程式由第三方開發和維護。您可以在此處找到一個非完整 CSI 驅動程式列表。

樹內卷外掛怎麼樣？

有一個計劃將大多數持久的、遠端的樹內卷外掛遷移到 CSI。有關更多詳情，請參閱設計文件。

GA 的侷限性

CSI 的 GA 實現有以下限制：

  • 臨時本地卷必須建立 PVC（不支援 pod 內聯引用 CSI 卷）。

下一步是什麼？

  • 正在努力將仍處於 alpha 狀態的 Kubernetes CSI 功能遷移到 beta 狀態
    • 原始塊卷
    • 拓撲感知（Kubernetes 理解和影響 CSI 卷配置位置（區域、區域等）的能力）。
    • 依賴 CSI CRD 的功能（例如，“跳過附加”和“掛載時 Pod 資訊”）。
    • 卷快照
  • 正在努力完成對本地臨時卷的支援。
  • 正在努力將遠端持久樹內卷外掛遷移到 CSI。

如何參與？

Kubernetes Slack 頻道 wg-csi 和 Google 群組 SIG 儲存通訊渠道 都是聯絡 SIG 儲存團隊的絕佳途徑。

與所有 Kubernetes 專案一樣，這個專案也是許多來自不同背景的貢獻者共同努力的成果。我們非常感謝本季度挺身而出幫助專案達到 GA 的新貢獻者：

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