Kubernetes CSI 是容器儲存介面(CSI)的 Kubernetes 特定實現。CSI 規範提供了一個標準,可在儲存系統和容器協調(CO)平台之間實現連接。它是Kubernetes 儲存管理的基礎。
CSI 標準決定了任意區塊和檔案儲存系統如何在 Kubernetes 等容器化系統上向工作負載公開。第三方儲存廠商可以使用 CSI 來建構外掛程式並部署它們,使 Kubernetes 能夠與新的儲存系統配合使用,而無需編輯 Kubernetes 的核心程式碼。
在本文中:
在 Container Storage Interface 出現之前,Kubernetes 只支援使用樹內 k8s 卷外掛程式,這些外掛程式必須使用核心 Kubernetes 二進位檔來編寫和部署。這意味著儲存供應商必須簽入其 k8s 外掛程式的核心程式碼庫,才能支援新的儲存系統。
Flex-volume 是一種基於外掛程式的解決方案,它試圖通過向第三方外掛程式公開基於可執行檔的 API 來解決此問題。雖然該解決方案在與 k8s 二進位檔分離方面遵循與 CSI 類似的原理運行,但這種方法存在許多問題。首先,它需要對主文件系統和主機文件系統的 root 訪問許可權才能啟用驅動程序檔的部署。其次,它帶來了操作系統依賴項和先決條件的沉重負擔,這些依賴項和先決條件假定可從主機獲得。
CSI 透過使用容器化和利用 k8s 儲存原語來解決這些問題。CSI 已成為支援使用樹外儲存外掛程式的無處不在的解決方案。它允許儲存供應商透過標準 k8s 原語(如儲存類別、PersistentVolumes(PV)和 PersistentVolumeClaims(PVC))部署外掛程式。
CSI 的主要目標是標準化在每個容器協調程式中公開所有類型儲存系統的機制。
相關內容:閱讀我們的Kubernetes 持久卷指南
CSI Volume 可用於配置 PersistentVolume 資源,這些資源可供 Kubernetes 工作負載使用。您可以動態配置 PersistentVolumes(當工作負載請求它們時)或手動配置。
您可以建立參照 CSI 儲存外掛程式的 StorageClass。這讓 Kubernetes 工作負載能夠動態建立 PersistentVolumes。儲存至這些 PersistentVolumes 的資料會保留至 CSI 外掛程式中定義的儲存設備。
例如,以下 StorageClass 可使用名為「csi-driver.example.com」的 CSI 外掛程式來配置「fast-storage」類型的儲存磁碟區。(此範例及以下其他範例均已在官方 Kubernetes CSI 部落格文章中分享。)
當 Kubernetes 實體建立一個請求此 StorageClass 的 PersistentVolumeClaim 物件時,系統會動態配置一個屬於該 StorageClass 的 PersistentVolume。下圖包含一個參考 fast-storage StorageClass 的 PVC 範例。
請注意,在上面的 StorageClass 定義中有三個參數:type、以及兩個稱為 mysecret 和 mynamespace 的機密。當 PVC 被宣告時,以下是幕後發生的事情:
閱讀我們的部落格文章:使用 NetApp Trident 和 Cloud Volumes ONTAP 進行動態 Kubernetes 持續性磁碟區資源配置
您可以在 Kubernetes 中手動配置卷並使其可用於工作負載,而無需使用 PVC 機制。下圖提供了一個 PV 物件的範例,該物件允許工作負載使用名為 "existingVolumeName" 的儲存卷。如上所述,CSI 卷引用儲存外掛程式 csi-driver.example.com。
下圖提供了一個範例,展示了 Kubernetes Pod 範本如何引用 PVC 來存取 CSI Volume。
當 PersistenVolumeClaim 出現在 Pod 範本中時,每次排程 Pod 時,Kubernetes 都會在 CSI 外掛程式上觸發多個操作,包括 ControllerPublishVolume、NodeStageVolume 和 NodePublishVolume。這將創建一個儲存磁碟區,掛載它,並使其可供 Pod 中運行的容器使用。
Kubernetes 中的 CSI 驅動程式通常與控制器和每個節點元件一起部署。
控制器元件
控制器外掛程式部署為 Deployment 或 StatefulSet,可以掛載到叢集內的任何節點上。它包括實現 CSI Controller 服務的 CSI 驅動程式以及 sidecar 容器(或多個容器)。Controller sidecar 容器通常與 Kubernetes 物件互動,並呼叫 CSI Controller 服務。
控制器不需要直接存取主機 - 它可以透過外部控制平面服務和 Kubernetes API 執行所有操作。可以部署控制器元件的多個副本以實現高可用性(HA),但應實施領導者選舉,以確保在任何給定時間只有一個控制器處於活動狀態。
控制器 sidecar 包括 external-provisioner、external-attacher、external-snapshotter 和 external-resizer。在部署中包含某些 sidecar 可以是可選的,具體取決於 sidecar 頁面中詳述的規範。
控制器與負責管理 Kubernetes 事件的 sidecar 容器通訊。然後,控制器將相關呼叫傳送到 CSI 驅動程式。UNIX 網域通訊端透過 emptyDir Volume 共用,從而啟用 sidecar 和驅動程式之間的呼叫。
控制器 sidecars 使用角色型存取控制(RBAC)規則來管理它們與 Kubernetes 物件的互動。sidecar 儲存庫提供了可合併到 RBAC 策略中的 RBAC 組態範例。
每節點元件
節點外掛程式應透過 DaemonSet 部署在叢集中的所有節點上。它包括實現 CSI 節點服務的 CSI 驅動程式和充當節點驅動程式註冊器的 sidecar 容器。
節點元件與 kubelet 通訊,kubelet 在所有節點上執行並處理對 CSI 節點服務的呼叫。這些呼叫可以從儲存系統掛載或卸載儲存磁碟區,並使其可供 Pod 使用。kubelet 使用 UNIX 網域通訊端,透過主機上的 HostPath 磁碟區共用,以呼叫 CSI 驅動程式。節點驅動程式登錄器使用額外的 UNIX 網域通訊端將驅動程式登錄到 kubelet。
節點外掛程式需要直接存取主機才能掛載驅動程式磁碟區。為了讓檔案系統掛載和區塊裝置可供 kubelet 使用,CSI 驅動程式需要使用雙向掛載點,使 kubelet 能夠看到驅動程式容器建立的掛載。
Kubernetes 不會決定 CSI Volume 驅動程式的封裝方式,但它確實提供了簡化在 Kubernetes 上部署容器化 CSI 驅動程式的建議。
建議儲存供應商在部署容器化 CSI Volume 驅動程式時執行以下步驟:
另一種可能更簡單的部署選擇是將所有元件放在一個 DaemonSet 中,包括 external-provisioner 和 external-attacher。但是,此策略會消耗更多資源,並且需要對 external-attacher 和 external-provisioner 元件使用領導者選舉協定(例如 https://git.k8s.io/contrib/election)。
Kubernetes 叢集必須啟用特權 Pod 才能使用 CSI 驅動程式。例如,您需要為 kubelet 和 API 伺服器將 --allow-privileged 標誌設置為 true ——在某些環境中,例如 kubeadm、GCE 和 GKE,這是預設值。
必須使用以下特權旗標啟動 API 伺服器:
$ ./kube-apiserver ...--allow-privileged=true ...$ ./kubelet ...--allow-privileged=true ...
Container Storage Interface 需要掛載傳播功能,以便在同一節點或 Pod 內的容器之間共用掛載的磁碟區。叢集的 Docker 常駐程式需要允許掛載共用才能啟用掛載傳播。
NetApp Cloud Volumes ONTAP 是領先業界的企業級儲存管理解決方案,可在 AWS、Azure 和 Google Cloud 上提供安全可靠、實證肯定的儲存管理服務。Cloud Volumes ONTAP 容量可以擴充至 PB 級,並支援各種使用案例,例如檔案服務、資料庫、DevOps 或任何其他企業工作負載,並具有一系列強大的功能,包括高可用度、資料保護、儲存效率、Kubernetes 整合等。
特別是,Cloud Volumes ONTAP 支援容器化工作負載的 Kubernetes Persistent Volume 資源配置和管理需求。
深入瞭解使用 Cloud Volumes ONTAP 和 Trident 的 Kubernetes NFS 資源配置檔案服務。
深入瞭解 Cloud Volumes ONTAP 如何協助解決這些Kubernetes 工作負載與 Cloud Volumes ONTAP 案例研究中容器化應用程式的挑戰。