本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 1.22：CSI Windows 支援（帶 CSI 代理）達到 GA
Windows 版 CSI Proxy 的穩定版本已隨 Kubernetes 1.22 釋出。CSI Proxy 使執行在 Windows 節點上的 CSI 驅動能夠執行特權儲存操作。
背景
Kubernetes 的容器儲存介面 (CSI) 在 Kubernetes 1.13 版本中正式釋出。CSI 已成為將塊儲存和檔案儲存暴露給 Kubernetes 等容器編排系統 (CO) 上容器化工作負載的標準。它使第三方儲存提供商能夠編寫和部署外掛，而無需修改 Kubernetes 核心程式碼庫。舊版樹內驅動已被棄用，新的儲存功能透過 CSI 引入，因此讓 CSI 驅動在 Windows 上工作變得非常重要。
Kubernetes 中的 CSI 驅動有兩個主要元件：一個在控制平面中執行的控制器外掛，以及一個在每個節點上執行的節點外掛。
控制器外掛通常不需要直接訪問主機，可以透過 Kubernetes API 和外部控制平面服務執行所有操作。
然而，節點外掛需要直接訪問主機，以便將塊裝置和/或檔案系統提供給 Kubernetes kubelet。由於 Windows 節點上的容器無法執行特權操作（CSI Proxy 作為 alpha 版本在 Kubernetes 1.18 中引入，作為一種使容器能夠執行特權儲存操作的方式），這使得容器化 CSI 驅動能夠在 Windows 節點上執行。
什麼是 CSI Proxy，CSI 驅動如何與之互動？
當排程使用持久卷的工作負載時，它將經歷 CSI 規範中定義的一系列步驟。首先，工作負載將被排程到節點上執行。然後，CSI 驅動的控制器元件會將持久卷附加到節點。最後，CSI 驅動的節點元件會將持久卷掛載到節點上。
CSI 驅動的節點元件需要執行在 Windows 節點上才能支援 Windows 工作負載。在 Windows 節點上執行的容器化應用程式還無法執行各種特權操作，例如磁碟裝置掃描、檔案系統掛載等（Kubernetes 1.22 中作為 alpha 版本引入的 Windows HostProcess 容器能夠實現需要主機訪問的功能，例如前面提到的操作）。但是，我們可以透過預裝在 Windows 節點上的二進位制檔案（CSI Proxy）來執行這些操作。CSI Proxy 採用客戶端-伺服器架構，允許 CSI 驅動透過在 CSI Proxy 啟動期間建立的命名管道暴露的 gRPC 介面發出特權儲存操作。
CSI Proxy 正式釋出
CSI Proxy 開發團隊與儲存廠商密切合作，其中許多廠商早在 CSI Proxy 設計方案階段就開始將 CSI Proxy 整合到他們的 CSI 驅動中，並提供了反饋。這種合作發現了需要額外 API 的用例，找到了錯誤，並確定了文件改進的領域。
CSI Proxy 設計 KEP 已更新，以反映當前的 CSI Proxy 架構。此外，還包含了 開發文件，供有興趣幫助開發新功能或修復錯誤的貢獻者參考。
在正式釋出之前，我們希望確保我們的 API 簡單且一致。我們對 v1beta API 組進行了廣泛的 API 審查，確保 CSI Proxy API 方法和訊息與 CSI 規範中定義的命名約定保持一致。作為這項工作的一部分，我們正在將 磁碟 (Disk)、檔案系統 (Filesystem)、SMB 和 卷 (Volume) API 組升級到 v1。
用於從 Windows 節點獲取資訊和支援在 Windows 節點中掛載 iSCSI 目標的附加 Windows 系統 API，可在 System API 和 iSCSI API 中作為 alpha API 使用。這些 API 將在升級到 v1 之前繼續改進。
CSI Proxy v1 與所有以前的 v1betaX 版本相容。正式釋出的 csi-proxy.exe 二進位制檔案可以處理來自 v1betaX 客戶端的請求，這得益於自動生成的轉換層，該層將任何版本化客戶端請求轉換為伺服器可以處理的與版本無關的請求。為了確保 CSI Proxy 向後相容，為所有升級到 v1 的 API 組的所有 API 版本添加了多個整合測試。
CSI Proxy 與與之互動的 CSI 驅動之間的版本漂移也經過了仔細考慮。我們為 CSI 驅動提供了一種連接回退機制，以處理多個 CSI Proxy 版本，從而平穩升級到 v1。這允許 CSI 驅動（例如 GCE PD CSI 驅動）識別正在執行的 CSI Proxy 二進位制檔案的版本，並處理部署在節點上的多個 CSI Proxy 二進位制檔案版本。
CSI Proxy v1 已經被許多 CSI 驅動使用，包括 AWS EBS CSI 驅動、Azure Disk CSI 驅動、GCE PD CSI 驅動和 SMB CSI 驅動。
未來計劃
我們對 CSI Proxy 的未來感到非常興奮。隨著即將推出的 Windows HostProcess 容器，我們正在考慮將 CSI Proxy 轉換為 CSI 驅動使用的庫，而不是當前的客戶端/伺服器設計。這將使我們能夠更快地迭代新功能，因為不再需要 csi-proxy.exe 二進位制檔案。
如何參與？
與所有 Kubernetes 專案一樣，這個專案也是許多來自不同背景的貢獻者共同努力的成果。對參與 CSI Proxy 或 Kubernetes 儲存系統任何部分的設計和開發感興趣的人員，可以加入 Kubernetes 儲存特別興趣小組 (SIG)。我們正在迅速發展，並始終歡迎新的貢獻者。
對 Windows 中 CSI 支援的更多詳細資訊感興趣的人員，請透過 Kubernetes Slack 頻道 #csi-windows 聯絡我們。
致謝
CSI-Proxy 收到了 Kubernetes 社群成員的諸多貢獻。我們感謝所有為 CSI Proxy 做出貢獻的人們，包括設計審查、錯誤報告、錯誤修復以及他們為實現這一里程碑提供的持續支援。