Kubernetes的采用正在呈現爆炸式增長，撇開炒作的話題，Kubernetes仍然處于非常的發展階段，而且還有很長的路要走，它極有可能成為大多數IT基礎架構的組成部分。

與此同時，即使不是大多數企業和IT商店，當他們進入Kubernetes領域時，也只是想要探索Kubernrtes這個神奇的新領域。在開發人員開始在平臺上開展工作之前， 管理員、運營團隊或DevOps必須奠定基礎，將傳統而重要的數據管理組件添加到混合組件中：持久性存儲是Kubernetes部署中必要組件的一個很好的示例，但它并不容易實現。

將持久添加到無狀態

企業應該具備的關鍵需求是開發人員能夠將數據存儲在Kubernetes集群中，而無需擔心持久存儲在底層如何工作。

“應用程序開發人員和DevOps團隊不是數據管理人員。就像我不希望我的DBA去玩應用程序開發人員一樣，我真的不希望我的應用程序開發人員在玩DBA。”企業管理協會(EMA)的分析師John L. Myers說。 “我想給應用程序開發人員提供通過API訪問持久數據管理層的機會，或者每次部署集裝箱化應用程序時都不必從頭創建一個。”

但是，Kubernetes的結構使其不適合部署在有狀態的卷上。

Constellation Research分析師Holger Mueller表示：“容器從來沒有被設計成持久的，但企業需要持久的改變負載，保持狀態，為不同的負載使用更多的硬件等。這是企業界容器設計的缺陷，因為對企業來說，所有重要的一切都需要持久。”

不過，Kubernetes提供了多種選項來設置持久性存儲。例如，Kubernetes提供了一種方法，可以在安裝到容器編排平臺的卷上靜態和動態地提供數據，MapR產品管理總監Suzy Visvanathan說：“這為用戶在需要時消費存儲提供了靈活性。”

然而，Kubernetes提供的靈活卷插件使得外部供應商可以與Kubernetes集成，但也有它的問題。 Visvanathan說，在引入容器存儲接口(CSI)模型之前，問題就是插件依賴性。使用Apache Mesos，Red Hat，OpenShift，Docker和云解決方案(例如Kubernetes的Amazon Elastic Container Service(EKS)和Google Kubernetes Engine(GKE))，業務流程層顯在的與Kubernetes內部集成。

Visvanathan說：“CSI模式在使外部存儲解決方案與Kubernetes集成方面變得更加容易。”

擴展

許多企業總是尋求擴展Kubernetes以容納大量的共享容器資源的用戶。但是，如何擴展持久存儲組件是一大挑戰。例如，傳統存儲解決方案及其配置不一定是最合適的。

“Kubernetes可以輕松快速地擴大生產中的容器規模。接下來的挑戰是提供一個與之一起擴展的數據平臺”MapR的Visvanathan說。“傳統的存儲選項根本無法跟上這一規模。在Kubernetes改造舊式安全措施，進一步惡化了這種狀況”

MapR的Visvanathan指出：“新的持久性存儲替代方案通常是單節點解決方案，如果集群化，仍然不能提供全球可尋址名稱空間或混合/多云移動性。”

“Kubernetes被用于云式彈性和選擇您選擇的云模型的能力，包括內部部署，混合或多云部署。”Visvanathan說。 “持久存儲需要實現相同的目標。”

“與此同時，在具有內部存儲的服務器上部署容器可以使擴展更直接”，Diamanti產品營銷總監Sean Roth說。

“擴大存儲空間可能會造成破壞性，并可能導致巨大且往往意料之外的額外開支，”Roth表示。 “Kubernetes持久存儲的主要挑戰主要源于縮放。對容器存儲基礎設施采取自己動手的做法可能會造成破壞性和造成昂貴的成本。“

最終，企業需要在越來越多的服務器之間平衡存儲使用。 Roth表示，跨Kubernetes部署共享存儲的可用資源可以由網絡文件系統(NFS)或開源集群文件系統協議(如Ceph或GlusterFS)組成。

卷集成 

盡管存在上述挑戰，但Kubernetes確實提供了廣泛的存儲集成量選項，也在不斷地改進。例如，Kubernetes提供了一種在靜態和動態調用Kubernetes上的數據時提供數據的方法，Visvanathan說。“這為用戶在需要時消費存儲提供了靈活性。”

事實上，Kubernetes的卷存儲驅動程序選項可以促進持久存儲的多種不同機制的使用，CloudPassage的策略工程專家Ash Wilson說，增加一些卷驅動程序是IaaS(基礎架構即服務)平臺特定的，而有些開發者不了解底層的云基礎架構。

“這些卷存儲驅動程序選項非常好，但是正確評估和確定哪些最符合應用程序需求花費很長的時間。”Wilson說。 “與保護Kubernetes中的永久存儲相關的任務通常是特定于驅動器的特定驅動程序，因此在架構過程中必須考慮安全問題。”

裸機服務器部署

MapR的Visvanathan認為，“Kubernetes虛擬化結構在建立持久性存儲時也非常適合裸機服務器部署。這是因為容器虛擬化操作系統，不是虛擬化操作系統下的硬件”。

Visvanathan說：“集裝箱就其本質而言是部署裸機應用的理想方式，而Kubernetes則簡化了集裝箱的創建和管理。” “這是概念的自然延伸，Kubernetes的持久存儲也是裸機上的最佳服務。一旦容器彈性化，虛擬化服務器不會提供任何額外的好處，因此，它們只是一個附加層，沒有附加價值。”

安全考慮

“在確定ubernetes中運行的應用程序的用戶訪問權限時，一大障礙就是Kubernetes工作負載的動態和無狀態特性。事實上，Kubernetes存儲的主要安全問題是維護訪問控制和授權特權，以確保只有相關的容器和服務才能訪問敏感數據。”Aqua Security營銷副總裁Rani Osnat說。

Osnat說：“有幾種方法可以實現這一目標，但它們必須與具有應用上下文和與特定服務關聯的安全策略綁定在一起。”

提供用于保護Kubernetes持久性存儲的安全工具也應該繼續發展。換句話說，一切都需要及時改善。

“短期工作負載可能會在捕獲適當的安全信息方面面臨挑戰，尤其是出于審計和合規目的。 這個問題的解決可能需要借助于工具的演變，而不是放慢敏捷過程，”CloudPassage的Wilson說。 “跟蹤、審計和保護存儲機制存在類似的問題 ----工具必須發展以滿足安全需求，而不應該減慢應用交付流程。”

譯者介紹：

劉志紅，17年IT從業經驗。曾在NTT DATA，Oracle，中鈔造幣集團，中國電信云計算分公司從事云計算等關聯IT研發工作。獨立擁有軟件著作權1件。目前就職于電子工業出版社。