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

介紹 COSI：使用 Kubernetes API 進行物件儲存管理

作者：Sidhartha Mani (Minio, Inc) |

本文介紹了容器物件儲存介面（Container Object Storage Interface，COSI），這是在 Kubernetes 中供應和使用物件儲存的標準。它是 Kubernetes v1.25 中的一個 Alpha 功能。

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

近年來，物件儲存作為檔案系統和塊裝置的替代儲存形式越來越受歡迎。物件儲存正規化促進了計算和儲存的解耦。這是透過使資料透過網路而非本地可用來實現的。解耦架構允許計算工作負載是無狀態的，從而使其更易於管理、擴充套件和自動化。

COSI

COSI 旨在標準化物件儲存的使用，以提供以下好處：

  • Kubernetes 原生 - 使用 Kubernetes API 來供應、配置和管理儲存桶（bucket）
  • 自助服務 - 明確劃分管理和運營（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 邊車充當 COSI API 請求和特定於供應商的 COSI 驅動程式之間的轉換器。該元件使用供應商驅動程式應滿足的標準化 gRPC 協議。

COSI 驅動程式是特定於供應商的元件，它從邊車接收請求，並呼叫相應的供應商 API 來建立儲存桶、管理其生命週期以及管理對其的訪問。

API

COSI API 以儲存桶（bucket）為中心，因為儲存桶是物件儲存的單元抽象。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 儲存桶新增更多身份驗證機制，我們正在設計高階的儲存桶共享原語、多叢集儲存桶管理等等。前方有許多偉大的想法和機會！

敬請關注接下來的內容，如果您有任何問題、評論或建議：