災難恢復是指在面臨不可預見的故障時，保護特定地域的基礎設施或應用程序以減少其對業務的影響。其目的是實現順暢的和自動的恢復，以確保您的應用程序在最小的停機時間內運行，并在幾分鐘內恢復功能。容器和Kubernetes等技術為應用開發帶來了新的機遇，但企業仍然需要災難恢復計劃來防范日益增多的網絡威脅。

在容器之前的世界里，備份和恢復解決方案通常是在虛擬機層面實施的，這適用于在傳統的本地系統上運行的應用程序。但是，當應用程序被容器化并通過Kubernetes這樣的編排器進行遠程管理時，原有的解決方案就不適用了。這意味著有效的災難恢復計劃必須為容器化架構而設計，并且理解Kubernetes的運作方式。

根據Gartner的數據，到明年，全球將有超過75%的企業在生產中運行容器化應用——比去年6月不到30%的數據增加了不少。如果容器化應用是企業IT服務的一部分，那么現實是，它應該像其他服務一樣受到有效的保護和管理。

現在正在使用容器化應用的組織中，存在著現有災難恢復準備與容器化應用所需準備之間的差距。隨著技術的不斷發展，首席信息官需要更多地考慮該領域。

應對災難恢復挑戰

盡管迄今為止從Kubernetes的發展中收獲了許多好處，但容器化的應用程序仍然有其局限性。具有諷刺意味的是，使應用開發、生產和部署更容易的基礎設施，正給災難恢復準備方面帶來更大的挑戰。

容器化架構旨在通過在每個獨特的容器上托管最少數量的獨立服務來最大程度地降低停機風險。這增加了企業需要的靈活性和可訪問性，同時也降低了在面臨動蕩時失敗的可能性。但是，鑒于Kubernetes工作負載可以在單個企業IT 戰略中包含數百個容器，這很容易使IT團隊不堪重負。這種復雜性帶來的最大挑戰是備份和恢復，因此Kubernetes應始終包含進災難恢復計劃的核心議題。

災難有多種形式——從人為錯誤和網絡攻擊到自然災害。雖然數字化有助于最大限度地減少數據丟失的風險，但每個應用程序都仍需要有一個鋼鐵般堅固的災難恢復戰略，以確保當受到攻擊時能夠有效的恢復數據。在災難發生時，有大量的容器需要備份和工作負載需要恢復，這可能將是非常復雜的，所以，在準備災難恢復計劃時一定不能忽視這點。

縮少準備差距

容器化的應用程序不應該使用傳統的一刀切的方法進行備份。一個針對容器化環境有效的災難恢復計劃還應有其他基本特征：速度、可重復性和可移植性。確保您的災難恢復計劃在災難發生前具備這些特性，將在之后為企業節省時間和金錢，避免可用性問題。最重要的是，確保您的IT團隊準備充分，以應對數據丟失的威脅。

Kubernetes和容器化應用的好處不僅僅是存儲應用數據，還包括保存其他關鍵任務的業務數據。由于容器化環境中有如此多的組件（如node、pod、容器），想要創建無漏洞的備份幾乎是不可能的。為了避免手動開發大量的災難恢復文檔和備份腳本，組織可以投資自動化解決方案，如KastenK10，幫助減輕負擔。

一個災難恢復計劃的有效性取決于它的可重復性。企業應該定期進行災難情況的模擬演習。這將使您的團隊（不只是IT團隊、還有其他團隊）都能評估您的準備工作，學習如何整合自上一次演習以來的任何變化，并定期審查和更新計劃。企業需要清楚地了解備份的存儲位置和恢復位置。您的組織在容器環境中進行越多的災難恢復測試，您的員工做的準備就越充分，在處理災難時就越有信心。

雖然Kubernetes讓使用現有服務創建應用程序變得更容易，并提供了一個更簡單的遷移過程，但涉及到災難恢復準備方面，它往往會產生更多的工作。災難恢復計劃應該讓您能輕松地整合變化，這樣當災難來臨時，恢復才是順暢的。從一個簡單的計劃開始，當環境變得更加復雜時，再進行補充。為了最大程度地縮小準備工作的差距，您需要仔細記錄對計劃做的所有改變以及改變的原因，并采用靈活的自動化，使更新插件變得簡單。

為成功做計劃

Kubernetes災難恢復不是一項簡單的工作。備份您的容器化工作負載的唯一正確方法是采用應用程序可感知的、云原生備份，這種備份不會妨礙遷移到新的基礎設施。第一步是確定您的具體要求，并制定適合容器化應用程序的災難恢復戰略。通過這樣做，企業可以擴展Kubernetes最受歡迎的功能——數據移動性。

正如那句老話所說，沒有計劃就是失敗的計劃。隨著IT基礎設施承擔著比以往任何時候都更重要的新角色，系統變得更加復雜，容器的災難恢復計劃必須關注高可用性、速度和可訪問性。雖然災難恢復準備計劃不是你需要每天更新的東西，但當災難來臨時，它將發揮至關重要的作用。