本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 1.23：Kubernetes 樹內到 CSI 卷遷移狀態更新
Kubernetes 樹記憶體儲外掛到容器儲存介面 (CSI) 遷移基礎設施自 v1.17 版本以來已進入Beta 階段。CSI 遷移功能在 Kubernetes v1.14 中作為 Alpha 版本引入。
自那時起，SIG Storage 和其他 Kubernetes 專項小組一直在努力確保功能穩定性和相容性，為 GA 做準備。本文旨在提供該功能的最新狀態以及 Kubernetes 1.17 到 1.23 之間的變化。此外，我還將介紹每個儲存外掛 CSI 遷移功能 GA 的未來路線圖。
快速回顧：什麼是 CSI 遷移，為什麼要遷移？
容器儲存介面 (CSI) 旨在幫助 Kubernetes 替換其現有的樹記憶體儲驅動機制——特別是特定於供應商的外掛。Kubernetes 對容器儲存介面的支援自 Kubernetes v1.13 以來已經普遍可用。引入 CSI 驅動程式支援是為了更容易地在 Kubernetes 和儲存後端技術之間新增和維護新的整合。使用 CSI 驅動程式可以帶來更好的可維護性（驅動程式作者可以定義自己的釋出週期和支援生命週期）並減少漏洞發生的機會（樹內程式碼越少，出錯的風險就越小，並且叢集操作員可以選擇叢集所需的儲存驅動程式）。
隨著更多 CSI 驅動程式的建立並投入生產使用，SIG Storage 組希望所有 Kubernetes 使用者都能從 CSI 模型中受益。然而，我們不能破壞與現有儲存 API 型別的 API 相容性。我們提出的解決方案是 CSI 遷移：一個將樹內 API 轉換為等效 CSI API 並將操作委託給替代 CSI 驅動程式的功能。
CSI 遷移工作支援將現有的樹記憶體儲外掛（如 kubernetes.io/gce-pd 或 kubernetes.io/aws-ebs）替換為儲存後端的相應 CSI 驅動程式。如果 CSI 遷移正常工作，Kubernetes 終端使用者應該不會注意到任何差異。現有的 StorageClass、PersistentVolume 和 PersistentVolumeClaim 物件應繼續工作。當 Kubernetes 叢集管理員更新叢集以啟用 CSI 遷移時，利用由樹記憶體儲外掛支援的 PVC 的現有工作負載將繼續像以前一樣執行。然而，在幕後，Kubernetes 將所有儲存管理操作（以前針對樹內驅動程式）的控制權交給 CSI 驅動程式。
例如，假設您是 kubernetes.io/gce-pd 使用者，在 CSI 遷移之後，您仍然可以使用 kubernetes.io/gce-pd 來配置新卷、掛載現有 GCE-PD 卷或刪除現有卷。所有現有 API/介面仍將正常執行。然而，底層函式呼叫都透過 GCE PD CSI 驅動程式，而不是樹內 Kubernetes 函式。
這使得終端使用者能夠順利過渡。此外，作為儲存外掛開發人員，我們可以減輕維護樹記憶體儲外掛的負擔，並最終將它們從核心 Kubernetes 二進位制檔案中移除。
有什麼變化，有什麼新功能？
在 Kubernetes v1.17 及更早版本的工作基礎上，自那以後釋出的版本進行了一系列更改
新功能門
Kubernetes v1.21 版本廢棄了 CSIMigration{provider}Complete 功能標誌，並停止對其進行處理。取而代之的是新的功能標誌 InTreePlugin{vendor}Unregister，它取代了舊的功能標誌並保留了 CSIMigration{provider}Complete 提供的所有功能。
CSIMigration{provider}Complete 之前作為 CSI 遷移在所有節點上啟用後的補充功能門引入。此標誌登出您使用標誌名稱的 {provider} 部分指定的樹記憶體儲外掛。
當您啟用該功能門時，您的叢集將直接選擇並使用相關的 CSI 驅動程式，而不是使用樹內驅動程式程式碼。這發生在不檢查 CSI 遷移是否在節點上啟用或您是否實際部署了該 CSI 驅動程式的情況下。
雖然這個功能門是一個很好的幫手，但 SIG Storage（我敢肯定，還有許多叢集操作員）也希望有一個功能門，讓您可以在不啟用 CSI 遷移的情況下停用樹記憶體儲外掛。例如，您可能希望在 GCE 叢集上停用 EBS 儲存外掛，因為 EBS 卷是特定於不同供應商的雲（AWS）。
為了實現這一點，Kubernetes v1.21 引入了一組新的功能標誌：InTreePlugin{vendor}Unregister。
InTreePlugin{vendor}Unregister 是一個獨立的功能門，可以獨立於 CSI 遷移啟用和停用。啟用後，元件不會將特定的樹記憶體儲外掛註冊到支援列表中。如果叢集操作員只啟用此標誌，當使用該外掛時，終端使用者將收到 PVC 錯誤，指出無法找到該外掛。如果叢集操作員不希望支援舊的樹內 API，而只希望在未來支援 CSI，則無論 CSI 遷移是否啟用，都可能希望啟用此功能。
可觀測性
Kubernetes v1.21 引入了用於跟蹤 CSI 遷移的指標。您可以使用這些指標來觀察您的叢集如何使用儲存服務，以及對該儲存的訪問是使用舊的樹內驅動程式還是其基於 CSI 的替代方案。
| 元件 | 指標 | 備註 |
|---|---|---|
| Kube-Controller-Manager | storage_operation_duration_seconds | 指標中添加了一個新標籤 migrated，用於指示此儲存操作是否為 CSI 遷移操作（true 表示已啟用，false 表示未啟用）。 |
| Kubelet | csi_operations_seconds | 新指標公開了包括 driver_name、method_name、grpc_status_code 和 migrated 在內的標籤。這些標籤的含義與 csi_sidecar_operations_seconds 相同。 |
| CSI 邊車（provisioner、attacher、resizer） | csi_sidecar_operations_seconds | 指標中添加了一個新標籤 migrated，用於指示此儲存操作是否為 CSI 遷移操作（true 表示已啟用，false 表示未啟用）。 |
錯誤修復和功能改進
在 Beta 測試人員的幫助下，我們修復了許多錯誤，例如懸空附件、垃圾回收和不正確的拓撲標籤。
雲提供商和叢集生命週期協作
SIG Storage 一直與 SIG Cloud Provider 和 SIG Cluster Lifecycle 密切合作，以推出 CSI 遷移。
如果您是託管 Kubernetes 服務的使用者，請諮詢您的提供商是否需要採取任何措施。在許多情況下，提供商將管理遷移，不需要額外的工作。
如果您使用 Kubernetes 發行版，請查閱其官方文件，瞭解有關此功能支援的資訊。對於 CSI 遷移功能畢業到 GA，SIG Storage 和 SIG Cluster Lifecycle 正在合作，以便在 Kubernetes 本身可用時，儘快在工具（例如 kubeadm）中提供遷移機制。
時間表/狀態如何？
下表顯示了每個驅動程式的當前和目標釋出版本
| 驅動程式 | Alpha | Beta（樹內已棄用） | 測試版 (預設啟用) | GA | 目標“樹內外掛”移除版本 |
|---|---|---|---|---|---|
| AWS EBS | 1.14 | 1.17 | 1.23 | 1.24 (目標) | 1.26 (目標) |
| GCE PD | 1.14 | 1.17 | 1.23 | 1.24 (目標) | 1.26 (目標) |
| OpenStack Cinder | 1.14 | 1.18 | 1.21 | 1.24 (目標) | 1.26 (目標) |
| Azure Disk | 1.15 | 1.19 | 1.23 | 1.24 (目標) | 1.26 (目標) |
| Azure File | 1.15 | 1.21 | 1.24 (目標) | 1.25 (目標) | 1.27 (目標) |
| vSphere | 1.18 | 1.19 | 1.24 (目標) | 1.25 (目標) | 1.27 (目標) |
| Ceph RBD | 1.23 | ||||
| Portworx | 1.23 |
以下儲存驅動程式將不支援 CSI 遷移。ScaleIO 驅動程式已被移除；其他驅動程式已被棄用並將從核心 Kubernetes 中移除。
| 驅動程式 | 已棄用 | 程式碼移除 |
|---|---|---|
| ScaleIO | 1.16 | 1.22 |
| Flocker | 1.22 | 1.25 (目標) |
| Quobyte | 1.22 | 1.25 (目標) |
| StorageOS | 1.22 | 1.25 (目標) |
接下來是什麼？
隨著更多 CSI 驅動程式畢業到 GA，我們希望很快將整個 CSI 遷移功能標記為 GA。我們預計雲提供商的樹記憶體儲外掛程式碼將在 Kubernetes v1.26 和 v1.27 之前移除。
作為使用者，我應該怎麼做？
請注意，Kubernetes 儲存系統的所有新功能（例如卷快照）將僅新增到 CSI 介面。因此，如果您正在啟動一個新叢集、首次建立有狀態應用程式或需要這些新功能，我們建議原生使用 CSI 驅動程式（而不是樹內卷外掛 API）。請遵循 更新的 CSI 驅動程式使用者指南 並使用新的 CSI API。
然而，如果您選擇升級叢集或繼續使用帶有傳統卷 API 的規範，CSI 遷移將確保我們繼續使用新的 CSI 驅動程式支援這些部署。但是，如果您想利用快照等新功能，則需要手動遷移才能將現有樹內 PV 重新匯入為 CSI PV。
我如何參與？
Kubernetes Slack 頻道 #csi-migration 以及任何標準 SIG Storage 通訊渠道 都是聯絡 SIG Storage 和遷移工作組團隊的絕佳方式。
這個專案，和所有 Kubernetes 專案一樣，是來自不同背景的許多貢獻者共同努力的成果。我們非常感謝這些季度以來幫助推動專案前進的貢獻者
- Michelle Au (msau42)
- Jan Šafránek (jsafrane)
- Hemant Kumar (gnufied)
特別感謝以下人員對 CSI 遷移功能的富有見地的審查、周密的考慮和寶貴的貢獻
- Andy Zhang (andyzhangz)
- Divyen Patel (divyenpatel)
- Deep Debroy (ddebroy)
- Humble Devassy Chirammal (humblec)
- Jing Xu (jingxu97)
- Jordan Liggitt (liggitt)
- Matthew Cary (mattcary)
- Matthew Wong (wongma7)
- Neha Arora (nearora-msft)
- Oksana Naumov (trierra)
- Saad Ali (saad-ali)
- Tim Bannister (sftim)
- Xing Yang (xing-yang)
那些有興趣參與 CSI 或 Kubernetes 儲存系統任何部分的設計和開發的人，請加入 Kubernetes 儲存特別興趣小組 (SIG)。我們正在快速成長，並隨時歡迎新的貢獻者。