K8s和其他容器編排平臺正在迅速下沉到主流的基礎設置中，對于大多數面向業務的應用，從傳統的數據中心遷移到容器部署還算獨立和簡單。然而，當遇到需要像數據庫或快速數據分析工作負載這樣要求更高的核心應用時，事情不那么簡單了。

首先，應用容器化對底層基礎設施提出了更高的要求，包括網絡、存儲和容錯。雖然K8s在這些方面取得了很大的進步，但無論是在本地還是云場景中運行，應用仍然會出現性能下降的問題。其次，即使是中等規模的應用，K8s網絡也不能為其提供低且可預測的延遲。

我們認為一個平穩運行的IT系統所需的CPU、帶寬和存儲容量，對于優化部署很重要。所以，了解數據在系統中的路徑，可以揭示出低于預期性能的潛在來源及其解決方案。

為容器化工作負載提供存儲的三種方法

私有云和并置設備/存儲集群

雖然本地存儲通常是功能最豐富、拓展最便捷的方式的存儲方式，但在容器原生的部署下可能就不那么完美了。在這些本地實例中，存儲與K8s系統并行存在，K8s通過一個容器存儲接口(CSI)插件將應用與存儲連接起來，其工作原理是將應用程序容器直接連接到外部存儲，完全繞過K8s控制的網絡。

容器存儲軟件

以容器形式誕生并使用容器實施的解決方案，具有專為容器而生的優勢。這些產品采取了 "功能優先 "的方法，這有助于確保IT團隊保留精簡配置和重復數據刪除等功能。然而，無論是在規模上還是在生產中，性能再次取決于數據路徑。這些解決方案通過存儲控制器提供對存儲設備的訪問，而存儲控制器本身是作為容器實現的，所以整個數據路徑都要經過K8s網絡，影響延遲。

在K8s中原生運行的軟件定義存儲

市場上有一些純軟件定義的存儲選擇，其中只有少數幾個在K8s中原生運行。其中包括獨立的裸機軟件定義存儲產品，這些產品被移植到K8s中使用，也支持私有云和混合云部署。

K8s中原有的軟件定義存儲利用上述兩種方法的優點來實現最佳性能以和擴展。它是容器原生的，根據實現方式，有些將數據路徑與K8s隔離，因此性能比僅容器存儲軟件方法中的CSP更好。

這使數據中心架構師能夠獲得最好的傳統本地架構和僅容器存儲的最佳效果。為了確保延遲可預測性，數據路徑在K8s之下——在容器和NVMe SSD之間——從內核移動到客戶端設備驅動程序，再到目標驅動，然后直接訪問NVMe驅動。

用這種方式，客戶端是完全獨立的，不需要跨客戶端通信就可以直接與目標通信。這種方式，減少了網絡跳躍點數量和通信線路的數量，使得該模式可以用于大規模環境，其中連接的數量是域大小的小倍數。

Elasticsearch 應用程序

幾個允許系統在K8s中原生運行的用例，展示了軟件定義的方法的好處。例如歐洲、中東和非洲地區的一家主要電信供應商為大型K8s中的Elasticsearch試用了三種存儲方法。外部的、基于iSCSI的SDS是可擴展的，但延遲在毫秒級，導致索引性能更差，而K8s原生的存儲解決方案則無法滿足數百個節點的規模要求。這兩種方法都導致了最終用戶的體驗明顯變差。第三種方法是基于NVMe的可擴展SDS，使用嵌入K8s節點的NVMe驅動器，結合原生集成到 K8s 控制和管理平面，實現了顯著更好的性能和延遲。

K8s的 NVMe 原生共享存儲的系統架構，具有裸機性能

CI/CD 應用

在另一個例子中，一家頂級網絡公司在一個擁有數萬個節點的數據中心的CI/CD應用程序中，在K8s中原生運行了一個SDS，為編譯、構建和本地測試提供一個強大的控制環境。圖1顯示了SDS的基于NVMe 的客戶端和橫向擴展架構是如何實現CI/CD工作負載向K8s的過渡，同時保留了裸機性能。

當在K8s下運行時，該方法用特權容器控制客戶端和目標設備驅動程序的部署，使數據路徑不受K8s環境的容器化性質的影響，并將所有控制和管理平面組件轉移到基于原生容器API的操作。在這家頂級網絡公司的生產環境中，應用程序性能比裸機情況高15%-20%，因為存儲軟件將多個遠程NVMe驅動器聚集在一個虛擬卷中，呈現給運行應用程序的容器。

通往成功的優秀數據路徑

尋找合適的存儲來滿足應用程序對可擴展性和性能的需求并不是一個放之四海而皆準的方法。當存儲架構師通過了解數據路徑的含義，為容器選擇存儲時，能夠在容器化混合部署中讓應用更加流暢，獲得可擴展、高性能、敏捷的存儲。