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

聚焦 SIG Storage

作者：Frederico Muñoz (SAS) |

自 Kubernetes 問世以來，持久性資料以及如何解決具狀態應用程式的需求一直是重要的主題。對無狀態部署的支援是自然而然的，從一開始就存在，並引起了關注，變得非常知名。從早期開始也存在對更好支援具狀態應用程式的工作，每次發布都增加了可以在 Kubernetes 上運行的範圍。

訊息佇列、資料庫、叢集檔案系統：這些是一些解決方案的範例，它們具有不同的儲存需求，並且如今越來越多地部署在 Kubernetes 中。處理臨時和持久性儲存、本地或遠端、檔案或區塊、來自許多不同供應商的儲存，同時考慮如何提供使用者期望的必要彈性和資料一致性，所有這些都在 SIG Storage 的範疇內。

在這次 SIG Storage 焦點報導中，Frederico Muñoz（SAS 的雲端與架構主管）與 Xing Yang（VMware 的技術主管兼 SIG Storage 聯合主席）討論了 SIG 的組織方式、當前的挑戰以及任何人如何參與和貢獻。

關於 SIG Storage

Frederico (FSM)：您好，感謝您提供這次機會讓我更了解 SIG Storage。您能否談談您自己、您的職責以及您是如何參與 SIG Storage 的。

Xing Yang (XY)：我是 VMware 的技術主管，負責雲原生儲存。我也是 SIG Storage 的聯合主席。我在 2017 年底開始參與 K8s SIG Storage，首先是為 VolumeSnapshot 專案做出貢獻。當時，VolumeSnapshot 專案仍處於實驗性的 pre-alpha 階段。它需要貢獻者。所以我自願提供幫助。然後我與其他社群成員合作，在 2018 年的 K8s 1.12 版本中將 VolumeSnapshot 帶入 Alpha 階段，在 2019 年的 K8s 1.17 版本中進入 Beta 階段，並最終在 2020 年的 1.20 版本中達到 GA 階段。

FSM：僅閱讀 SIG Storage 章程 就清楚地表明 SIG Storage 涵蓋了很多領域，您能否描述一下 SIG 的組織方式？

XY：在 SIG Storage 中，有兩位聯合主席和兩位技術主管。來自 Google 的 Saad Ali 和我本人是聯合主席。來自 Google 的 Michelle Au 和來自 Red Hat 的 Jan Šafránek 是技術主管。

我們每兩週舉行一次會議，在會議中我們會討論每個特定版本正在開發的功能、獲取狀態、確保每個功能都有開發負責人和審閱者在處理，並提醒人們注意發布截止日期等等。有關 SIG 的更多資訊，請參閱社群頁面。人們還可以將需要關注的 PR、需要討論的設計提案和其他主題添加到會議議程文件中。我們將在專案追蹤完成後查看它們。

我們還有其他定期會議，例如 CSI 實施會議、物件儲存桶 API 設計會議，以及在需要時針對特定主題的一次性會議。還有一個由 SIG Storage 和 SIG Apps 贊助的 K8s 資料保護工作組。SIG Storage 擁有或共同擁有在資料保護工作組中討論的功能。

儲存和 Kubernetes

FSM：儲存在許多方面都是基礎組件，尤其是在 Kubernetes 中：您認為 Kubernetes 特有的儲存管理挑戰是什麼？

XY：在 Kubernetes 中，卷操作涉及多個組件。例如，建立 Pod 以使用 PVC 涉及多個組件。有 Attach Detach Controller 和 external-attacher 負責將 PVC 連接到 Pod。還有 Kubelet 負責將 PVC 掛載到 Pod。當然，CSI 驅動程式也參與其中。在協調多個組件之間時，有時可能會出現競爭條件。

另一個挑戰是關於核心與 自訂資源定義 (CRD)，實際上並非儲存特有。CRD 是擴展 Kubernetes 功能的好方法，同時不會向 Kubernetes 核心本身添加太多程式碼。但是，這也意味著在運行 Kubernetes 叢集時需要許多外部組件。

從 SIG Storage 方面來看，最值得注意的例子是 Volume Snapshot。Volume Snapshot API 被定義為 CRD。API 定義和控制器是樹狀結構外的。有一個通用的快照控制器和快照驗證 webhook 應該部署在控制平面上，類似於 kube-controller-manager 的部署方式。雖然 Volume Snapshot 是一個 CRD，但它是 SIG Storage 的核心功能。建議 K8s 叢集發行版部署 Volume Snapshot CRD、快照控制器和快照驗證 webhook，但是，大多數時候我們沒有看到發行版部署它們。因此，這成為儲存供應商的問題：現在部署這些非驅動程式特定的通用組件成為他們的責任。如果客戶想要使用多個儲存系統並部署多個 CSI 驅動程式，這可能會導致衝突。

FSM：不僅是單個儲存系統的複雜性，您還必須考慮它們如何在 Kubernetes 中一起使用？

XY：是的，有許多不同的儲存系統可以為 Kubernetes 中的容器提供儲存。它們的工作方式不同。找到一個適用於所有人的解決方案具有挑戰性。

FSM：Kubernetes 中的儲存也涉及與外部解決方案互動，可能比 Kubernetes 的其他部分更多。與供應商和外部供應商的這種互動是否具有挑戰性？隨著時間的推移，它是否以任何方式演變？

XY：是的，這絕對具有挑戰性。最初，Kubernetes 儲存具有樹狀結構內的卷外掛程式介面。多家儲存供應商實施了樹狀結構內介面，並在 Kubernetes 核心程式碼庫中擁有卷外掛程式。這導致了很多問題。如果卷外掛程式中存在錯誤，則會影響整個 Kubernetes 程式碼庫。所有卷外掛程式都必須與 Kubernetes 一起發布。如果儲存供應商需要修復其外掛程式中的錯誤或想要與其自己的產品發布保持一致，則沒有靈活性。

FSM：這就是 CSI 發揮作用的地方？

XY：沒錯，然後就出現了 容器儲存介面 (CSI)。這是一個產業標準，旨在設計通用的儲存介面，以便儲存供應商可以編寫一個外掛程式並使其在一系列容器協調系統 (CO) 中工作。現在 Kubernetes 是主要的 CO，但在 CSI 剛開始時，除了 Kubernetes 之外，還有 Docker、Mesos、Cloud Foundry。CSI 驅動程式是樹狀結構外的，因此錯誤修復和發布可以按照自己的節奏進行。

與樹狀結構內的卷外掛程式相比，CSI 絕對是一個很大的改進。Kubernetes 對 CSI 的實施自 1.13 版本以來 已達到 GA 階段。它已經走了很長的路。SIG Storage 一直在努力將樹狀結構內的卷外掛程式移動到樹狀結構外的 CSI 驅動程式，這已經有好幾個版本了。

FSM：將驅動程式從 Kubernetes 主樹移動到 CSI 是一個重要的改進。

XY：CSI 介面是對樹狀結構內卷外掛程式介面的改進，但是，仍然存在挑戰。儲存系統有很多。目前，CSI 驅動程式文件中列出了 100 多個 CSI 驅動程式。這些儲存系統也非常多樣化。因此，很難設計一個適用於所有人的通用 API。我們在 CSI 驅動程式級別引入了功能，但是當同一個驅動程式佈建的卷具有不同的行為時，我們也面臨挑戰。前幾天我們剛舉行了一次會議，討論每個卷 CSI 驅動程式功能。當同一個驅動程式同時支援區塊卷和檔案卷時，我們在區分某些 CSI 驅動程式功能時遇到問題。我們將舉行後續會議來討論這個問題。

持續的挑戰

FSM：具體來說，對於 1.25 版本，我們可以看到有相當多的儲存相關 KEP 正在進行中，您會說這個版本對 SIG 特別重要嗎？

XY：我不會說一個版本比其他版本更重要。在任何給定的版本中，我們都在處理一些非常重要的事情。

FSM：確實如此，但是有沒有您想指出的 1.25 版本特有的具體性和亮點？

XY：是的。對於 1.25 版本，我想強調以下幾點

  • CSI 遷移 是 SIG Storage 多個版本以來一直在努力進行的工作。目標是將樹狀結構內的卷外掛程式移動到樹狀結構外的 CSI 驅動程式，並最終移除樹狀結構內的卷外掛程式。我們在 1.25 版本中針對的 7 個 KEP 與 CSI 遷移相關。有一個核心 KEP 用於通用的 CSI 遷移功能。目標是在 1.25 版本中達到 GA 階段。GCE PD 和 AWS EBS 的 CSI 遷移目標是 GA 階段。vSphere 的 CSI 遷移目標是在 1.25 版本中預設開啟功能閘道，同時保持在 Beta 階段。Ceph RBD 和 PortWorx 的目標是 Beta 階段，功能閘道預設關閉。Ceph FS 的目標是 Alpha 階段。
  • 我想強調的第二個是 COSI，容器物件儲存介面。這是 SIG Storage 下的一個子專案。COSI 提出了物件儲存 Kubernetes API，以支援 Kubernetes 工作負載的物件儲存操作協調。它還為物件儲存供應商引入了 gRPC 介面，以編寫驅動程式來佈建儲存桶。COSI 團隊在這個專案上已經工作了兩年多了。COSI 功能的目標是在 1.25 版本中達到 Alpha 階段。KEP 剛剛合併。COSI 團隊正在根據更新後的 KEP 更新實施。
  • 我想提到的另一個功能是 CSI 臨時卷 支援。此功能允許直接在 Pod 規範中指定 CSI 卷，用於臨時用例。它們可用於使用掛載的卷直接在 Pod 內部注入任意狀態，例如配置、密碼、身分、變數或類似資訊。這最初在 1.15 版本中作為 Alpha 功能引入，現在目標是在 1.25 版本中達到 GA 階段。

FSM：如果必須挑選一件事，您認為 SIG 正在努力的最緊迫領域是什麼？

XY：CSI 遷移絕對是 SIG 投入了大量精力的領域之一，並且已經持續了好幾個版本。它涉及多家雲端供應商和儲存供應商的工作。

社群參與

FSM：Kubernetes 是一個社群驅動的專案。對於任何想要參與 SIG Storage 工作的人，有什麼建議嗎？他們應該從哪裡開始？

XY：查看 SIG Storage 社群頁面，它有很多關於如何入門的資訊。有 SIG 年度報告 告訴您我們每年做了什麼。查看貢獻指南。它有指向演示文稿的連結，可以幫助您熟悉 Kubernetes 儲存概念。

加入我們的 每週四舉行的雙週會議。了解 SIG 的運作方式以及我們每個版本正在開發的內容。找到您感興趣的專案並提供幫助。正如我之前提到的，我透過為 Volume Snapshot 專案做出貢獻而開始參與 SIG Storage。

FSM：您還有什麼最後的想法要補充嗎？

XY：SIG Storage 始終歡迎新的貢獻者。我們需要貢獻者來幫助構建新功能、修復錯誤、進行程式碼審查、編寫測試、監控測試網格健康狀況以及改進文件等等。

FSM：非常感謝您抽出時間並深入了解 SIG Storage 的運作方式！