K8S資料保護工具比較：Cohesity、 Kasten、 OpenEBS、 Portworx、 Rancher Longhorn、 和Velero
資料保護對于客戶越來越重要。從概念上來說，資料保護包括備份、高可用性、應用連續性、和容災恢複。所有的企業都需要實施，測試和運維自己的資料保護政策，來避免在發生問題時對商業産生不利影響。随着資料在使用者體驗和商業流程中的作用越來越重要，對關鍵資料突然不能通路的問題的容忍度越來越低。根據Uptime Institute的報告(
https://uptimeinstitute.com/data-center-outages-are-common-costly-and-preventable)資料無法通路問題中41%的情況導緻的損失均超過了百萬美元。企業對高可用性的基礎架構的依賴性逐漸增強。
是以，一個有效的資料保護政策可以使當機時間極少，即便發生意外當機，應用和資料也都可以快速的恢複。同時資料保護政策還需要確定資料的隐私性和合規性（比如GDPR和CCPA），現在越來越多的使用者資料轉移到了線上隐私合規愈發重要。
雖然資料保護是一個硬性需求，很多客戶仍然做的不夠好。傳統的資料保護方式在單獨主機環境裡很出色，但在分布式或跨資料中心環境裡就能力不足了。而Kubernetes環境是典型的分布式環境。傳統的業務連續性和容災恢複（BCDR）方案，無法支援現今運作在Kubernetes上的關鍵商業應用所要求的RPO（Recovery Point Objective）和RTO（Recovery Time Objective）。
由于每個應用和每個客戶環境都各不相同，是以資料保護方式也多種多樣。當我們考慮資料保護解決方案的時候，一些重要的問題我們首先需要思考：
- 我是不是隻需要在一個單獨的資料中心裡保護我的資料？
- 我是否需要保護數中心内和資料中心外的資料，需要建立一個混合的資料保護方案？
- 是不是合規部門對一些備份和恢複資料的存儲位置有要求？
- 應用對RPO和RTO的要求低還是高？
- 是否需要對Kubernetes叢集裡的每一個應用都采用同樣水準的資料保護方式？
- 我們準備對資料保護方案花多少錢，可否對不同的應用采用不同的資料保護方式，以降低成本？
還有一些問題取決于你的目标，比如：
- 即使出現伺服器當機，或者磁盤當機，也需要保證Kubernetes應用的高可用。
- 備份資料和應用的配置，這樣我們可以在另一個環境裡恢複它們。
- 一旦出現資料中心服務中斷，應用可以即時在另一個環境重新開機且沒有資料損失。
我們可以把資料保護場景分為：
- 本地高可用
- 備份和恢複
- 容災恢複
這三種場景是所有企業級資料保護的基礎，也是評估一個Kubernetes資料保護解決方案能力的重要要素。不同解決方案的客戶要求可能各有不同，客戶需要根據自身的需求來評估這些要素。通常來說，隻有靜态資料備份不足以完成有效的資料保護，本地高可用通常是必須的基礎性需求。
本地高可用、備份和恢複、容災恢複是評估一個Kubernetes資料保護解決方案能力的重要要素。
對于Kubernetes，資料保護是一個較新的領域，市場有一些解決方案提供。本文我們要分析Kubernetes應用資料保護領域的一些主要供應商（
https://www.computerweekly.com/feature/Spread-of-Kubernetes-spurs-backup-and-disaster-recovery-products）。我們在博文中讨論的解決方案主要是為了保護Kubernetes中正在運作的應用、和應用中的持久性資料，而不是備份Kubernetes的節點服務或者etcd存儲，明确這些有助于我們更好的了解資料保護工具和Kubernetes的資料保護。
本地高可用性
本地高可用性指的是保護發生在某單個資料中心的錯誤，或者是某單個可用性區域内的雲平台的錯誤。當應用正在運作時，如果基礎架構、應用或者節點發生錯誤，都被認為是本地的錯誤。當我們用Kubernetes資料保護工具來建構本地高可用時，應用的複本可以在使用者無感覺的情況下快速恢複，達到對使用者的高可用。一個在本地節點錯誤情況下，當機的例子：
https://thenewstack.io/overcome-stuck-ebs-volumes-running-stateful-containers-aws/。本地高可用性是資料保護的基礎。為達到本地高可用性，一般通過建立本地資料複制集的方式。如果本地高可用性是通過從外部其它位置的備份資料恢複的方式進行，那就應該被歸類為是備份恢複方案，因為恢複時間會比本地高可用性的方案長很多。
備份和恢複方案，指的是把Kubernetes上的整個應用，從本地Kubernetes叢集上，備份到非本地的另一位置的對象存儲裡（非本地指位于其他區域的公有雲、私有雲、或者是本地部署環境）。備份解決方案也可以有多個備份位置。備份通常是為了防止系統錯誤，或者為了應用的合規和監管要求。而Kubernetes備份，需要符合Kubernetes環境特點。包括：
- Kubernetes資源，比如Secrets、服務賬戶、CRDs等
- 應用配置和資料
這些對象對Kubernetes來說都需要被備份。傳統的備份方案一般不會考慮這些Kubernetes的對象，而是通常隻把應用所依賴的VM、伺服器、磁盤作為備份目标。一個Kubernetes備份解決方案，不僅能備份單個應用，而且可以備份多個應用或者整個Kubernetes命名空間，同時也能夠支援傳統備份方式的内容，比如排程、Jobs、 retention、加密和分層。
一個Kubernetes備份必須包括Kubernetes的資源比如Secrets、服務賬戶、CRDs、應用配置和資料。
與備份類似，容災恢複也必須要包括Kubernetes的一系列對象，應用配置和資料。并且需要建立主站點之外的容災站點，這樣資源和持久狀态能夠在主站點出問題時快速恢複到容災站點。容災恢複系統也可以處理不同保護層級的RPO和RTO，取決于成本和商業需要的綜合考慮。
例如，如果應用不能承擔任何資料丢失，那就必須設定零RPO的目标。如果要求沒那麼高，也可以設定15分鐘RPO的目标。再例如，一個應用的RTO要求<2分鐘，而另一個應用可以允許1小時之内的當機時間。
容災恢複系統必須規劃應用如何配置才能夠在容災節點上有效的啟動運作。這需要處理應用的中繼資料，例如标簽和複制集等，讓它們能夠自動啟動起來。如果Kubernetes的API不能夠被了解和啟動，就會産生當機事故或者資料損失。
Kubernetes資料保護解決方案的比較
我們已經了解了資料保護的多種類型，我們接下來比較一下市場上的解決方案：*比較基于各解決方案提供商的網站和文檔。
快速索引
X – 沒有這項功能，或者宣稱有功能但沒有找到任何支援性資訊
❍ – 宣稱有這項功能，但是功能較為薄弱
◑ – 宣稱有這項功能，但是功能不完整
✅ – 宣稱有這項功能，并且從網站上的文檔來看功能完整
Cohesity
Cohesity在網站上介紹，“Cohesity保護Kubernetes命名空間的資料和應用狀态。Web-Scale平台備份命名空間包括運作狀态，而不僅僅是資料。”Cohesity是資料保護和存儲領域的一個主要服務商，它近期也通過備份命名空間的資料和應用，開始支援Kubernetes。但是Cohesity僅僅針對整個命名空間，而不能保護命名空間内的每個獨立應用。保護單獨應用是很有必要的，因為不是所有命名空間内的應用都需要同一水準的保護級别。是以Cohesity保護的顆粒度還不夠。另外Cohesity目前還沒有Kubernetes主存儲，也還沒有基于Kubernetes的容災恢複方案。由于Cohesity對于備份VM的傳統解決方案積累很久，現在進入到對Kubernetes的支援，也是一個很好的解決方案。
Kasten
Kasten在網站上介紹，“K10資料管理平台，為Kubernetes而建，為企業營運團隊提供易用、可擴充、安全的備份恢複、容災恢複、和叢集間應用遷移能力”。Kasten使用自身建構的存儲系統 -EBS/RBD，不支援應用自身所在叢集裡的複制，是以它無法支援本地高可用。基于雲端的塊存儲來建構Kubernetes卷，經常會由于Stuck Volumes導緻應用的當機。由于沒有資料路徑的元件，Kasten無法達到資料完全無損的零RPO，備份隻能是異步的，是以恢複後的資料與最新的資料會有一定的不同。有時候企業在容災恢複上的要求不高，但很多企業仍然在容災恢複上需要零RPO。
OpenEBS
OpenEBS這樣描述：“我們是應用和本地、網絡或雲存儲之間的抽象層，通過OpenEBS可以減少維護工作量，降低存儲成本并且簡化管理。”OpenEBS主要集中在本地高可用，也可以和Velero內建來達到OpenEBS 資料管理即服務（DMaaS）。DMaaS能夠把Kubernetes有狀态應用以及持久資料進行遷移。本地部署、雲部署等任意方式都可以互相遷移。相對于Cohesity隻備份整個命名空間而非每個獨立的Kubernetes應用，OpenEBS隻備份獨立的應用。應用層級的備份的确更加靈活，但很多客戶仍然需要命名空間層級的備份。另外OpenEBS隻能用來備份包含持久存儲卷的有狀态應用，而不能備份或遷移Kubernetes對象和應用配置。OpenEBS備份是基于Velero進行的，而Velero也有自身的局限性 – 不能提供完整的容災恢複功能，而OpenEBS自身也沒有容災恢複功能的補充，雖然OpenEBS也可以提供類似Kasten那樣的異步備份的容災，但問題也是無法達到資料完全無損的零RPO。
Portworx
Portworx是一個端到端的Kubernetes存儲和資料管理方案。包括基于容器的CaaS，DBaaS，SaaS，備份恢複，以及容災恢複。Portworx被市場研究機構GigaOm評為全球第一的Kubernetes存儲平台。GigaOm評價Portworx的功能完美适應大型客戶與服務提供商的需求。Portworx解決方案支援複雜的Kubernetes基礎架構，無論是本地部署還是公有雲/混合雲部署。在Portworx的支援下，所有的Kubernetes應用都可以獲得容器原生存儲能力，以及本地高可用、容災恢複、備份、安全管理、多雲間遷移的能力等。Portworx提供一個資料層能夠伸展在低延遲的網絡上，進而達到零RPO容災恢複，本地應用的備份和命名空間的備份。Portworx一開始就支援本地高可用，以及後來推出的PX-DR和PX-Backup能夠提供更加多樣的資料保護能力。
Rancher Longhorn
根據Rancher的描述，Longhorn是“輕量的，可靠的，和強大的。你可以使用簡單的Kubectl指令，或者使用Helm來把Longhorn安裝到Kubernetes叢集上。一旦安裝完成，Kubernetes叢集就具備了持久存儲卷的支援。”雖然比起其他開源解決方案，Longhorn的社群較小，但它近期被接受加入了CNCF。Longhorn有DR Volume的功能，可以被設定成源卷和目标卷，這樣卷可以在一個新叢集上基于最新的備份被激活。這個很類似Kasten的DR解決方案，是基于備份的，是以無法達到零RPO的能力。同樣由于也不含應用中繼資料，是以也無法達到Kubernetes應用層級的恢複。
Velero
Velero描述自己的解決方案：“一個開源工具，可實作安全的備份恢複、容災和恢複，以及遷移Kubernetes叢集資源和持久卷。”Velero自身隻能支援無狀态應用資源。但是使用者可以選擇增加插件來達到持久卷聲明快照備份。另一個選擇是Restic，它通過檔案/拷貝方式來實作。Velero自身并沒有解決Kubernetes應用的資料問題。但如果結合插件或者Restic一起使用，可以提供備份和恢複，以及基于異步備份的容災恢複能力 – 類似OpenEBS和Kasten。但是一樣也無法提供零RPO的容災恢複能力。結語
希望這篇文章能夠幫助您更多的了解Kubernetes備份和資料保護解決方案，以及它們與傳統的容災恢複方案或者備份恢複方案有什麼不同。各種解決方案在目前雲原生架構下的建構方式都各有不同，是以這需要使用者根據自身的應用的實際情況與需要，為應用選擇不同層級的資料保護機制，進而選擇有效的資料保護解決方案。
參考文檔：
[1]
https://www.cohesity.com/resource-assets/solution-brief/Data-Protection-for-Entire-Kubernetes-and-Container-Application-Stack-Solution-Brief.pdf[2] www.kasten.io/product/
[3]
https://openebs.io/[4]
https://help.mayadata.io/hc/en-us/articles/360033401591-DMaaS[5]
https://github.com/longhorn/longhorn[6]
https://velero.io/