Kubernetes 1.17 功能：Kubernetes 樹狀結構內到 CSI 磁碟區遷移移至 Beta 版

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 遷移工作旨在將現有的樹狀結構內儲存外掛程式（例如 kubernetes.io/gce-pd 或 kubernetes.io/aws-ebs）替換為對應的 CSI 驅動程式。如果 CSI 遷移正常運作，Kubernetes 最終使用者不應注意到任何差異。遷移後，Kubernetes 使用者可以繼續使用現有介面依賴樹狀結構內儲存外掛程式的所有功能。

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

Kubernetes 團隊努力工作，以確保儲存 API 的穩定性以及順利升級體驗的承諾。這涉及對所有現有功能和行為進行細緻的核算，以確保向後相容性和 API 穩定性。您可以將其想像成在賽車以高速直線行駛時更換輪胎。

如何試用現有外掛程式的 CSI 遷移？

如果您是 Kubernetes 發行商，在以下列出的環境之一中進行部署，那麼現在是開始測試 CSI 遷移並弄清楚如何部署/管理適當 CSI 驅動程式的好時機。

若要試用現有外掛程式的 Beta 版 CSI 遷移，您必須使用 Kubernetes v1.17 或更高版本。首先，您必須更新/建立 Kubernetes 叢集，並在所有 Kubernetes 組件（主節點和工作節點）上啟用功能標誌 CSIMigration（在 1.17 中預設為開啟）和 CSIMigration{provider}（預設為關閉）。其中 {provider} 是叢集中使用的樹狀結構內雲端供應商儲存類型。請注意，在叢集升級期間，您必須先清空每個節點（移除正在運行的工作負載），然後才能更新或變更 Kubelet 的組態。您也可能會看到一個可選的 CSIMigration{provider}Complete 標誌，如果您可以啟用所有節點都已啟用 CSI 遷移，則可以啟用它。

您還必須在叢集上安裝必要的 CSI 驅動程式 - 相關說明通常可以從您選擇的供應商處找到。CSI 遷移適用於 Beta 版的 GCE Persistent Disk 和 AWS Elastic Block Store，以及 Alpha 版的 Azure File/Disk 和 OpenStack Cinder。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 在一段時間後是否處於 RUNNING 狀態

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 File/Disk、OpenStack 和 VMWare 外掛程式目前處於較不成熟的狀態，而 NFS、Portworx、RBD 等非雲端外掛程式仍處於規劃階段。

下表顯示了每個雲端驅動程式的目前和目標發布版本

下一步是什麼？

即將進行的主要工作包括為其餘樹狀結構內外掛程式實作和強化 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 遷移進行了富有成果的對話、深入的審查和周全的考量。

• ←上一篇
下一篇→