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

COSI 簡介：使用 Kubernetes API 的物件儲存管理

作者：Sidhartha Mani (Minio, Inc) |

本文介紹容器物件儲存介面 (COSI)，這是在 Kubernetes 中佈建和使用物件儲存的標準。它是 Kubernetes v1.25 中的 Alpha 功能。

透過容器儲存介面 (CSI)，檔案和區塊儲存在 Kubernetes 生態系統中被視為一等公民。使用 CSI 卷的工作負載享有跨供應商和跨 Kubernetes 叢集的移植性優勢，而無需更改應用程式清單。物件儲存不存在同等標準。

近年來，物件儲存作為檔案系統和區塊裝置的替代儲存形式，越來越受歡迎。物件儲存範例促進了運算和儲存的分離。這是透過在網路上而非本地提供資料來完成的。分離式架構允許運算工作負載為無狀態的，這使得它們更容易管理、擴展和自動化。

COSI

COSI 旨在標準化物件儲存的使用，以提供以下優勢

  • Kubernetes 原生 - 使用 Kubernetes API 來佈建、配置和管理儲存桶
  • 自助服務 - 明確劃分管理和營運 (DevOps) 之間的界線，為 DevOps 人員啟用自助服務能力
  • 可移植性 - 透過跨 Kubernetes 叢集和跨物件儲存供應商的可移植性實現供應商中立性

只有當兩個供應商都支援通用的資料路徑 API 時，跨供應商的可移植性才有可能實現。例如，可以從 AWS S3 移植到 Ceph，或從 AWS S3 移植到 MinIO 並返回，因為它們都使用 S3 API。相反地，無法從 AWS S3 和 Google Cloud 的 GCS 之間相互移植。

架構

COSI 由三個組件組成

  • COSI 控制器管理器
  • COSI Sidecar
  • COSI 驅動程式

COSI 控制器管理器充當主控制器，處理對 COSI API 物件的變更。它負責處理儲存桶建立、更新、刪除和存取管理的要求。每個 Kubernetes 叢集都需要一個控制器管理器實例。即使叢集中使用多個物件儲存供應商，也只需要一個。

COSI Sidecar 充當 COSI API 要求和供應商特定的 COSI 驅動程式之間的翻譯器。此組件使用標準化的 gRPC 協定，供應商驅動程式應滿足該協定。

COSI 驅動程式是供應商特定的組件，它接收來自 Sidecar 的請求並呼叫適當的供應商 API 來建立儲存桶、管理其生命週期並管理對它們的存取。

API

COSI API 以儲存桶為中心，因為儲存桶是物件儲存的單位抽象概念。COSI 定義了三個旨在管理它們的 Kubernetes API

  • Bucket（儲存桶）
  • BucketClass（儲存桶類別）
  • BucketClaim（儲存桶請求）

此外，還定義了另外兩個用於管理儲存桶存取的 API

  • BucketAccess（儲存桶存取）
  • BucketAccessClass（儲存桶存取類別）

簡而言之，Bucket 和 BucketClaim 可以分別被認為類似於 PersistentVolume 和 PersistentVolumeClaim。BucketClass 在檔案/區塊裝置世界中的對應物是 StorageClass。

由於物件儲存始終經過身份驗證，並且透過網路，因此需要存取憑證才能存取儲存桶。兩個 API，即 BucketAccess 和 BucketAccessClass，用於表示身份驗證的存取憑證和策略。有關這些 API 的更多資訊，請參閱官方 COSI 提案 - https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1979-object-storage-support

自助服務

除了提供 Kubernetes API 驅動的儲存桶管理之外，COSI 還旨在授權 DevOps 人員自行佈建和管理儲存桶，而無需管理員干預。這進一步使開發團隊能夠實現更快的周轉時間和更快的上市時間。

COSI 透過將儲存桶佈建步驟劃分給兩個不同的利害關係人來實現這一點，即管理員 (admin) 和叢集操作員。管理員將負責設定關於如何佈建儲存桶以及如何取得其存取的廣泛策略和限制。叢集操作員將可以在管理員設定的限制內自由建立和使用儲存桶。

例如，叢集操作員可以使用管理員策略來限制最大佈建容量為 100GB，開發人員將被允許建立儲存桶並儲存高達該限制的資料。同樣地，對於存取憑證，管理員將能夠限制誰可以存取哪些儲存桶，而開發人員將能夠存取所有可供他們使用的儲存桶。

可移植性

COSI 的第三個目標是實現儲存桶管理的供應商中立性。COSI 實現了兩種可移植性

  • 跨叢集
  • 跨供應商

跨叢集可移植性是允許在一個叢集中佈建的儲存桶在另一個叢集中可用。這僅在物件儲存後端本身可從兩個叢集存取時才有效。

跨供應商可移植性是關於允許組織或團隊從一個物件儲存供應商無縫遷移到另一個物件儲存供應商，而無需更改應用程式定義（PodTemplates、StatefulSets、Deployment 等）。這僅在來源和目的地供應商使用相同的資料時才有可能。

COSI 不處理資料遷移，因為它超出其範圍。如果供應商之間的移植也需要遷移資料，則需要採取其他措施來確保資料可用性。

接下來是什麼

令人驚嘆的 sig-storage-cosi 社群努力工作，使 COSI 標準達到 Alpha 狀態。我們期待許多供應商加入編寫 COSI 驅動程式並變得與 COSI 相容！

我們希望為 COSI 儲存桶添加更多身份驗證機制，我們正在設計進階的儲存桶共享原語、多叢集儲存桶管理等等。前方有許多很棒的想法和機會！

請繼續關注接下來的發展，如果您有任何問題、意見或建議