Longhorn 雲原生分散式塊存儲解決方案設計架構和概念

• 2021 年 8 月 17 日
• 筆記

內容來源於官方 Longhorn 1.1.2 英文技術手冊。

系列

Longhorn 是什麼?

目錄

• 1. 設計
  • 1.1. Longhorn Manager 和 Longhorn Engine
  • 1.2. 基於微服務的設計的優勢
  • 1.3. CSI Driver
  • 1.4. CSI Plugin
  • 1.5. Longhorn UI
• 2. Longhorn 卷和主存儲
  • 2.1. 精簡配置和卷大小
  • 2.2. 在維護模式下恢復卷
  • 2.3. 副本
    • 2.3.1. 副本讀寫操作的工作原理
    • 2.3.2. 如何添加新副本
    • 2.3.3. 如何重建有故障的副本
  • 2.4. 快照
    • 2.4.1. 快照的工作原理
    • 2.4.2. 定期快照
    • 2.4.3. 刪除快照
    • 2.4.4. 存儲快照
    • 2.4.5. 崩潰一致性
• 3. 備份和輔助存儲
  • 3.1. 備份的工作原理
  • 3.2. 定期備份
  • 3.3. 災難恢復卷
  • 3.4. 備份存儲更新間隔、RTO 和 RPO
• 附錄：持久性存儲在 Kubernetes 中的工作原理
  • Kubernetes 工作負載如何使用新的和現有的持久存儲
    • 現有存儲配置
    • 動態存儲配置
  • 具有持久存儲的 Kubernetes Workloads 的水平擴展

1. 設計

Longhorn 設計有兩層：數據平面(data plane)和控制平面(control plane)。Longhorn Engine 是存儲控制器對應數據平面，Longhorn Manager 對應控制平面。

1.1. Longhorn Manager 和 Longhorn Engine

Longhorn Manager Pod 作為 Kubernetes DaemonSet 在 Longhorn 集群中的每個節點上運行。
它負責在 Kubernetes 集群中創建和管理卷，並處理來自 UI 或 Kubernetes 卷插件的 API 調用。它遵循 Kubernetes controller pattern，有時也稱為 operator pattern。

Longhorn Manager 與 Kubernetes API 伺服器通訊以創建新的 Longhorn 卷 CRD。
然後 Longhorn Manager 觀察 API 伺服器的響應，當看到 Kubernetes API 伺服器創建了一個新的 Longhorn volume CRD 時，Longhorn Manager 就創建了一個新的卷。

當 Longhorn Manager 被要求創建一個卷時，它會在該卷所連接的節點上創建一個 Longhorn Engine 實例，並在每個將放置副本的節點上創建一個副本。副本應放置在不同的主機上以確保最大的可用性。

副本的多條數據路徑確保了 Longhorn 卷的高可用性。 即使某個副本或引擎出現問題，問題也不會影響所有副本或 Pod 對卷的訪問。Pod 仍將正常運行。

Longhorn Engine 始終在與使用 Longhorn volume 的 Pod 相同的節點中運行。它跨存儲在多個節點上的多個副本同步複製卷。

引擎(Engine)和副本(replicas)使用 Kubernetes 進行編排。

在下圖中，

• Longhorn volumes 有三個實例。
• 每個卷都有一個專用控制器，稱為 Longhorn Engine 並作為 Linux 進程運行。
• 每個 Longhorn 卷有兩個副本(replica)，每個副本是一個 Linux 進程。
• 圖中的箭頭表示卷(volume)、控制器實例(controller instance)、副本實例(replica instances)和磁碟之間的讀/寫數據流。
• 通過為每個卷創建單獨的 Longhorn Engine，如果一個控制器出現故障，其他卷的功能不會受到影響。

圖 1. 卷、Longhorn 引擎、副本實例和磁碟之間的讀/寫數據流

1.2. 基於微服務的設計的優勢

在 Longhorn 中，每個 Engine 只需要服務一個卷，簡化了存儲控制器的設計。由於控制器軟體的故障域與單個卷隔離，因此控制器崩潰只會影響一個卷。

Longhorn Engine 足夠簡單和輕便，因此我們可以創建多達 100,000 個獨立的引擎。
Kubernetes 調度這些獨立的引擎，從一組共享的磁碟中提取資源，並與 Longhorn 合作形成一個彈性的分散式塊存儲系統。

因為每個卷都有自己的控制器，所以每個卷的控制器和副本實例也可以升級，而不會導致 IO 操作明顯中斷。

Longhorn 可以創建一個長時間運行的作業(long-running job)來協調所有實時卷的升級，而不會中斷系統的持續運行。
為確保升級不會導致不可預見的問題，Longhorn 可以選擇升級一小部分卷，並在升級過程中出現問題時回滾到舊版本。

1.3. CSI Driver

Longhorn CSI driver 獲取塊設備(block device)，對其進行格式化，然後將其掛載到節點上。
然後 kubelet 將設備綁定掛載到 Kubernetes Pod 中。
這允許 Pod 訪問 Longhorn volume。

所需的 Kubernetes CSI 驅動程式鏡像將由 longhorn driver deployer 自動部署。

1.4. CSI Plugin

Longhorn 通過 CSI Plugin 在 Kubernetes 中進行管理。 這允許輕鬆安裝 Longhorn 插件。

Kubernetes CSI plugin 調用 Longhorn 創建卷，為 Kubernetes 工作負載創建持久數據(persistent data)。
CSI plugin 使您能夠創建(create)、刪除(delete)、附加(attach)、分離(detach)、掛載(mount)卷，並對卷進行快照。Longhorn 提供的所有其他功能都是通過 Longhorn UI 實現的。

Kubernetes 集群內部使用 CSI interface 與 Longhorn CSI plugin 進行通訊。Longhorn CSI plugin 使用 Longhorn API 與 Longhorn Manager 通訊。

Longhorn 確實利用了 iSCSI，因此可能需要對節點進行額外配置。這可能包括根據發行版安裝 open-iscsi 或 iscsiadm。

1.5. Longhorn UI

Longhorn UI 通過 Longhorn API 與 Longhorn Manager 進行交互，並作為 Kubernetes 的補充。
通過 Longhorn 介面可以管理快照(snapshots)、備份(backups)、節點(nodes)和磁碟(disks)。

此外，集群工作節點的空間使用情況由 Longhorn UI 收集和說明。有關詳細資訊，請參見此處。

2. Longhorn 卷和主存儲

創建 volume 時，Longhorn Manager 將為每個 volume 創建 Longhorn Engine 微服務和副本作為微服務。
這些微服務一起構成了一個 Longhorn volume。每個複製副本應放置在不同的節點或不同的磁碟上。

Longhorn Manager 創建 Longhorn Engine 後，它將連接到副本(replicas)。引擎在 Pod 運行的節點上暴露塊設備(block device)。

kubectl 支援創建 Longhorn 卷。

2.1. 精簡配置和卷大小

Longhorn 是一個精簡配置(thin-provisioned)的存儲系統。這意味著 Longhorn volume 只會佔用它目前需要的空間。
例如，如果您分配了 20 GB 的卷，但只使用了其中的 1 GB，則磁碟上的實際數據大小將為 1 GB。 您可以在 UI 的卷詳細資訊中查看實際數據大小。

如果您從卷中刪除了內容，則 Longhorn 卷本身的大小不會縮小。
例如，如果您創建了一個 20 GB 的卷，使用了 10 GB，然後刪除了 9 GB 的內容，則磁碟上的實際大小仍然是 10 GB 而不是 1 GB。
發生這種情況是因為 Longhorn 在塊級別(block level)而不是文件系統級別(filesystem level)上運行，
因此 Longhorn 不知道內容是否已被用戶刪除。該資訊主要保存在文件系統級別。

2.2. 在維護模式下恢復卷

從 Longhorn UI 附加卷時，會有一個維護模式複選框。它主要用於從快照恢復卷。

該選項將導致在不啟用前端（塊設備或 iSCSI）的情況下附加卷，以確保在附加卷時沒有人可以訪問卷數據。

v0.6.0 之後，快照恢復操作要求卷處於維護模式。這是因為如果在掛載或使用卷時修改了塊設備的內容，則會導致文件系統損壞。

檢查卷狀態而不必擔心數據被意外訪問也很有用。

2.3. 副本

每個副本都包含 Longhorn 卷的一系列快照。快照就像鏡像(image)的一層，最舊的快照用作基礎層，較新的快照在頂部。
如果數據覆蓋舊快照中的數據，則數據僅包含在新快照中。一系列快照一起顯示了數據的當前狀態。

對於每個 Longhorn 卷，該卷的多個副本應該在 Kubernetes 集群中運行，每個副本位於單獨的節點上。
所有副本都被同等對待，Longhorn Engine 始終運行在與 pod 相同的節點上，pod 也是卷的消費者。
通過這種方式，我們可以確保即使 Pod 宕機，引擎也可以被轉移到另一個 Pod，您的服務將不會中斷。

默認的副本數(replica count)可以在 settings 中更改。當附加一個卷時，可以在 UI 中更改卷的副本計數。

如果當前運行良好的副本計數小於指定的副本計數，Longhorn 將開始重新生成新的副本。

如果當前正常的副本計數大於指定的副本計數，Longhorn 將不執行任何操作。
在這種情況下，如果副本失敗或被刪除，Longhorn 將不會開始重新構建新的副本，除非健康的副本計數低於指定的副本計數。

Longhorn 副本使用支援精簡配置的 Linux sparse files 構建。

2.3.1. 副本讀寫操作的工作原理

從卷的副本讀取數據時，如果可以在實時數據中找到數據，則使用該數據。
如果沒有，將讀取最新的快照。如果在最新的快照中找不到數據，則讀取次早的快照，依此類推，直到讀取最舊的快照。

在創建快照時，會創建一個差異(differencing)磁碟。隨著快照數量的增加，差異磁碟鏈（也稱為快照鏈）可能會變得很長。
因此，為了提高讀取性能，Longhorn 維護了一個讀取索引，該索引記錄哪個差異磁碟為每個 4K 存儲塊保存有效數據。

在下圖中，卷有八個塊。讀取索引(read index)有八個條目，並且在讀取操作發生時被惰性填充。

寫操作重置讀索引，使其指向實時數據。實時數據由某些索引上的數據和其他索引上的空白空間組成。

除了讀取索引之外，我們目前沒有維護額外的元數據來指示使用了哪些塊。

圖 2. 讀取索引如何跟蹤保存最新數據的快照

上圖用顏色編碼(color-coded)，根據讀取索引顯示哪些塊包含最新的數據，最新數據的來源也列在下表中：

請注意，如上圖綠色箭頭所示，讀取索引的 Index 5 之前指向第二個最舊的快照作為最近數據的來源，然後在 4K 塊時更改為指向實時數據 Index 5 的存儲被實時數據覆蓋。

讀取索引保存在記憶體中，每個 4K 塊消耗一個位元組。位元組大小的讀取索引意味著您可以為每個卷創建多達 254 個快照。

讀取索引為每個副本消耗一定數量的記憶體數據結構。例如，一個 1 TB 的卷消耗 256 MB 的記憶體讀取索引。

2.3.2 如何添加新副本

添加新副本時，現有副本將同步到新副本。第一個副本是通過從實時數據中獲取新快照來創建的。

以下步驟顯示了 Longhorn 如何添加新副本的更詳細細分：

1. Longhorn Engine 暫停。
2. 假設副本中的快照鏈由實時數據和快照組成。創建新副本後，實時數據將成為最新（第二個）快照，並創建新的空白版本的實時數據。
3. 新副本以 WO（只寫）模式創建。
4. Longhorn Engine 取消暫停。
5. 所有快照均已同步。
6. 新副本設置為 RW（讀寫）模式。

2.3.3. 如何重建有故障的副本

Longhorn 將始終嘗試為每個卷維護至少給定數量的健康副本。

當控制器在其副本之一中檢測到故障時，它會將副本標記為處於錯誤狀態(error state)。Longhorn Manager 負責啟動和協調重建故障副本的過程。

為了重建故障副本，Longhorn Manager 創建一個空白副本並調用 Longhorn Engine 將空白副本添加到卷的副本集中。

為了添加空白副本，Engine 執行以下操作：

1. 暫停所有讀取和寫入操作。
2. 以 WO（只寫）模式添加空白副本。
3. 創建所有現有副本的快照，現在它的頭部有一個空白的差異磁碟(differencing disk)。
4. 取消暫停所有讀取寫入操作。只有寫操作會被分派到新添加的副本。
5. 啟動後台進程以將除最近的差異磁碟之外的所有磁碟從良好副本同步到空白副本。
6. 同步完成後，所有副本現在都擁有一致的數據，卷管理器將新副本設置為 RW (讀寫)模式。

最後，Longhorn Manager 調用 Longhorn Engine 從其副本集中移除故障副本。

2.4. 快照

快照功能使卷能夠恢復到歷史中的某個點。輔助存儲中的備份也可以從快照構建。

從快照還原卷時，它會反映創建快照時卷的狀態。

快照功能也是 Longhorn 重建過程的一部分。 每次 Longhorn 檢測到一個副本宕機時，它會自動創建（系統）快照並開始在另一個節點上重建它。

2.4.1. 快照的工作原理

快照就像鏡像(image)的一層，最舊的快照用作基礎層，較新的快照在頂部。
如果數據覆蓋舊快照中的數據，則數據僅包含在新快照中。
一系列快照一起顯示了數據的當前狀態。

快照在創建後無法更改，除非快照被刪除，在這種情況下，其更改會與下一個最近的快照合併。新數據始終寫入實時版本。新快照始終從實時數據創建。

要創建新快照，實時數據將成為最新的快照。 然後創建一個新的空白版本的實時數據，取代舊的實時數據。

2.4.2. 定期快照

為了減少快照佔用的空間，用戶可以安排一個定期快照(recurring snapshot)或備份(backup)，保留多個快照，這將自動按計劃創建一個新的快照/備份，然後清理任何過多的快照/備份。

2.4.3. 刪除快照

不需要的快照可以通過介面手動刪除。當系統生成的快照被觸發刪除時，系統會自動將其標記為刪除。

在 Longhorn 中，不能刪除最新的快照。這是因為無論何時刪除快照，Longhorn 都會將其內容與下一個快照合併，以便下一個和以後的快照保留正確的內容。

但 Longhorn 無法對最新快照執行此操作，因為沒有更多最近的快照可以與已刪除的快照合併。最新快照的下一個「快照」是實時卷（volume-head），此時用戶正在讀/寫，因此不會發生合併過程。

相反，最新的快照將被標記為已刪除，並且在可能的情況下，將在下次對其進行清理。

要清理最新快照，可以創建一個新快照，然後刪除以前的「最新」快照。

2.4.4. 存儲快照

快照存儲在本地，作為卷的每個副本的一部分。它們存儲在 Kubernetes 集群中節點的磁碟上。快照與主機物理磁碟上的卷數據存儲在同一位置。

2.4.5. 崩潰一致性

Longhorn 是崩潰一致(crash-consistent)的塊存儲解決方案。

作業系統在寫入塊層(block layer)之前將內容保留在快取中是正常的。
這意味著如果所有副本都關閉，那麼 Longhorn 可能不包含關閉前立即發生的更改，因為內容保存在作業系統級快取中，尚未傳輸到 Longhorn 系統。

此問題類似於台式電腦因停電而關閉時可能發生的問題。恢復供電後，您可能會發現硬碟驅動器中有一些損壞的文件。

要在任何給定時刻強制將數據寫入塊層(block layer)，可以在節點上手動運行同步命令，或者可以卸載磁碟。在任一情況下，作業系統都會將內容從快取寫入塊層(block layer)。

Longhorn 在創建快照之前自動運行同步命令。

3. 備份和輔助存儲

備份是備份存儲(backupstore)中的一個對象，它是 Kubernetes 集群外部的 NFS 或 S3 兼容對象存儲。
備份提供了一種二級(secondary)存儲形式，因此即使您的 Kubernetes 集群變得不可用，您的數據仍然可以被檢索。

由於卷複製(volume replication)是同步的，而且由於網路延遲(network latency)，很難進行跨地域複製。備份存儲(backupstore)也用作解決此問題的媒介。

在 Longhorn 設置中配置備份目標後，Longhorn 可以連接到備份存儲並在 Longhorn UI 中向您顯示現有備份列表。

如果 Longhorn 在第二個 Kubernetes 集群中運行，它還可以將災難恢復卷同步到二級存儲(secondary storage)中的備份，
以便您的數據可以在第二個 Kubernetes 集群中更快地恢復。

3.1. 備份的工作原理

使用一個快照作為源創建備份，以便它反映創建快照時卷數據的狀態。

與快照相比，備份可以被認為是一系列快照的扁平化版本。與將分層鏡像(layered image)轉換為平面鏡像(flat image)時資訊丟失的方式類似，當一系列快照轉換為備份時，數據也會丟失。在這兩種轉換中，任何被覆蓋的數據都將丟失。

由於備份不包含快照，因此它們不包含卷數據更改的歷史記錄。從備份還原卷後，該卷最初包含一個快照。 此快照是原始鏈中所有快照的合併版本，它反映了創建備份時卷的實時數據。

雖然快照可以達到 TB(terabytes)，但備份由 2 MB 文件組成。

同一原始卷的每個新備份都是增量的，檢測並在快照之間傳輸更改的塊。這是一項相對容易的任務，
因為每個快照都是一個差異(differencing)文件，並且只存儲上一個快照的更改。

為了避免存儲大量的小存儲塊，Longhorn 使用 2 MB 塊執行備份操作。這意味著，如果 2MB 邊界中的任何 4K 塊發生更改，Longhorn 將備份整個 2MB 塊。這提供了可管理性和效率之間的正確平衡。

圖 3. 二級存儲中的備份與主存儲中的快照之間的關係

上圖描述了如何從 Longhorn 中的快照創建備份：

• 圖表的主存儲一側顯示了 Kubernetes 集群中 Longhorn 卷的一個副本。副本由四個快照鏈組成。按照從新到舊的順序，快照是 Live Data、snap3、snap2 和 snap1。
• 圖表的二級存儲側顯示了外部對象存儲服務（如 S3）中的兩個備份。
• 在二級存儲中，backup-from-snap2 的顏色編碼顯示它包括來自 snap1 的藍色變化和來自 snap2 的綠色變化。
  snap2 中的任何更改都沒有覆蓋 snap1 中的數據，因此 snap1 和 snap2 中的更改都包含在 backup-from-snap2 中。
• 名為 backup-from-snap3 的備份反映了創建 snap3 時卷數據的狀態。顏色編碼和箭頭表示 backup-from-snap3 包含來自 snap3 的所有深紅色更改，但僅包含來自 snap2 的綠色更改之一。
  這是因為 snap3 中的一項紅色更改覆蓋了 snap2 中的一項綠色更改。這說明了備份如何不包括更改的完整歷史記錄，因為它們將快照與其之前的快照混為一談。
• 每個備份維護自己的一組 2 MB 塊。 每個 2 MB 塊僅備份一次。 兩個備份共享一個綠色塊和一個藍色塊。

當備份從二級存儲中刪除時，Longhorn 不會刪除它使用的所有塊。相反，它會定期執行垃圾收集以清除輔助存儲中未使用的塊。

屬於同一卷的所有備份的 2 MB 塊存儲在一個公共目錄下，因此可以跨多個備份共享。

為了節省空間，備份之間沒有變化的 2 MB 塊可以重複用於在二級存儲中共享相同備份卷的多個備份。
由於校驗(checksums)和用於定址 2 MB 塊，因此我們對同一卷中的 2 MB 塊實現了某種程度的重複數據刪除。

卷級元數據(Volume-level metadata)存儲在 volume.cfg 中。每個備份的元數據文件（例如 snap2.cfg）相對較小，
因為它們僅包含備份中所有 2 MB 塊的offsets和checksums。

壓縮每個 2 MB 塊（.blk 文件）。

3.2. 定期備份

可以使用定期快照(recurring snapshot)和備份功能來安排備份操作，但也可以根據需要進行。

建議為您的卷安排定期備份。如果備份存儲(backupstore)不可用，建議改為安排定期快照。

創建備份涉及通過網路複製數據，因此需要時間。

3.3. 災難恢復卷

災難恢復 (DR) 卷是一種特殊卷，可在整個主集群出現故障時將數據存儲在備份集群中。DR 卷用於提高 Longhorn 卷的彈性。

由於 DR 卷的主要用途是從備份中恢複數據，因此此類卷在激活之前不支援以下操作：

• 創建、刪除和恢復快照
• 創建備份
• 創建持久卷
• 創建持久卷聲明

可以從備份存儲中的卷備份創建 DR 卷。 創建 DR 卷後，Longhorn 將監控其原始備份卷並從最新備份增量恢復。備份卷是備份存儲中包含同一卷的多個備份的對象。

如果主集群中的原始卷宕機，可以立即激活備份集群中的 DR 卷，這樣可以大大減少將數據從備份存儲恢復到備份集群中的卷所需的時間。

當 DR 卷被激活時，Longhorn 將檢查原始卷的最後備份。 如果該備份尚未恢復，則將開始恢復，並且激活操作將失敗。用戶需要等待恢復完成後再重試。

如果存在任何 DR 卷，則無法更新 Longhorn 設置中的備份目標。

DR 卷被激活後，它會變成一個普通的 Longhorn 卷並且不能被停用。

3.4. 備份存儲更新間隔、RTO 和 RPO

通常增量恢復由定期備份存儲更新觸發。用戶可以在設置(Setting)-通用(General)-備份(Backupstore)存儲輪詢間隔中設置備份存儲更新間隔。

請注意，此間隔可能會影響恢復時間目標 (RTO)。 如果時間過長，容災卷恢復的數據量可能比較大，時間會比較長。

至於恢復點目標 (RPO)，它由備份卷的定期備份計劃確定。如果正常卷 A 的定期備份計劃每小時創建一個備份，則 RPO 為一小時。
您可以在此處查看如何在 Longhorn 中設置定期備份。

以下分析假設該卷每小時創建一個備份，並且從一個備份中增量恢複數據需要五分鐘：

• 如果 Backupstore 輪詢間隔為 30 分鐘，則自上次恢復以來最多有一個備份數據。 恢復一份備份的時間為五分鐘，因此 RTO 為五分鐘。
• 如果 Backupstore 輪詢間隔為 12 小時，則自上次恢復以來最多有 12 個數據備份。恢復備份的時間為 5 * 12 = 60 分鐘，因此 RTO 為 60 分鐘。

附錄：持久性存儲在 Kubernetes 中的工作原理

要了解 Kubernetes 中的持久存儲，重要的是要了解 Volumes、PersistentVolumes、PersistentVolumeClaims 和 StorageClasses，以及它們如何協同工作。

Kubernetes Volume 的一個重要屬性是它與它所屬的 Pod 具有相同的生命周期。
如果 Pod 不見了，Volume 就會丟失。相比之下，PersistentVolume 繼續存在於系統中，直到用戶將其刪除。
卷也可用於在同一個 Pod 內的容器之間共享數據，但這不是主要用例，因為用戶通常每個 Pod 只有一個容器。

PersistentVolume (PV) 是 Kubernetes 集群中的一塊持久存儲，
而 PersistentVolumeClaim (PVC) 是一個存儲請求。
StorageClasses 允許根據需要為工作負載動態配置新存儲。

Kubernetes 工作負載如何使用新的和現有的持久存儲

從廣義上講，在 Kubernetes 中使用持久化存儲主要有兩種方式：

• 使用現有的持久卷
• 動態配置新的持久卷

現有存儲配置

要使用現有 PV，您的應用程式需要使用綁定到 PV 的 PVC，並且 PV 應包含 PVC 所需的最少資源。

換句話說，在 Kubernetes 中設置現有存儲的典型工作流程如下：

1. 在您有權訪問的物理或虛擬存儲的意義上設置持久存儲卷。
2. 添加引用持久存儲的 PV。
3. 添加引用 PV 的 PVC。
4. 在您的工作負載中將 PVC 掛載為卷。

當 PVC 請求一塊存儲時，Kubernetes API 伺服器將嘗試將該 PVC 與預先分配的 PV 匹配，因為匹配的卷可用。
如果可以找到匹配項，則 PVC 將綁定到 PV，並且用戶將開始使用該預先分配的存儲塊。

如果不存在匹配的卷，則 PersistentVolumeClaims 將無限期地保持未綁定狀態。
例如，配置了許多 50 Gi PV 的集群與請求 100 Gi 的 PVC 不匹配。 將 100 Gi PV 添加到集群後，可以綁定 PVC。

換句話說，您可以創建無限的 PVC，但只有當 Kubernetes 主節點可以找到足夠的 PV 且至少具有 PVC 所需的磁碟空間量時，它們才會綁定到 PV。

動態存儲配置

對於動態存儲配置，您的應用程式需要使用綁定到 StorageClass 的 PVC。 StorageClass 包含提供新持久卷的授權。

在 Kubernetes 中動態配置新存儲的整個工作流程涉及一個 StorageClass 資源：

1. 添加 StorageClass 並將其配置為從您有權訪問的存儲中自動配置新存儲。
2. 添加引用 StorageClass 的 PVC。
3. 將 PVC 掛載為工作負載的卷。

Kubernetes 集群管理員可以使用 Kubernetes StorageClass 來描述他們提供的存儲「類(「classes」)」。
StorageClasses 可以有不同的容量限制、不同的 IOPS 或供應商支援的任何其他參數。
存儲供應商特定的 provisioner 與 StorageClass 一起使用，以按照 StorageClass 對象中設置的參數自動分配 PV。
此外，provisioner 現在能夠為用戶強制執行資源配額和許可權要求。
在這種設計中，管理員可以從預測 PV 需求和分配 PV 的不必要工作中解放出來。

當使用 StorageClass 時，Kubernetes 管理員不負責分配每一塊存儲。
管理員只需要授予用戶訪問某個存儲池的許可權，並決定用戶的配額即可。
然後用戶可以從存儲池中挖掘出所需的存儲部分。

也可以使用 StorageClass，而不需要在 Kubernetes 中顯式創建 StorageClass 對象。
由於 StorageClass 也是一個用於匹配帶有 PV 的 PVC 的欄位，因此可以使用自定義存儲類名稱手動創建 PV，
然後可以創建一個要求帶有該 StorageClass 名稱的 PV 的 PVC。
然後，Kubernetes 可以使用指定的 StorageClass 名稱將 PVC 綁定到 PV，即使 StorageClass 對象並不作為 Kubernetes 資源存在。

Longhorn 引入了一個 Longhorn StorageClass，這樣 Kubernetes 工作負載就可以根據需要劃分持久性存儲。

具有持久存儲的 Kubernetes Workloads 的水平擴展

VolumeClaimTemplate 是一個 StatefulSet spec 屬性，它為塊存儲解決方案提供了一種方法來水平擴展 Kubernetes 工作負載。

此屬性可用於為由 StatefulSet 創建的 pod 創建匹配的 pv 和 pvc。

這些 PVC 是使用 StorageClass 創建的，因此可以在 StatefulSet 擴展時自動設置它們。

當 StatefulSet 縮小時，額外的 PV/PVC 會保留在集群中，當 StatefulSet 再次放大時，它們會被重用。

VolumeClaimTemplate 對於 EBS 和 Longhorn 等塊存儲解決方案很重要。
因為這些解決方案本質上是 ReadWriteOnce，所以它們不能在 Pod 之間共享。

如果您有多個 Pod 運行持久性數據(persistent storage)，那麼部署(Deployment)不能很好地與持久性存儲(persistent storage)配合使用。對於多個 pod，應該使用 StatefulSet。