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

Kubernetes 1.17 特性：Kubernetes 樹內到 CSI 卷遷移進入 Beta 階段

作者：David Zhu (Google 軟體工程師) |

Kubernetes 樹記憶體儲外掛到容器儲存介面 (CSI) 的遷移基礎設施在 Kubernetes v1.17 中已進入 Beta 階段。CSI 遷移在 Kubernetes v1.14 中作為 Alpha 引入。

Kubernetes 功能通常作為 Alpha 引入，並在隨後的 Kubernetes 版本中進入 Beta 階段（最終進入穩定/GA 階段）。這個過程允許 Kubernetes 開發者獲取反饋、發現並修復問題、迭代設計，並交付高質量、生產級的特性。

為什麼我們要將樹內外掛遷移到 CSI？

在 CSI 之前，Kubernetes 提供了一個強大的卷外掛系統。這些卷外掛是“樹內”的，這意味著它們的程式碼是 Kubernetes 核心程式碼的一部分，並隨 Kubernetes 核心二進位制檔案一起釋出。然而，為 Kubernetes 新增新卷外掛支援非常具有挑戰性。希望為 Kubernetes 新增其儲存系統支援（甚至修復現有卷外掛中的錯誤）的供應商被迫與 Kubernetes 釋出流程保持一致。此外，第三方儲存程式碼導致核心 Kubernetes 二進位制檔案出現可靠性和安全問題，而且 Kubernetes 維護者通常難以（在某些情況下甚至不可能）測試和維護這些程式碼。在 Kubernetes 中使用容器儲存介面解決了這些主要問題。

隨著越來越多的 CSI 驅動程式被建立並投入生產，我們希望所有 Kubernetes 使用者都能從 CSI 模型中獲益。然而，我們不想透過破壞現有的通用儲存 API 來強迫使用者進行工作負載/配置更改。前進的道路很清晰——我們必須用 CSI 替換“樹內外掛”API 的後端。

什麼是 CSI 遷移？

CSI 遷移工作使得能夠用相應的CSI 驅動程式替換現有樹記憶體儲外掛，例如 kubernetes.io/gce-pd 或 kubernetes.io/aws-ebs。如果 CSI 遷移正常工作，Kubernetes 終端使用者不應注意到任何差異。遷移後，Kubernetes 使用者可以繼續使用現有介面，依賴樹記憶體儲外掛的所有功能。

當 Kubernetes 叢集管理員更新叢集以啟用 CSI 遷移時，現有的有狀態部署和工作負載將繼續像往常一樣執行；然而，在幕後，Kubernetes 將所有儲存管理操作（以前針對樹內驅動程式）的控制權移交給 CSI 驅動程式。

Kubernetes 團隊一直努力確保儲存 API 的穩定性，並承諾提供平滑的升級體驗。這涉及對所有現有功能和行為進行細緻的核算，以確保向後相容性和 API 穩定性。你可以把它想象成在一輛高速行駛的賽車上換輪胎。

如何為現有外掛試用 CSI 遷移？

如果您是 Kubernetes 分銷商，並且部署在以下環境中之一，那麼現在是開始測試 CSI 遷移並弄清楚如何部署/管理相應 CSI 驅動程式的好時機。

要試用現有外掛的 Beta 版 CSI 遷移，您必須使用 Kubernetes v1.17 或更高版本。首先，您必須更新/建立一個 Kubernetes 叢集，並在所有 Kubernetes 元件（master 和節點）上啟用功能標誌 CSIMigration（在 1.17 中預設開啟）和 CSIMigration{provider}（預設關閉）。其中 {provider} 是叢集中使用的樹內雲提供商儲存型別。請注意，在叢集升級期間，您必須在更新或更改 Kubelet 配置之前清空每個節點（移除正在執行的工作負載）。您可能還會看到一個可選的 CSIMigration{provider}Complete 標誌，如果所有節點都啟用了 CSI 遷移，您**可以**啟用它。

您還必須在叢集上安裝必要的 CSI 驅動程式——有關此說明通常可以在您選擇的提供商處找到。CSI 遷移已在 GCE 持久磁碟和 AWS 彈性塊儲存中進入 Beta 階段，並在 Azure 檔案/磁碟和 Openstack Cinder 中進入 Alpha 階段。Kubernetes 分銷商應考慮自動化其將依賴的 CSI 驅動程式的部署和管理（升級、降級等）。

要驗證功能標誌是否已啟用並且驅動程式已安裝在特定節點上，您可以獲取 CSINode 物件。您應該在驅動程式列表中看到已遷移外掛的樹內外掛名稱以及您[已安裝的]驅動程式。

kubectl get csinodes -o yaml

- apiVersion: storage.k8s.io/v1
  kind: CSINode
  metadata:
    annotations:
      storage.alpha.kubernetes.io/migrated-plugins: kubernetes.io/gce-pd
    name: test-node
    ...
  spec:
    drivers:
      name: pd.csi.storage.gke.io
      ...

完成上述設定後，您可以透過使用舊版 API 部署有狀態工作負載來確認您的叢集具有正常執行的 CSI 遷移。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-disk
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
   - name: web-server
     image: nginx
     volumeMounts:
       - mountPath: /var/lib/www/html
         name: mypvc
  volumes:
   - name: mypvc
     persistentVolumeClaim:
       claimName: test-disk

一段時間後驗證 Pod 是否正在執行

kubectl get pods web-server

NAME         READY   STATUS    RESTARTS   AGE
web-server   1/1     Running   0          39s

為了確認 CSI 驅動程式確實正在處理您的請求，在執行儲存管理操作後，檢查 CSI 驅動程式的容器日誌可能更謹慎。請注意，您的容器日誌可能會因使用的提供商而異。

kubectl logs {CSIdriverPodName} --container={CSIdriverContainerName}

/csi.v1.Controller/ControllerPublishVolume called with request: ...
Attaching disk ... to ...
ControllerPublishVolume succeeded for disk ... to instance ...

當前限制

儘管 CSI 遷移現在已進入 Beta 階段，但仍然存在一個主要限制，阻止我們預設將其開啟。開啟遷移仍然需要叢集管理員安裝 CSI 驅動程式，然後儲存功能才能無縫移交。我們目前正在與 SIG-CloudProvider 合作，以提供將所需 CSI 驅動程式與雲分發捆綁的無摩擦體驗。

時間線/狀態如何？

CSI 遷移的時間表實際上是由雲提供商提取專案設定的。它是從 Kubernetes 中刪除所有云提供商程式碼工作的一部分。透過將雲端儲存外掛遷移到外部 CSI 驅動程式，我們能夠提取出所有云提供商依賴項。

儘管整體功能處於 Beta 階段且預設未開啟，但仍需對每個外掛進行工作。目前只有 GCE PD 和 AWS EBS 已進入遷移的 Beta 階段，但由於它們依賴於手動安裝各自的 CSI 驅動程式，因此預設情況下仍處於關閉狀態。Azure 檔案/磁碟、OpenStack 和 VMWare 外掛目前處於不太成熟的狀態，而 NFS、Portworx、RBD 等非雲外掛仍處於規劃階段。

下表顯示了每個雲驅動程式的當前和目標釋出版本。

驅動程式AlphaBeta（樹內已棄用）GA目標“樹內外掛”移除版本
AWS EBS1.141.171.19 (目標)1.21
GCE PD1.141.171.19 (目標)1.21
OpenStack Cinder1.141.18 (目標)1.19 (目標)1.21
Azure 磁碟 + 檔案1.151.18 (目標)1.19 (目標)1.21
VSphere1.18 (目標)1.19 (目標)1.20 (目標)1.22

接下來是什麼？

主要即將進行的工作包括為剩餘的樹內外掛實現和強化 CSI 遷移，在發行版中預設安裝 CSI 驅動程式，預設開啟 CSI 遷移，最後作為雲提供商提取的一部分移除所有樹內外掛程式碼。我們預計將在 Kubernetes v1.21 完成此專案，包括完全切換到“預設開啟”遷移。

作為使用者我應該怎麼做？

請注意，Kubernetes 儲存系統的所有新功能（如卷快照）都將僅新增到 CSI 介面。因此，如果您正在啟動新叢集、首次建立有狀態應用程式或需要這些新功能，我們建議您原生使用 CSI 驅動程式（而不是樹內卷外掛 API）。請遵循更新的 CSI 驅動程式使用者指南並使用新的 CSI API。

然而，如果您選擇將叢集向前滾動或繼續使用帶有舊版卷 API 的規範，CSI 遷移將確保我們繼續使用新的 CSI 驅動程式支援這些部署。

我如何參與？

Kubernetes Slack 頻道 csi-migration 以及任何標準的 SIG Storage 通訊渠道都是聯絡 SIG Storage 和遷移工作組團隊的好途徑。

這個專案，就像所有的 Kubernetes 一樣，是許多來自不同背景的貢獻者共同努力的成果。我們對過去幾個季度為幫助專案達到 Beta 階段而付出努力的貢獻者表示衷心的感謝。

  • David Zhu
  • Deep Debroy
  • Cheng Pan
  • Jan Šafránek

特別感謝

  • Michelle Au
  • Saad Ali
  • Jonathan Basseri
  • Fabio Bertinatto
  • Ben Elder
  • Andrew Sy Kim
  • Hemant Kumar

感謝他們富有成效的對話、富有洞察力的評論以及對其他功能中 CSI 遷移的全面考慮。