Kubernetes 集群的災(zāi)難恢復(fù)
業(yè)務(wù)連續(xù)性的重要性
業(yè)務(wù)連續(xù)性是指制定應(yīng)對重大中斷和災(zāi)難的策略。災(zāi)難恢復(fù)(DR) 幫助組織在發(fā)生中斷或災(zāi)難時恢復(fù)和恢復(fù)業(yè)務(wù)關(guān)鍵功能或正常操作。
高可用性集群 是支持關(guān)鍵業(yè)務(wù)應(yīng)用程序的服務(wù)器組。應(yīng)用程序在主服務(wù)器上運行，如果出現(xiàn)故障，應(yīng)用程序操作將轉(zhuǎn)移到輔助服務(wù)器上，并在輔助服務(wù)器上繼續(xù)運行。
與容器前相比，災(zāi)難恢復(fù)策略的工作方式顯著不同。那么關(guān)系就簡單直接了，應(yīng)用程序和應(yīng)用服務(wù)器之間是一對一的映射。對所有內(nèi)容進行備份或快照以便在發(fā)生故障時進行恢復(fù)是過時的方法。
災(zāi)難恢復(fù)類型
在我們討論不同的災(zāi)難恢復(fù)方法之前，了解不同類型的災(zāi)難恢復(fù)站點非常重要。容災(zāi)站點分為冷站點、溫站點、熱站點三種。
冷站點：這是基本選項，需要最少的硬件/設(shè)備或沒有硬件/設(shè)備。將不會有連接、備份或數(shù)據(jù)同步。盡管這是最基本、最便宜的選項之一，但它還沒有準備好承受故障轉(zhuǎn)移的影響。
暖站點：與冷站點相比，這種類型的升級選項很少。可以選擇網(wǎng)絡(luò)連接和硬件。這具有數(shù)據(jù)同步功能，并且可以在數(shù)小時或數(shù)天內(nèi)解決故障轉(zhuǎn)移，具體取決于設(shè)置類型。
熱門站點：這是該地塊中最優(yōu)質(zhì)的選項，具有配備齊全的硬件和連接以及近乎完美的數(shù)據(jù)同步。與其他兩種類型的站點相比，這是一種昂貴的設(shè)置類型。
災(zāi)難對組織的影響可能非常昂貴，因此首先做出最佳選擇非常重要。災(zāi)難恢復(fù)管理可以減輕災(zāi)難造成的破壞性事件的影響。沒有一種方法/選項是完美的，并且可能會根據(jù)企業(yè)/組織的要求和類型而有所不同。
傳統(tǒng)災(zāi)難恢復(fù)方法
選項 1：我們可以通過定期備份來實現(xiàn)冷備用，或者您可以通過批量/計劃復(fù)制數(shù)據(jù)來實現(xiàn)熱備用。這里的主要區(qū)別在于從主數(shù)據(jù)中心到災(zāi)難恢復(fù)的復(fù)制類型。在此選項中，只有在線購買備用設(shè)備后，應(yīng)用程序和數(shù)據(jù)才可用，并且由于定期/計劃的備份而導(dǎo)致數(shù)據(jù)丟失的可能性很高。
選項 2： 在這種情況下，我們采用連續(xù)復(fù)制，復(fù)制之間的基線時間非常短。這是一種熱備，另一種是帶有只讀副本的熱備。這意味著兩者在讀取數(shù)據(jù)方面將是相同的，而數(shù)據(jù)只能在主數(shù)據(jù)中心位置寫入。備用可以在發(fā)生中斷時立即使用。
選項 3：這是進行災(zāi)難恢復(fù)設(shè)置的最可靠的方法。在這種情況下，您需要維護兩個具有實時數(shù)據(jù)無縫復(fù)制的活動數(shù)據(jù)中心。該模型需要使用最新技術(shù)和工具堆棧進行高級設(shè)置。這是一個綜合模型，但可能很昂貴。配置和維護可能很復(fù)雜——運行這種設(shè)置需要特定的技能。
容器災(zāi)難恢復(fù)
現(xiàn)在，我們來討論一下如何利用容器化生態(tài)系統(tǒng)進行災(zāi)難恢復(fù)管理。
Kubernetes 集群：部署 Kubernetes 時，您將獲得一個集群。Kubernetes 集群由一組稱為節(jié)點的工作機器組成，它們運行容器化應(yīng)用程序。每個集群至少有一個工作節(jié)點。工作節(jié)點托管作為應(yīng)用程序工作負載組件的Pod ?？刂破矫婀芾砑褐械墓ぷ鞴?jié)點和 Pod。在生產(chǎn)環(huán)境中，控制平面通?？缍嗯_計算機運行，集群通常運行多個節(jié)點，提供容錯和高可用性。要了解有關(guān)集群組件的更多信息，請參閱鏈接。
在此設(shè)置中，應(yīng)用程序不會部署到一臺定義的服務(wù)器中。它可以調(diào)度在任何工作節(jié)點上。容量管理將在集群中完成，因為 Kubernetes 是一個編排工具——根據(jù)節(jié)點的可用性分配部署。
我們需要備份什么
我們知道 Kubernetes 生態(tài)系統(tǒng)的本質(zhì)是非常動態(tài)的，這使得更傳統(tǒng)的備份系統(tǒng)和技術(shù)更難在 Kubernetes 節(jié)點和應(yīng)用程序環(huán)境中良好運行。RPO 和 RTO 可能需要更加嚴格，因為應(yīng)用程序需要不斷啟動和運行。
以下是備份的重要事項列表：
- 配置
- 容器鏡像
- 政策
- 證書
- 用戶訪問控制
- 持久卷
集群中有兩種類型的組件：有狀態(tài)組件和無狀態(tài)組件。狀態(tài)完整組件會留意、期待響應(yīng)、跟蹤信息，并在未收到響應(yīng)時重新發(fā)送請求。ETCD 和 Volumes 是有狀態(tài)組件。在 Kubernetes 平面的其余部分，工作節(jié)點和工作負載是無狀態(tài)組件。備份所有有狀態(tài)組件非常重要。
ETCD備份
ETCD 是一種分布式鍵值存儲，用于保存和管理分布式系統(tǒng)保持運行所需的關(guān)鍵信息。最值得注意的是，它管理流行的容器編排平臺 Kubernetes 的配置數(shù)據(jù)、狀態(tài)數(shù)據(jù)和元數(shù)據(jù)。
我們可以利用ETCD內(nèi)置的快照功能來備份ETCD。另一種選擇是拍攝存儲卷的快照。第三個選項是備份 Kubernetes 對象/資源。恢復(fù)可以分別從快照、卷和對象完成。
持久卷備份
Kubernetes 持久卷是管理員配置的卷。它們是使用特定的文件系統(tǒng)、大小和識別特征（例如卷 ID 和名稱）創(chuàng)建的。
Kubernetes 持久卷具有以下屬性
- 它是動態(tài)配置的或由管理員配置的
- 使用特定文件系統(tǒng)創(chuàng)建
- 有特定的尺寸
- 具有識別特征，例如卷 ID 和名稱
為了讓 pod 開始使用這些卷，需要聲明它們，以及 pod 規(guī)范中引用的聲明。持久卷聲明描述 Pod 所需的存儲量和特征，查找任何匹配的持久卷，并聲明這些。存儲類描述默認卷信息。
從持久卷創(chuàng)建卷快照：
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: new-snapshot-test
spec:
volumeSnapshotClassName: csi-hostpath-snapclass
source:
persistentVolumeClaimName: pvc-test
恢復(fù)卷快照
您可以引用 aVolumeSnapshot來PersistentVolumeClaim使用現(xiàn)有卷中的數(shù)據(jù)配置新卷，或?qū)⒕砘謴?fù)到您在快照中捕獲的狀態(tài)。VolumeSnapshot要在 a 中引用 a PersistentVolumeClaim，請將數(shù)據(jù)源字段添加到您的PersistentVolumeClaim.
在此示例中，您引用VolumeSnapshot在新聲明中創(chuàng)建的PersistentVolumeClaim并更新Deployment來使用新聲明。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-restore
spec:
dataSource:
name: my-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
storageClassName: standard-rwo
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
恢復(fù) Kubernetes 平臺操作
我們可以通過兩種方式恢復(fù)k8s平臺：重建或恢復(fù)。以下是恢復(fù)平臺運營的一些策略：
- 平臺備份與恢復(fù)
我們需要使用備份工具來運行此操作，該工具將從與應(yīng)用程序 ETCD、配置和映像相關(guān)的源集群中獲取備份，并將這些信息存儲在備份存儲庫中。備份完成后，您需要使用相同的備份工具從目標集群運行此恢復(fù)操作，并且可以從復(fù)制存儲庫恢復(fù)信息。
- 從快照恢復(fù)虛擬機
該策略僅適用于 ETCD 恢復(fù)。從 ETCD 快照恢復(fù) Kubernetes 集群所涉及的步驟可能會有所不同，具體取決于 Kubernetes 環(huán)境的設(shè)置方式，但下面描述的步驟旨在讓您熟悉基本過程。還值得注意的是，下面描述的過程替換了現(xiàn)有的 ETCD 數(shù)據(jù)庫，因此如果組織需要保留數(shù)據(jù)庫內(nèi)容，則必須在繼續(xù)之前創(chuàng)建數(shù)據(jù)庫的備份副本。
- 安裝ETCD客戶端
- 確定適當(dāng)?shù)?IP 地址
- 編輯清單文件以更新路徑
- 找到規(guī)格部分
- 將初始集群令牌添加到文件中
- 更新掛載路徑
- 替換軟管路徑的名稱
- 驗證新恢復(fù)的數(shù)據(jù)庫
- 故障轉(zhuǎn)移到另一個集群
如果一個集群出現(xiàn)故障，我們會使用故障轉(zhuǎn)移集群。這些集群與基礎(chǔ)設(shè)施和無狀態(tài)應(yīng)用程序相同。然而，配置和秘密可能不同。在設(shè)置時，這兩種類型的集群可以與 CI/CD 同步。由于我們有并行運行的雙集群，因此在設(shè)置和維護方面可能會很昂貴。
- 在多站點情況下故障轉(zhuǎn)移到另一個站點
在這個策略中，我們需要構(gòu)建一個跨多個站點的集群。這適用于云和本地。由于 ETCD 仲裁，始終建議擁有兩個以上站點且站點數(shù)量為奇數(shù)，以便在一個站點發(fā)生故障時保持集群運行。與其他選項相比，這是一種流行且有效的方式。節(jié)省收益取決于我們?nèi)绾喂芾懋a(chǎn)能。
- 從頭開始重建
這就是所謂的GitOps，這里的概念是，我們?yōu)槭裁床辉诔霈F(xiàn)故障的情況下重建系統(tǒng)而不是修復(fù)呢？如果集群出現(xiàn)故障，我們可以從git包裝器構(gòu)建整個集群，并且不需要對ETCD進行備份。這非常適合無狀態(tài)應(yīng)用程序，但如果您將其與持久性數(shù)據(jù)相結(jié)合，那么我們需要尋找支持和恢復(fù)存儲的選項。
結(jié)論/總結(jié)
根據(jù)需求、復(fù)雜性和預(yù)算來規(guī)劃和設(shè)計自己的災(zāi)難恢復(fù)策略非常重要。提前做好計劃非常重要。我們需要知道基礎(chǔ)設(shè)施的容忍程度是多少，可以承受多少服務(wù)損失等，從而設(shè)計出經(jīng)濟高效的災(zāi)難恢復(fù)策略。所需的另一項關(guān)鍵了解是關(guān)于工作負載。我們正在運行有狀態(tài)的工作負載還是無狀態(tài)的工作負載？我們需要了解與備份和恢復(fù)相關(guān)的底層技術(shù)和依賴項。當(dāng)涉及需要 100% 正常運行時間和可用性的任務(wù)關(guān)鍵型云原生應(yīng)用程序的 DevOps 時。在發(fā)生災(zāi)難時，應(yīng)用程序需要繼續(xù)可用并順利運行。
