主持人 > 博客 > 管理 > 在 Kubernetes 集群中存儲數據

在 Kubernetes 集群中存儲數據

有多種方法可以為 Kubernetes 集群上運行的應用程序設置數據存儲。 其中一些已經過時，另一些則是最近才出現的。 在本文中，我們將考慮連接存儲系統的三個選項的概念，包括最新的一個 - 通過容器存儲接口連接。

在 Kubernetes 集群中存儲數據

方法一：在Pod Manifest中指定PV

描述 Kubernetes 集群中 Pod 的典型清單：

在 Kubernetes 集群中存儲數據

清單的某些部分以顏色突出顯示，其中描述了連接哪個卷以及連接位置。

在第 卷掛載 指示掛載點 (mountPath) - 持久卷將掛載到容器內的哪個目錄，以及卷的名稱。

在第 x 列出 Pod 中使用的所有捲。 指定每個卷的名稱以及類型（在我們的示例中：awsElasticBlockStore）和連接選項。 清單中列出的參數取決於卷類型。

同一卷可以同時掛載到多個 Pod 容器上。 這樣不同的應用程序進程就可以訪問相同的數據。

這種連接方法是在 Kubernetes 剛剛起步的時候就被發明的，如今這種方法已經過時了。

使用時存在幾個問題：

  1. 所有捲都必須手動創建，Kubernetes 將無法為我們創建任何內容；
  2. 每個卷的訪問參數都是唯一的，並且必須在使用該卷的所有 pod 的清單中指定它們；
  3. 要更改存儲系統（例如，從 AWS 遷移到 Google Cloud），您需要更改所有清單中的設置和已安裝卷的類型。

這一切都非常不方便，因此，現實中只有一些特殊類型的捲才會採用這種方式進行連接：configMap、secret、emptyDir、hostPath：

  • configMap 和秘密服務卷，允許您使用 Kubernetes 清單中的文件在容器中創建卷。

  • emptyDir - 臨時卷，僅為 pod 的生命週期創建。 方便用於測試或存儲臨時數據。 當刪除 pod 時，emptyDir 卷也會被刪除，並且所有數據都會丟失。

  • hostPath - 允許您將應用程序安裝在容器內，運行應用程序的服務器本地磁盤上的任何目錄 - 包括 /etc/kubernetes。 這不是一個安全功能，因此安全策略通常禁止使用此類卷。 否則，攻擊者的應用程序將能夠在其容器內掛載 HTC Kubernetes 目錄並竊取所有集群證書。 通常，hostPath 卷僅允許在 kube-system 命名空間中運行的系統應用程序使用。

Kubernetes 開箱即用的存儲系統 文檔中給出。

方法 2. 連接 SC/PVC/PV Pod

另一種連接方法是Storage類、PersistentVolumeClaim、PersistentVolume的概念。

存儲類 存儲與存儲系統的連接參數。

持久卷聲明 描述應用程序所需的要求。
持久卷 存儲訪問設置和音量狀態。

這個想法的本質是：在pod清單中，指定PersistentVolumeClaim類型的捲，並在claimName參數中指示該實體的名稱。

在 Kubernetes 集群中存儲數據

PersistentVolumeClaim 清單描述了應用程序所需的數據卷的要求。 包括：

  • 磁盤大小；
  • 訪問方式：ReadWriteOnce 或 ReadWriteMany；
  • 引用 Storage 類 - 我們要在其中創建卷的數據存儲系統。

存儲類清單存儲用於連接到存儲系統的類型和設置。 kublet 需要它們將捲掛載到其節點上。

PersistentVolume 清單指定特定卷的存儲類和訪問參數（卷 ID、路徑等）。

創建 PVC 時，Kubernetes 會查看卷的大小以及所需的存儲類，然後選擇一個空閒的 PersistentVolume。

如果這樣的PV不可用，Kubernetes可以運行一個特殊的程序——Provisioner（它的名字在Storage類中標明）。 該程序連接到存儲系統，創建所需大小的捲，獲取標識符，並在 Kubernetes 集群中創建與 PersistentVolumeClaim 關聯的 PersistentVolume 清單。

所有這組抽象允許您從應用程序清單級別到管理級別刪除有關應用程序使用的存儲系統的信息。

所有存儲連接設置都在 Storage 類中，這是集群管理員的職責。 從 AWS 遷移到 Google Cloud 時，所需要做的就是將應用程序清單中的存儲類名稱更改為 PVC。 將使用Provisioner程序在集群中自動創建用於數據存儲的持久卷。

方法三、容器存儲接口

所有與各種存儲系統交互的代碼都是 Kubernetes 核心的一部分。 錯誤修復或新功能的發布與新版本相關，必須針對所有受支持的 Kubernetes 版本更改代碼。 所有這些都很難維護和添加新功能。

為了解決這個問題，來自 Cloud Foundry、Kubernetes、Mesos 和 Docker 的開發人員創建了容器存儲接口（CSI）——一個簡單的統一接口，描述容器管理系統和與特定存儲系統配合使用的特殊驅動程序（CSI Driver）之間的交互。 所有與存儲系統交互的代碼都從 Kubernetes 核心移至單獨的系統。

容器存儲接口文檔.

通常，CSI 驅動程序由兩個組件組成：節點插件和控制器插件。

節點插件運行在每個節點上，負責卷的安裝和操作。 控制器插件與存儲系統交互：創建或刪除卷、分配訪問權限等。

雖然舊驅動程序仍保留在 Kubernetes 核心中，但不再建議使用它們，並且建議每個人專門為其將要使用的系統安裝 CSI 驅動程序。

這項創新可能會嚇到那些已經習慣通過 Storage 類設置數據存儲的人，但實際上並沒有發生什麼可怕的事情。 對於程序員來說，沒有任何變化是肯定的 - 他們都只使用 Storage 類的名稱，並且將繼續下去。 對於管理員來說，添加了 Helm Chart 安裝並且設置結構已更改。 如果之前將設置直接輸入到 Storage 類中，那麼現在必須首先在 Helm Chart 中設置它們，然後再在 Storage 類中設置。 如果你明白了，就沒有什麼不好的事情發生。

讓我們看一個示例，了解切換到使用 CSI 驅動程序連接 Ceph 存儲可以獲得哪些好處。

使用 Ceph 時，CSI 插件提供了比內置驅動程序更多的存儲系統選項。

  1. 動態磁盤創建。 通常，RBD 僅在 RWO 模式下使用，而 Ceph 的 CSI 允許它們在 RWX 模式下使用。 不同節點上的多個 Pod 可以將相同的 RDB 磁盤掛載到其節點上並並行使用它們。 公平地說，並非一切都如此光彩奪目 - 該磁盤只能作為塊設備連接，也就是說，您必須調整應用程序以在多訪問模式下使用它。
  2. 快照創建。 在 Kubernetes 集群上，您可以創建一個要求您創建快照的清單。 CSI 插件將看到它並從磁盤獲取快照。 在此基礎上，可以製作 PersistentVolume 的備份或副本。
  3. 增加磁盤大小 Kubernetes 集群中的存儲和 PersistentVolume。
  4. 配額。 Kubernetes 中內置的 CephFS 驅動程序不支持配額，而帶有新 Ceph Nautilus 的新 CSI 插件可以在 CephFS 分區上啟用配額。
  5. 指標。 CSI 插件可以為 Prometheus 提供許多關於安裝了哪些卷、正在發生哪些交互等的指標。
  6. 拓撲感知。 允許您在清單中指定集群的地理分佈方式，並避免連接到位於阿姆斯特丹的存儲系統上在倫敦運行的 Pod。

如何通過 CSI 將 Ceph 連接到 Kubernetes 集群，請參閱 夜校Slurm講座的實踐部分。 您還可以訂閱 Ceph 視頻課程將於15月XNUMX日推出。

文章作者：Sergey Bondarev，執業南橋架構師，認證 Kubernetes 管理員，kubespray 開發者之一。

一點Post Scriptum不是為了廣告，而是為了......

PS Sergey Bondarev 領導兩項強化訓練：更新 Kubernetes 基地 28 月 30 日至 XNUMX 日及高級 Kubernetes Mega 14 月 16 日至 XNUMX 日。

在 Kubernetes 集群中存儲數據

來源： www.habr.com

添加評論