規模化執行容器時的最佳資料儲存路徑

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驅動器聚集在一個虛擬卷中，呈現給執行應用程式的容器。

通往成功的最佳資料路徑

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