Kubernetes應用程式的保護和移動性政策

随着Kubernetes（K8s）和容器成為開發、部署、運作和擴充雲原生和下一代IT應用程式的事實選擇，企業正在K8s叢集上運作越來越多的業務關鍵型應用程式。業務關鍵型應用程式通常是有狀态的。有狀态應用程式具有關聯的狀态、資料和配置資訊，并依賴以前的資料事務來執行其業務邏輯。

Kubernetes上提供服務的業務關鍵型應用程式通常與傳統應用程式一樣具有可用性和業務連續性要求，這意味着服務中斷（違反SLA）會嚴重影響提供商的收入和聲譽。企業通常意識到，他們需要使用資料管理工具使其Kubernetes部署能夠在影響服務的災難之後或面臨到新叢集或環境的硬應用程式遷移任務時對服務故障具有恢複能力。

企業認識到這一需求，但使用内部開發的定制工具，這些工具很難在企業和應用程式團隊之間進行擴充、應用和規範化。換句話說，這種工具是特定于應用程式的，需要為每個應用程式定制開發。是以，企業需要為其Kubernetes資産制定一個連貫一緻的持久性和資料管理戰略。

K8s應用程式資料持久性和管理的現狀

更大的Kubernetes社群和生态系統在定義容器存儲接口（CSI）方面做得非常出色，它解決了使用者在有狀态Kubernetes應用程式的持久存儲資源調配和消耗方面的一階問題。CSI接口還定義了資料管理原語，如對持久卷（PV）快照和克隆的支援。這些接口為存儲和資料管理供應商建立綜合應用資料保護和移動性解決方案奠定了基礎。

Kubernetes資料管理（應用程式感覺是關鍵），并不總是關于叢集中的内容

目前還沒有關于Kubernetes應用程式組成的具體定義。但是，對于大多數Kubernetes從業者和使用者來說，K8s應用程式是通過包含有關應用程式的資料和中繼資料形成的，這些資料和中繼資料結合了标準K8s對象和資源（如ConfigMap、Secrets、Deployment、ReplicaSet）、Persistent Volumes（PV）和跨命名空間（在某些情況下，跨叢集）的自定義資源（CRD和CRs）。是以，任何與應用程式無關的Kubernetes資料管理工具都需要考慮構成應用程式的所有這些元件。

如果不這樣做，也不複制和/或備份與K8s應用程式關聯的持久卷，則在災難發生後恢複應用程式時，可能會導緻一些嚴重的故障。将應用程式視為保護和遷移的整體單元是實作Kubernetes應用程式資料管理的關鍵。

使這種情況更加複雜的是主要用于公共雲的雲原生K8s應用程式設計模式，在公共雲中，應用程式團隊利用了使用完全托管的雲服務（如資料庫、消息隊列和對象存儲）的便利性、穩定性和性能。在這種情況下，根據定義，K8s應用程式不再局限于叢集，而是跨叢集之外的完全托管的服務。在Kubernetes叢集中運作的應用程式中使用外部完全托管或自我管理的資料庫是非常常見的。

在這種雲原生開發設計模式的基礎上，AWS和Azure等公共雲使得通過Kubernetes原生API使用Kubernetes叢集的完全托管服務變得更加容易。AWS Controllers for Kubernetes（ACK）和Azure Service Operator（for Kubernetes）就是例子。

Kubernetes原生持久性的替代方案——常見設計模式及其原因

如上所述，建構基于Kubernetes的現代服務的應用程式團隊除了使用不限于K8s叢集中使用持久卷的原生雲服務外，還經常使用多種持久性技術。出現這種模式的原因有很多，包括但不限于：

——堅信Kubernetes是隻運作無狀态應用程式的優秀平台。

——在K8s叢集上運作資料庫的早期經驗，或了解嘗試這樣做的失敗項目。

——采用雲原生和微服務方法，使用原生公共雲DBaaS（例如AWS RDS、Google cloud SQL、Azure Cosmos DB）、第三方供應商管理的資料存儲（作為SaaS提供）或自我管理的外部資料庫叢集建構Kubernetes應用程式，感覺很正常。這種設計範式遵守雲原生設計方法，它利用這些資料服務的可伸縮性、可恢複性、彈性和靈活性，在微服務之間使用基于API的契約。

——使用對象存儲滿足K8s持久性需要，因為它在公共雲中無處不在，并且廣泛用于持久化現代應用程式。

與其他選擇一樣，這些持久性選擇也有缺點。使用完全托管的原生公共雲資料庫和NoSQL資料存儲可能成本高昂，并導緻對一個公共雲的隐式鎖定。但對于那些選擇單一或主要雲提供商滿足其IT需求的企業來說，這可能是一個不錯的設計選擇。為了避免雲提供商鎖定，采用多雲戰略的企業通常使用第三方ISV提供的雲不可知DBaaS産品。

在其他情況下，他們在雲提供商的保留執行個體上運作外部資料庫叢集（利用折扣保留執行個體定價），以節省成本。這樣做，他們最終會自我管理資料庫叢集，這可能會很乏味。

使用對象存儲實作Kubernetes持久性非常流行。但是，使用對象存儲也會使應用程式本身的可移植性降低，因為用于通路公共雲中原生對象存儲服務的API不相容，因為不支援相同的API。K8s社群正在開發一個新的标準容器對象存儲接口（COSI），為使用K8s應用程式的對象存儲提供公共抽象層，這将讓使用對象存儲的K8s應用程式的可移植性更容易。此外，對象存儲不适用于許多現有應用程式，即使它們正在重構。

這對企業意味着什麼？