K8S容災方案的五個關鍵點是那些

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

容災恢復是絕大多數企業級應用的基本要求

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

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

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

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

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

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

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

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

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

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

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

數據和配置備份

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

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

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

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

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

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

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

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

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

以上就是K8S容災方案的五個關鍵點是那些，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。