Kubernetes 容器儲存介面 (CSI) Alpha 版介紹

Kubernetes 的主要差異化因素之一是強大的 磁碟區外掛程式系統，該系統使許多不同類型的儲存系統能夠

1. 在需要時自動建立儲存空間。
2. 讓儲存空間在容器排程到的任何地方都可用。
3. 在不再需要時自動刪除儲存空間。然而，為 Kubernetes 新增對新儲存系統的支援一直具有挑戰性。

Kubernetes 1.9 引入了 容器儲存介面 (CSI) 的 alpha 實作，這使得安裝新的磁碟區外掛程式就像部署 Pod 一樣容易。它還使協力廠商儲存供應商能夠開發解決方案，而無需新增到核心 Kubernetes 程式碼庫。

由於該功能在 1.9 中是 alpha 版本，因此必須明確啟用。不建議在生產環境中使用 Alpha 功能，但它們很好地指示了專案的前進方向（在本例中，朝向更具可擴展性和基於標準的 Kubernetes 儲存生態系統）。

為何選擇 Kubernetes CSI？

Kubernetes 磁碟區外掛程式目前是「樹內 (in-tree)」，這表示它們與核心 Kubernetes 二進位檔案連結、編譯、建置和運送在一起。為 Kubernetes 新增對新儲存系統的支援（磁碟區外掛程式）需要將程式碼簽入到核心 Kubernetes 儲存庫中。但是，對於許多外掛程式開發人員來說，與 Kubernetes 發布流程保持一致是很痛苦的。

現有的 Flex Volume 外掛程式 試圖透過為外部磁碟區外掛程式公開基於 exec 的 API 來解決這種痛苦。儘管它使協力廠商儲存供應商能夠在樹外編寫驅動程式，但為了部署協力廠商驅動程式檔案，它需要存取節點和主機的根檔案系統。

除了難以部署之外，Flex 沒有解決外掛程式依賴項的痛苦：磁碟區外掛程式往往有許多外部需求（例如，關於掛載和檔案系統工具）。這些依賴項被假定在底層主機作業系統上可用，但情況往往並非如此（並且安裝它們需要存取節點機器的根檔案系統）。

CSI 透過啟用在樹外開發、容器化、透過標準 Kubernetes 原語部署以及透過使用者熟悉且喜愛的 Kubernetes 儲存原語（PersistentVolumeClaims、PersistentVolumes、StorageClasses）使用儲存外掛程式來解決所有這些問題。

什麼是 CSI？

CSI 的目標是為容器協調系統 (CO) 建立標準化機制，以將任意儲存系統公開給其容器化工作負載。CSI 規範源於來自各種容器協調系統 (CO)（包括 Kubernetes、Mesos、Docker 和 Cloud Foundry）的社群成員之間的合作。該規範是獨立於 Kubernetes 開發的，並維護在 https://github.com/container-storage-interface/spec/blob/master/spec.md。

Kubernetes v1.9 公開了 CSI 規範的 alpha 實作，使 CSI 相容的磁碟區驅動程式能夠部署在 Kubernetes 上並由 Kubernetes 工作負載使用。

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

CSI 外掛程式作者將提供他們自己的說明，以說明如何在 Kubernetes 上部署他們的外掛程式。

如何使用 CSI 磁碟區？

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

CSI 是 Kubernetes v1.9 中的 alpha 功能。要啟用它，請設定以下標誌

CSI is an alpha feature in Kubernetes v1.9. To enable it, set the following flags:

API server binary:
--feature-gates=CSIPersistentVolume=true
--runtime-config=storage.k8s.io/v1alpha1=true
API server binary and kubelet binaries:
--feature-gates=MountPropagation=true
--allow-privileged=true

動態佈建

您可以透過建立指向 CSI 外掛程式的 StorageClass，為支援動態佈建的 CSI 儲存外掛程式啟用磁碟區的自動建立/刪除。

例如，以下 StorageClass 透過名為「com.example.team/csi-driver」的 CSI 磁碟區外掛程式啟用「快速儲存」磁碟區的動態建立。

kind: StorageClass

apiVersion: storage.k8s.io/v1

metadata:

  name: fast-storage

provisioner: com.example.team/csi-driver

parameters:

  type: pd-ssd

若要觸發動態佈建，請建立 PersistentVolumeClaim 物件。例如，以下 PersistentVolumeClaim 使用上述 StorageClass 觸發動態佈建。

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: my-request-for-storage

spec:

  accessModes:

  - ReadWriteOnce

  resources:

    requests:

      storage: 5Gi

  storageClassName: fast-storage

當叫用磁碟區佈建時，參數「type: pd-ssd」透過「CreateVolume」呼叫傳遞到 CSI 外掛程式「com.example.team/csi-driver」。作為回應，外部磁碟區外掛程式佈建新的磁碟區，然後自動建立 PersistentVolume 物件以表示新的磁碟區。然後，Kubernetes 將新的 PersistentVolume 物件繫結到 PersistentVolumeClaim，使其準備好使用。

如果「fast-storage」StorageClass 標記為預設值，則無需在 PersistentVolumeClaim 中包含 storageClassName，它將預設使用。

預先佈建的磁碟區

您可以隨時透過手動建立 PersistentVolume 物件來表示現有的磁碟區，從而在 Kubernetes 中公開預先存在的磁碟區。例如，以下 PersistentVolume 公開了名稱為「existingVolumeName」的磁碟區，該磁碟區屬於名為「com.example.team/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.team/csi-driver

    volumeHandle: existingVolumeName

    readOnly: false

附加和掛載

您可以在任何 Pod 或 Pod 範本中參考繫結到 CSI 磁碟區的 PersistentVolumeClaim。

kind: Pod

apiVersion: v1

metadata:

  name: my-pod

spec:

  containers:

    - name: my-frontend

      image: dockerfile/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、NodePublishVolume 等），以確保指定的磁碟區已附加、掛載並準備好供 Pod 中的容器使用。

如需更多詳細資訊，請參閱 CSI 實作 設計文件 和 文件。

如何建立 CSI 驅動程式？

Kubernetes 在 CSI 磁碟區驅動程式的封裝和部署方面盡可能地減少規範性。在 此處 文件中記錄了在 Kubernetes 上部署 CSI 磁碟區驅動程式的最低要求。

最低要求文件還包含一個 章節，其中概述了在 Kubernetes 上部署任意容器化 CSI 驅動程式的建議機制。儲存供應商可以使用此機制來簡化在 Kubernetes 上部署容器化 CSI 相容磁碟區驅動程式。

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

• external-attacher

  • Sidecar 容器，用於監看 Kubernetes VolumeAttachment 物件，並針對 CSI 端點觸發 ControllerPublish 和 ControllerUnpublish 操作。

• external-provisioner

  • Sidecar 容器，用於監看 Kubernetes PersistentVolumeClaim 物件，並針對 CSI 端點觸發 CreateVolume 和 DeleteVolume 操作。

• driver-registrar

  • Sidecar 容器，用於向 kubelet 註冊 CSI 驅動程式（在未來），並將驅動程式的自訂 NodeId（透過針對 CSI 端點的 GetNodeID 呼叫檢索）新增到 Kubernetes Node API 物件上的註釋。

儲存供應商可以使用這些組件為他們的外掛程式建置 Kubernetes 部署，同時讓他們的 CSI 驅動程式完全不知道 Kubernetes。

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

CSI 驅動程式由協力廠商開發和維護。您可以在 此處 找到 CSI 驅動程式範例，但這些範例僅供說明之用，並非旨在用於生產工作負載。

Flex 呢？

Flex Volume 外掛程式 作為基於 exec 的機制存在，用於建立「樹外」磁碟區外掛程式。儘管它有一些缺點（如上所述），但 Flex 磁碟區外掛程式與新的 CSI 磁碟區外掛程式共存。SIG Storage 將繼續維護 Flex API，以便現有的協力廠商 Flex 驅動程式（已部署在生產叢集中）繼續運作。在未來，新的磁碟區功能將僅新增到 CSI，而不是 Flex。

樹內磁碟區外掛程式會怎樣？

一旦 CSI 達到穩定性，我們計劃將大多數樹內磁碟區外掛程式遷移到 CSI。請繼續關注更多詳細資訊，因為 Kubernetes CSI 實作正趨於穩定。

alpha 版本的限制是什麼？

CSI 的 alpha 實作具有以下限制

• 不支援 CreateVolume、NodePublishVolume 和 ControllerPublishVolume 呼叫中的憑證欄位。
• 不支援區塊磁碟區；僅支援檔案。
• 不支援指定檔案系統，預設為 ext4。
• CSI 驅動程式必須與提供的「external-attacher」一起部署，即使它們沒有實作「ControllerPublishVolume」亦然。
• Kubernetes 排程器拓撲感知功能不支援 CSI 磁碟區：簡而言之，即不支援分享關於磁碟區佈建位置（區域、地區等）的資訊，以允許 k8s 排程器做出更明智的排程決策。

下一步是什麼？

根據回饋和採用情況，Kubernetes 團隊計劃在 1.10 或 1.11 版本中將 CSI 實作推進到 Beta 階段。

如何參與？

這個專案，如同所有 Kubernetes 專案一樣，是來自不同背景的眾多貢獻者共同努力的成果。衷心感謝 Vladimir Vivien (vladimirvivien)、Jan Šafránek (jsafrane)、Chakravarthy Nelluri (chakri-nelluri)、Bradley Childs (childsb)、Luis Pabón (lpabon) 和 Saad Ali (saad-ali) 在將 CSI 帶入 Kubernetes 的過程中，所付出的不懈努力。

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

• ←上一頁
下一頁→