隨著開發(fā)人員和應用程序團隊選擇容器和Kubernetes作為構建、部署、運行和擴展應用程序的首選技術，越來越多的數(shù)據(jù)應用程序每天都會登陸Kubernetes。越來越多的獨立軟件供應商（ISV）將其應用程序打包成容器分發(fā)到Kubernetes上運行，在所有垂直行業(yè)中大量使用這些應用程序。許多這樣的應用程序都是業(yè)務關鍵型的，其中斷可能會導致嚴重的收入、生產率和聲譽損失。

當企業(yè)意識到保護其Kubernetes應用程序的業(yè)務需求時，他們轉而使用市場上可用的開源或商業(yè)解決方案。保護Kubernetes應用程序通常需要在發(fā)生災難、網絡攻擊、惡意或意外用戶錯誤后恢復應用程序：

——在同一集群內

——同一地區(qū)的不同集群

——區(qū)域/地理上的獨立集群

應用這些解決方案來保護和移動Kubernetes應用程序通常不會一蹴而就。Kubernetes（使用自定義資源定義）的靈活性和可擴展性使其在開發(fā)人員中非常流行，這使得保護Kubernetes應用程序變得更加困難，因為沒有標準的方法來確定災難后需要備份什么才能成功恢復。

現(xiàn)實世界中的Kubernetes應用程序是雪花

由于沒有一個定義應用程序組成部分的標準Kubernetes規(guī)范，因此確定要備份和克隆哪些資源的問題尤其具有挑戰(zhàn)性。因此，專注于Kubernetes應用程序保護（提供備份/恢復和災難恢復（DR））的解決方案會假設開發(fā)人員將如何構建其應用程序，并盡最大努力找出實際應用程序的組成部分，以及如何最好地保護它。

這種方法可以實現(xiàn)Kubernetes應用程序發(fā)現(xiàn)過程的自動化。在高度動態(tài)的Kubernetes環(huán)境中，自動化應用程序發(fā)現(xiàn)過程是可取的。然而，自動發(fā)現(xiàn)通常只適用于應用程序簡單且僅限于命名空間的一部分情況。如果應用程序跨越多個命名空間，具有集群范圍的資源，和/或使用外部完全管理的數(shù)據(jù)庫、數(shù)據(jù)存儲或消息服務，那么提供的過于簡單的應用程序發(fā)現(xiàn)和隨后的應用程序保護功能不足以保護大多數(shù)Kubernetes工作負載。

Kubernetes應用程序的構成

大多數(shù)真實世界的Kubernetes應用程序都不符合開發(fā)人員開發(fā)和部署Kubernetes應用程序所遵循的標準配方。開發(fā)人員如何定義Kubernetes應用程序可以是以下內容的組合（不是詳盡的列表）：

App=1..1個命名空間中有N個資源

App=1..N個命名空間

App=1..N個命名空間+1..N個集群范圍的資源

App=1..N個資源位于1..N個命名空間+1..N個集群范圍的資源

App=1..N個資源位于1..N個命名空間+1..N個集群范圍的資源+外部資源（例如，公共云中的完全管理的數(shù)據(jù)庫）

如上所述，使用命名空間作為應用程序分隔符并不能涵蓋開發(fā)人員定義其Kubernetes應用程序的所有不同方式。自動推斷構成Kubernetes應用程序的所有組件也可能導致識別Kubernetes應用程序資源的失誤。

使用用戶輸入的自定義應用程序定義

為了有效地備份和恢復應用程序，用戶必須能夠指定Kubernetes應用程序的組成部分，該應用程序提供關鍵的“服務”，必須確保其業(yè)務連續(xù)性。理想情況下，應該讓用戶有機會使用Kubernetes原生機制定義其應用程序，或者允許用戶定義符合上面列舉的應用程序定義模式的自定義應用程序。

在某些情況下，同樣重要的是確定應該從應用程序定義中排除的資源，因為這些資源在目標/目標集群或命名空間中可能不相關，從而阻止成功恢復。一個有效的Kubernetes應用程序保護解決方案必須為用戶提供指定這些詳細信息的能力，或者智能地促進發(fā)現(xiàn)此類復雜的應用程序。一旦用所有必要的資源定義了一個應用程序，保護應用程序就不再是猜測了，從而得到更可預測的結果。

鉤子，還是鉤子

多年來，企業(yè)備份軟件一直使用鉤子或前置腳本/后置腳本，使用戶可以插入自定義操作來執(zhí)行應用程序一致性備份，例如在拍攝快照以將內存中的表刷新到磁盤之前停止數(shù)據(jù)庫。使用“執(zhí)行鉤子”插入自定義操作的能力在Kubernetes應用程序中有了全新的含義。可預測地控制Kubernetes應用程序的端到端備份和恢復，以在恢復后實現(xiàn)成功的應用程序實例化，通常需要在備份前后以及恢復前后對組成Kubernetes應用程序的多個資源執(zhí)行自定義操作。

備份恢復工作流期間Kubernetes中的執(zhí)行鉤子可用于實現(xiàn)許多目標，如在備份/恢復之前或之后動態(tài)應用網絡安全策略，在克隆之前更改入口控制器的注冊路徑，刷新IP地址，以及其他特定于應用程序的自定義操作。Kubernetes應用程序保護解決方案必須允許具有執(zhí)行鉤子的備份/災難恢復工作流的可擴展性，使用執(zhí)行鉤子可以插入特定于應用程序的自定義操作。

不備份和恢復的內容

確定哪些應用程序資源需要保護至關重要，但哪些不需要備份和/或恢復也同樣重要。這是因為某些資源（如秘密、IP地址和節(jié)點端口）在目標集群中可能與災難恢復無關。對組成Kubernetes應用程序的所有資源進行大容量備份，然后進行后續(xù)恢復，可能會導致錯誤的恢復，因為目標集群中的資源子集完全無效。從概念上講，通常有兩種方法來解決這種情況。

——使用過濾器排除備份或恢復在目標集群中沒有意義的特定資源，使Kubernetes或operator（部署和管理Kubernetes應用程序的流行設計模式）能夠重新創(chuàng)建這些資源。

——在資源到達目標集群之前進行轉換。

Kubernetes應用程序保護解決方案必須允許用戶執(zhí)行上述所有操作，以確保恢復后的應用程序行為正確。

總結

隨著企業(yè)意識到需要保護其Kubernetes應用程序，在大規(guī)模采用這些解決方案之前，評估其可定制性和可擴展性非常重要。提供一套最佳實踐也很重要，它可以指導開發(fā)人員在設計Kubernetes應用程序時遵循一套方法，包括推薦一套他們利用的標準集群內和外部服務，以便在關鍵業(yè)務Kubernetes應用程序在企業(yè)中無處不在時更容易保護它們。

原文鏈接：

https://thenewstack.io/kubernetes-apps-are-snowflakes-find-an-extensible-protection-framework/