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

聚焦 SIG Storage

作者：Frederico Muñoz (SAS) | 2022年8月22日，星期一

自 Kubernetes 誕生之初，持久資料以及如何滿足有狀態應用程式的需求一直是一個重要議題。對無狀態部署的支援是自然而然的，從一開始就存在，並得到了廣泛關注，變得非常知名。對有狀態應用程式更好支援的工作也從早期就開始了，每個版本都增加了 Kubernetes 上可執行的範圍。

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

在本次 SIG Storage 聚焦活動中，Frederico Muñoz (SAS 的雲與架構主管) 與 VMware 技術主管兼 SIG Storage 聯合主席 Xing Yang 進行了交談，討論了 SIG 的組織方式、當前的挑戰以及如何參與和貢獻。

關於 SIG Storage

Frederico (FSM)：你好，感謝有機會了解更多關於 SIG Storage 的資訊。您能簡單介紹一下您自己、您的角色以及您是如何參與 SIG Storage 的嗎？

Xing Yang (XY)：我是 VMware 的技術主管，負責雲原生儲存。我也是 SIG Storage 的聯合主席。我於 2017 年底開始參與 K8s SIG Storage，最初是為 VolumeSnapshot 專案貢獻程式碼。當時，VolumeSnapshot 專案仍處於實驗性的 pre-alpha 階段。它需要貢獻者。所以我自願提供了幫助。然後我與社群其他成員合作，使 VolumeSnapshot 在 2018 年的 K8s 1.12 版本中達到 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 實現會議、Object Bucket 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 定義和控制器是樹外（out-of-tree）的。有一個通用的快照控制器和一個快照驗證 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 驅動程式是樹外（out-of-tree）的，因此錯誤修復和釋出可以按照它們自己的節奏進行。

CSI 絕對是與樹內卷外掛相比的一個重大改進。Kubernetes 的 CSI 實現自 1.13 版本以來已達到 GA 階段。它已經走過了漫長的道路。SIG Storage 幾個版本以來一直在努力將樹內卷外掛遷移到樹外 CSI 驅動程式。

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

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

持續的挑戰

FSM：特別是對於 1.25 版本，我們可以看到有大量與儲存相關的 KEPs 正在推進中，您會說這個版本對 SIG 來說特別重要嗎？

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

FSM：確實如此，但是您想指出 1.25 版本中有什麼特別之處和亮點嗎？

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

CSI 遷移是 SIG Storage 幾個版本以來一直在進行的一項持續工作。目標是將樹內卷外掛遷移到樹外 CSI 驅動程式，並最終移除樹內卷外掛。在 1.25 中，我們有 7 個與 CSI 遷移相關的 KEPs。其中有一個核心 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 運作的見解！