Longhorn 云原生分布式塊存儲解決方案設(shè)計架構(gòu)和概念

內(nèi)容來源于官方Longhorn 1.1.2英文技術(shù)手冊。(原創(chuàng)整理)

1. 設(shè)計

Longhorn?設(shè)計有兩層：數(shù)據(jù)平面(data plane)和控制平面(control plane)。Longhorn Engine?是存儲控制器對應(yīng)數(shù)據(jù)平面，Longhorn Manager?對應(yīng)控制平面。

1.1. Longhorn Manager 和 Longhorn Engine

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

Longhorn Manager?與?Kubernetes API?服務(wù)器通信以創(chuàng)建新的?Longhorn?卷?CRD。然后?Longhorn Manager?觀察?API?服務(wù)器的響應(yīng)，當看到?Kubernetes API?服務(wù)器創(chuàng)建了一個新的?Longhorn volume CRD?時，Longhorn Manager?就創(chuàng)建了一個新的卷。

當?Longhorn Manager?被要求創(chuàng)建一個卷時，它會在該卷所連接的節(jié)點上創(chuàng)建一個?Longhorn Engine?實例，并在每個將放置副本的節(jié)點上創(chuàng)建一個副本。副本應(yīng)放置在不同的主機上以確保最大的可用性。

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

Longhorn Engine?始終在與使用?Longhorn volume?的?Pod?相同的節(jié)點中運行。它跨存儲在多個節(jié)點上的多個副本同步復制卷。

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

在下圖中，

• Longhorn volumes?有三個實例。

• 每個卷都有一個專用控制器，稱為?Longhorn Engine?并作為?Linux?進程運行。

• 每個 Longhorn 卷有兩個副本(replica)，每個副本是一個 Linux 進程。

• 圖中的箭頭表示卷(volume)、控制器實例(controller instance)、副本實例(replica instances)和磁盤之間的讀/寫數(shù)據(jù)流。

• 通過為每個卷創(chuàng)建單獨的?Longhorn Engine，如果一個控制器出現(xiàn)故障，其他卷的功能不會受到影響。

圖 1. 卷、Longhorn 引擎、副本實例和磁盤之間的讀/寫數(shù)據(jù)流

1.2. 基于微服務(wù)的設(shè)計的優(yōu)勢

在?Longhorn?中，每個?Engine?只需要服務(wù)一個卷，簡化了存儲控制器的設(shè)計。由于控制器軟件的故障域與單個卷隔離，因此控制器崩潰只會影響一個卷。

Longhorn Engine?足夠簡單和輕便，因此我們可以創(chuàng)建多達?100,000?個獨立的引擎。?Kubernetes?調(diào)度這些獨立的引擎，從一組共享的磁盤中提取資源，并與?Longhorn?合作形成一個彈性的分布式塊存儲系統(tǒng)。

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

Longhorn?可以創(chuàng)建一個長時間運行的作業(yè)(long-running job)來協(xié)調(diào)所有實時卷的升級，而不會中斷系統(tǒng)的持續(xù)運行。為確保升級不會導致不可預見的問題，Longhorn?可以選擇升級一小部分卷，并在升級過程中出現(xiàn)問題時回滾到舊版本。

1.3. CSI Driver

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

所需的?Kubernetes CSI?驅(qū)動程序鏡像將由?longhorn driver deployer?自動部署。

1.4. CSI Plugin

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

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

Kubernetes 集群內(nèi)部使用?CSI interface?與?Longhorn CSI plugin?進行通信。Longhorn CSI plugin?使用?Longhorn API?與?Longhorn Manager?通信。

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

1.5. Longhorn UI

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

此外，集群工作節(jié)點的空間使用情況由?Longhorn UI?收集和說明。有關(guān)詳細信息，請參見此處。

2. Longhorn 卷和主存儲

創(chuàng)建?volume?時，Longhorn Manager?將為每個?volume?創(chuàng)建?Longhorn Engine?微服務(wù)和副本作為微服務(wù)。這些微服務(wù)一起構(gòu)成了一個?Longhorn volume。每個復制副本應(yīng)放置在不同的節(jié)點或不同的磁盤上。

Longhorn Manager?創(chuàng)建?Longhorn Engine?后，它將連接到副本(replicas)。引擎在?Pod?運行的節(jié)點上暴露塊設(shè)備(block device)。

kubectl?支持創(chuàng)建?Longhorn?卷。

2.1. 精簡配置和卷大小

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

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

2.2. 在維護模式下恢復卷

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

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

v0.6.0?之后，快照恢復操作要求卷處于維護模式。這是因為如果在掛載或使用卷時修改了塊設(shè)備的內(nèi)容，則會導致文件系統(tǒng)損壞。

檢查卷狀態(tài)而不必擔心數(shù)據(jù)被意外訪問也很有用。

2.3. 副本

每個副本都包含?Longhorn?卷的一系列快照?？煺站拖耒R像(image)的一層，最舊的快照用作基礎(chǔ)層，較新的快照在頂部。如果數(shù)據(jù)覆蓋舊快照中的數(shù)據(jù)，則數(shù)據(jù)僅包含在新快照中。一系列快照一起顯示了數(shù)據(jù)的當前狀態(tài)。

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

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

如果當前運行良好的副本計數(shù)小于指定的副本計數(shù)，Longhorn?將開始重新生成新的副本。

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

Longhorn?副本使用支持精簡配置的?Linux?sparse files?構(gòu)建。

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

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

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

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

寫操作重置讀索引，使其指向?qū)崟r數(shù)據(jù)。實時數(shù)據(jù)由某些索引上的數(shù)據(jù)和其他索引上的空白空間組成。

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

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

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

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

讀取索引保存在內(nèi)存中，每個?4K?塊消耗一個字節(jié)。字節(jié)大小的讀取索引意味著您可以為每個卷創(chuàng)建多達?254?個快照。

讀取索引為每個副本消耗一定數(shù)量的內(nèi)存數(shù)據(jù)結(jié)構(gòu)。例如，一個?1 TB?的卷消耗?256 MB?的內(nèi)存讀取索引。

2.3.2 如何添加新副本

添加新副本時，現(xiàn)有副本將同步到新副本。第一個副本是通過從實時數(shù)據(jù)中獲取新快照來創(chuàng)建的。

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

1. Longhorn Engine?暫停。

2. 假設(shè)副本中的快照鏈由實時數(shù)據(jù)和快照組成。創(chuàng)建新副本后，實時數(shù)據(jù)將成為最新（第二個）快照，并創(chuàng)建新的空白版本的實時數(shù)據(jù)。

3. 新副本以?WO（只寫）模式創(chuàng)建。

4. Longhorn Engine?取消暫停。

5. 所有快照均已同步。

6. 新副本設(shè)置為?RW（讀寫）模式。

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

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

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

為了重建故障副本，Longhorn Manager?創(chuàng)建一個空白副本并調(diào)用?Longhorn Engine?將空白副本添加到卷的副本集中。

為了添加空白副本，Engine?執(zhí)行以下操作：

1. 暫停所有讀取和寫入操作。

2. 以?WO（只寫）模式添加空白副本。

3. 創(chuàng)建所有現(xiàn)有副本的快照，現(xiàn)在它的頭部有一個空白的差異磁盤(differencing disk)。

4. 取消暫停所有讀取寫入操作。只有寫操作會被分派到新添加的副本。

5. 啟動后臺進程以將除最近的差異磁盤之外的所有磁盤從良好副本同步到空白副本。

6. 同步完成后，所有副本現(xiàn)在都擁有一致的數(shù)據(jù)，卷管理器將新副本設(shè)置為?RW?(讀寫)模式。

最后，Longhorn Manager?調(diào)用?Longhorn Engine?從其副本集中移除故障副本。

2.4. 快照

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

從快照還原卷時，它會反映創(chuàng)建快照時卷的狀態(tài)。

快照功能也是?Longhorn?重建過程的一部分。每次?Longhorn?檢測到一個副本宕機時，它會自動創(chuàng)建（系統(tǒng)）快照并開始在另一個節(jié)點上重建它。

2.4.1. 快照的工作原理

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

快照在創(chuàng)建后無法更改，除非快照被刪除，在這種情況下，其更改會與下一個最近的快照合并。新數(shù)據(jù)始終寫入實時版本。新快照始終從實時數(shù)據(jù)創(chuàng)建。

要創(chuàng)建新快照，實時數(shù)據(jù)將成為最新的快照。然后創(chuàng)建一個新的空白版本的實時數(shù)據(jù)，取代舊的實時數(shù)據(jù)。

2.4.2. 定期快照

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

2.4.3. 刪除快照

不需要的快照可以通過界面手動刪除。當系統(tǒng)生成的快照被觸發(fā)刪除時，系統(tǒng)會自動將其標記為刪除。

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

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

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

要清理最新快照，可以創(chuàng)建一個新快照，然后刪除以前的“最新”快照。

2.4.4. 存儲快照

快照存儲在本地，作為卷的每個副本的一部分。它們存儲在?Kubernetes?集群中節(jié)點的磁盤上?？煺张c主機物理磁盤上的卷數(shù)據(jù)存儲在同一位置。

2.4.5. 崩潰一致性

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

操作系統(tǒng)在寫入塊層(block layer)之前將內(nèi)容保留在緩存中是正常的。這意味著如果所有副本都關(guān)閉，那么?Longhorn?可能不包含關(guān)閉前立即發(fā)生的更改，因為內(nèi)容保存在操作系統(tǒng)級緩存中，尚未傳輸?shù)?Longhorn?系統(tǒng)。

此問題類似于臺式計算機因停電而關(guān)閉時可能發(fā)生的問題?；謴凸╇姾?，您可能會發(fā)現(xiàn)硬盤驅(qū)動器中有一些損壞的文件。

要在任何給定時刻強制將數(shù)據(jù)寫入塊層(block layer)，可以在節(jié)點上手動運行同步命令，或者可以卸載磁盤。在任一情況下，操作系統(tǒng)都會將內(nèi)容從緩存寫入塊層(block layer)。

Longhorn?在創(chuàng)建快照之前自動運行同步命令。

3. 備份和輔助存儲

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

由于卷復制(volume replication)是同步的，而且由于網(wǎng)絡(luò)延遲(network latency)，很難進行跨地域復制。備份存儲(backupstore)也用作解決此問題的媒介。

在?Longhorn?設(shè)置中配置備份目標后，Longhorn?可以連接到備份存儲并在?Longhorn UI?中向您顯示現(xiàn)有備份列表。

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

3.1. 備份的工作原理

使用一個快照作為源創(chuàng)建備份，以便它反映創(chuàng)建快照時卷數(shù)據(jù)的狀態(tài)。

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

由于備份不包含快照，因此它們不包含卷數(shù)據(jù)更改的歷史記錄。從備份還原卷后，該卷最初包含一個快照。此快照是原始鏈中所有快照的合并版本，它反映了創(chuàng)建備份時卷的實時數(shù)據(jù)。

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

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

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

圖 3. 二級存儲中的備份與主存儲中的快照之間的關(guān)系

上圖描述了如何從?Longhorn?中的快照創(chuàng)建備份：

• 圖表的主存儲一側(cè)顯示了?Kubernetes?集群中?Longhorn?卷的一個副本。副本由四個快照鏈組成。按照從新到舊的順序，快照是?Live Data、snap3、snap2?和?snap1。

• 圖表的二級存儲側(cè)顯示了外部對象存儲服務(wù)（如?S3）中的兩個備份。

• 在二級存儲中，backup-from-snap2?的顏色編碼顯示它包括來自?snap1?的藍色變化和來自?snap2?的綠色變化。

snap2?中的任何更改都沒有覆蓋?snap1?中的數(shù)據(jù)，因此?snap1?和?snap2?中的更改都包含在?backup-from-snap2?中。

• 名為?backup-from-snap3?的備份反映了創(chuàng)建?snap3?時卷數(shù)據(jù)的狀態(tài)。顏色編碼和箭頭表示?backup-from-snap3?包含來自?snap3?的所有深紅色更改，但僅包含來自?snap2?的綠色更改之一。

這是因為?snap3?中的一項紅色更改覆蓋了?snap2?中的一項綠色更改。這說明了備份如何不包括更改的完整歷史記錄，因為它們將快照與其之前的快照混為一談。

• 每個備份維護自己的一組?2 MB?塊。每個?2 MB?塊僅備份一次。兩個備份共享一個綠色塊和一個藍色塊。

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

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

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

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

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

3.2. 定期備份

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

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

創(chuàng)建備份涉及通過網(wǎng)絡(luò)復制數(shù)據(jù)，因此需要時間。

3.3. 災(zāi)難恢復卷

災(zāi)難恢復 (DR) 卷是一種特殊卷，可在整個主集群出現(xiàn)故障時將數(shù)據(jù)存儲在備份集群中。DR?卷用于提高?Longhorn?卷的彈性。

由于?DR?卷的主要用途是從備份中恢復數(shù)據(jù)，因此此類卷在激活之前不支持以下操作：

• 創(chuàng)建、刪除和恢復快照

• 創(chuàng)建備份

• 創(chuàng)建持久卷

• 創(chuàng)建持久卷聲明

可以從備份存儲中的卷備份創(chuàng)建?DR?卷。創(chuàng)建?DR?卷后，Longhorn?將監(jiān)控其原始備份卷并從最新備份增量恢復。備份卷是備份存儲中包含同一卷的多個備份的對象。

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

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

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

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

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

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

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

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

以下分析假設(shè)該卷每小時創(chuàng)建一個備份，并且從一個備份中增量恢復數(shù)據(jù)需要五分鐘：

• 如果?Backupstore?輪詢間隔為?30?分鐘，則自上次恢復以來最多有一個備份數(shù)據(jù)。恢復一份備份的時間為五分鐘，因此?RTO?為五分鐘。

• 如果?Backupstore?輪詢間隔為?12?小時，則自上次恢復以來最多有?12?個數(shù)據(jù)備份?；謴蛡浞莸臅r間為?5 * 12 = 60?分鐘，因此?RTO?為?60?分鐘。

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

要了解?Kubernetes?中的持久存儲，重要的是要了解?Volumes、PersistentVolumes、PersistentVolumeClaims?和?StorageClasses，以及它們?nèi)绾螀f(xié)同工作。

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

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

Kubernetes 工作負載如何使用新的和現(xiàn)有的持久存儲

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

• 使用現(xiàn)有的持久卷

• 動態(tài)配置新的持久卷

現(xiàn)有存儲配置

要使用現(xiàn)有?PV，您的應(yīng)用程序需要使用綁定到?PV?的?PVC，并且?PV?應(yīng)包含?PVC?所需的最少資源。

換句話說，在?Kubernetes?中設(shè)置現(xiàn)有存儲的典型工作流程如下：

1. 在您有權(quán)訪問的物理或虛擬存儲的意義上設(shè)置持久存儲卷。

2. 添加引用持久存儲的?PV。

3. 添加引用?PV?的?PVC。

4. 在您的工作負載中將?PVC?掛載為卷。

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

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

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

動態(tài)存儲配置

對于動態(tài)存儲配置，您的應(yīng)用程序需要使用綁定到?StorageClass?的?PVC。?StorageClass?包含提供新持久卷的授權(quán)。

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

1. 添加?StorageClass?并將其配置為從您有權(quán)訪問的存儲中自動配置新存儲。

2. 添加引用?StorageClass?的?PVC。

3. 將?PVC?掛載為工作負載的卷。

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

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

也可以使用?StorageClass，而不需要在?Kubernetes?中顯式創(chuàng)建?StorageClass?對象。由于?StorageClass?也是一個用于匹配帶有?PV?的?PVC?的字段，因此可以使用自定義存儲類名稱手動創(chuàng)建?PV， 然后可以創(chuàng)建一個要求帶有該?StorageClass?名稱的?PV?的?PVC。然后，Kubernetes?可以使用指定的?StorageClass?名稱將?PVC?綁定到?PV，即使?StorageClass?對象并不作為?Kubernetes?資源存在。

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

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

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

此屬性可用于為由?StatefulSet?創(chuàng)建的?pod?創(chuàng)建匹配的?pv?和?pvc。

這些?PVC?是使用?StorageClass?創(chuàng)建的，因此可以在?StatefulSet?擴展時自動設(shè)置它們。

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

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

如果您有多個?Pod?運行持久性數(shù)據(jù)(persistent storage)，那么部署(Deployment)不能很好地與持久性存儲(persistent storage)配合使用。對于多個?pod，應(yīng)該使用?StatefulSet。