內容來源於官方 Longhorn 1.1.2 英文技術手冊。
系列
目錄
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)，根據讀取索引顯示哪些塊包含最新的資料，最新資料的來源也列在下表中：
| Read Index | Source of the latest data |
|---|---|
| 0 | 最新快照 |
| 1 | 實時資料 |
| 2 | 最舊的快照 |
| 3 | 最舊的快照 |
| 4 | 最舊的快照 |
| 5 | 實時資料 |
| 6 | 實時資料 |
| 7 | 實時資料 |
請注意，如上圖綠色箭頭所示，讀取索引的 Index 5 之前指向第二個最舊的快照作為最近資料的來源，然後在 4K 塊時更改為指向實時資料 Index 5 的儲存被實時資料覆蓋。
讀取索引儲存在記憶體中，每個 4K 塊消耗一個位元組。位元組大小的讀取索引意味著您可以為每個卷建立多達 254 個快照。
讀取索引為每個副本消耗一定數量的記憶體資料結構。例如，一個 1 TB 的卷消耗 256 MB 的記憶體讀取索引。
2.3.2 如何新增新副本
新增新副本時，現有副本將同步到新副本。第一個副本是通過從實時資料中獲取新快照來建立的。
以下步驟顯示了 Longhorn 如何新增新副本的更詳細細分：
Longhorn Engine暫停。- 假設副本中的快照鏈由實時資料和快照組成。建立新副本後，實時資料將成為最新（第二個）快照，並建立新的空白版本的實時資料。
- 新副本以
WO（只寫）模式建立。 Longhorn Engine取消暫停。- 所有快照均已同步。
- 新副本設定為
RW（讀寫）模式。
2.3.3. 如何重建有故障的副本
Longhorn 將始終嘗試為每個卷維護至少給定數量的健康副本。
當控制器在其副本之一中檢測到故障時，它會將副本標記為處於錯誤狀態(error state)。Longhorn Manager 負責啟動和協調重建故障副本的過程。
為了重建故障副本，Longhorn Manager 建立一個空白副本並呼叫 Longhorn Engine 將空白副本新增到卷的副本集中。
為了新增空白副本，Engine 執行以下操作：
- 暫停所有讀取和寫入操作。
- 以
WO（只寫）模式新增空白副本。 - 建立所有現有副本的快照，現在它的頭部有一個空白的差異磁碟(
differencing disk)。 - 取消暫停所有讀取寫入操作。只有寫操作會被分派到新新增的副本。
- 啟動後臺程式以將除最近的差異磁碟之外的所有磁碟從良好副本同步到空白副本。
- 同步完成後，所有副本現在都擁有一致的資料，卷管理器將新副本設定為
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 中設定現有儲存的典型工作流程如下：
- 在您有權訪問的物理或虛擬儲存的意義上設定持久儲存卷。
- 新增引用持久儲存的
PV。 - 新增引用
PV的PVC。 - 在您的工作負載中將
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 資源：
- 新增
StorageClass並將其配置為從您有權訪問的儲存中自動配置新儲存。 - 新增引用
StorageClass的PVC。 - 將
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。