本篇文章給大家分享的是有關(guān)K8S容災方案的五個關(guān)鍵點是那些，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

堅守“ 做人真誠 · 做事靠譜 · 口碑至上 · 高效敬業(yè) ”的價值觀，專業(yè)網(wǎng)站建設服務10余年為成都鑿毛機小微創(chuàng)業(yè)公司專業(yè)提供企業(yè)網(wǎng)站建設營銷網(wǎng)站建設商城網(wǎng)站建設手機網(wǎng)站建設小程序網(wǎng)站建設網(wǎng)站改版，從內(nèi)容策劃、視覺設計、底層架構(gòu)、網(wǎng)頁布局、功能開發(fā)迭代于一體的高端網(wǎng)站建設服務。

容災恢復是絕大多數(shù)企業(yè)級應用的基本要求

在沒有Kubernetes也沒有容器的時候，備份和恢復解決方案通常在虛擬機（VM）級別上實現(xiàn)。當應用程序在單個VM上運行時，容災系統(tǒng)適用于這樣的傳統(tǒng)應用程序。但是，當使用Kubernetes對應用程序進行容器化管理時，這樣的容災系統(tǒng)就無法使用了。有效的Kubernetes容災恢復方案必須針對容器化架構(gòu)進行重新設計，并按Kubernetes的原生方式來運行。
傳統(tǒng)的基于VM的備份和恢復解決方案，使用快照來收集數(shù)據(jù)，但這些數(shù)據(jù)對于某個具體容器化應用并不足夠。因為任何一個特定的VM都將包含來自多個應用的數(shù)據(jù)。如果您嘗試通過VM快照來備份APP 1，將會同時獲取其他應用的多余數(shù)據(jù)。但這些數(shù)據(jù)從容器角度來看又不夠：APP 1可能還會將數(shù)據(jù)存儲在其他VM上。因此通過對某個單獨VM的快照無法捕獲所有APP1的數(shù)據(jù)。

基于分布式體系結(jié)構(gòu)的現(xiàn)代應用需要的容災方案，需要能夠找到特定應用的所有相關(guān)數(shù)據(jù)和配置信息，并能夠以零RPO（Recovery Point Objective，復原點目標）和接近零RTO（Recovery Time Object，復原時間目標）的方式進行恢復。

一個有效的Kubernetes容災解決方案需要具備：

容器粒度的控制
能夠備份數(shù)據(jù)和配置
Kubernetes命名空間感知
針對多云和混合云架構(gòu)的優(yōu)化
保持應用的一致性

容災解決方案必須滿足以上五個標準，才能確保Kubernetes上運行的含大量數(shù)據(jù)的應用程序在容災恢復的時候，滿足服務水平協(xié)議（SLA）或相關(guān)法律要求。

讓我們分析一下為什么這五個標準都很重要。

容器粒度控制
容器粒度控制容災方案意味著用戶可以備份特定的Pod或Pod組，而不是備份整個VM或服務器。這使得用戶可以僅快照屬于該應用程序的容器。

假設您有一個三節(jié)點Kubernetes集群，其中有一個三節(jié)點Cassandra環(huán)和三個單節(jié)點PostgreSQL數(shù)據(jù)庫，分布在三個虛擬機上。使用傳統(tǒng)的災難恢復解決方案，備份群集的唯一方法是備份三個虛擬機。這將導致提取，轉(zhuǎn)換和加載過程帶來的復雜性增加，存儲成本增加和RTO增加。備份充足數(shù)據(jù)的唯一方法是備份超出必要數(shù)據(jù)的更多數(shù)據(jù)。
使用容器粒度的方式，可以在三個VM上僅備份一個PostgreSQL數(shù)據(jù)庫或三節(jié)點Cassandra環(huán)，而無需其他任何備份。

Kubernetes命名空間感知
傳統(tǒng)的備份和恢復解決方案不是以Kubernetes的方式進行的。
Kubernetes中的命名空間通常運行多個相關(guān)的應用程序。例如，企業(yè)Kubernetes部署中的一種常見模式是使公司/部門所有的應用都運行在同一個命名空間內(nèi)。在這種情況下，通常有必要一起備份Kubernetes命名空間中的所有應用程序。

但是，像每個單獨的應用一樣，命名空間分布在許多虛擬機上。每個虛擬機可能還有來自幾個不同命名空間的Pod。如果沒有支持命名空間的容災解決方案，則完全備份將需要備份和存儲遠遠超出必要的數(shù)據(jù)。即使采用了這種過分的備份策略，在發(fā)生故障的情況下也很難還原整個命名空間，從而導致較高的RTO。

應用的一致性
即使您想通過備份系統(tǒng)中的所有VM來解決上述問題，使用傳統(tǒng)的容災恢復方案也很難避免數(shù)據(jù)損壞。為了成功地備份分布式應用，而沒有數(shù)據(jù)損壞的風險，在快照進行過程中，必須鎖定應用程序中的所有Pods。基于VM的快照無法實現(xiàn)此目的，因為它們無法鎖定整個應用程序，無法跨多個VM執(zhí)行應用一致性的快照。
成功的快照，要使數(shù)據(jù)損壞風險最小化，并必須保持分布式架構(gòu)的應用的一致性。這意味著在鎖定屬于應用程序的所有Pods的同時，來執(zhí)行快照。

數(shù)據(jù)和配置備份

容災系統(tǒng)的目標不僅是防止數(shù)據(jù)丟失，還在于保持RTO較低。您需要應用程序在遇到問題后盡快重新啟動并運行。
這需要備份應用數(shù)據(jù)和配置信息。如果備份中不包含配置信息，則必須就地重建應用程序，這是一個緩慢，手動且可能容易出錯的過程。但是，如果僅保存配置，則可能會丟失所有數(shù)據(jù)。

一個真正的Kubernetes的企業(yè)級容災系統(tǒng)將同時包含數(shù)據(jù)和配置備份。這樣在系統(tǒng)失敗后，可以用一兩個命令快速重新部署應用程序。

針對多云和混合云架構(gòu)進行了優(yōu)化
絕大多數(shù)企業(yè)在實踐中，應用程序至少在兩個環(huán)境中運行。這可能意味著多個本地數(shù)據(jù)中心或多個Amazon Web Services（AWS）區(qū)域。在容災恢復的情況下，通常將一個數(shù)據(jù)中心作為主站點，而將第二個數(shù)據(jù)中心作為備份站點。但是，也有許多公司使用公有云和本地數(shù)據(jù)中心的組合來運行應用程序并滿足其業(yè)務需求。在大多數(shù)情況下，企業(yè)會根據(jù)其RPO和RTO要求選擇最佳的架構(gòu)方式。

對于容災恢復解決方案而言，結(jié)合這些不同的架構(gòu)方式以支持不同級別的RPO和RTO至關(guān)重要。有效的容災恢復解決方案應該能夠提供同步和異步數(shù)據(jù)復制，具體取決于主群集和備份群集之間的延遲。

當主站點和備份站點之間的往返延遲通常在10毫秒以下時，可以實現(xiàn)允許RTO和RPO為零的同步復制。這種情況通常是當主集群和備份群集所在數(shù)據(jù)中心地理相距較近。
在某些情況下，企業(yè)希望主站點和備份站點之間的地理距離遠一些。在這種情況下，RTO仍可以為零或接近零。但是延遲的增加，同步復制數(shù)據(jù)會產(chǎn)生比較大的性能問題。如果應用能夠接受15分鐘或1小時的RPO，則也是可接受的容災方案。

Kubernetes的企業(yè)級容災恢復方案，應為用戶提供適用于多云或混合云架構(gòu)的，同步復制或異步復制的選擇。這樣可以使用戶能夠基于自己的數(shù)據(jù)中心架構(gòu)和業(yè)務需求情況，來選擇不同的容災恢復方案。

結(jié)論
當企業(yè)將關(guān)鍵業(yè)務應用遷移至Kubernetes時，重新思考和設計容災恢復的方案非常重要。實際上可以做到在滿足與容災相關(guān)的SLA的同時，
在Kubernetes上運行應用。

但它需要采用專為Kubernetes設計的容災方法，與Kubernetes的工作方式深入結(jié)合。傳統(tǒng)的基于VM的容災解決方案無法做到這一點。

Portworx Enterprise 存儲平臺是專門為容器和Kubernetes構(gòu)建的。它可為Kubernetes上運行的應用實現(xiàn)零RPO和接近零的RTO容災恢復。并具有容器粒度控制的，命名空間感知的，應用一致性的容災恢復。故障恢復可以完全自動化，從盡可能降低RTO。

以上就是K8S容災方案的五個關(guān)鍵點是那些，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

標題名稱：K8S容災方案的五個關(guān)鍵點是那些-創(chuàng)新互聯(lián)
文章URL：http://vcdvsql.cn/article34/ejese.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、App開發(fā)、網(wǎng)站導航、動態(tài)網(wǎng)站、外貿(mào)建站、軟件開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)